【实用资料】需求分析PPT.ppt

需求分析软件工程5.1需求获取需求定义系统目标：业务目标；经济目标
项目范围：每一版的组织范围、业务范围、实施范围
涉众：系统的利益相关者。
相关技术标准和法规：相关法律法规、行业规范与标准、领域参考模型
涉众用户需求分类
(1)功能性需求:定义了系统做什么（描述系统必须支持的功能和过程）
(2)性能需求:定义了系统工作时的特性（响应时间、恢复时间、吞吐能力等）
可靠性和质量：系统正确性、稳定性、健壮性、安全性、可维护性
成本和进度限制：
环境和约束：实现语言及环境、系统部署环境和条件、操作环境等
外部接口：与人、硬件、其它软件和硬件的相互关系(1)功能需求(2)性能需求(3)环境需求(4)界面需求(5)用户或人的因素(6)文档需求(7)数据需求(8)资源需求(9)安全保密要求(10)软件成本消耗与开发进度需求(11)质量保证需求获取的基本原则流程的描述既要有宏观，又要有微观。即要强调总体的业务流程、全生存期的业务流程，又要对流程细化，有分支的业务流程。
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。表现在：
需求的不稳定性：在整个软件生存周期内软件需求会随着时间的推移发生变化；
需求的不准确性：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。
需求获取只有通过有效的客户/开发者的合作才能成功。需求获取技术1.弄清软件需求的层次2.产品功能、性能要求及过程要求需求调研的方法对与用户沟通的情况及时总结归纳，整理调研结果，初步构成需求基线。若基线符合要求，则需求获取完成。
需求调研的主要手段：
发调查表；
召开调查会；
向用户领域的专家个别咨询；
实地考察，
跟踪现场业务流程；
查阅与待开发系统有关的资料；
使用各种调查工具等。某出版社系统调查表某出版社系统调查表由于软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。
下面列出9个步骤，用以指导需求获取活动。定义项目的视图和范围包括组织结构图、各部门的岗位/角色列表。
确定用户类包括人员/责任矩阵。
确定目标系统的业务工作流包括物流、资金流、信息流，建立业务工作流模型。
运用需求获取技术开发用例（或数据流图）并设置优先级用以掌握主要业务规则。
收集来自用户的质量特性信息和其他非功能需求将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。分类在用例（或数据流图）中涉及的数据包括数据的组成和数据之间的关系。
详细拟订用例（或数据流图）建立功能模型，并进行审查，用以澄清需求获取的参与者对需求的理解。
开发并评估界面原型设想输入设备、输出设备、显示风格、显示方式、输出格式等，建立接口规范和信息流传输规则。
从功能描述中开发概念测试用例用测试用例来验证用例（或数据流图）、功能需求和原型。需求整理与表达的方法需求确认5.2需求分析软件开发是要实现目标系统的物理模型。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。需要能够表达和理解问题的信息域和功能域
信息流：数据和控制通过一个系统时的变化方式。两个功能之间的数据/控制传递就确定了功能间的接口。
信息内容：单个数据或控制对象，它们构成了某个更大的由软件变换生成的信息的集合。
信息结构：各种数据和控制项的内部组织。以层次化的方式对问题进行分解和不断细化系统分析的目标需求分析的任务需求分析的过程可以分成四个阶段：
问题识别（需求获取）
刻划出软件的功能和性能需求；
明确用户界面需求；
指明软件与其他系统元素的接口需求；
建立软件必须满足的约束。
从系统角度来理解软件并评审用于产生计划估算的软件范围是否恰当；
确定对目标系统的需求；
提出这些需求实现条件，以及需求应达到的标准；
修正系统开发计划。问题识别的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分析。分析与综合，导出软件的逻辑模型（需求建模）
进行各种要求的一致性检查；
逐步细化所有的软件功能；
分解数据域，分配给各个子功能；
找出系统各成分之间的联系、接口特性和设计限制。
判断是否存在不合理的用户要求或用户尚未提出的潜在要求。
综合成系统的解决方案，给出目标系统的详细逻辑模型。编制需求分析阶段的文档
软件需求规格说明；
初步的用户手册；
确认测试计划；
修改和完善软件开发计划。
需求评审
作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备性、准确性和清晰性，以及其它需求给予评价。5.需求整理与表达的方法给出系统的逻辑视图和物理视图
软件需求的逻辑视图给出的是软件要达到的功能和要处理的数据之间的关系，而不是实现的细节。
软件需求的逻辑描述是软件设计的基础。
软件需求的物理视图给出的是处理功能和数据结构的实际