第9章 需求开发
第9章 需求开发 1 9.1 介绍 1 9.2 用户需求调查 2 9.2.1 目的 2 9.2.2 角色与职责 2 9.2.3 启动准则 2 9.2.4 输入 2 9.2.5 主要步骤 3 [Step1] 准备 3 [Step2] 调查与记录 3 [Step3] 分析需求信息 3 [Step4] 撰写用户需求说明书 3 [后续活动：需求确认] 3 9.2.6 输出 4 9.2.7 结束准则 4 9.2.8 度量 4 9.3 产品需求定义 4 9.3.1 目的 4 9.3.2 角色与职责 4 9.3.3 启动准则 4 9.3.4 输入 4 9.3.5 主要步骤 5 [Step1] 细化并分析用户需求 5 [Step2] 撰写产品需求规格说明书 5 [后续活动：需求确认] 5 9.3.6 输出 5 9.3.7 结束准则 5 9.3.8 度量 6 9.4 需求分析方法概述 6 9.4.1 问答分析法 6 9.4.2 建模分析法 6 一、结构化分析法 7 二、面向对象分析法 7 三、恰当地使用图形符号 8 9.5 实施建议 8 第9章 需求开发 需求开发（Requirement Development, RD）的目的是通过调查与分析，获取用户需求并定义产品需求。 需求开发过程域是SPP模型的重要组成部分。本规范阐述了需求开发过程域的两个主 要规程： ← 需求调查 [SPP-PROC-RM-SURVEY] ← 需求定义 [SPP-PROC-RM-DEFINE] 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出 ”、“完成准则”和“度量”均已定义。 需求分析是需求开发过程域的重要活动之一，但是不宜用“规范”这种形式来论述。本 章对需求分析方法作了概括性介绍，请读者阅读更加专业性的需求分析论著。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研 发实力等）适当地修改本规范，然后推广使用。 9.1 介绍 需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。需求工 程结构图如图8-1所示，需求开发和需求管理的流程如图9-1所示。 图9-2 需求开发与需求管理流程图 需求开发可分为两个阶段：“用户需求调查阶段”和“产品需求定义阶段”。而“需求分 析”则贯穿于上述两个阶段。需求调查阶段和需求定义阶段在逻辑上存在先后关系，实际 工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（也叫 系统分析员），避免与其它开发人员混淆。 一、需求调查 需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求 说明书》。 二、需求分析 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常用的需求分 析方法有“问答分析法”、“结构化分析法”和“面向对象分析法”。 三、需求定义 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求 ，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设 计工作。 需求开发过程域产生的主要文档有： ← 《用户需求说明书》，模板见 [SPP-TEMP-RD-UR]。 ← 《产品需求规格说明书》，模板见 [SPP-TEMP-RD-PRS]。 9.2 用户需求调查 9.2.1 目的 o 获取用户（客户与最终用户）的需求信息，经过分析后产生《用户需求说明书》。 9.2.2 角色与职责 o 需求分析员调查、分析用户的需求。 o 客户与最终用户提供必要的需求信息。 9.2.3 启动准则 o 需求分析员已经确定。 9.2.4 输入 o 任何与用户需求相关的材料 9.2.5 主要步骤 [Step1] 准备 o 需求分析员确定需求调查的方式，例如： ← 与用户交谈，向用户提问题。 ← 参观用户的工作流程，观察用户的操作。 ← 向用户群体发调查问卷。 ← 与同行、专家交谈，听取他们的意见。 ← 分析已经存在的同类软件产品，提取需求。 ← 从行业标准、规则中提取需求。 ← 从Internet上搜查相关资料。 o 需求分析员准备调查问卷（问题表）。 o 需求分析员与被调查者建立联系，确定调查的时间、地点、人员等。 [Step2] 调查与记录 o 需求分析员调查用户需求，随时记录调查过程中所获取的需求信息。 [Step3] 分析需求信息 o 需求分析员分析已经获取的需求信息，消除错误，归纳与总结共性的用户需求。 [Step4] 撰写用户需求说明书 o 需求分析员按照指定的文档模板撰写《用户需求说明书》，主要内容包括： ← 产品介绍； ← 描述用户群体的特征； ← 产品应当遵循的标准或规范； ← 描述产品的功能性需求； ← 描述产品的非功能性需求，如用户界面、软硬件环境、质量等需求。 补充说明：调查过程中获取的需求信息可以作为《用户需求说明书》的附件。 [后续活动：需求确认] o 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《用户需求说明书》，尽 最大努力使《用户需求说明书》能够正确无误地反映用户的真实意愿。 o 需求评审之后，开发方和客户方的责任人对《用户需求说明书》作书面承诺。 补充说明：“需求确认”活动属于需求管理范畴，详见 [SPP-PROC-RM] 。 9.2.6 输出 o 《用户需求说明书》 9.2.7 结束准则 o 需求分析员已经撰写完成《用户需求说明书》，并做了内部审查（消除拼写、排版等错误 ）。 9.2.8 度量 o 需求分析员统计工作量和上述文档的规模，汇报给项目经理。 9.3 产品需求定义 9.3.1 目的 o 定义准确无误的产品需求，产生《产品需求规格说明书》。 9.3.2 角色与职责 o 需求分析员定义产品需求。 o 客户与最终用户提供必要的需求信息，并确认产品需求。 9.3.3 启动准则 o 《用户需求说明书》已经撰写完成。 9.3.4 输入 o 《用户需求说明书》 9.3.5 主要步骤 [Step1] 细化并分析用户需求 o 需求分析员对《用户需求说明书》进行细化，以便产生详细的产品需求。 o 需求分析员对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求 。建议采用Rational 的Rose工具进行需求的建模分析，建模分析产生的文档可以作为《产品需求规格说明 书》的附件。 补充说明：建模分析的技术难度比较高，需求分析员应当根据自身水平进行取舍。 [Step2] 撰写产品需求规格说明书 o 需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软 件和硬件两部分的话，则应当分别撰写《软件需求规格说明书》和《硬件需求规格说明 书》。 o 《产品需求规格说明书》的主要内容包括： ← 产品介绍； ← 描述用户群体的特征； ← 定义产品的范围； ← 阐述产品应当遵循的标准或规范； ← 定义产品中的角色； ← 定义产品的功能性需求； ← 定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求； [后续活动：需求确认] o 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书 》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。 o 需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》作书面承诺。 补充说明：“需求确认”活动属于需求管理范畴，详见 [SPP-PROC-RM] 。 9.3.6 输出 o 《产品需求规格说明书》 9.3.7 结束准则 o 《产品需求规格说明书》已经撰写完成。 o 已经对产品需求进行了评审，并且获得了开发方和客户方对需求的承诺。 9.3.8 度量 o 项目经理统计工作量和上述文档的规模。 9.4 需求分析方法概述 很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。 需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误、弥 补不足，确保需求文档正确地反映用户的真实意图。 需求分析是需求开发过程中“最费脑子”的工作。分析方法大体有两类：“问答分析法”和 “建模分析法”。后者技术性比较强，大多数软件工程书籍都有论述。前者就是一些常识 而已，虽然写不成文章，但是简单易用，很有实用价值。 9.4.1 问答分析法 问答分析方法很简单：刨根究底地问，如果解答了这些问题，那么需求也就分析清楚 了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。 问答分析最重要的问题是：“是什么”和“为什么”。 每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说 明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么 ”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 其它常见的问题有： ← 需求存在二义性吗？ ← 需求文档的上下文有矛盾吗？ ← 需求完备吗？ ← 需求是必要的吗？ ← 需求可实现吗？ ← 需求可验证吗？ ← 需求的优先级确定了吗？ 9.4.2 建模分析法 人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目 了然，所谓“一图低千言”就是这个道理。 在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将 图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻 画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。 一、结构化分析法 软件的建模分析兴起于20世纪60年代末期和70年代初期。结构化分析方法并不是由里程 碑式的明确地涉及这个主题的一篇文章或者一本著作引入的，它也不是被所有使用者一 致采用的单一方法。相反地，它是几乎发展了20多年的一个混合物。结构化分析方法在 70年代和80年代非常流行，相关论著很多。对结构化分析方法有较大贡献的学者有DeMa rco, Gane, Sarsen, Yourdon, Constantine, Ward, Mellor, Hatly, Pirbhai等人。文献[Pressmen99, p206-p214]对结构化分析方法作了高度概括（如图9- 2所示），我们不妨称之为“一个中心三种图”： ← “数据字典”是中心，它包含了软件中所有数据对象的描述。 ← “实体－关系图”是用图形符号来标识数据对象以及它们之间的关系。 ← “数据流图”指明了数据在系统中移动时如何被变换。 ← “状态－变迁图”表示了系统存在的各种状态以及它们之间的变迁方式。 图9-2 结构化分析方法示意图 二、面向对象分析法 面向对象分析设计（OOAD）方法兴起于20世纪80年代，从90年代起至今它已经在分析设 计领域占据了无可争议的主流地位。 作者在读本科（90年至94年）时就充分地感受到了人们对“面向对象”的狂热。关于“面向 对象”的课堂、学术报告常常人满为患。搞软件研发的人都“言必谈对象”，并引以为荣。 面向对象分析设计领域有一些比较著名的学派，如： ← Coad和Yourdon学派，其代表作为[Coad91]。 ← Booch学派，其代表作为[Booch94]。 ← Jocobson学派，其代表作为[Jacobson92]。 ← Rumbaugh学派，其代表作为[Rumbaugh91]。 有趣的是，这些学派的掌门人就像上帝、真主、如来佛，他们用各自的方式定义了这 个世界，并留下一堆经书来解释这个世界。这种混乱的局面被学术界称为百家争鸣，每 年诞生了许多论著和教授。叫苦的是软件企业和开发人员：没有统一的方法，不好干活 啊！ 终于等到了那一天，Rational公司招纳了Booch, Jocobson, Rumbaugh，这三位“面向对象”业界的权威强强联手，制定了“统一建模语言”（UML）。1 997年11月，UML被国际对象管理组织（OMG）采纳，此后UML成为OOAD建模语言的国际标 准。 UML吸取了各种OOAD方法的精髓，对于OOAD中的语义、图形表示法和使用规则作了完整而 详细的定义。UML的建模能力超过了以往任何一种OOAD方法，当然其复杂性也随之膨胀。 大多数软件开发人员没有兴趣阅读枯燥乏味的UML文档（如[Rumbaugh99]）。真正使UML 流行的是Rational公司基于UML的建模工具Rose。Rose易学易用，它能交互式地构建类图 、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等等，深得开发人员的 喜爱。 介绍UML和Rose的书籍非常多，读者自己选择、学习，这里不再论述。 三、恰当地使用图形符号 现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要 注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开 发人员更难掌握，而且使图形文档更加杂乱。 世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。 在需求规格说明书中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将 模型存放在需求规格说明书的附录中，便于正文引用。 9.5 实施建议 o 先对需求分析员进行培训，让他们掌握必要的需求开发技能。 o 对需求开发过程域产生的所有有价值的文档进行配置管理。 o 对于非合同项目，本规范中有关客户的活动可以简化。 o 需求的建模分析有较高的技术难度，需求分析员应当根据自身水平进行取舍。建议企业 购买Rational Rose作为需求建模分析的工具。 o 需求分析员...
第9章 需求开发