需求开发指南

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