传统上,需求被视为可归为概念:需求中所述类别之一的文本声明。每个需求都陈述了“系统必须遵循的条件或能力”。

我们引入需求类型的概念以帮助区分需求的不同抽象级别和用途。 

软件需求规范 ../../artifact/ar_tstste.htm -- This hyperlink in not present in this generated website 设计模型 补充规范 用例模型 涉众请求 远景 概念:需求

我们可能想要跟踪来自涉众的含糊的“愿望”以及正式的请求,以确保能了解它们的处理情况。远景文档帮助我们跟踪系统的关键“用户需要”和“特性”。用例模型是一种表达详细的功能“软件需求”的有效方法,因此可能需要跟踪用例并将其作为需求来维护,并且可能需要跟踪和维护用例特征中的个别陈述,这些陈述声明“系统必须遵循的条件或能力”。补充规范可以包含其它“软件需求”,例如系统上的设计约束或者法律或规章要求。对于软件需求的完整定义,用例补充规范可以封装在一起,来为特定的“特性”或其它子系统分组定义软件需求规范(SRS)

所开发的系统越大、越复杂,就会出现越多的表达或需求类型,且需求量也越大。项目的“业务规则”和“远景”声明会跟踪“用户需要”、“特性”或其它“产品需求”。用例或其它形式的建模以及其它补充规范可驱动设计需求,这些需求又可进一步分解为功能和非功能“软件需求”,如“分析与设计”模型和图中所示。

更多信息

可在以下部分找到关于此主题的更多信息:

概念:需求
../../../papers/apprmuc.htm -- This hyperlink in not present in this generated website白皮书:通过用例来应用需求管理



Rational Unified Process   2003.06.15