PIII700/1G/18G
VxWorksX
无
Xx
PIII700/1G/18G
VxWorksX
无
Xx
PIII700/1G/18G
WindowsNT4Server
Oracle8i
xxServer
SPARC/1G/18G
SUNSolarisX
Oracle8i
xxServer
SPARC/1G/18G
SUNSolarisX
Oracle8i>
具体需求
<本章具体描述以下需求：
功能需求、性能需求、质量属性需求、外部接口需求、其它需求（如标准化相关需求、国际化需求等）。
可以采用分组描述（即“父-子需求描述”）的方式描述需求。
由于只有叶节点需求才是重要的，因此，组需求或父需求可以只有名称而没有标识及其它内容（如需求描述、优先级等）。
叶结点需求应该在产品范围内唯一标识。
一般采用分级的标识方式，具体规则为：
SR-X-YYYYY-nnnn。
a）半角大写的“SR”为前缀（SR代表软件需求），半角减号“-”为连接符。
nnnn为流水号，具体位数不统一规定，但对于某篇具体的SRS，应为固定值（如固定为4位）。
XXXXX为0到多种分类符（各分类符间以连接符连接）。
如果不存在分类符，则标识规则为：
SR-X-nnnn。
X为需求种类标识符，可取F（功能）、P（性能）、Q（质量属性）、I（外部接口）、M（其它需求，如执行标准、设计和实现上的限制、国际化需求等）。
b）需求标识中的流水号不要求连续、顺序。
但为了方便读者阅读，从前到后应尽可能地顺序编号。
c）需求标识中的流水号的最后一位应尽可能为“0”，这样可方便产生新的、顺序的需求标识，以方便读者阅读。
如，已有两个需求标识：
SR-F-0010、SR-F-0020，插入新的相关的功能需求时，其标识可以为SR-F-0015。
d）文档基线化后，不允许修改其中使用到的需求标识。
在具体描述需求时，还应注意以下问题：
a）如果项目被要求编写数据字典，则应在项目的早期（如项目论证阶段）就应编写数据字典，以定义相关的数据元素和结构（如输入、输出、存储或数据表字段等，一般与功能、内外部接口等相关）的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围。
需求描述中的输入项可以直接引用数据字典的数据项。
数据字典应独立维护。
b）无论是需求标识还是需求内部描述的步骤号，都应手工编号，而不要使用编辑器的自动编号。
因为如果采用自动编号，一旦增加或删除中间的某个编号，将会引起其后所有需求的RP记录的变更，并影响处理过程中的引用关系。
c）需求优先级的设置应基于上游文档（如《用户需求说明书》、《用户需求论证说明》、系统方案）中相关内容的优先级，一般应不比上游的低。
一般情况下，不在本文档中描述需求的实现版本的信息。
最佳的体现需求实现的版本信息的地方有两处：
一是项目计划；二是需求追踪工具RP中的需求属性：
实现版本。
>
功能需求
<功能需求表示了产品的行为，或期望产品能够完成的工作。
这些需求通常是面向动作的，需要重点描述产品与外界的交互。
凡是功能需求，都是可以通过“激励、响应”模型（对应于usecase描述方式）或“输入、处理、输出”模型（对应于IPO描述方式）来描述的。
反之，如果某条需求不能通过这两个模型描述出来，则这条需求不可能是功能需求。
需要强调的是：
a）外部接口相关的功能应在此处描述（而不是在“4.4外部接口需求”中描述）。
b）应确认是否有某些容易被忽略的功能，如环境监控相关的（如温度、湿度、烟雾等）、透明传输相关的功能。
应逐一描述每一个具体的功能需求，包括需求标识、需求名称、需求描述、优先级、使用频度等。
可以采用usecase、IPO（输入/处理/输出）、规范化的模型或其它适当的方式进行描述。
规范化的模型，包括实体-关系图、状态转换图、数据流图、对话图等。
本模板要求优先使用usecase文本描述方式，在特殊情况下才可使用IPO等其它方法（如，对于平台类API需求，如果处理流程是顺序的，则使用IPO方法比较有效）。
由于不同的功能需求可能有不同的性能、质量属性等需求，为了避免冗余及阅读方便，在描述功能需求时可在“特殊需求”一栏中同时描述其独有的性能、质量属性等需求。
4.1.1描述了usecase的使用。
4.1.2描述了IPO的使用。
为了能唯一标识、并进而引用功能需求描述中的各子项，我们进行了如表4.1所示的定义。
表4.1
序号
功能需求
描述子项
前缀
编号及格式说明
示例
1
前置条件
C
a）使用缩进两格的正文。
b）行首应加编号及两个空格，编号以大写的C（代表条件）引导，编号的位数应相等（即不允许出现C90，C100，可为C0090，C0100），如只有一个条件，也应编号，且应换一行开始条件的描述。
由于不是一般的“列项”，因此无须遵守“凡是列项都应连续编号且对齐”的标准化要求。
建议：
编号以0结尾（如C0090，C0100），这样可方便在C0090后插入C0095。
为了方便，建议编号统一使用5位。
c）前置条件的引用规则：
需求标识+“.”+前置条件编号
C0050XXXX
引用某个前置条件的例子：
SR-F-0010.C0050
2
后置条件
R
格式同上。
编号的前缀为大写的R（代表结果）
3
触发条件
T
格式同上。
编号的前缀为大写的T（代表触发）
4
正常过程
N
a）接着“正常过程：
”后描述正常过程编号，编号以大写的N（代表正常）引导。
一般只有一个正常过程。
b）过程编号的引用规则：
需求标识+“.”+正常过程编号
正常过程：
N1XX
引用正常过程的例子：
SR-F-0010.N1
5
正常过程步骤
N
a）格式同“前置条件”。
编号的前缀为大写的N
b）正常过程、可选过程、异常过程的步骤可以放在一起编号，如N01、A02、E03，也可以独立编号。
c）正常过程步骤的引用规则：
需求标识+“.”+正常过程编号+“.”+正常过程步骤编号
N0010XXXX
引用正常过程步骤的例子：
SR-F-0010.N1.
N0010
6
可选过程
A
a）接着“可选过程：
”后描述可选过程编号，空两格后描述可选过程名称。
编号以大写的A（代表可选）引导，编号的位数可以等于最大位数+1，不足用0补齐
b）过程编号的引用规则：
需求标识+“.”+正常过程编号
可选过程：
A1XX
引用可选过程的例子：
SR-F-0010.A1
7
可选过程步骤
A
格式同“正常过程步骤”。
编号的前缀为大写的A
A0050XXXX
引用可选过程步骤的例子：
SR-F-0010.A1.
A0050
8
异常过程
E
格式同“可选过程”。
编号的前缀为大写的E
9
异常过程步骤
E
格式同“可选过程步骤”。
编号的前缀为大写的E
10
特殊需求
S
格式同“前置条件”。
编号的前缀为大写的S（代表特殊）
11
输入
I
格式同“前置条件”。
编号的前缀为大写的I（代表输入）
12
输出
O
格式同“前置条件”。
编号的前缀为大写的O（代表输出）
13
处理
P
格式同“前置条件”。
编号的前缀为大写的P（代表处理）
>
<需求组1标识+两个空格+需求组1名称>
<需求组标识不是必须的，可以只有“需求组名称”。
当然，如果有需求组标识则更好，可以从需求标识判断是否是叶节点需求，方便进行需求追踪。
>
<需求组1标识-01+两个空格+需求组1的第1条子需求名称>
<需求名称应当使用确定性的语句，建议采用动宾结构（如“建立小区”，而不是“小区建立”），应尽可能简短，使得标题能够写在一行。
>
需求描述：
<对需求的正常过程、可选过程进行概述，以方便那些不需要知道需求细节的读者。
格式：
直接接在“需求描述：
”后写。
>
执行者：
<又叫“参与者”、“角色”。
执行者是指同产品交互的所有事物，包括产品的用户、与产品拥有物理或逻辑连接的其它系统、外部事件（如满足特定日期或时间、满足特殊环境条件如涨潮/落潮、峰谷/峰顶等）。
描述执行者时，应注意：
a）执行者一定存在于产品的外部，不可能是产品本身，但可能是产品的一个实例，如控制RNC。
b）执行者一定要在后续的过程描述中出现，否则，要么是此处多写了，要么是过程描述少写了。
实践中，后者占绝大部分：
活动描述中经常只出现“系统”，而没有任何执行者。
没有执行者，怎么能体现“交互”呢？
格式：
直接接在“执行者：
”后写。
>
优先级：
<5、4、3、2、1。
具体取值依据请见本模板1.3。
格式：
直接接在“优先级：
”后写。
>
使用频度：
<可根据项目的实际情况取值，如“经常”、“偶尔”、“不关心”或“高”、“中”、“低”、“不关心”等。
一般应在1.3中统一定义。
格式：
直接接在“使用频度”后写。
>
前置条件：
<只有具备该条件（即前置条件应为真）才可执行该功能，即必要条件。
描述前置条件时，应注意以下问题：
a）一般由其它产品或其它需求负责设置前置条件。
b）不能将触发条件当成前置条件。
如“收到XX消息”，正确的前置条件可能是“XX与系统间已经建立XX链路”。
c）不能将应在异常过程中捕获的条件作为前置条件。
如“通信正常”，由于前置条件是必须为真的，因此在实现时无需验证，而“通信正常”则是谁也不能保证的，在实现时需要采用某种机制保证。
格式：
如无需填写，则直接接在“前置条件：
”后写“无”；否则应换行，按正文格式（即行首空两格，换行后顶格）：
前置条件编号+两个空格+具体的前置条件。
对于“无”的编写要求，同样适用于“后置条件”、“可选过程”、“异常过程”、“特殊需求”。
>
后置条件：
<描述用例执行后状态的改变、输出等。
又叫“请求结果”、“最小保证及成功保证”。
一般只包括正常过程、可选过程的结果，异常过程的结果在异常过程中描述。
通过前置、后置条件可以将功能需求有机地联系起来：
某个功能需求的前置条件是由另一个功能需求通过其后置条件设置的。
事实上，我们在开发用例时，经常可以从某些基本的、常见的功能需求的前置条件中发现更多的用例。
描述后置条件时，应注意以下问题：
a）正确理解“状态的改变”、“输出”。
如，“XX与YY间建立了ZZ链路”（注意：
不要画蛇添足地加上“建立了正确的ZZ链路”，因为这样一来，就需要定义“正确”）、“文件被保存”、“系统为客户创建了一个订单，收到付款信息，并将订单请求记入日志”。
b）后置条件一般不为空，因为系统总得处于某个状态。
但如果用例执行前后，系统状态没有变化，则可以没有后置条件。
格式：
“后置条件：
”后换行，按正文格式（即行首空两格，换行后顶格书写）：
后置条件编号+两个空格+具体的后置条件。
>
正常过程：
<当一切运转正常时就得到了正常过程。
没有故障、没有错误。
每一个用例都必须有一个正常过程。
格式为：
正常过程编号+两个空格+正常过程名称。
如果只有一个正常过程，其名称可以省略。
描述正常过程时，应注意以下问题：
a）正常过程步骤的第一步，通常是描述用例由于“触发条件”被触发而执行，如“XX（指执行者）收到XX消息，用例开始”。
b）正常过程的最后一步，通常为“用例结束”。
c）过程描述中应出现“执行者”中所列的所有的执行者，否则，要么是本处写错了，要么是“执行者”处少写了。
后者占绝大多数。
d）不要将一个以上的活动放在一个步骤中描述。
如“系统收到XX消息，并检查其是否合法”。
应拆成两个步骤：
N0020系统收到XX消息。
XX见《YY数据字典》中的同名数据。
N0030系统确认XX消息是合法的。
e）不应该使用“如果...那么...否则”一类的句式。
要记住，正常过程是没有必要处理分支、异常的！
用户输入数据后，一般应检查其合法性。
关于合法性，正确的描述为：
“N0030系统确认数据是合法的。
”，这样N0040就很自然地沿着正确的路径往下走了。
正常过程步骤的格式为：
正常过程步骤编号+两个空格+正常过程步骤描述。
>
可选过程：
<可选过程也可促进功能的成功完成，但它们代表了功能的细节或用于完成功能的途径的变化部分。
一个用例有0到多个可选过程。
格式为：
可选过程编号+两个空格+可选过程名称（XXXX<指正常过程步骤编号>后的分支）。
如，“A1处理网上支付（N1.0070之后）。
”
描述可选过程步骤时，应注意以下问题：
a）可选过程的第一步，一般应描述具体的分支条件。
可以采用类似的句式：
“A0010在N1.0070处，如果客户使用网上支付支付货款，则进行以下处理。
”
b）可选过程结束后，一般应回到正常过程的下一步继续执行，但这也不是绝对的，可视情回到正常过程的合适的地方继续执行。
应显式说明这一点。
如：
“A0080回到N1.0080处继续执行。
”
c）为了避免阅读困难，在可选过程中可以直接处理条件判断，而无需再编写独立的可选过程。
d）可选过程中的异常，应放在用例的异常过程中统一描述。
可选过程步骤的格式为：
可选过程步骤编号+两个空格+可选过程步骤描述。
>
异常过程：
<描述引起功能不能顺利完成的情况。
正常过程、可选过程都会引起异常。
一个用例有0到多个异常过程。
格式为：
异常过程编号+两个空格+异常过程名称（XXXX<指正常/可选过程步骤编号>后的分支）。
如，“E1处理客户输入非法数据。
”
描述可选过程步骤时，应注意以下问题：
a）异常过程的第一步，一般应描述此异常过程对应的出错条件。
可以采用类似的句式：
“在N1.0030处，如果客户输入的数据是非法的，则进行以下处理。
”
b）异常过程一般会结束整个用例的执行，但这也不是绝对的，可视情回到正常过程、可选过程的合适的地方继续执行。
应显式说明这一点。
如：
“E0050回到N1.0080处继续执行。
”
c）为了避免阅读困难，在异常过程中可以直接处理可选和异常，而无需再编写独立的可选或异常过程。
异常过程步骤的格式为：
异常过程步骤编号+两个空格+异常过程步骤描述。
>
特殊需求：
<描述不可见的、或很难在用例中表示的需求，如性能需求、质量属性需求等。
格式：
如无需填写，则直接接在“特殊需求：
”后写“无”；否则应换行，按正文格式（即行首空两格，换行后顶格）：
特殊需求标识+两个空格+特殊需求名称。
>
<说明：
这里列出的仅是最小要求，模板使用者可以根据实际需要进行扩充。
另外，尽管没有强调，usecase图、合并描述正常、可选、异常过程的流程图也是十分鼓励使用的。
>
<需求组1标识-02+两个空格+需求组1的第2条子需求名称>
<具体要求与格式同4.1.1.1。
>
<需求编号2+两个空格+需求名称2（IPO例）>
需求描述：
<需求详细描述。
格式：
直接接在“需求描述：
”后写>
优
升级会员 