软件工程概论ch需求分析概述PPT课件

目录,第1章绪论第2章可行性分析与项目计划第3章需求分析第4章概要设计第5章详细设计第6章编程与测试第7章软件维护第8章面向对象的方法第9章面向对象的需求获取第10章面向对象的分析第11章面向对象的设计第12章面向对象的测试,第3章软件需求分析,可行性研究通过以后，下一步就要根据草拟的开发计划，展开详细的需求分析活动。软件需求分析，是详细分析需求，并建立需求分析模型的阶段,第3章软件需求分析,3.1需求分析概述3.2结构化分析方法3.3数据流图的绘制3.4编制数据字典3.5加工逻辑的分析与表达3.6原型技术3.7需求验证与评审,3.1需求分析概述,3.1.1需求分析的任务、特点、主要困难3.1.2人员组成3.1.3分析师的角色3.1.4需求分析的活动和原则,3.1.1需求分析的任务,完成“分析建模”;拟定“确认测试”计划修订“开发计划”编写“需求规划说明书”需求评审,1.分析建模,针对用户要求实现的软件功能、性能等目标，与开发人员进一步澄清、达成共识、形成规约;准确讲，需求分析是发掘需求、分析求精、逻辑建模、形成规约的过程。,1.分析建模,发掘需求调查需求、挖掘潜在需求、预测未来可能的需求；需求求精对模糊不清的用户需求明确、精化；逻辑建模在现行系统逻辑模型的基础上，考虑新的用户需求、限制和约束的基础上导出新系统的逻辑模型；形成规约将双方达成共识的需求文档化、模型化，这份文档被称为“需求规约”和“需求规格说明书”，它将是后需活动开发方努力实现的目标,2.拟定“确认测试”计划,有了共同的需求约定以后，就可以制定“确认测试”计划，它是用户验证软件是否满足需求的依据；这个计划到综合测试后期执行。,3.修订开发计划,系统调查与可行性研究阶段的最后，草拟了初步的开发计划，当时由于需求尚不详细，现可有了详细的需求分析结果以后，应该使开发计划更准确一些。,4.编写“需求规划说明书”,需求分析阶段的成果集中体现在“需求规格说明书”中，这是一个里程碑；,“需求规划说明书”的内容,有明确的格式和内容,5.需求评审,需求评审是“质量保证活动”的内容；体现出瀑布模型的“文档驱动”特点由项目经理、用户、分析员、前一阶段（可行性研究）的主要人员和后一阶段（概要设计）的主要人员组成评审小组；,阶段性成果（主要文档）包括：,需求规格说明书细化的项目计划确认测试计划,主要特点:,面向问题域（即用户业务领域）只关注“逻辑”，不考虑“物理”只研究应该“做什么？”，暂不考虑用什么手段、如何实现，即“怎么做”的问题；用数流据图、数据字典、加工描述等工具建立逻辑模型,面临的主要困难,需求分析活动面临的挑战：使用有效的软件工程方法克服复杂性建立分析员与用户的有效沟通使用有效的工具，克服需求表述的二义性,3.1需求分析概述,3.1.1需求分析的任务、特点、主要困难3.1.2人员组成3.1.3分析师的角色3.1.4需求分析的活动和原则,3.1.2人员组成,如果是一个企业信息系统开发项目，那么项目团队成员应包括用户和开发人员；参与团队的用户包括：企业负责人、部门负责人、专业岗位上的员工；参开团队的开发人员包括：系统分析师、数据管理员；在需求评审时，还需要”可行性分析“和”系统设计“阶段的主要人员参与；,3.1需求分析概述,3.1.1需求分析的任务、特点、主要困难3.1.2人员组成3.1.3分析师的角色3.1.4需求分析的活动和原则,3.1.3分析师的角色,是用户与开发人员的桥梁；与项目经理合作，是开发团队的领军人物；具体业务主要集中在可行性研究和需求分析阶段；个人素质方面：具有领导才能，善于沟通；具有实干作风；知识面宽，重在广度而不是深度；技术全面；有时分析师是一个团队，由若干人承担；,3.1需求分析概述,3.1.1需求分析的任务、特点、主要困难3.1.2人员组成3.1.3分析师的角色3.1.4需求分析的活动和原则,3.1.4需求分析的活动和原则,活动主要分为：需求获取；分析建模；需求评审,需求获取的目标,对用户需求进行鉴别、综合，清除用户需求的模糊性、歧义性和不一致性；把对原始问题的理解和软件开发经验结合起来，鉴别由于用户的片面性或短期行为所导致的不合理要求，发现用户尚未发现的但具有真正价值的潜在需求；,需求获取中风验,需求获取隐藏着很大的风险任何错误的需求描述，都必然造成错误的设计、错误的编程和错误的软件结果,需求获取的困难,第一，通讯渠道不畅，数据管理不严第二，专业领域知识的鸿沟对分析师的业务技能是一个绝对的挑战第三，对分析活动没有系统的工作方法,第一，通讯渠道不畅，数据管理不严,用户和开发者之间免不了会有错误的解释或误传的可能性，造成需求模糊、错误或二义性。解决这个问题的原则是：建立有效的通信渠道，如调查、座谈会、交流、报告会、电子文档等，做好数据管理，充分发挥数据字典的作用。,第二，专业领域知识的鸿沟,用户想要什么他说不清，分析师告诉他新系统将会做什么他听不懂分析师由于受计算机专业知识影响，容易把用户拒之门外。例如，每当用户提出一个问题，分析师都马上回答用计算机是如何实现的，或探讨应该如何用计算机实现，使得用户无法参与交流解决这个问题的原则是：避免使用计算机专业术语。在访谈时，不要试图把用户带到自己的专业知识领域探讨问题。好的作法是，使用大家都能看得懂的图形工具描述问题。如数据流图、IPO图、功能目标图等。,第三，对分析活动没有系统的工作方法,没有成熟的系统的策略，需求获取和分析没有章法，不分主次，容易陷入数据堆中。有些分析人员在获取用户需求时，经常是随意地问一些主要的问题，记录下回答，然后继续这样问下去。这种不规范的做法常常导致分析师与用户的思路前后不连贯，效率低下。,第三，对分析活动没有系统的工作方法,解决上述问题的原则是：一方面，以数据为出发点，或是以功能为出发点，利用系统的过程性的特点，顺藤摸瓜。以绘制数据流图为线索，安排需求的调查和挖掘的顺序。另一方面，合理掌握问题的抽象级别，分析绘制上层数据流图时，不要把问题考虑的过细。这好比是拔洋葱皮，需要采取由表及里，自上而下挖掘和剖析的策略。,总的原则,分析师关注的焦点是“做什么（What）”，而不是“怎么做How”，系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会遇到什么约束？等。这一阶段主要精力集中在获取和分析系统的逻辑功能上。不要把“用计算机如何实现”这样的物理因素牵扯进来，影响逻辑功能的分析。,3.1.4需求分析的活动和原则,活动主要分为：需求获取；分析建模；需求评审,分析建模；,由于用户往往会从不同的角度、不同的抽象级别中阐述对原始问题的理解和需求，相对比较另零乱，有必要借助模型。一方面，模型用于精确地记录用户从各个视角、不同抽象级别上对原始问题及目标软件的描述；另一方面，它将帮助分析人员去伪存真、由表及里地挖掘用户需求。不同的方法有不同的建模规则，但建模的用途都是一致的，它不仅是描述系统的工具，也是用户与开发人员进行交流的工具。例如，在面向对象的分析方法中，要建立对象模型，而在结构化分析方法中，数据流图则是建模的主要工具。逻辑模型不仅是描述问题的图形工具，同时更是分析问题的一种工作方法。,分析建模；,调研阶段产生的文档，是需求分析的起点，是目标软件系统逻辑模型的雏型。在需求分析阶段，分析师将进一步对它进行细化、扩充，直到足够具体为止。在分析的过程中建立数据字典，对模型进行注解。逻辑模型是分析师与用户交流的主要工具，也是需求分析阶段的成果的主要体现。,3.需求评审,需求审查和管理复审是需求分析的最后一个环节，通过了这一环节，就等于暂时为需求分