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