需求开发指南(SPTDI-SPI-REQ-Guid-Rd)V1.0
- 格式：doc
- 大小：153.00 KB
- 文档页数：13
目录1.目的 (4)2.适用范围 (4)3.参考文件 (4)4.术语和缩写 (4)5.需求获取的方式 (4)5.1.与用户交谈向用户提问题 (5)5.1.1.访谈重点注意事项 (5)5.1.2.访谈指南 (5)5.2.参观用户的工作流程 (7)5.3.向用户群体发调查问卷 (7)5.4.已有软件系统调研 (7)5.5.资料收集 (8)5.6.原型系统调研 (8)5.6.1.原型功能分类 (8)5.6.2.原型形式分类 (8)5.6.3.原型评价 (9)5.6.4.注意 (9)5.7.需求评审 (9)6.需求分析的准则 (9)7.需求分析的方法 (9)7.1.绘制关联图 (10)7.2.创建开发原型 (10)7.3.可行性分析 (10)7.4.为需求建立模型 (10)7.5.创建数据字典 (11)7.6.问答分析方法 (11)8.需求开发考虑的方面 (11)8.1.功能需求 (11)8.2.非功能需求 (12)8.3.约束条件 (12)9.需求确认的方法 (12)10.需求优先级的设定 (12)10.1.参与者 (13)10.2.需求优先级 (13)1.目的介绍需求开发中用到的方法，供项目组在需求开发中学习使用。
2.适用范围适用于公司软件开发人员。
3.参考文件本文件的编写依据是美国软件工程研究院（SEI）的集成软件能力成熟度模型1.2版本（CMMI-DEV V1.2）。
4.术语和缩写需求开发Requirement Development（简称RD）：产生和分析顾客需求、产品需求和产品构件需求。
客户需求：客户及其共利益者的需要、期望、限制条件及接口要求。
产品需求：对客户需求进行分析，派生出更详细和精确的需求。
5.需求获取的方式需求获取的方式通常有下面几种，这几种方法即可以单独使用也可以组合使用，详细的内容将分章节具体介绍。
1)与用户交谈，向用户提问题。
2)参观用户的工作流程。
3)向用户群体发调查问卷。
4)与同行、专家交谈，听取他们的意见。
5)分析已经存在的同类软件产品，提取需求。
6)从行业标准、规则中提取需求。
7)从Internet上搜查相关资料。
8)公开的文献资料9)原型系统调研5.1. 与用户交谈向用户提问题5.1.1. 访谈重点注意事项1)运用作者本人的已有知识猜测或提出一些假设，请客户协助使之逐渐接近现实；2)与具有这方面专门知识的一个或几个“专家”的深谈是最主要的；3)访谈需寻找事实，以便理解当前的操作和现有的环境；讨论改进，确定新系统的操作和环境；展望发展，有助于建立未来的需求。
5.1.2. 访谈指南为了成功地进行访谈，获取尽可能多的信息，把访谈分成准备、对话、结束和总结四个阶段，每个阶段都要有很好的气氛和对答话人造成心理上的信任感。
1）准备事先想得越细越深，访谈效果必然越好。
大体上有下面几步准备工作：●选好访谈的人员（根据负责的领域、别人的推荐，或者不同层次的人员，上层人物谈大局概貌，下层的人员谈信息的细节，中层的人则弥合了这两者的间隙）；●保证与别的访谈人员协调（答话人是否已与别人谈过，如果是一次补充访谈则要检查一下原访谈结果）；●写出初步议程（访谈议题范围，避免泛泛而谈，提出专门问题）；编写问题列表或问卷。
●与被访谈人员建立联系（时间不要太长，一般为半小时到一小时，不要在临近午饭或下午很晚的时间，要讲清访谈的目的和要求）；●正式作出访谈议程，发送邮件给对话人，打电话确认时间。
2）引导访谈访谈过程中，要把握两个方面，一是信息的合格性（Qualification），另一是诱导信息流（通俗的说就是打开话匣子）。
人脑的综合速度比说话速度要快一倍，访谈人要不断在想对方应该说什么而不单是听对方正在说什么，下面这些问题可作为参考：●所提出的事实是否支持了所讨论的主要观点？●这些信息是新近的吗？●我真的理解了所说的内容吗？●所提供的细节是否适合我的目的了？●有没有漏掉什么方面？●这些信息跟别人讨论过吗？●这些信息有多重要？●是否讨论枝节问题了？●谈话的观点变掉了吗？另一方面还要诱导信息流，使答话人能提供最多最可靠的的信息。
可有下列做法：●尽量少发表评论和交谈，因为这次访谈是为了获取信息，而不是推销你的思想；●给答话者以思考时间，不要去建议这样那样的答复或提出另外的问题；谈话过程中的暂停有利于答话人回忆一些最关键的信息；●避免可能打断他思路的外界干扰，如果可能，访谈地点尽量避开答话人通常呆的地方；●要意识到内部分心的表现，答话人是否感到不舒服或者拘束；●尽可能确定一下所获得的信息是事实还是意见;●请求复述一遍或小结一下以便表达得更精确些;●弄清答话人的背景和与所讨论事物的联系，因为只有知道了他与组织或已有软件系统的关系才能了解他的评论的价值;●不要用讽刺或幽默；●不要提到或讨论其他人的任何谈话;●记下答话人提出的所有问题，除了涉及用户组织的管理、计划或人身评论的事情，谈话人应回答所有问题；●对答话人所谈的内容要表示出感兴趣；●集中精力于所讨论问题的不熟悉的和困难的方面，避开那些显而易见的事；●警惕不确切或不正确的用词，对任何不熟悉或有疑问的名词要问清定义；●不要跟答话人当面顶牛，即使他说的不符合事实；●要谦虚，答话人是专家，而不是你的访谈人；●推迟那些在商定的时间内来不及谈论的题目，与其拖长谈话时间不如另约一次；●要喜欢对同一问题的不同意见，然后用在初步需求中标明这些意见并解决矛盾；●用恰当的不急于作出结论的问题来启发答话人的思路。
3）结束访谈在下面四种情况下，应结束访谈：●访谈中所获得的信息不合适；●时间已到；●谈话人觉得信息已经饱和了；●谈话人与答话人之间个性不合。
随着不同的结束的原因，还需做下面一些事：●不要突然中止，还应有几分钟非正式讨论后结束；●小结一下谈话的主要内容；●明确一下被推迟的或未谈到的共同关心的问题；●如果需要，安排一次补充访谈；●请答话人推荐一些可以谈话的其他人；●假如谈话笔记在散发前还要请答话人检查一下的话，应在结束前讲清楚；●要对答话人的帮助表示感谢。
4）总结访谈过程中按照《需求调研报告》模板填写调研记录。
●如同一部门意见不一，则由部门领导确定意见；●如不同部门意见不一，则应再召开部门间会议统一意见。
注意：这时的会议需要不同部门的领导参加，并且不同部门的与会人的级别应相同。
如会议上不能统一意见，则报请上级确定。
5.2. 参观用户的工作流程需求开发人员需抽象和总结用户的直接活动，以确保所获取的需求具有普遍性。
主要观察业务流程、业务发生频率、业务量及业务信息。
5.3. 向用户群体发调查问卷需求开发人员根据需要制订客户调查问卷，发与被调查人员填写。
5.4. 已有软件系统调研已有软件系统可能为客户正在使用的软件系统，准备使用本项目进行替换；也可能为与本项目相近的市场已有软件系统（通过Internet网或其他渠道获取）。
●查看系统使用手册如已有软件系统有使用手册，在使用已有软件系统前，需仔细阅读。
●使用已有软件系统按照正轨业务流程详细使用已有软件系统，获取详细的信息，直接转化为需求或功能规格说明。
如有使用手册，则项目的需求或功能规格说明直接使用，而不必再重写。
●查看数据库结构说明书通过查看数据库结构，获取其设计思想。
●确定已有软件系统的运行环境和系统架构（参考《需求说明书》中“项目视图——运行环境和架构”）、编程语言（B/S或C/S,J2EE等）、数据量、数据增量●确定已有软件系统的使用范围、使用情况、价格●确定已有软件系统是否需要进行数据移植，已有软件系统是否具有数据接口，数据的质量（数据的错误率是多少）●查看其他已有软件系统资料●对已有软件系统的不足（自己认为的和客户提出的）也要记录为新需求，但更重要的是，要看已有软件系统优秀的地方。
5.5. 资料收集资料来源：Internet网、客户、相关书籍、已有软件系统。
资料种类：组织机构图、办事指南、规章制度(如ISO9001文档)、报表、单据、行业规范、国家国际标准等。
5.6. 原型系统调研通过为客户演示或客户使用原型系统，让用户对原型系统提意见或建议，以获取需求。
5.6.1. 原型功能分类原型可分为三种：1、明确并完善需求（水平原型或行为模型或模型）；2、探索设计选择方案（垂直原型或结构化原型或概念证明）；3、发展为最终产品。
原型系统调研为第一种。
第一种原型是展示给用户在界面上的功能和导航选择，而功能未真正实现。
例如一个B/S 系统的HTML页面，并可根据功能进行导航选择；但HTML页面上的数据是固定的，不是从数据库中得到的。
更抽象级别上的第一种原型还可没有详细的外形和界面元素，这时，更集中于总体需求与工作流。
主要用于：1、澄清并精华使用实例和功能需求；2、查明遗漏功能；探索用户界面等。
第二种原型，则必须实现一部分应用功能。
常用于软件设计阶段证明技术可行性、实现并优化核心算法。
第三种原型最好不要采用。
5.6.2. 原型形式分类原型还可分为两种：书面原型和电子原型。
书面原型：画在纸上或PPT上的原型；（在立项前、投标中使用最佳）电子原型：VB、Delphi、HTML页等工具制作的原型；（需求开发中使用最佳）5.6.3. 原型评价原型评价有两种方法：一种是让用户看，然后问问题，得到需求（比较常用）；另一种是让观察用户使用原型，可以问以下一些一般性问题：●原型实现的功能与你的期待一致吗？如不一致，有哪些？●有遗漏的功能吗？●有多余的功能吗？●请讲一下原型中涉及到的出错或需特殊处理的情况。
●有更简单的方法完成这一任务吗5.6.4. 注意●尽快并廉价地建立原型●对已理解的需求不要建立原型●在原型中注意使用真实的模拟数据5.7. 需求评审需求评审时发挥与会人员对项目的各种想法，使用“头脑风暴法”得出需求，具体参见《评审指南》。
6.需求分析的准则1)对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；2)将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；3)分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
7.需求分析的方法很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。
需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误、弥补不足，确保需求文档正确地反映用户的真实意图。
需求分析的方法大体有以下几种，供项目组进行需求分析时使用。
（注：许多需求开发方面的书籍都有详细的描述）7.1. 绘制关联图绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
