搜索
SoftwareEngineering软件工程第三章需求工程情景互动需求评审会项目名称：俄罗斯方块报告人：项目小组代表评审组：客户方代表、技术顾问、相关各项目小组全体成员2020年2月26日一个优秀的需求文档应具备的特征完整性、正确性•不能遗漏用户需求说明书中的必要需求。需求分析员必须在将需求进行细化时，不能丢失和改变信息，需求规格说明书必须经过用户确认。具有准确性和一致性。•它是连接计划时期和开发时期的桥梁，也是软件设计的依据。任何含混不清、前后矛盾或者一个微小的错漏，都可能导致误解或铸成系统的大错，在纠正时付出巨大的代价。可行性•描述的功能必须从技术上是可以实现的，并且满足时间、费用、质量等约束。必要性•需求规格说明书中的内容对用户来讲都是必需的，不可或缺的。划分优先级•根据需求“轻重缓急”进行分级表述，可以在有限的资源（资金、人员、时间等）情况下进行取舍，降低在实现过程遇到风险。无二义性。•因为它是沟通用户和系统分析员思想的媒介，双方要用它来表达对于需要计算机解决的问题的共同理解。如果在需求说明中使用了用户不容易理解的专门术语，或用户与分析员对要求的内容可以做出不同的解释，便可能导致系统的失败。可验证性•是软件需求的基本属性。需求必须是可验证的，否则软件评审和测试就没有相应的依据。•需求应尽量进行量化，使得其可以被验证、测试。直观、易读和易于修改。•应尽量采用标准的图形、表格和简单的符号来表示，使不熟悉计算机的用户也能一目了然。如何才能有效地描述需求？需求到底要达到一种什么样的目标呢？一、需求概述什么是需求？用户解决问题或达到目标所需要的条件或权能；系统或系统部件要满足合同、标准、规范或其他正式规定文档所要具有的条件或权能；反映上面两条的文档说明。需求工程指系统分析人员通过细致的调研分析，准确地理解用户的需求，确定客户“需要”什么样的软件。将不规范的需求陈述转化为完整的需求定义，再将需求定义写成需求规约的过程。需求工程包含需求开发和需求管理两部分。需求的捕获需求的分析标识涉众收集需求高度分散、凌乱的非结构的信息系统边界的确定需求的筛选问题陈述需求演化正式的结构化的需求解决方案设计需求的演变过程—需求的“沙漏”1.需求的演变需求获取又被称为需求捕获或需求启发发现客户需求的过程需求分析一旦提出了最初的需求，推敲和扩充的过程构建正式的需求文档2.需求工程的主要活动和文档需求开发活动需求获取需求分析编写需求规格说明书需求评审《用户需求说明书》《产品(系统)需求规格说明书》《需求评审报告》需求开发文档的区别内容•用户需求–是用自然语言加图表的形式给出的关于系统需要提供哪些服务，以及系统操作受到哪些约束的声明。•软件需求规约(需求规格说明书)–详细地给出系统将要提供的服务以及系统所受到的约束。软件需求规约文档有时也称为功能描述，应该非常精确，它可能成为系统买方和软件开发者之间合同的主要内容需求开发文档的区别读者对象客户管理者最终用户系统体系结构工程师承包商管理者客户工程师《用户需求说明书》需求开发文档的区别读者对象软件开发人员系统体系结构工程师《需求规格说明书》客户工程师最终用户需求管理活动需求变更控制版本控制需求跟踪需求状态跟踪《需求跟踪报告》《需求变更控制报告》3.需求的类型功能需求和非功能需求功能需求•描述系统所应提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。非功能需求•作为功能需求的补充，非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性、响应时间、存储空间等。非功能需求产品需求机构需求外部需求可用性需求效率需求可靠性需求性能需求空间需求可移植性需求交付需求实现需求标准需求互操作性需求道德需求立法需求隐私需求安全性需求非功能性需求的类型针对不同需求来源的需求分类领域需求•领域需求的来源不是系统的用户，而是系统应用的领域，反映了该领域的特点。它们主要反映了应用领域的基本问题，如果这些需求得不到满足，系统的正常运转就不可能。领域需求可能是功能需求，也可能是非功能需求，其确定所需的领域知识。它经常采用一种应用领域中的专门语言来描述。业务需求•反映组织机构或客户对软件高层次的目标要求，这项需求是用户高层领导机构决定的，它确定了系统的目标规模和范围。用户需求•用户使用该软件要完成的任务系统需求•容易被忽视的要求通常是为了保证整个系统能够正常运行的辅助功能,用户一般不会意识到。软件需求各组成部分之间的关系二、需求获取需求获取（requirementselicitation）也称为需求收集（requirementscapture），它是与发现目标系统应该提供的需求相关的活动的统称。1.需求获取的过程需求获取的步骤2.需求调查的主要内容环境调查包括与开发项目相关的企业的组织结构、规章制度、工艺流程、产品和服务等。新系统目标的调查将系统目标具体化，例如节约成本的手段，提高业务处理速度的方法等。管理功能和决策方式调查了解各级组织的职能和有关人员的工作内容，发现各种现存问题和薄弱环节，及对新系统的功能要求。业务流程详细了解各职能部门人员的业务分工情况和各单位人员之间业务关系、作业顺序和管理信息流动等。调查结果用业务流程图表示。数据流程收集各业务及管理岗位使用的账目、报表、单据、文件等数据，弄清这些数据的来龙去脉。需求的其他来源编写调研报告--《用户需求说明书》得出需求股票持有人想要的和需要的当前组织和系统现有文档领域模型当前状况模型建议的需求类型可复用的需求需求模板需求模板3.需求获取的方法会谈建立联合分析小组•由用户、系统分析员和领域专家构成的需求收集方法座谈会•由开发组组织用户和相关部门的经理、IT技术人员以及高层管理人员参加，目的是集中精力、缩短时间、提高搜集信息的效率和准确度；搜集资料搜集现有文档、报表等：这是最常用的方法，但必须依靠企业负责人和系统最终用户的帮助，才能获得所需文件；调查问卷：涉及调查表，对一些共性的问题进行较大范围的调查，但效果不一定好；场景系统分析师为每个用户设计一个场景，以提问的方式提取需求。学徒法实地观察工作环境，参加业务实践，对理解一些复杂细致的业务流程较为有效；原型法由于用户对系统需求的含义不甚了解，因此由系统开发人员为用户提供可以借鉴的模型系统，引导用户提出更加合理的需求。4.分析人员与用户的合作关系了解用户客户•掏钱买软件的用户最终用户•最终操作软件的用户间接用户•既不掏钱买软件，也不使用软件，但它可能对软件产品产生很大影响。分清用户的重要性5.权利和义务客户合法要求（权利）要求分析人员使用符合客户语言习惯的表达；要求分析人员了解客户的业务及目标；要求分析人员编写软件需求规约；要求得到需求工作结果的解释说明；要求开发人员尊重客户的意见；要求开发人员对需求及产品实施提供建议，拿出主意；描述产品易使用的特性；调整需求，允许重用已有的软件构件；获得满足客户功能和质量要求的系统。软件需求获取过程中客户的义务给分析人员讲解自己的业务；抽出时间清楚地说明宽完善需求；准确而详细地说明需求；及时地做出决定；尊重开发人员的需求可行性及成本评估；划分需求优先级别；评审需求文档和原型；需求出现变更要马上联系；应遵照开发组织处理需求变更的过程；尊重开发人员采用的需求工程过程。