软件项目需求分析

交通运输部管理干部学院QQ:447477039Mail:[e-mail]软件工程与项目管理主讲教师：钱哨（副教授）第五章、软件项目需求分析为什么要做需求管理？一天，一家爱斯基摩人来找你帮忙做一个杯子。要求：这个杯子在使用时要能适应北极的环境。这家人承诺：杯子做好后会有高额的酬谢。你心里想：所谓适应北极环境。北极的地面很硬。那应该做一个结实的杯子。于是你历经千辛万苦做出了：爱斯基摩人不断摇头，决定一分钱也不付给你。最后你才知道，他们需要一个拿着不冻手的杯子。他们的真实需求是这样的：为什么要做需求管理？•客户不知道自己要什么–客户：塑料杯、木头杯、还是橡胶杯，我也不知道！•客户知道自己要什么，但表达不清–客户提要求：使用时要能适应北极的环境。•我们经常会对客户的要求产生错误的理解–我们的理解：他一定要一个结实的杯子！我们不能知其然，而不知其所以然。要做好需求管理。什么是《需求规格说明书》？《需求规格说明书》概念软件开发项目中用于明确定义系统需求的文档。•需求规格说明书的作用–开发者与用户间事实上的技术合同书–开发者下一步设计和编码的基础–测试验收目标系统的依据•功能性需求：用来描述系统所应提供的功能和服务–系统功能–输入输出–异常•非功能性需求：不直接与系统的具体功能相关的一类需求–安全性–可扩展性–响应时间《需求规格说明书》的构成用例详细描述-格式•前置条件–用例开始时会发生什么•事件流–用例执行的各个步骤•后置条件–用例结束时会发生什么用例详细描述–示例•前置条件：系统管理员登录系统•事件流：1、系统管理员在系统菜单中选择“用户管理”时用例开始2、系统管理员可以增加一个系统用户3、系统管理员可以根据用户名查询系统用户4、对于每一个用户a）系统管理员可以查看该用户的详细信息b）系统管理员可以为该用户分配角色c）系统管理员可以删除该用户循环结束。•后置条件：系统管理员执行的用户管理动作生效为什么要用静态原型法？•遇到下面的问题，你该怎么办？–耗时耗力地完成了系统，用户却说这根本不是他想要的？–系统完成了，可用户突然说，能不能换套系统界面？–项目开发完一半了。用户说，你说开发完一半了，给我演示看看？静态原型法可以帮助我们避免这些问题。什么是静态原型法？•以少量代价快速地构造一个可执行的软件系统模型–使用户和开发人员可以较快地确定需求静态原型法的实施•快速建立一套用户界面原型–体现主要的功能（操作命令的使用）–提供基本的界面风格（菜单格式、输出格式）•原型的表现工具–HTML–MSVisio–MSPowerPoint–...需求管理小结•用例详细描述中的前置条件、后置条件和事件流分别是什么含义？•在项目开发过程中使用静态原型法有什么好处？•什么是《需求规格说明书》？为什么要做设计？一天，上帝来到小王的家里，请他帮忙制作两个人！小王理解了上帝的需求，没有做设计，直接开始动手。做到一半之后，小王发现越做越不对，然后反复的修改，疲惫不堪…最后期限到来，上帝来向小王要人。小王面带羞涩的将他的工作成果拿给上帝…想象一下此时上帝的表情！什么是软件设计？•软件需求：系统“做什么？”–上帝要求：我要做两个人（软件系统）！•软件设计：系统“怎么做？”–人的骨架（系统框架）应该怎么做...–人的大脑（系统数据库）应该怎么做...–人的皮肤（系统界面）应该怎么做...–人的性格（系统性能）应该怎么做...设计的目标就是使所设计的系统能够被开发方顺利地实现，并且恰如其分地满足用户的需求•概要设计–描绘出软件的概貌•详细设计–在概要设计的基础上再将其细化，得到一个非常接近于源代码的设计表达形式软件设计的两个阶段软件设计详细设计概要设计软件概要设计•概要设计–系统设计：系统具体的技术方案，与其他系统的接口方式系统设计需要考虑到：硬件环境、软件环境、网络环境用户操作水平团队技术能力开发时间限制–结构设计：确定程序是由哪些模块组成的，各模块分别完成什么样的功能，它们之间存在着什么样的关系概要设计的核心是系统框架设计软件详细设计(1)•详细设计的核心是将业务模型映射到技术模型–业务模型–技术模型执行selectbook_namefromsys_bookwherebook_no=[书籍编号]andbook_status='已预订'andbook_subscribe_stu_no[学生借书卡编号]。如果查询到1条记录，则抛出异常，异常信息为：“图书《[图书名称]》已经被预订，不能借出。”；否则，继续处理。学生到图书馆申请借书，图书管理员登录图书管理系统。首先，检查这本书是否已经被预订了，如果已被预订则不能借出。软件详细设计(2)•详细设计还包括–实现某一功能时，具体包含哪些类、方法、类。以及类之间的关系和调用顺序–对应的界面如何展示，如何交互，界面间如何切换–核心算法的伪代码–数据库设计的工作需求分析是软件项目的立足之本•需求分析是整个软件项目开展工作的基础，需求分析质量的好坏，直接关系到软件项目交付成果的客户满意度，甚至整个项目的成败。•如果需求分析工作做的不扎实，无论设计阶段工作完成得如何出色、软件编码质量如何高，其结果将只会给用户带来失望，给开发者带来失败的苦恼。软件需求在软件项目中的作用：需求分析主要工作内容•刻画出软件系统的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束条件；•建造软件体系结构，分解软件系统模块，建造软件处理的数据、界面和处理流程的设计模型；•提交需求分析说明书，形成软件项目管理过程的第一个里程碑成果。需求分析阶段的主要任务•问题分析（即如何获取需求？）•需求描述（即如何定义需求？）•需求的验证•这一阶段，系统分析人员应该将自己对客户需求及问题的理解与自己所拥有的软件开发经验结合起来，以便发现哪些需求是由于用户的片面理解和短期行为所提出的不合理的要求，哪些要求是由于尚未提出但拥有真正价值的潜在要求。（1）问题分析•以需求模型为基础，考虑问题的软件可解性，生成需求规格说明书和初步的用户手册。•需求规格说明书包含对目标系统外部行为的完整描述、需求验证标准以及用户对系统在性能、质量、对维护性等方面的要求。•用户手册则包括用户界面描述以及有关目标系统使用方法的初步构想。（2）需求描述（3）需求验证•分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明书进行复核，以确保软件需求的全面性、精确性、一致性、可行性以及用户的认同，并使用户和软件设计人员对需求规格说明及用户手册的理解达成共识，达成对目标系统理解的一致性。一旦发现遗漏和模糊点，必须进行检查，尽快更正。．软件需求的抽象层次项内容：（1）系统的输入（2）系统的输出（3）系统的功能（4）系统的属性（5）系统环境的属性系统需求的描述语言结构化语言是对自然语言格式化，依赖于定义标准格式或模板来表达需求描述表现能力强易于理解一致性约束控制结构图形化显示仍然有一定程度的二义性；细致程度欠缺名称说明优点缺点过程设计语言PDL源于像Java或Ada这样的程序设计语言，包含附加的、更抽象的构造来提高其表达能力通过软件工具进行语法和语义检查表达系统功能的能力不足使用的符号只有具有程序设计背景的人才能理解系统需求的分类(1)功能需求（2）非功能需求（3）领域需求个过程（1）系统分析员和用户开展面对面的交流，记录用户提供的信息，即开展获取活动；（2）需求分析员处理从用户那里获取的信息并理解它们，把他们分成不同的类别，并将客户需求同可能的软件需求相联系，即开展分析活动；（3）系统分析人员将客户需求信息结构化，编写成文档和示意图，形成需求规格说明书；（4）组织用户代表评审文档并纠正存在的错误，完成需求的验证工作。需求分析的工作模式需求三步法：第一步：“访谈式”第二步:“诱导式”第三步:“确认式”第一步:“访谈式”•和具体用户方的领导层、业务层人员进行访谈式沟通，主要目的从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有系统等具体情况，建立起良好的沟通渠道和方式。•针对具体的职能部门，最好能制定本次项目的接洽人。图需求分析第一阶段角色及工作流程用户方分析人员项目经理支持确认执行反馈协调协同监督输出结果•访谈备忘录•调查结果•业务流程报告•……配合请求/计划需求分析第一阶段•组织构架•业务流程•软硬件环境•现有的运行系统•用户的需求描述访谈、发放调查表格第二步:“诱导式”是在分析人员已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等信息的基础上，结合现有的硬件、软件实现方案，做出简单的用户流程和操作界面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、方便性、习惯性和操作性。配合审查执行反馈协调协同监督输出结果•访谈备忘录•调查分析报告•业务流程反馈报告•……确认请求/计划需求分析第二阶段用户方分析人员项目经理诱导、演示、模拟•组织构架•业务流程•软硬件环境•现有的运行系统•用户的需求描述图需求分析第二阶段角色及工作流程•在前两个阶段成果的基础上，进行具体的流程细化，数据项的确认阶段。•这个阶段的分析人员需要完成明确的业务流程报告、数据项描述，最好能够提供修改后的DEMO系统，并能清晰地向用户描述系统的业务流程设计目标。•用户可以通过审查业务流程报告、数据项描述以及通过操作开发方提供的DEMO系统，提出反馈意见，并对已经完成并可接受的报告、文档签字确认。第三步：“确认式”配合确认执行提交协调协同审查输出结果•原始演示系统•调查分析报告提议请求/计划需求分析第三阶段用户方分析人员项目经理诱导、演示、模拟•业务流程报告•软件环境报告•现行系统接口报告•用户的需求描述图需求分析第三阶段角色及工作流程软件需求文档软件项目客户了解软件项目能够提供的软件产品，检查软件需求是否满足需要项目管理人员根据需求文档制定项目的开发计划和软件过程，初步预测资源的使用软件开发人员理解要开发的产品及具体要开发的内容软件测试人员验证软件系统是否满足了预期的要求软件维护人员使用需求文档帮助理解软件系统内在的逻辑关系软件发布人员在需求文档的基础