软件需求分析重点

用例之间的关系：

包含，扩展，泛化

软件需求规格说明书（SRS）应具备哪些特点:

? 正确性 ? 无二义性 ? 完整性 ? 一致性

? 按重要度/稳定性排序 ? 可验证性 ? 可修改性 ? 可跟踪性

编写SRS的原则有哪些:

? 原则1：只描述“做什么”而无须描述“怎么做” ? 原则2：必须说明运行环境

? 原则3：考虑用户、分析员和实现者的交流

? 对形式化和自然语言之间作出恰当的选择

? 明确的理解最重要，不存在十全十美的软件规格说明书

? 原则4：力求寻找到恰如其分的需求详细程度

? 一个有益的原则就是编写单个的可测试需求文档

? 建议将可测试的需求作为衡量软件产品规模大小的尺度 ? 原则5：文档段落不宜太长 ? 简短

? 记住：不要在需求说明中使用“和/或”、“等等”之类的词 ? 原则6：避免使用模糊的、主观的术语

? 如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、最大化、最小化、提高等 ? 不可验证

需求验证要验证哪些内容:

? 软件需求规格说明正确描述了预期的系统行为和特征 ? 从系统需求或其它来源中得到软件需求 ? 需求是完整的和高质量的 ? 所有对需求的看法是一致的

? 需求为继续进行产品设计、构造和测试提供了足够的基础

需求验证的技术:

? 需求评审：由不同代表(如分析员、客户、设计人员、测试人员)组成的评审小组以会议形式对需求进行系统性分析。 ? 原型评价：客户和用户在一个可运行的原型系统上实际检验系统是否符合他们的真正需要。

? 测试用例生成：通过设计具体的测试方法，发现需求中的问题。

需求评审过程及退出条件:

过程：

退出条件：

? 已经明确阐述了审查员提出的所有问题 ? 已经正确修改了文档

? 修订过的文档已经进行了拼写检查和语法检查

? 所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程、

目标日期和提出问题的人

? 文档已经登记入项目的配置管理系统

? 检查是否已将审查过的资料送到有关收集处

需求变更控制流程:

变更控制过程并不是“拖延时间以敷衍用户”，它是一个渠道和过滤器，通过它可以确保采纳最合适的变更，使变更产生的负面影响减少到最小。

需求跟踪管理:

? 需求跟踪：

? 维护需求与软件制品之间的映射(例如设计对象、用例、测试用例、已实现的软件模块等)

? 全面分析变更所带来的影响，以便作出正确的变更决策。 ? 建立需求跟踪的过程：

? 识别并唯一地标识SRS中的每一个需求 ? 建立和更新SRS中的跟踪矩阵

? 工作制品的创建者负责增加该制品与需求的跟踪信息

? 跟踪矩阵应该作为工作制品的一部分进行审查需求版本控制

需求版本控制：

? 版本控制是管理需求的一个必要方面。 ? 需求文档的每一个版本必须被统一确定。

? 组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。

? 为防止混乱，应仅允许指定的人来更新需求。