需求分析方法

需求分析方法一．软件需求的基础知识目录1.1需求分析在软件开发中所处的位置1.2什么是软件需求1.3软件需求的类型1.4软件需求的分类1.5质量属性的分类1.6需求对架构的影响1.7需求的易变更性二.需求分析实践目录2.1需求的获取2.2需求分析的目的2.3需求分析的思维方式2.4软件需求的分层2.5需求分析的步骤2.6好的需求有哪些特征2.7需求验证与确认三.需求管理目录3.1需求总是变化的3.2需求是渐变的3.3如何应对需求变更一．软件需求的基础知识在一个以软件架构为中心的软件项目开发过程中，需求分析在概念化阶段和架构设计之间。软件需求的基础知识概念化阶段分析阶段架构设计阶段详细设计阶段并行开发与测试阶段验收与交付阶段交付的系统软件需求规格软件架构文档软件设计文档代码及集成系统愿景文档1.1需求分析在软件开发中所处的位置“这个软件到底要为用户做什么？”软件需求的基础知识1.2什么是软件需求IEEE将需求定义为：1.用户所需的解决某个问题或达到某个目标索要具备的条件或能力。2.系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足条件或必须具备的能力。RUP（统一软件开发过程）将需求定义为：1.需求描述了系统必须满足的情况或提供的能力，它可以是直接来自客户需求，也可以来自合同、标准、规范或其他有正规约束力的文档。软件需求的基础知识软件需求1.3软件需求的类型非功能需求功能需求质量属性约束开发期质量属性运行期质量属性界面需求软件架构重点关注的是质量属性。架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性。商业需求软件需求的基础知识1.4软件需求的分类功能需求描述要开发的软件系统应该做什么，既包括为用户提供的服务，又包括本系统为其他系统提供的服务。非功能需求包括质量属性，界面需求，约束以及商业需求。•质量属性是架构设计最受关注的需求。•架构设计通常不涉及界面需求。•约束需求规定了开发软件系统时必须遵守的限制条件。如：为了获得相关行业或组织的认可，或者大型企业集团处于长期整合规划的要求；软件的设计和开发可能还必须遵守相关行业标准、企业标准等约束。•商业需求可能包含系统的上线时间要求，成本因素等。软件需求的基础知识1.5质量属性的分类软件质量属性分为运行期质量属性和开发期质量属性两大类：•开发期质量属性包含了和软件开发、维护和移植这三类活动相关的所有质量属性；•开发期质量属性是开发人员、开发管理人员和维护人员都非常关心的，对最终用户而言，这些质量属性只是间接地促进用户需求的满足；•运行期质量属性是软件系统在运行期间，最终用户可以直接感受到的一类属性，这些质量属性直接影响着用户对软件产品的满意度。软件需求的基础知识1.5质量属性的分类运行期质量属性开发期质量属性性能（Performance）安全性（Security）易用性（Usability）可用性（Availability）可伸缩性（Scalability）互操作性（Interoperability）可靠性（Reliability）鲁棒性（Robustness）易理解性（Understandability）可扩展性（Extensibility）可重用性（Reusability）可测试性（Testability）可维护性（Maintainability）可移植性（Portability）软件需求的基础知识1.5质量属性的分类性能（Performance）：软件系统及时提供相应服务的能力，包括速度、吞吐量和持续行三个方面的要求•吞吐量通过单位时间处理的交易数来度量•速度往往通过平均响应时间来度量•持续时间是指保持高速处理速度的能力安全性（Security）：软件同时兼顾向合法用户提供服务，以及阻止非授权使用的能力易用性（Usability）：软件易于使用的程度持续可用性（Availability）：在预定的运行时间中，系统真正可用并且完全运行时间所占的百分比。软件需求的基础知识1.5质量属性的分类可伸缩性（Scalability）：当用户数和数据量增加时，软件系统维持高服务质量的能力互操作性（Interoperability）：本软件系统与其他软件系统交换数据和相互调用服务的难易程度可靠性（Reliability）：软件在一定时间内无故障运行的能力鲁棒性（Robustness）：软件系统在以下情况仍能够正常运行的能力：用户进行了非法操作；相连的软硬件系统发生了故障，以及其他非正常情况。软件需求的基础知识1.5质量属性的分类提高可靠性需要强调减少系统中断（故障）的次数，提高可用性需要强调减少从灾难中恢复的时间。A系统每年因故障中断十次，每次恢复平均要20分钟，B系统每年因故障中断2次，每次需5小时恢复。则A系统可用性比B系统高，但可靠性比B系统差。可靠性的量化指标是周期内系统平均无故障运行时间，可用性的量化指标是周期内系统无故障运行的总时间。一般提高可靠性的同时，也同时提高了可用性。要提高可靠性，可使用变更管理，UPS，RAID，Cluster，链路冗余等管理和技术手段减少系统Down机的可能性。要提高可用性，除提高可靠性外，还可以使用合理备份，业务连续性计划等方式来减少从灾难中恢复的时间。软件需求的基础知识1.5质量属性的分类易理解性（Understandability）：指设计被开发人员理解的难易程度可扩展性（Extensibility）：为适应新需求或需求变化为软件增加功能的能力可重用性（Reusability）：重用软件系统或者其中一部分的能力的难易程度可测试性（Testability）：对软件测试以证明其满足需求规约的难易程度可维护性（Maintainability）：对软件运行时进行维护的难易程度可移植性（Portability）：将软件系统从一个环境转移到另一个环境的难易程度软件需求的基础知识1.6需求对架构的影响功能需求架构质量属性约束导致某些功能需求导致某些质量属性需求支持限制影响适应更大的影响遵守关键需求决定架构，其他需求验证架构。软件需求的基础知识1.7需求的易变更性需求的变更既蕴含了风险，又包含了机遇需求变更可能有三类来源•我们要解决的问题发生了变化•我们对问题的理解发生了变化•我们理解问题的过程有误软件需求的基础知识1.7需求的易变更性功能需求最易变，而质量属性需求最稳定功能需求的易变性中潜藏着两类不易变性•功能需求中存在少量长期稳定的功能•功能点本身趋于稳定约束性需求的稳定性稍差，技术趋势发生变化、法律规范重新界定、用户组织调整，都有可能使约束性需求变更易变更性（从低到高）质量属性需求约束性需求功能需求二.需求分析实践软件需求分析实践2.1需求的获取需求获取五步法1.收集资料，了解概况，初步划定范围2.识别所有可能的需求提供者3.准备需要了解调研的问题4.调查和访谈5.总结归纳，准备新的问题，多次迭代软件需求分析实践2.1需求的获取需求获取的方式•与用户个别交流•需求讨论会•查阅相关文档•分发问卷调查表•现场访问客户•业务流程分析•同类产品分析•根据现有系统推导需求•回顾以往项目•观察用户对原有系统的使用软件需求分析实践2.1需求的获取识别所有可能的需求提供者•谁使用该系统•谁维护该系统•谁需要从系统中获取数据•系统会影响到谁•谁推广该系统•谁测试该系统•谁生产该系统•谁购买该系统软件需求分析实践2.1需求的获取需求获取的常用技术•需求访谈推荐3人访谈小组（1人提问，1人记录，1人辅助）•用例技术最终用户使用用例来模拟用户与系统之间交互用例可以看作是解释如何使用系统的经历•原型法需求原型；设计原型；产品原型纸上原型；界面原型；可执行原型抛弃型原型；演化型原型•专题讨论会（头脑风暴）软件需求分析实践2.2需求分析的目的消除原始需求中存在的：•冲突•重叠•遗漏•不一致•不切实际的细化需求划分需求的优先级需求建模软件需求分析实践2.3需求分析的思维方式穷举：确保需求无遗漏分类：确保需求无遗漏并去除冗余的需求分层：结构化表达需求抽象：识别出稳定与变化的需求软件需求分析实践2.4需求的分层提出者获取方法文档量文档形式评审方式稳定性返工影响优先级的确定者目标需求高层经理访谈几页ppt,word正规评审会最稳定最大客户业务需求中层经理访谈几十页excel,word正规评审会较稳定次之客户操作需求操作员+开发人员原型几十页,上百页word非正式评审会,正规评审会,分多次评审最易变化局部影响客户+开发人员软件需求分析实践2.5需求分析的步骤步骤一：列举需求1.消除客户需求中的矛盾与不一致2.补充遗漏的客户需求3.删除不必要的需求4.定义非功能性需求5.定义外部接口需求软件需求分析实践2.5需求分析的步骤步骤二：整理需求1.功能分解2.定义内部接口3.平衡需求、进度、质量与投入4.识别需求相关的风险5.对需求进行分类6.划分需求优先级7.识别可复用需求8.建立需求分析模型软件需求分析实践2.5需求分析的步骤步骤三：需求建模需求建模方法结构化建模IPOER图数据流程数据字典面向对象建模USECASE模型USECASE图USECASE描述静态建模类图包图动态建模交互图简单的理解为将自然语言描述的需求转换为开发人员能够理解的设计语言。软件需求分析实践2.5需求分析的步骤步骤四：设定系统目标与划分系统范围•目标–要解决的核心问题是什么?–为解决该问题的约束有哪些?•范围–哪些是系统应该完成的任务?–哪些不是系统的责任?–从广度与深度2个纬度考虑范围•广度：覆盖的业务,部门,功能•深度：做到什么程度？•Gilb的模糊目标定律：一个没有明确目标的项目，是不可能明确地实现其目标的。软件需求分析实践2.5需求分析的步骤步骤五：划分需求的优先级1.优先级的分配由系统分析员和客户一起完成2.优先级一般分为3级，不宜定义太多的等级3.帮助客户定义优先级的问题：•最重要的3个需求是什么？•是否有其他方法可以满足这一需求？•如果忽略或者推迟实现这一需求，其后果是什么？•如果不立即实现这一需求，对项目目标会有什么影响？4.需求的优先级可以从两个层次来划分•用户划分宏观的优先级：需求优先级•开发划分微观的优先级：特性优先级5.需求的优先级影响了开发顺序和开发计划软件需求分析实践2.5需求分析的步骤步骤六：使用需求分析检查单来分析需求1.检查单中的问题：•需求中包含不成熟的设计或实现信息吗？•这项需求还可以细分为不同的需求吗？•这项需求只是系统的装饰，而不是真正必须的吗？•这项需求符合系统的目标吗？•这项需求存在二义性吗？•这项需求可以实现吗？•这项需求是可测试的吗？软件需求分析实践2.6好的需求有哪些特征•正确•清楚•无二义性•一致•必要•完备•可实现•可验证•确定优先级•阐述“做什么”，而不是“怎么做”软件需求分析实践2.7需求规格说明书ReleaseProductBacklogSprint4weekSprintBacklogDailymeetingsBurndownScrum开发模型软件需求分析实践2.8需求验证与确认方式•检查文档是否符合标准•组织正式的需求审查•需求审查应有一个多学科的小组来进行•使用原型来确认需求•编写用户手册草案•设计测试用例•检查文档是否符合标准•组织正式的需求审查•需求审查应有一个多学科的小组来进行•使用原型来确认需求•编写用户手册草案•设计测试用例•检查文档是否符合标准•组织正式的需求审查•需求审查应有一个多学科的小组来进行•使用原型来确认需求•编写用户手册草案•设计测试用例•检查文档是否符合标准•组织正式的需求审查•需求审查应有一个多学科的小组来进行•使用原型来确认需求•编写用户手册草案•设计测试用例二.需求管理软件需求管理3.1需求的变化是永恒的需求变化的原因1.误解2.遗漏了需求3.外部环境发生了变化，产生了新的需求软件需求管理3.2需求是渐变的•秃头论证•稻草原理•蚂蚁效应量变引起质变。当你警觉时，项目已经变得面目全非了。软件需求管理3.3如何应对需求变