需求分析方法

1、目录目录目录在一个以 软件架构为中心 的软件项目开发过程中，需求分析在概念化阶段和架构设计之间。软件需求的基础知识概念化阶段分析阶段架构设计阶段详细设计阶段并行开发与测试阶段验收与交付阶段交付的系统软件需求规格软件架构文档软件设计文档代码及集成系统愿景文档软件需求的基础知识IEEE将需求定义为：1.用户所需的解决某个问题或达到某个目标索要具备的条件或能力。2. 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足条件或必须具备的能力。RUP（统一软件开发过程）将需求定义为：1.需求描述了系统必须满足的情况或提供的能力，它可以是直接来自客户需求，也可以来自合同、标准、规范或其他有正规约束

2、力的文档。软件需求的基础知识软件需求非功能需求功能需求约束开发期质量属性运行期质量属性界面需求软件架构重点关注的是质量属性。架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性。商业需求软件需求的基础知识p 功能需求 描述要开发的 软件系统应该做什么，既包括为用户提供的服务，又包括本系统为其他系统提供的服务。p 非功能需求 包括质量属性，界面需求，约束 以及 商业需求。质量属性是架构设计最受关注的需求。架构设计通常不涉及界面需求。约束需求规定了开发软件系统时必须遵守的限制条件。如：为了获得相关行业或组织的认可，或者大型企业集团处于长期整合规划的要求；软件的设计和开发可能还必须遵守相关行

3、业标准、企业标准等约束。商业需求可能包含系统的上线时间要求，成本因素等。软件需求的基础知识p 软件质量属性分为运行期质量属性和开发期质量属性两大类：开发期质量属性包含了和软件开发、维护和移植这三类活动相关的所有质量属性；开发期质量属性是开发人员、开发管理人员和维护人员都非常关心的，对最终用户而言，这些质量属性只是间接地促进用户需求的满足；运行期质量属性是软件系统在运行期间，最终用户可以直接感受到的一类属性，这些质量属性直接影响着用户对软件产品的满意度。软件需求的基础知识运行期质量属性开发期质量属性性能（Performance）安全性（Security）易用性（Usability）可用性（Ava

4、ilability）可伸缩性（Scalability）互操作性（Interoperability）可靠性（Reliability）鲁棒性（Robustness）易理解性（Understandability）可扩展性（Extensibility）可重用性（Reusability）可测试性（Testability）可维护性（Maintainability）可移植性（Portability）软件需求的基础知识p 性能（Performance）：软件系统及时提供相应服务的能力，包括速度、吞吐量和持续行三个方面的要求吞吐量通过单位时间处理的交易数来度量速度往往通过平均响应时间来度量持续时间是指保持高速处

5、理速度的能力p 安全性（Security）：软件同时兼顾向合法用户提供服务，以及阻止非授权使用的能力p 易用性（Usability）：软件易于使用的程度p 持续可用性（Availability）：在预定的运行时间中，系统真正可用并且完全运行时间所占的百分比。软件需求的基础知识p 可伸缩性（Scalability）：当用户数和数据量增加时，软件系统维持高服务质量的能力p 互操作性（Interoperability）：本软件系统与其他软件系统交换数据和相互调用服务的难易程度p 可靠性（Reliability）：软件在一定时间内无故障运行的能力p 鲁棒性（Robustness）：软件系统在以下情况仍

6、能够正常运行的能力：用户进行了非法操作；相连的软硬件系统发生了故障，以及其他非正常情况。软件需求的基础知识 提高可靠性需要强调减少系统中断（故障）的次数，提高可用性需要强调减少从灾难中恢复的时间。 A系统每年因故障中断十次，每次恢复平均要20分钟，B系统每年因故障中断2次，每次需5小时恢复。则A系统可用性比B系统高，但可靠性比B系统差。 可靠性的量化指标是周期内系统平均无故障运行时间，可用性的量化指标是周期内系统无故障运行的总时间。一般提高可靠性的同时，也同时提高了可用性。 要提高可靠性，可使用变更管理，UPS，RAID，Cluster，链路冗余等管理和技术手段减少系统Down机的可能性。要提

7、高可用性，除提高可靠性外，还可以使用合理备份，业务连续性计划等方式来减少从灾难中恢复的时间。软件需求的基础知识p 易理解性（Understandability）：指设计被开发人员理解的难易程度p 可扩展性（Extensibility）：为适应新需求或需求变化为软件增加功能的能力p 可重用性（Reusability）：重用软件系统或者其中一部分的能力的难易程度p 可测试性（Testability）：对软件测试以证明其满足需求规约的难易程度p 可维护性（ Maintainability）：对软件运行时进行维护的难易程度p 可移植性（Portability）：将软件系统从一个环境转移到另一个环境的难

8、易程度软件需求的基础知识功能需求架构质量属性约束导致某些功能需求导致某些质量属性需求支持限制影响适应更大的影响遵守软件需求的基础知识p 需求的变更既蕴含了风险，又包含了机遇p 需求变更可能有三类来源我们要解决的问题发生了变化我们对问题的理解发生了变化我们理解问题的过程有误软件需求的基础知识p 功能需求最易变，而质量属性需求最稳定p 功能需求的易变性中潜藏着两类不易变性功能需求中存在少量长期稳定的功能功能点本身趋于稳定p 约束性需求的稳定性稍差，技术趋势发生变化、法律规范重新界定、用户组织调整，都有可能使约束性需求变更易变更性 （从低到高）质量属性需求约束性需求功能需求软件需求分析实践p 需求获

