需求开发指南.docx
《需求开发指南.docx》由会员分享，可在线阅读，更多相关《需求开发指南.docx（25页珍藏版）》请在冰豆网上搜索。
需求开发指南
需求开发指南
公司
拟制：
文档编号：
XXX_需求开发指南
审核：
批准：
版本号：
生效日期：
机密等级：
内部公开
修改记录
修订号
作者
日期
简要说明
1简介
1.1目的
介绍需求开发顶用到的方式，供项目组在需求开发中学习利用。
1.2适用范围
适用于公司软件开发人员、需求开发工程师。
1.3术语表
请参见《CMMI术语表》。
2确信系统边界
2.1目的
Ø将项目的参与者定位到一个一起的和明确的方向上。
Ø确信系统中有什么（必需为创建他们投入大量精力），系统外有什么（不需要创建，可是必需考虑与它们的接口）。
Ø估量项目规模，概念要创建系统的哪些部份（在一按时刻段和必然预算的基础上）。
2.2确信执行者
咱们将采纳用例分析技术，通过确信执行者和用例来确信系统边界。
在一些参考资料中，咱们会常常看到“外部实体”那个术语，咱们以为外部实体和执行者具有一样的含义。
执行者是同系统交互的事物，包括人、其它软件、硬件设备、数据存储或网络。
每一个执行者概念一种特定的角色，每一个系统之外的实体能够用一个或多个执行者来代表。
执行者老是在系统之外，不是系统的一部份。
提出以下问题会帮忙分析员确信执行者：
Ø谁利用那个系统？
Ø谁安装那个系统？
Ø谁启动系统？
Ø谁保护系统？
Ø谁关闭系统？
Ø哪些其它的系统利用那个系统？
Ø谁从那个系统获取信息？
Ø谁为那个系统提供信息？
Ø是不是有情形自动在估量的时刻发生？
2.3确信誉例
用例是系统的一种行为，它为执行者产生一种能够估量的价值结果，它描述执行者想要系统完成的情形。
从执行者的角度看，用例应该是一个完整的任务，一个用例行为常常是在一个相对较短的时刻段内完成。
若是用例的各部份被分在不同的时刻段，尤其是被不同的执行者执行时，最好仍是将各部份作为单独的用例对待。
用例通常由执行者启动，因此咱们能够从执行者角度动身，判定有哪些用例。
考虑以下问题：
Ø执行者希望系统提供什么样的功能？
Ø系统存储信息吗？
执行者将要创建、读取、更新或删除什么信息？
Ø系统是不是需要把自身内部状态的转变通知给执行者？
Ø系统必需明白哪些外部的事件？
执行者将如何通知系统这些事件？
Ø如何修复系统？
是不是需要把系统关闭或在系统运行的情形下进行系统保护？
2.4描述执行者和用例
用一个名字和简单的话描述每一个执行者和用例。
建议采纳“执行者列表”和“用例表”别离描述执行者和用例。
表1执行者列表
执行者名称
执行者描述
客户代表
ABC公司处理客户请求的雇员
客户
从ABC公司订购商品的人
表2用例表
用例
触发器
来源
动作
响应
目的地
客户发送订单
新订单
客户
生成新订单
实时连接
信用卡部门
订单确认
客户
订单细节
发货部门
交易处理
银行
Ø用例：
引发系统去执行某种操作的情形；
Ø触发器：
系统如何明白那个用例发生了？
或是进入系统的数据，或是概念好的时刻点。
Ø来源：
执行者；
Ø动作：
当用例发生时，系统做了什么操作？
Ø响应：
系统产生了什么样的输出结果（若是有的话）？
Ø目的地：
哪个执行者取得了产生的输出结果？
第一，对每一个用例来讲，系统怎么明白某一事件发生了呢？
用来通知系统某一事件发生了的事物称为触发器。
关于一个外部事件，触发器确实是系统必需处置的数据抵达了。
关于临时事件，触发器是某一个时刻点。
第二，当用例发生时，系统该做些什么呢？
系统对用例的响应称为动作。
最后，动作致使系统产生什么响应呢？
响应是系统的输出结果。
一个动作通常会有多个响应。
目的地确实是系统发送响应的地址，也确实是执行者。
注意，有些时候不需要系统响应。
2.5处置时刻
在用例中要紧用两种方式来处置时刻。
一个方式是把时刻看成一个执行者，然后由时刻执行者启动用例。
第二种方式是把它看成系统的一部份，用例在某个时刻自己启动。
2.6潜在的边界问题
若是某些需求需要一个执行者来处置，可是那个执行者又超出了已经确信的执行者的范围，如何办？
需要确信那个执行者是不是真的是系统的一部份。
若是不是，那么需求也就不能成为系统的一部份；若是是，那么看一看对它的描述，可能需要从头概念执行者或它的角色以使系统边界清楚。
若是执行者变成系统的一部份，可能需要从头概念用例。
当你发觉新的需求时，应该考虑的一些问题如下：
Ø这些需求是不是对系统是必需的？
Ø这些需求是系统在逻辑上能够完成的吗？
Ø新的需求将如何阻碍咱们目前的风险分析？
Ø这些需求是不是能够被系统目前的执行者处置？
Ø这些需求是客户希望系统去做的吗？
Ø这些需求会使产品在市场上变得不同凡响吗？
2.7确信项目范围
确信了系统的边界以后，需要为系统确信一个范围。
一个项目有特定的开始和终止的时刻，用于完成项目目标的资金也有必然的限制。
因此，必然要清楚地概念系统将要包括和不包括的成份。
利用需求优先级的方式确信系统必需包括的情形，并确信没有必要的情形确实被放在了一边。
成立了用例表以后，系统分析员能够和用户进一步沟通协商，也能够召开联系会议，确信列表中的用例哪些是在项目范围之内的，哪些是项目范围之外的。
考虑以下问题有助于确信下面的范围：
Ø是不是能够应付得了把这些需求添加到打算和预算上去？
Ø是不是应该再有一个后期的版本？
Ø若是咱们不能不此刻考虑这些，是不是能够把其它需求移到后期版本？
2.8边界和范围的图形化
利用用例图，描述项目的边界和范围。
能够用Visio画用例图。
下面是用例图用到的图形符号。
图1用例的图形符号
下面是一个“定单处置系统”的边界和范围图，本文后续的部份，都将以“定单处置系统”为例子。
图2定单处置系统用例图
需要注意的是，万万不要以为有了用例图，就能够够不写文档了。
事实上，图形仅仅是更直观地表现用户需求的一种方式，文字描述仍是必不可少的。
咱们建议采纳的文字描述方式仍是上文提到的“用例列表”。
3编写大体用例
3.1大体用例
每一个用例必需包括一些细节，这些细节告知咱们需要完成哪些步骤才能实现那个用例的功能。
咱们需要考虑大体功能、所有可选方案、异样情形，进入用例之前和退出用例时必需正确的因素。
用例能够包括条件、分支和循环。
此刻让咱们看一个可能的用例例子：
定单处置系统。
表3定单处置系统的用例
进入标准：
一个合法的用户已经登录到这个系统；
事件流：
1.当客户选择订购货物时，用例开始；
2.客户输入他的姓名和地址；
3.如果客户只输入邮编，系统将给出城市名；
4.客户输入想购买产品的代码；
5.系统为每一项给出产品描述和价格；
6.系统保存连续的已经订购的产品清单；
7.客户输入信用卡支付信息；
8.客户选择submit；
9.系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统转发支付信息。
如果客户提交的信息不正确，系统将提示客户修改；
10.当支付确认后，订单就被标记上已经确认，同时返回给用户一个订单ID，用例结束。
如果支付没有被确认，系统将提示客户改正支付信息或者取消。
如果客户选择修改信息，就回到第7步；如果选择取消，用例结束。
退出标准：
如果订单没有被取消，它将被保存在系统里，并做上标记。
3.1.1进入与退出标准
进入与退出标准表示用例开始和终止时会发生什么，即在用例开始时系统必需处在什么状态，用例终止时系统必需处在什么状态。
不管紧随用例以后是哪个分支或选择，退出标准都必需为真。
3.1.2事件流
从执行者的角度看，事件流是一系列陈述句，它列出了用例的各个步骤：
告知咱们它如何开始，利用一个像“当……时用例开始”的描述。
用例是为软件做的，软件如何明白何时用例开始？
一样地，用例如何终止？
能够利用如“用例终止”的短语清楚地陈述它。
利用分支能够表示选择。
为了表示分支，咱们能够利用一个if语句。
当需要重复一个或一系列步骤时，能够利用循环。
要清楚地指出循环在哪儿开始和在哪儿终止，还要清楚地指出如何终止。
咱们能够利用for语句或while语句来表示循环。
3.2大体用例的评审
用例的编写进程中需要进行多次评审，大体用例终止以后，是最正确的评审时刻。
咱们给出第一次评审用例的大体原那么。
Ø用例的每一步都应该是一个简单的陈述句，缺省时这些步骤按时刻顺序执行。
若是这些步骤能够按任何顺序发生，需要清楚地描述。
Ø幸免试图做得太细，咱们将随着时刻的推动添加更多的细节，可是这一时期，咱们是在搜集需求，而不是详细分析或设计。
另一方面，用例还要完整，开始和终止时都必需超级清楚，确保这一系列的步骤大体上包括了完成用例功能所需要的一切。
Ø用例是一个转达工具，只有它们向读者转达关于系统如何工作的信息时才有效。
因此考虑谁会阅读用例是很重要的，是最终用户、市场专家、开发人员仍是治理人员？
不管是谁，他们必需能够明白得用例。
若是他们不能明白得用例，那个用例就需要改写了。
Ø不要担忧如何才能利用例完美，那个进程的特点确实是不断反复。
要持续查看已经完成的工作，而且精简它，以反映了解到的情形。
用例质量会随着分析员对系统了解的深切而提高。
Ø必需在用例中包括足够的信息，以判定是不是用了特定的用例处置了特定的功能。
3.3表示形式
能够超级正式地或较自由地表示用例，但要清楚用例的读者，从而选择一个易于被读者同意的形式。
咱们推荐了两种形式，项目领导能够从当选择。
一种是用编号序列来表示用例（表4），另一种是用表格形式表示（表5）。
表4取消定单用例的编号序列表示
1.当客户收到取消订单的请求时，用例开始；
2.客户代表输入一个订单ID；
3.客户代表按下“查找”；
4.系统显示这个订单的内容；
5.客户代表选择取消；
6.系统将该订单做上取消标志；
7.记账系统收到向客户账号中加钱的通知，用例结束。
表5取消定单用例的表格形式
客户代表
系统
记账系统
1.接收到一个取消订单的请求
2.输入一个订单ID；
3.按下“查找”
5.选择取消
4.显示订单内容
6.给该订单打上取消标志
7.向客户账号中加钱
3.4其他需求
分析员编写用例的时候，可能会发觉一些需求对执行者并非可见，或有一些特殊的需求很难在用例中表示。
这些需求需要和用例一路记录下来，它们一样是系统的一个组成部份。
当构建和测试系统时，必需将它们考虑进去。
你能够将它们归到其他的需求文档，这些文档和用例文档编排在一路。
有时这些需求是非功能性的需求，如可用性、平安性、稳固性、可保护性等方面的内容。
若是需求是针对一个特殊的用例，能够在用例描述中添加一个专门的需求部份：
“特殊需求”。
其他文档常常是伴随用例开发出来的，这些文档包括一个术语表、一个数据概念文档和用户接口的指导原那么。
还需要一个文档，它列出了需要解决的重要问题。
到目前为止，咱们已经确信了用例的大体途径。
可是一个完整的用例描述可能相当复杂，并非像最开始时所写的那样，它会随着时刻的推移不断进展。
3.5大体途径
用例的大体事件流确信了以后，还要考虑所有可能的犯错条件。
一个完整的用例描述可能相当复杂，它是随着时刻的推移不断进展的。
事件流分为两个部份：
大体途径和可选途径。
当一切运转正常时咱们就取得了大体途径。
没有故障、没有错误，是一个完美的境遇。
每一个用例都必需有一个大体途径。
3.6可选途径
大体途径确信了以后，就要扩充可选途径。
一个可选途径指的是不同于大体途径而许诺不同的事件序列的途径。
客户能够从用例的假设干情形中挑选一件情形来做，最可能的选择归入大体途径。
关于明显有可能随时发生的情形来讲，可选途径超级有效。
找出可选途径的方式确实是沿着大体途径一条一条地找，而且考虑：
Ø在那个点上，还能够执行别的活动吗？
Ø在那个点上，有无什么能够犯错的？
Ø有什么随时可能发生的行为吗？
另一种方式确实是用以下典型问题去发觉可选途径：
Ø执行者退出应用程序；
Ø执行者取消指定操作；
Ø执行者请求帮忙；
Ø执行者提供了不正确的数据；
Ø执行者提供了不完整的数据；
Ø执行者提供了一个执行用例的可选方式；
Ø系统崩溃；
Ø系统不可用。
每一个可选途径需要一个名字或一个简单的描述，如表6所示。
表6通过度类订购货物附加的可选项
不完整的数据
没有付费；订单不完整；运送地址不完整
不正确的数据
密码错误、用户名错误、产品代码错误、无效支付。
可选行为
客户通过支票付款、客户通过发邮件或电话订购。
取消操作
客户取消这次订购
系统崩溃
系统在订购过程中崩溃
系统不可用
系统没有响应、客户不能登录、订单丢失
关于每一个大体途径，简单地列出所有你能够想到的可选途径和异样情形。
识别出可选途径和异样后，用新的假设更新假设列表。
这张列表将在评审时提交给由用户、客户、市场人员组成的评委。
3.7文档化可选项
重要而复杂的可选途径还需要一系列步骤去细化它们的行为，能够用写大体途径的方式去写可选途径。
咱们将用订购货物用例大体途径，利用不同的方式调整它，从多方面说明此类技术，而且讨论每种技术的优缺点。
表7原先的订购货物用例
事件流：
基本路径：
1.当客户选择订购货物时用例开始；
2.客户输入他的姓名和地址；
3.当客户输入产品代码
a）系统显示产品描述和价格；
b）系统在该客户的订单中添加这个物品的价格
4.客户输入信用卡支付信息；
5.客户选择submit；
6.系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息；
7.当支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。
第一个技术是直接往用例文本中添加可选项，适本地添加新的标号步骤。
那个技术的优势是能够超级容易地看到用例中可能的行为，缺点是它会致使用例难以明白得和阅读。
添加的内容以蓝色字体表示。
（表7）。
表7添加可选项的订购货物用例
事件流：
基本路径：
1.当客户选择订购货物时用例开始；
2.客户输入他的姓名和地址；
3.如果客户只输入邮编，系统给出城市。
4.客户输入将要订购产品的代码
5.对每个输入的代码
a）如果系统中有该产品代码，系统提供该产品的介绍和价格，并在该客户的订单中添加这个物品的价格。
b）如果系统中没有这个产品代码则打印出错信息，提示客户输入新的产品代码。
6.客户输入信用卡支付信息；
7.客户选择submit；
8.系统核查支付信息。
9.如果所有的信息都正确，用例就从第13步继续执行。
10.如果客户没有输入支付信息，系统提示客户输入支付信息或取消。
11.如果客户选择取消，用例结束；
12.如果客户输入新的支付信息并选择submit，用例从第8步开始重复。
13.系统把该订单作为未完成的交易保存，同时向记账系统提供支付信息；
14.如果记账系统确认支付信息正确，订单被标上已经确认，一个订单ID就返回给客户，用例结束。
15.如果记账系统返回错误，系统就打印出错信息，提示客户输入新的支付信息或者取消；
16.如果客户选择取消，用例结束；
17.如果客户选择输入新的支付信息，用例从第6步开始重复。
第二个技术是在原先的基础上，在段落中增加可选项。
这比前面的例子更易于阅读，而以前的步骤成为那个用例的大体明白得的题目，可选项细节和错误处置成为编号步骤的下级段落。
这种方式不改变原先的步骤编号。
（表8）。
表8在段落中添加可选项的订购货物用例
事件流：
基本路径：
1.当客户选择订购货物时用例开始；
2.客户输入他的姓名和地址；
如果客户只输入邮编，系统提供城市。
3.客户输入产品代码
4.对每个输入的产品代码
a）系统给出该产品的介绍和价格。
如果系统中没有这个产品代码则显示出错信息，提示客户输入新的产品代码。
b）系统在该客户的订单中添加这个物品的价格
若物品未找到，订单保持不变；
循环结束。
5.客户输入信用卡支付信息；
6.客户选择submit；
7.系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息；
如果客户没有输入支付信息，系统将提示客户输入支付信息或取消；如果客户选择取消，用例结束。
入客户输入新的支付信息，客户选择submit，用例从第7步重复。
8.当支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。
如果记账系统返回错误，系统打印出错信息，提示客户输入新的支付信息或者取消。
如果客户选择取消，用例结束。
如果客户选择输入新的支付信息，用例从第5步重复。
第三个技术是把可选项放在用例文档的其他部份，那个部份称为可选途径部份，它紧接着大体途径（表9）。
那个方式的优势是大体途径很容易明白得，同时又有足够的空间来展现可选项的细节。
可是缺点是查找关于每一可选项的所有信息时，必需阅读好几页文档。
表9利用可选途径部份的订购货物用例
事件流：
基本路径：
1.当客户选择订购货物时用例开始；
2.客户输入他的姓名和地址；
3.客户输入产品代码
4.对每个输入的产品代码
c）系统显示产品描述和价格；
d）系统在该客户的订单中添加这个物品的价格
5.客户输入信用卡支付信息；
6.客户选择submit；
7.系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息；
8.当支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。
可选路径：
在第7步，如果有任何不正确的信息，系统提示客户修改这些信息；
在选择submit之前的任何时候，客户可以取消这次订购，用例结束；
在第8步，如果支付没有确认，系统将提示客户去修正支付信息或取消。
如果客户选择修正信息，就回到基本路径的第5步，否则用例结束。
表9中的可选项部份能够用与大体途径相同的方式书写，见表10。
事件流：
基本路径：
1.当客户选择订购货物时用例开始；
2.如果客户只输入邮编，系统提供城市。
3.客户输入他的姓名和地址；
4.客户输入产品代码
5.对每个输入的产品代码
e）系统显示产品描述和价格；
f）系统在该客户的订单中添加这个物品的价格
循环结束。
6.客户输入信用卡支付信息；
7.客户选择submit；
8.系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息；
9.当支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。
可选路径：
可选项1：
不正确的数据
1.如果有任何不正确的信息，可选项就从基本路径的第8步开始；
2.系统提示客户修正错误的信息；
3.基本路径从第8步开始继续执行。
可选项2：
取消
1.在订购货物用例的任何时候，客户都可能选择取消；
2.系统提示客户验证是否取消；
3.客户选择“OK”键，用例结束。
可选途径细化到什么程度？
很多情形下，没必要写下整个的步骤序列，只需要用简练的话描述可选途径引发的变更。
3.8场景
任意一条贯穿用例的特定途径，咱们称为场景。
上述订购货物的用例中，包括的场景有一个正确付款的完整的账单抵达；缺少支付的定单抵达；缺少送货地址的定单抵达。
3.9关联用例和执行者
咱们已经把用例的细节写出来了，明白谁开始用例――执行者，可是咱们尚未考虑如何以图示的形式表示执行者和用例之间的关系。
它们之间的关系是通过通信关联表示的，启动方向是通过在通信关联中添加箭头实现的。
咱们用例子来讲明，见图3和图4。
4高级用例
开发了大体用例以后，系统分析员可能会发觉有必要对大体用例进行优化。
用于优化的技术有包括、扩展、继承和接口。
但是，咱们的目的是制作一个清楚易懂的文档。
因此，关于最终用户，唯一的优化技术是包括（Include）。
其它技术――扩展（Extend）、接口（Interface）和继承（Inheritance）只是开发人员感爱好的，不是最终用户关切的。
4.1包括
若是你发觉自己常常裁剪或粘贴同一部份内容，就意味着你已经有了能够重用的通用部份了，你能够用一种包括关系来抽象这种通用行为。
从概念一个你在很多地址都需要用到的步骤开始，把这些步骤放在一个用例里，然后给它命名。
比如在定单处置系统中，通过客户ID、定单ID和客户名等一系列步骤来搜索一个定单，这种搜索需要在很多的用例顶用到，包括取得定单状态、取消定单、退货等等，咱们称那个用例为搜索定单。
此刻从原始用例中抽出这些步骤，把它们替换成一个引用，指向新组成的用例（表11）。
表11搜索定单用例
1.当客户键入订单ID、客户ID或者客户名时，用例开始；
2.客户点击Find；
3.如果客户键入订单ID
a）系统显示订单，用例结束
4.如果客户键入客户名或者客户ID
a）系统返回当前客户的所有订单表
b）客户在这个列表中选择一个订单
c）系统显示这个订单，然后用例结束。
表12有包括关系的取消定单用例
1.客户键入请求取消一个订单，用例开始
2.包含搜索订单；
3.如果这个订单状态被确认
a）系统标志订单取消
b）系统通知记账系统向客户账号中加钱，用例结束；
5.如果订单状态是已运送
a）系统通知发货部门，用例结束。
当取消定单用例执行到搜索定单步骤的时候，就会执行搜索定单中的步骤，然后返回到取消定单继续执行以下的步骤。
用例图的表示方式如下（图5）：
4.2扩展
扩展一样用于有条件地扩展已有效例的行为，这是一种在不改变原始用例的情形下增加用例行为的一种方式。
因为扩展技术不是必不可少的，咱们建议系统分析员尽可能不利用。
4.3继承
在用例图中，继承能够在执行者或用例之间利用。
继承是一个“种属”关系，其中一个元素是其它元素的一种。
执行者之间的继承意味着一个执行者能够完成另一个执行者的一样任务，它也补充额外的角色，它以一样的方式与相同的用例进行交互。
用例之间的继承意味着一个用例是另一个用例的特殊的版本。
那个特殊的用例从一个通用用例中继承行为或增加行为。
看一下在定单处置系统中（图2）的一个简单例子。
客户和客户代表有相同的与之进行交互的用例集合。
咱们通过加入执行者之间的继承能够使得用例图大为简化。
见图6。
4.4接口
接口是为执行者、用例或二者概念的。
一个接口能够告知咱们希望实体做什么。
接口不是执行者或用例的一部份，是对怎么样与执行者和用例交互的一种描述。
你能够为任何执行者和用例设置多个接口。
第一步：
概念接口。
接口由名字和操作符号组成，一个操作符号告知咱们操作发生时传输何种数据和在操作终止时将何种数据返回给咱们，操作告知咱们希望实体做什么。
仍是考虑订购货物的例子，咱们发觉从库存系统中取得产品描述和价钱是必需的，咱们为库存系统概念接口如下：
表13接口的例子
PRODUCTINFO接口
得到产品描述和价格，返回产品描述、价格、库存数量
第二步，把它们加到用例图中。
执行者和接口之间直线的意思是执行者支持接口；虚线表示利用那个接口的用例，见图7。
若是执行者不是人，那么那个接口将是一段程序命令，用它来与执行者进行交互。
比如，若是执行者是一个网络，接口可能是TCP/IP命令。
若是执行者是与定单处置系统相交互的库存系统，就需要找出什么样的命令能够发送到库存系统，这些命令将到库存系统执行者的接口。
利用接口技术的最要紧目的主若是两个问题，一个是成立用例和人机界面的联系，一个是确信誉例利用到的数据。
有关继承、接口、
升级会员 