传统上,需求可视为概念:需求中所述类别之一的文本声明。每个需求都陈述了“系统必须遵循的条件或能力”。
为执行有效的需求管理,我们已经知道将我们作为需求维护的范围扩展到不再仅限于详细“软件需求”,这是有帮助的。我们引入需求类型的概念以帮助区分需求的不同抽象级别和用途。
我们可能想要跟踪来自项目干系人的含糊的“愿望”以及正式的请求,以确保能了解它们的处理情况。 远景文档帮助我们跟踪系统的关键“用户需要”和“特性”。用例模型是一种表达详细的功能“软件需求”的有效方法,因此可能需要跟踪这些用例并将其作为需求来维护,并且可能需要跟踪和维护用例属性中的个别陈述,这些陈述声明“系统必须遵循的条件或能力”。补充规范可以包含其他“软件需求”,例如系统上的设计约束或者法律或规章要求。对于软件需求的完整定义,用例和补充规范可封装在一起,来为特定的“特性”或其他子系统分组定义软件需求规范(SRS)。
所开发的系统越大、越复杂,就会出现越多的表达或需求类型,且需求量也越大。项目的“业务规则”和“远景”陈述跟踪到“用户需要”、“特征”或其他“产品需求”。用例或其他形式的建模及其他补充规范可驱动设计需求,这些需求又可进一步分解为功能和非功能“软件需求”,如“分析与设计”模型和图中所示。
可在以下部分找到关于此主题的更多信息:
概念:需求
概念:需求管理
概念:可跟踪性
白皮书:将需求管理应用于用例
|