9、取五步法1.收集资料，了解概况，初步划定范围2. 识别所有可能的需求提供者3. 准备需要了解调研的问题4. 调查和访谈5. 总结归纳，准备新的问题，多次迭代软件需求分析实践p 需求获取的方式与用户个别交流需求讨论会查阅相关文档分发问卷调查表现场访问客户业务流程分析同类产品分析根据现有系统推导需求回顾以往项目观察用户对原有系统的使用软件需求分析实践p 识别所有可能的需求提供者谁使用该系统谁维护该系统谁需要从系统中获取数据系统会影响到谁谁推广该系统谁测试该系统谁生产该系统谁购买该系统软件需求分析实践p 需求获取的常用技术需求访谈推荐3人访谈小组（1人提问，1人记录，1人辅助）用例技术最终用户使用用

10、例来模拟 用户与系统之间交互用例可以看作是解释如何使用系统的经历原型法需求原型；设计原型；产品原型纸上原型；界面原型；可执行原型抛弃型原型；演化型原型专题讨论会（头脑风暴）软件需求分析实践p 消除原始需求中存在的：冲突重叠遗漏不一致不切实际的p 细化需求p 划分需求的优先级p 需求建模软件需求分析实践p 穷举：确保需求无遗漏p 分类：确保需求无遗漏并去除冗余的需求p 分层：结构化表达需求p 抽象：识别出稳定与变化的需求软件需求分析实践提出者获取方法文档量文档形式评审方式稳定性返工影响优先级的确定者目标需求高层经理访谈几页ppt,word正规评审会最稳定最大客户业务需求中层经理访谈几十页exce

11、l,word正规评审会较稳定次之客户操作需求操作员+开发人员原型几十页,上百页word非正式评审会,正规评审会,分多次评审最易变化局部影响客户+开发人员软件需求分析实践p 步骤一：列举需求1.消除客户需求中的矛盾与不一致2. 补充遗漏的客户需求3. 删除不必要的需求4. 定义非功能性需求5. 定义外部接口需求软件需求分析实践p 步骤二：整理需求1.功能分解2. 定义内部接口3. 平衡需求、进度、质量与投入4. 识别需求相关的风险5. 对需求进行分类6. 划分需求优先级7. 识别可复用需求8. 建立需求分析模型软件需求分析实践p 步骤三：需求建模需求建模方法结构化建模IPOER图数据流程数据字典

12、面向对象建模USE CASE 模型USE CASE 图USE CASE 描述静态建模类图包图动态建模交互图简单的理解为将自然语言描述的需求转换为开发人员能够理解的设计语言。软件需求分析实践p 步骤四：设定系统目标与划分系统范围 目标 要解决的核心问题是什么? 为解决该问题的约束有哪些? 范围 哪些是系统应该完成的任务? 哪些不是系统的责任? 从广度与深度2个纬度考虑范围 广度：覆盖的业务,部门,功能 深度：做到什么程度？ Gilb的模糊目标定律：一个没有明确目标的项目，是不可能明确地实现其目标的。 软件需求分析实践p 步骤五：划分需求的优先级1.优先级的分配由系统分析员和客户一起完成2. 优先

13、级一般分为3级，不宜定义太多的等级3. 帮助客户定义优先级的问题：最重要的3个需求是什么？是否有其他方法可以满足这一需求？如果忽略或者推迟实现这一需求，其后果是什么？如果不立即实现这一需求，对项目目标会有什么影响？4. 需求的优先级可以从两个层次来划分用户划分宏观的优先级：需求优先级开发划分微观的优先级：特性优先级5. 需求的优先级影响了开发顺序和开发计划软件需求分析实践p 步骤六：使用需求分析检查单来分析需求1.检查单中的问题：需求中包含不成熟的设计或实现信息吗？这项需求还可以细分为不同的需求吗？这项需求只是系统的装饰，而不是真正必须的吗？这项需求符合系统的目标吗？这项需求存在二义性吗？这项

14、需求可以实现吗？这项需求是可测试的吗？软件需求分析实践正确清楚无二义性一致必要完备可实现可验证确定优先级阐述“做什么”，而不是“怎么做”软件需求分析实践ReleaseProduct BacklogSprint4 weekSprint BacklogDaily meetingsBurn downScrum开发模型软件需求分析实践检查文档是否符合标准组织正式的需求审查需求审查应有一个多学科的小组来进行使用原型来确认需求编写用户手册草案设计测试用例检查文档是否符合标准组织正式的需求审查需求审查应有一个多学科的小组来进行使用原型来确认需求编写用户手册草案设计测试用例检查文档是否符合标准组织正式的需求审查需求审查应有一个多学科的小组来进行使用原型来确认需求编写用户手册草案设计测试用例检查文档是否符合标准组织正式的需求审查需求审查应有一个多学科的小组来进行使用原型来确认需求编写用户手册草案设计测试用例软件需求管理p 需求变化的原因1.误解2. 遗漏了需求3. 外部环境发生了变化，产生了新的需求软件需求管理秃头论证稻草原理蚂蚁效应软件需求管理商务手段沟通手段技术手段管理手段ReleaseProduct BacklogSprint4 wee