软件需求分析——阅读笔记5

读《需求工程——软件建模与分析》 第四部分 需求的文档化和验证 有感

　　需求获取活动收集了需求信息，需求分析活动深入地理解了需求信息并建立了能够满足用户需要的软件解决方案。而需求规格说明活动就是将需求及其软件解决方案进行定义和文档化，并传递给开发人员的需求工程活动。

　　需求规格说明文档是需求规格说明活动的一个核心元素。（1）需求规格说明文档可以成为各方人员之间有关软件系统的协议基准。（2）需求规格说明文档可以成为项目开发活动的一个重要依据。（3）在需求规格说明文档的编写过程中，可以尽早的发现和减少可能的需求错误，从而减少项目的返工，降低项目的工作量。（4）需求规格说明文档可以成为有效的智力资产。

　　需求规格说明文档的几个常见读者群体：项目管理者、设计人员和程序员、测试人员、文档编写人员、维护人员、培训人员、律师。为了让文档的编写工作更加顺利，同时也让编写出的文档具有更高的质量，人们倾向于总结、借鉴和复用已有的经验。因此，在编写需求规格说明时，首先要选择一份适合的文档模板。

　　软件需求规格说明模板：（1）引言（是对整个软件需求规格说明的概览）：a.文档的意图（目的）b.主要内容（范围）c.阅读时的注意事项（定义、首字母缩写和缩略语）、参考文献、组织方式（文档组织）（2）总体描述（从总体上描述影响蟾皮和需求的因素）：a.产品前景 b.产品功能 c.用户特征 d.约束 e.假设和依赖 （3）详细需求描述（最多和最重要的部分）：a.功能需求 b.性能需求 c.约束 d.质量属性 e.对外接口

　　优秀的需求规格说明文档应该具备下面的特性：正确性、无歧义、完备性、一致性、根据重要性和稳定性分级、可验证、可修改、可跟踪。

　　在需求验证中，验证有两层含义：验证与确认。要深入的了解验证与确认的实质意义，就有必要在整个软件工程的框架下来理解系统验证的意义。软件开发过程中的完全正确性是可望而不可即的，总还有一些小的偏差和错误发生。所以有在开发过程中发现的偏差和错误都应该在最终的软件产品中得到修正。软件测试时人们最为熟悉和常用的软件质量保证措施。

　　和验证活动贯穿于软件开发活动一样，验证活动同样也普遍存在于需求开发活动中。需求验证并不是一个可以一次结束的活动，它可能需要多次、反复地执行验证。执行验证的常见方法有：需求评审、原型与模拟、测试用例开发、用户手册编制、利用跟踪关系和自动化分析。

　　评审又被称为统计评审，是指由作者之外的其他人来检查产品问题的方法。在系统验证中，评审时主要的静态分析手段，所以评审也是需求评审的一种主要方法。审查过程中的所有参与者，包括作者，他们的任务都是查找缺陷和对其进行改进的机会。审查组中的成员在审查期间可能扮演下面的角色：（1）组织者，负责整个项目当中审查活动的组织和规划。（2）仲裁者，负责确保整个审查过程的正确进行，协调审查活动。（3）作者，创建或者维护软件需求规格说明文档的人，在评审中作为听众听取评论，并在需要时解答审查人员的问题。（4）阅读人员。（5）记录人员。（6）收集人员。（7）审查人员。

　　常见的评审过程可以分为6个阶段：（1）在和规划阶段，作者和仲裁者共同制定审查计划，决定审查会议的次数，安排每次审查会议的时间、地点、参与人员、审查内容。（2）在总体部署阶段，作者和仲裁者向所有参与审查会议的人员描述待审查材料的内容、审查的目标以及一些假设，并分发文档。（3）在准备阶段，审查人员各自独立执行检查任务。（4）审查会议阶段，通过会议讨论，识别、确认和分类发现的错误。（5）返工阶段，作者修改发现的缺陷。（6）在跟踪阶段，仲裁者要确认所有发现的问题都得到了解决，所有的错误都得到了修正。