活动:详述软件需求
目的
- 收集、详述并组织完整描述系统或子系统的软件需求的工件集(包)。
|
角色:
需求指定者
|
频率: |
步骤
|
确保以所需的详细级别指定了所有需求以便传递给设计人员、测试人员和文档编写人员。回顾检查点:补充规范来查看要捕获用例中没有包含的任何软件需求是否需要进一步的详细信息。
如果正在生成正式的软件需求规范(SRS),请回顾检查点:软件需求规范。
如果需求得到跟踪或其他形式的正式管理,请确保每个需求都明确地标识并标注出来。
通常使用一个或多个工具存储和管理需求。例如,以下用途的工具:
这一步骤从这些工具生成文档,这样就可以很容易复审信息了。关于与该工作相关的可以运行的适用报告的详细内容,请参阅本活动的“更多信息”一节。
如果专门工具不用于捕获需求,那么该步骤就不适用(所有的软件需求将直接写在文档中)。
对于不太正式的项目,这一步骤包括将相关的报告和手工生成的文档打包,并附带足够的支持材料,这样就可以有效地复审需求了。
对于较正式的项目,一个或多个软件需求规范(SRS)收集并组织所有围绕项目的需求。例如,一个独立的 SRS 可以描述产品的某个发行版中的每个特性的完整的软件需求。这可能包括来自系统用例模型的数个用例,来描述该特性的功能需求以及补充规范中相关的详细需求集。
软件需求规范是正式的、IEEE 830 类型的文档,用 UML“包”构造表示。提供了两个样本 SRS 模板:一个 *与* 用例建模一起使用(rup_srsuc.dot),一个 *不与* 用例建模一起使用(rup_srs.dot)。第一个(rup_srsuc.dot)引用(或包含)用例模型工件:用例模型调查、用例报告以及补充规范。这使您不必复制这其它 3 个工件中的信息就可以拥有正式的与 IEEE 兼容的 SRS。
第二个(rup_srs.dot)是一个独立的文档,它直接在文档中包含 *所有* 软件需求。该文档将要求您使用对用例工件需求的可跟踪性(如果使用这些需求的话)。
从技术的角度讲,两者包含相同的信息,但是用例模型中的信息在第一个中是以引用形式包含的(不是复制的),而在第二个中则是完全复制的(如果使用用例),这就要求在维护可跟踪性关系时的工作量比第一个要多得多。
使用软件需求规范模板,将各个 SRS 包汇编起来并提供剩余的信息来获得该子系统或特性的软件需求的完整定义。
|