毕业设计说明书
（2）参与者扮演的角色
① 作者：创建或维护正在被审查的产品。作者在审查中却起着被动的作用，作者经常可以发现其他审查员没有觉察到的错误。
② 协调者：与作者一起为审查制订计划，组织与协调各种活动，并且推进审查会的进行。督促作者对需求文档做出建议性的更改，以保证向执行者明确说明在审查过程中提出的问题和缺陷。
③ 读者：扮演审查员的角色。在审查会进行期间，读者一次审查规格说明中的一块内容，并做出解释，而且允许其他审查员在审查时提出问题。对于一份需求规格说明，审查员每次必须对需求给出注解或一个简短评论。通过用自己的话来陈述，读者可能做出与其他审查员不同的解释，这将有利于发现二义性或可能的错误。
④ 记录员：用标准化的形式记录在审查会中提出的问题和缺陷。 （3）进入和退出审查的标准 ① 文档进入审查的标准：
— 文档符合标准模板；
— 文档已经做过拼写检查和语法检查； — 作者已经检查了文档在版面上所存在的错误；
— 已经获得了审查员所需要的先前系统的运行资料或确认所需要的参考文档，例如系统需求规格说明；
— 在文档中打印了行序号以方便对特定位置的查阅和标记； — 所有未解决的问题都被标记为TBD（待确定）； — 文档中使用到的术语词汇表已全部进行了说明。
② 文档退出审查的标准：
— 已经明确阐述了审查员提出的所有问题； — 已经正确修改了文档；
— 修订过的文档已经进行了拼写检查和语法检查；
— 所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程、目标日期和提出问题的人；
— 文档已经录入项目的配置管理系统； — 已将审查过的资料送到有关归档部门。
- 11 - 11
毕业设计说明书
（4）需求审查清单
① 软件需求规格说明书审查清单：
— 组织和完整性； — 正确性； — 质量属性； — 可跟踪性； — 特殊的问题。
② 使用实例审查清单：
— Use Case是否是独立的分散任务； — Use Case的目标或价值度量是否明确； — Use Case给操作者带来的益处是否明确；
— Use Case是否处于抽象级别上，而不具有详细的情节； — Use Case中是否不包含设计和实现的细节； — 是否记录了所有可能的可选过程； — 是否记录了所有可能的例外条件；
— 是否存在一些普通的动作序列可以分解成独立的Use Case； — 是否简明书写、无二义性和完整地记录了每个过程的对话； — Use Case中的每个操作和步骤是否都与所执行的任务相关； — Use Case中定义的每个过程是否都可行； — Use Case中定义的每个过程是否都可确认。
- 12 - 12
毕业设计说明书
第四章 合格需求的标准
合格需求的标准概括如下：
1. 必要性：如果没有这项需求，系统仍然能够满足经优化的实际需要，则该项需求是不必要的；
2. 可行性：在可用的费用和时间约束下，该项需求是可以实现和运行的； 3. 正确性：与需求有关的事实是准确的，需求在技术上和法律上是可能实现的；
4. 简明性：需求的描述应该简单明瞭；
5. 无歧义性：各项需求只有唯一的一种解释方法； 6. 完全性：需求应用的全部条件，都得到陈述； 7. 可验证性：需求在系统运行中可以得到验证；
8. 可跟踪性：需求的起源，设计，编码，测试和文档是可跟踪的； 9. 可分配性：需求可以分配到系统的部件，加以实现； 10.设计独立性：需求不应该仅有一种唯一的解决方案； 11.无冗余性：需求不应该重复；
12.使用标准结构陈述：使用命令式语气，采用词汇Shall陈述； 13.具有唯一的识别码：每个需求拥有唯一的标识数码。
14.无不确定词汇：不能使用含义不确定的词汇，例如if, when, but, except, unless, usually, generally, often, normally, and typically。
结论
需求分析是软件工程项目的开始，也是质量控制额开始，同时，需求分析还具有决策性，方向性，策略性的作用，在需求阶段如果出了问题，在后面的阶段问题也随之留下来。所以不论是在学习软件工程学的过程中，还是在软件的开发
- 13 - 13
毕业设计说明书
实践中，一定要对需求分析有足够的重视，它是开发出正确的，高质量的软件的前提和重要保证。
参考文献：
（1） 龚波. 软件过程管理. 北京 ：中国水利水电出版社, 2003. （2） 张海藩.软件工程导论.北京 : 清华大学出版社，2003
（3） 梁震戈，梁立新，王文君. IT项目的面向对象开发及管理：电子政务
系统案例分析，2009
- 14 - 14
毕业设计说明书
- 15 - 15