需求开发过程定义模板二
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
《需求开发及管理计划》
《用户需求说明书》
《软件需求说明书》
部分的《系统测试用例》
部分的《用户手册》
2.7
《《用户需求说明书》》和《《软件需求说明书》》通过评审。
3
3.1
3.1.1
3.1.2
为整个需求开发过程的顺利完成而进行的准备工作。
输入及要求
1、立项报告，经过了内部的审核批准。
2、合同、或者方案建议书等原始需求，取得了用户和公司的签署，已经正式生效。
需求开发
(RD，Requirement Development)
文件状态
草稿
正式发布
正在修改
项目编号
N/A
文件标识
OSSP-Process-RD
当前版本
0.1
总页数
页
正文
7页
附件
个
页
审批
生效日期
Yyyy-mm-dd
版本历史(HISTORY OF VERSION)
版本号
日期
版本说明/变更理由/变更内容
界面原型
配合《用户需求说明书》、用于补充说明用户需求的原型，可以全部是静态页面。
系统原型
配合《软件需求说明书》、用于补充说明软件需求的原型，必须完整、动态地实现页面之间的关联。
2
2.1
需求开发的目标是产生和分析用户需求、软件需求和软件构件需求。
2.2
类别
角色
职责
高级管理
高层经理
1）评审、批准用户需求、产品需求、构件需求、接口需求规格说明书等过程产品，并参与本过程域重要的活动
3）参与、并协调用户需求工程师参与软件需求分析工作
4）参与评审本过程域的工作产品
5）完成或协助完成本过程域的工作产品
6）向高层经理报告本过程域的实施情况
7）跟踪需求开发工作完成情况
执行
用户需求工程师
1）收集、分析、细化、导出和描述用户需要、期望、约束和接口，并把它们转换成用户需求
2）按时完成项目经理指定的工作产品
场景
scenario。用于描述行为、按特定顺序排列的动作序列。可用来描述系统用户与系统的交互或执行，也可以理解为用例的实例。
CRS，用户需求
从用户和业务角度描述的需求
SRS，软件需求
从软件系统的角度描述的需求
业务测试用例
基于用户需求开发的测试用例
软件测试用例
针对业务测试用例、基于软件需求开发的测试用例
3）参与评审本过程域有关工作产品
4）对用户、产品、产品构件需求进行确认
5）指导创建并审核业务测试用例。
系统分析工程师
1）跟踪、协助需求开发人员开展用户需求开发工作。
2）把用户需求转换为软件、软件构件和接口的需求
3）参与评审本过程域有关工作产品
4）对用户、软件、软件构件需求进行确认
5）指导创建并审核软件测试用例。
软件设计工程师
1）和需求分析人员共同分配产品构件需求和产品构件接口需求。
支持
CM
负责在本过程所涉及的配置管理工作
QA
负责在本过程所涉及的质量保证工作
MA
负责在本过程所涉及的度量工作
参与
客户代表
1）提供用户需求和确认用户的潜在需求
2）参与本过程域工作产品的评审
3）提供操作概念和场景
软件测试工程师
参与需求开发过程，创建和维护测试计划、业务测试用例、软件测试用例。
3、根据需要建立系统原型。当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
4、撰写《软件需求说明书》。系统分析工程师按照指定的文档模板撰写《软件需求说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写《软件需求说明书》和硬件需求说明书。
7、对《用户需求说明书》进行评审。用户需求负责人安排客户代表或客户需求负责人及有关项目人员对《用户需求说明书》进行评审。
8、评审如果没有通过，回到“1”。
输出及要求
1、《用户需求说明书》，通过了评审
2、（可选）《界面原型》
3、《访谈记录》
4、《需求跟踪矩阵》，纳入了基线管理。
备注
3.3
3.3.1
3.3.2
ii.分析可行性：在允许的时间、成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
iii.确定需求优先级：确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
5、对软件需求（包括《软件需求说明书》和系统原型，下同）进行内部确认：软件开发负责人安排用户需求负责人、用户需求工程师、系统分析工程师、及有关项目人员对软件需求进行内部评审。评审如果没有通过，回到“1”，或者返回到用户需求开发步骤。
6、维护《需求跟踪矩阵》。
7、对软件需求进行评审。用户需求负责人安排客户代表、及用户需求工程师，软件开发负责人安排系统分析工程师、及有关项目人员，共同对《软件需求说明书》进行评审。项目经理主持。
相关工作产品
需求开发过程
《需求开发及管理计划》
《用户需求说明书》
《需求跟踪矩阵》
《界面原型》
《软件需求说明书》
《系统原型》
部分的《系统测试用例》
部分的《用户手册》
7.2
过程名称
相关规程/规范/指南
相关工作产品
7.3
7.3.1
工具：
模拟和建模工具
原型工具
场景定义和管理工具
活动内容
1、项目经理（用户需求负责人配合）根据立项报告、合同、或者方案建议书等制定需求开发及管理计划，确定需求开发的方式，时间，地点，参加人员等，并定义不同时期要提交的工作产品。
2、必要时，项目经理（用户需求负责人配合）组织人员对参加需求开发的人员进行需求开发培训，确保参加需求开发的人员掌握项目需求开发的方法。
5、按计划实施项目团队各项工作，并完成上级交办的其他工作任务
6、控制项目进度以及项目的跟踪与监控
7、解决存在于项目团队内或团队间的分歧（冲突）或问题
8、协商承诺、项目内外部协调
9、负责组建和维护项目知识库,参与并积极配合过程改进活动
10、遵循公司/部门考核制度，对项目组成员进行绩效考核
11、在必要的情况下向下级授权（仅项目经理权限）
4、依据访谈记录撰写本次需求内容的用户需求说明，必要时建立相应的界面原型并于用户确认。
5、回到“1”
6、撰写《用户需求说明书》（包括需求优先等级的定义、以及需求跟踪矩阵）：在所有需求获取过程结束后，整理所有确认后的需求内容，消除其中的矛盾之处，并对其中不一致的地方进行协调和平衡。如有界面原型，进行汇整。
8、评审如果没有通过，回到“1”，或者返回到用户需求开发步骤。
输出及要求
1、《软件需求说明书》，通过了评审
2、《系统原型》，通过了评审
3、《需求跟踪矩阵》，纳入了基线管理。
备注
4
定义度量元：
(1)需求开发过程中的返工的成本、进度和工作量；
(2)需求规格说明书的缺陷密度；
5
验证方法
验证方式
验证关键点
验证时机
软件开发负责人*
1）参与、并组织系统分析工程师参与用户需求开发
2）组织软件需求分析工作
3）参与评审本过程域的工作产品
4）完成或协助完成本过程域的工作产品
5）向高层经理报告本过程域的实施情况
用户需求负责人*
1）为需求开发工作提供各种必要的环境和条件
2）负责联系用户和用户需求工程师、软件开发负责人、系统分析工程师进行用户需求开发工作
用户需求分析完成、软件需求分析完成
6
1)如果用户能够提供准确的《用户需求说明书》，则活动“制定需求开发及管理计划”可以被裁剪为只制定软件需求的开发及管理计划。
2)对于活动“用户需求开发”：1、界面原型是可选的。2、如果用户能够提供准确的《用户需求说明书》，则本活动可以被裁剪。
7
7.1
过程名称
规程/指南
输出及要求
1、《需求开发及管理计划》，通过了评审。
2、确认了所有用户需求工程师具备了进行用户需求开发的能力。
3、当补充软件需求的开发及管理计划时，要确认所有系统分析工程师具备了进行软件需求开发的能力。
备注
3.2
3.2.1
3.2.2
软件需求可以来自方方面面，这取决于所开发产品的性质和开发环境。需使用各种方法，从不同客户代表和来源收集需求，这说明了需求工程是以相互交流为核心的性质。
在实施需求开发的过程中，按项目的行业、规模和属性不同，用户需求负责人可以采用不同的方法或综合使用多种方法、分多次进行来获取需求。
用户需求开发的过程定义如下：
输入及要求
1、用户《需求开发及管理计划》，已经评审通过
2、原始需求（可选），已经生效
如果客户没有提供原始需求，则用户需求的开发活动中所做的访谈记录，也是挖掘原始需求的过程。
输入及要求
1、用户《需求开发及管理计划》，已经评审通过
2、《用户需求说明书》，通过了评审
活ห้องสมุดไป่ตู้内容
1、项目经理（软件开发负责人辅助）详细制定软件需求分析计划，补充到《需求开发及管理计划》中。
2、分析用户需求。项目经理（软件开发负责人辅助）组织系统分析工程师对《《用户需求说明书》》进行细化，以便产生详细的软件需求。
2）解决在实施本过程域中所遇到的、项目组无法解决的问题
管理
项目经理*
1、参与项目团队的组建、负责项目组人才培养和规划、项目组成员潜能的挖掘
2、遵循公司项目管理的方针和实践，选择所负责项目适用的过程；
3、负责所属系统/项目/产品的启动、策划、开发、设计、测试、验收、维护等生命周期全过程
4、负责项目策划、制订项目计划、提交审批
3、项目经理（用户需求负责人配合）就需求开发及管理计划的内容与客户进行沟通并达成一致，并确定客户代表和客户方需求负责人。
4、项目经理（用户需求负责人配合）召集并主持评审会议，对《需求开发及管理计划》进行评审。项目组的相关人员参加评审，此外还应包括客户代表。
5、当本过程进入到软件需求开发活动时，需要对《需求开发及管理计划》进行补充，内容是软件需求的开发及管理计划。由项目经理负责，系统分析工程师配合。
客户服务工程师
跟踪需求开发过程。
*：在具体的项目组织中，项目经理和用户需求负责人、软件开发负责人可能被赋予同一个人。
2.3
立项申请、可行性论证报告被批准或商务合同已经生效。
2.4
输入
具体要求
立项申请、可行性论证报告或商务合同。
立项申请、可行性论证报告被批准或商务合同已经生效。
2.5
2.6
输出
具体要求
作者
备注
0.1
2006-04-07
初始创建
目录(TABLE OF CONTENTS)
1
1.1
本文档为组织描述需求开发过程。
本文档适用于：
1)本文档适用于整个生命周期与需求开发有关的活动。
2)本文档适用于组织范围内实施CMMI过程体系的所有部门。
1.2
1.3
术语
说明
操作概念
operational concept。对每一个实体使用方法的全面描述。
1）如果客户当前已在使用一个信息系统，则需要了解当前系统的运行情况，收集用户在使用现有系统过程中所遇到问题，以及用户关于系统改进的想法。
2）如果已经开发了新产品的原型，或已有类似的产品，则通过向用户演示该系统，搜集用户的意见。
3、将本次获取到的需求整理成访谈记录，并与客户确认《访谈记录》；对于暂时无法确定的问题则标记为问题，并记录需求问题追踪表，在以后的过程中进行跟踪解决。
系统分析工程师对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。可以采用的分析步骤有：
i.建议使用RationalRose建模工具进行需求的建模分析，通过分析系统的功能模型、结构模型和行为模型，进行系统建模。建模的过程包括系统功能建模、系统数据建模和体系结构建模。在需求开发阶段应至少完成功能建模。功能建模的方式包括静态建模和动态建模。静态建模要求画出业务用例图、用例（实现）图、主要的类图和对象图，动态建模要求画出主要的状态图、活动图、时序图（可选）、以及协作图（可选）等。另外在用例图中，需标明每个用例的业务描述、业务数据、业务流程、入口条件、输出结果、异常处理等要素。
活动内容
1、用户需求负责人按《需求开发及管理计划》确定本次需求获取的内容，并在小组内部取得一致，然后与客户联系并确定进行本次需求获取的时间，地点及双方参加人员。
包括准备调查问卷、对目前市场上的产品或竞争产品进行调研、对政府或行业法规进行研究等。
2、访问客户以获得需求。主要的活动包括：与客户进行直接交流、让有关客户填写调查问卷、观察正在工作的用户等。
PPQA检查验证
PPQA检查的工作产品包括：《用户需求说明书》或软件需求说明。
过程中随时
同行评审
按照同行评审的规范进行同行评审。评审的工作产品包括：《用户需求说明书》或《软件需求说明书》。
用户需求分析完成、软件需求分析完成
高层经理验证
主要参与的审核活动包括：需求开发过程的活动、状态和结果，高层经理也负责解决有关问题。
《用户需求说明书》
《软件需求说明书》
部分的《系统测试用例》
部分的《用户手册》
2.7
《《用户需求说明书》》和《《软件需求说明书》》通过评审。
3
3.1
3.1.1
3.1.2
为整个需求开发过程的顺利完成而进行的准备工作。
输入及要求
1、立项报告，经过了内部的审核批准。
2、合同、或者方案建议书等原始需求，取得了用户和公司的签署，已经正式生效。
需求开发
(RD，Requirement Development)
文件状态
草稿
正式发布
正在修改
项目编号
N/A
文件标识
OSSP-Process-RD
当前版本
0.1
总页数
页
正文
7页
附件
个
页
审批
生效日期
Yyyy-mm-dd
版本历史(HISTORY OF VERSION)
版本号
日期
版本说明/变更理由/变更内容
界面原型
配合《用户需求说明书》、用于补充说明用户需求的原型，可以全部是静态页面。
系统原型
配合《软件需求说明书》、用于补充说明软件需求的原型，必须完整、动态地实现页面之间的关联。
2
2.1
需求开发的目标是产生和分析用户需求、软件需求和软件构件需求。
2.2
类别
角色
职责
高级管理
高层经理
1）评审、批准用户需求、产品需求、构件需求、接口需求规格说明书等过程产品，并参与本过程域重要的活动
3）参与、并协调用户需求工程师参与软件需求分析工作
4）参与评审本过程域的工作产品
5）完成或协助完成本过程域的工作产品
6）向高层经理报告本过程域的实施情况
7）跟踪需求开发工作完成情况
执行
用户需求工程师
1）收集、分析、细化、导出和描述用户需要、期望、约束和接口，并把它们转换成用户需求
2）按时完成项目经理指定的工作产品
场景
scenario。用于描述行为、按特定顺序排列的动作序列。可用来描述系统用户与系统的交互或执行，也可以理解为用例的实例。
CRS，用户需求
从用户和业务角度描述的需求
SRS，软件需求
从软件系统的角度描述的需求
业务测试用例
基于用户需求开发的测试用例
软件测试用例
针对业务测试用例、基于软件需求开发的测试用例
3）参与评审本过程域有关工作产品
4）对用户、产品、产品构件需求进行确认
5）指导创建并审核业务测试用例。
系统分析工程师
1）跟踪、协助需求开发人员开展用户需求开发工作。
2）把用户需求转换为软件、软件构件和接口的需求
3）参与评审本过程域有关工作产品
4）对用户、软件、软件构件需求进行确认
5）指导创建并审核软件测试用例。
软件设计工程师
1）和需求分析人员共同分配产品构件需求和产品构件接口需求。
支持
CM
负责在本过程所涉及的配置管理工作
QA
负责在本过程所涉及的质量保证工作
MA
负责在本过程所涉及的度量工作
参与
客户代表
1）提供用户需求和确认用户的潜在需求
2）参与本过程域工作产品的评审
3）提供操作概念和场景
软件测试工程师
参与需求开发过程，创建和维护测试计划、业务测试用例、软件测试用例。
3、根据需要建立系统原型。当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。
4、撰写《软件需求说明书》。系统分析工程师按照指定的文档模板撰写《软件需求说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写《软件需求说明书》和硬件需求说明书。
7、对《用户需求说明书》进行评审。用户需求负责人安排客户代表或客户需求负责人及有关项目人员对《用户需求说明书》进行评审。
8、评审如果没有通过，回到“1”。
输出及要求
1、《用户需求说明书》，通过了评审
2、（可选）《界面原型》
3、《访谈记录》
4、《需求跟踪矩阵》，纳入了基线管理。
备注
3.3
3.3.1
3.3.2
ii.分析可行性：在允许的时间、成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
iii.确定需求优先级：确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。
5、对软件需求（包括《软件需求说明书》和系统原型，下同）进行内部确认：软件开发负责人安排用户需求负责人、用户需求工程师、系统分析工程师、及有关项目人员对软件需求进行内部评审。评审如果没有通过，回到“1”，或者返回到用户需求开发步骤。
6、维护《需求跟踪矩阵》。
7、对软件需求进行评审。用户需求负责人安排客户代表、及用户需求工程师，软件开发负责人安排系统分析工程师、及有关项目人员，共同对《软件需求说明书》进行评审。项目经理主持。
相关工作产品
需求开发过程
《需求开发及管理计划》
《用户需求说明书》
《需求跟踪矩阵》
《界面原型》
《软件需求说明书》
《系统原型》
部分的《系统测试用例》
部分的《用户手册》
7.2
过程名称
相关规程/规范/指南
相关工作产品
7.3
7.3.1
工具：
模拟和建模工具
原型工具
场景定义和管理工具
活动内容
1、项目经理（用户需求负责人配合）根据立项报告、合同、或者方案建议书等制定需求开发及管理计划，确定需求开发的方式，时间，地点，参加人员等，并定义不同时期要提交的工作产品。
2、必要时，项目经理（用户需求负责人配合）组织人员对参加需求开发的人员进行需求开发培训，确保参加需求开发的人员掌握项目需求开发的方法。
5、按计划实施项目团队各项工作，并完成上级交办的其他工作任务
6、控制项目进度以及项目的跟踪与监控
7、解决存在于项目团队内或团队间的分歧（冲突）或问题
8、协商承诺、项目内外部协调
9、负责组建和维护项目知识库,参与并积极配合过程改进活动
10、遵循公司/部门考核制度，对项目组成员进行绩效考核
11、在必要的情况下向下级授权（仅项目经理权限）
4、依据访谈记录撰写本次需求内容的用户需求说明，必要时建立相应的界面原型并于用户确认。
5、回到“1”
6、撰写《用户需求说明书》（包括需求优先等级的定义、以及需求跟踪矩阵）：在所有需求获取过程结束后，整理所有确认后的需求内容，消除其中的矛盾之处，并对其中不一致的地方进行协调和平衡。如有界面原型，进行汇整。
8、评审如果没有通过，回到“1”，或者返回到用户需求开发步骤。
输出及要求
1、《软件需求说明书》，通过了评审
2、《系统原型》，通过了评审
3、《需求跟踪矩阵》，纳入了基线管理。
备注
4
定义度量元：
(1)需求开发过程中的返工的成本、进度和工作量；
(2)需求规格说明书的缺陷密度；
5
验证方法
验证方式
验证关键点
验证时机
软件开发负责人*
1）参与、并组织系统分析工程师参与用户需求开发
2）组织软件需求分析工作
3）参与评审本过程域的工作产品
4）完成或协助完成本过程域的工作产品
5）向高层经理报告本过程域的实施情况
用户需求负责人*
1）为需求开发工作提供各种必要的环境和条件
2）负责联系用户和用户需求工程师、软件开发负责人、系统分析工程师进行用户需求开发工作
用户需求分析完成、软件需求分析完成
6
1)如果用户能够提供准确的《用户需求说明书》，则活动“制定需求开发及管理计划”可以被裁剪为只制定软件需求的开发及管理计划。
2)对于活动“用户需求开发”：1、界面原型是可选的。2、如果用户能够提供准确的《用户需求说明书》，则本活动可以被裁剪。
7
7.1
过程名称
规程/指南
输出及要求
1、《需求开发及管理计划》，通过了评审。
2、确认了所有用户需求工程师具备了进行用户需求开发的能力。
3、当补充软件需求的开发及管理计划时，要确认所有系统分析工程师具备了进行软件需求开发的能力。
备注
3.2
3.2.1
3.2.2
软件需求可以来自方方面面，这取决于所开发产品的性质和开发环境。需使用各种方法，从不同客户代表和来源收集需求，这说明了需求工程是以相互交流为核心的性质。
在实施需求开发的过程中，按项目的行业、规模和属性不同，用户需求负责人可以采用不同的方法或综合使用多种方法、分多次进行来获取需求。
用户需求开发的过程定义如下：
输入及要求
1、用户《需求开发及管理计划》，已经评审通过
2、原始需求（可选），已经生效
如果客户没有提供原始需求，则用户需求的开发活动中所做的访谈记录，也是挖掘原始需求的过程。
输入及要求
1、用户《需求开发及管理计划》，已经评审通过
2、《用户需求说明书》，通过了评审
活ห้องสมุดไป่ตู้内容
1、项目经理（软件开发负责人辅助）详细制定软件需求分析计划，补充到《需求开发及管理计划》中。
2、分析用户需求。项目经理（软件开发负责人辅助）组织系统分析工程师对《《用户需求说明书》》进行细化，以便产生详细的软件需求。
2）解决在实施本过程域中所遇到的、项目组无法解决的问题
管理
项目经理*
1、参与项目团队的组建、负责项目组人才培养和规划、项目组成员潜能的挖掘
2、遵循公司项目管理的方针和实践，选择所负责项目适用的过程；
3、负责所属系统/项目/产品的启动、策划、开发、设计、测试、验收、维护等生命周期全过程
4、负责项目策划、制订项目计划、提交审批
3、项目经理（用户需求负责人配合）就需求开发及管理计划的内容与客户进行沟通并达成一致，并确定客户代表和客户方需求负责人。
4、项目经理（用户需求负责人配合）召集并主持评审会议，对《需求开发及管理计划》进行评审。项目组的相关人员参加评审，此外还应包括客户代表。
5、当本过程进入到软件需求开发活动时，需要对《需求开发及管理计划》进行补充，内容是软件需求的开发及管理计划。由项目经理负责，系统分析工程师配合。
客户服务工程师
跟踪需求开发过程。
*：在具体的项目组织中，项目经理和用户需求负责人、软件开发负责人可能被赋予同一个人。
2.3
立项申请、可行性论证报告被批准或商务合同已经生效。
2.4
输入
具体要求
立项申请、可行性论证报告或商务合同。
立项申请、可行性论证报告被批准或商务合同已经生效。
2.5
2.6
输出
具体要求
作者
备注
0.1
2006-04-07
初始创建
目录(TABLE OF CONTENTS)
1
1.1
本文档为组织描述需求开发过程。
本文档适用于：
1)本文档适用于整个生命周期与需求开发有关的活动。
2)本文档适用于组织范围内实施CMMI过程体系的所有部门。
1.2
1.3
术语
说明
操作概念
operational concept。对每一个实体使用方法的全面描述。
1）如果客户当前已在使用一个信息系统，则需要了解当前系统的运行情况，收集用户在使用现有系统过程中所遇到问题，以及用户关于系统改进的想法。
2）如果已经开发了新产品的原型，或已有类似的产品，则通过向用户演示该系统，搜集用户的意见。
3、将本次获取到的需求整理成访谈记录，并与客户确认《访谈记录》；对于暂时无法确定的问题则标记为问题，并记录需求问题追踪表，在以后的过程中进行跟踪解决。
系统分析工程师对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。可以采用的分析步骤有：
i.建议使用RationalRose建模工具进行需求的建模分析，通过分析系统的功能模型、结构模型和行为模型，进行系统建模。建模的过程包括系统功能建模、系统数据建模和体系结构建模。在需求开发阶段应至少完成功能建模。功能建模的方式包括静态建模和动态建模。静态建模要求画出业务用例图、用例（实现）图、主要的类图和对象图，动态建模要求画出主要的状态图、活动图、时序图（可选）、以及协作图（可选）等。另外在用例图中，需标明每个用例的业务描述、业务数据、业务流程、入口条件、输出结果、异常处理等要素。
活动内容
1、用户需求负责人按《需求开发及管理计划》确定本次需求获取的内容，并在小组内部取得一致，然后与客户联系并确定进行本次需求获取的时间，地点及双方参加人员。
包括准备调查问卷、对目前市场上的产品或竞争产品进行调研、对政府或行业法规进行研究等。
2、访问客户以获得需求。主要的活动包括：与客户进行直接交流、让有关客户填写调查问卷、观察正在工作的用户等。
PPQA检查验证
PPQA检查的工作产品包括：《用户需求说明书》或软件需求说明。
过程中随时
同行评审
按照同行评审的规范进行同行评审。评审的工作产品包括：《用户需求说明书》或《软件需求说明书》。
用户需求分析完成、软件需求分析完成
高层经理验证
主要参与的审核活动包括：需求开发过程的活动、状态和结果，高层经理也负责解决有关问题。