本文为学习笔记

目录

基本概念与软件需求概述

定义

通俗定义

待开发软件产品的目标用户对该产品的功能,性能,设计约束和其他方面的期望和要求

其他经典定义

1. Rational: (正在构建的)系统必须符合的条件或具备的功能
2. Merlin Dorfman 和 Richard H. Thayer :
   用户解决某一问题或达到某一目标所需的软件功能。
   系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。

定义剖析

• 需求与问题紧密相关,关注用户的期望,要求和需要
• 软件需求服务于目标用户(软件最终用户、用户方负责人、用户代表)，必须是用户所需的
• 不是所有方面的要求都是软件需求，软件需求必需对用户有价值和意义
• 软件需求表现形式
  • 功能性需求：eg. 通过ISBN号查询图书
  • 非功能性需求：性能、安全、外观等
  • 限制条件：技术、平台等

作用与解决的问题

作用

在用户意图与软件设计中架起桥梁，将现实元素转化为软件元素

理解需求:  (当前系统)-->(物理模型)-->(逻辑模型) 
表达需求: (目标系统)<--(物理模型)<--(逻辑模型)

任务

借助当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。

需求捕获在需求分析过程的位置

可行性研究 (需求获取) (需求分析) (系统模型) (需求文档)
                               (需求描述) (有效性验证) (需求文档)
                                         (用户需求与系统需求) (需求文档)

• 需求捕获为需求分析提供原材料
• 需求捕获的有效性和完整性直接影响需求分析的产出质量
• 需求捕获活动出现大的误差将是方向性的重大错误！！！

获取软件需求

重要性

• 软件开发的基础和前提 (有明确需求才能有针对的开发)
• 制定软件开发计划的基础(知道做什么 -> 确定工作了 -> 制定计划)
• 最终目标软件系统验收的标准 (基于明确需求进行验收)

复杂性

(ps. -> 之后的内容为个人的理解)

• 系统复杂和庞大 (如何得到需求并描述清楚) -> 听描述人员说需求,自己理需求,列提纲画流程图确定理解?
• 片面 不完全 (如何保证得到所有的软件需求) -> 与目标用户多次确认,思考业务流,看看是否能走通
• 模糊,不准确(如何保证把需求说清楚和准确) -> 与开发人员多次有效沟通,确定自己全面理解了需求,再图文结合准确表达
• 歧义,不一致(如何保证所描述的需求是不矛盾的) -> 自己检查文档是否有冲突的地方,与客户和开发人员结合确定需求不冲突
• 及时性(当需求变更时，如何让相关人员都知道需求已经变更) -> 沟通用户与开发, 要有有效的通知沟通方式,有书面文档记录
• 软件需求变动带来的影响 (波动性(横向)/放大性(纵向))

如何应对需求的复杂性

• 过程和规范
  • 需求过程
    • 瀑布式: 强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制
    • 迭代: 每次只设计和实现这个产品的一部分,逐步实现系统
    • 螺旋: 定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复
    • 敏捷: 作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果；关注业务优先级； 检查与调整。
  • 规范：文档模板
• 技术层面－方法、技术和工具
  • 方法：结构化分析(细化分解问题、化繁为简)、OO
  • 技术：抽象、建模、原型、数据流图……
  • 工具：UML、Rose、Visio、MindManager、Excel、CC……
• 管理层面－需求管理配置库
  • 对需求分析中, 人、活动和产品进行管理，使之可追溯

优秀需求具有的特性

• 完整性
• 正确性
• 可行性
• 必要性
• 划分优先级
• 无二义性
• 可验证性

软件需求捕获过程

过程及结果

过程

[理解问题域与目标] [需求捕获准备] [需求交流] [整理需求文档] [需求捕获收尾]

成果

• 前景文档(项目视图)
  • 用户问题与目标定义
• 用户需求采集文档
  • 功能性需求
  • 非功能性需求
  • 限制条件

需求捕获时点

• 软件产品研发启动阶段：需求捕获来自用户问题域(*)
• 软件产品优化提升阶段：需求捕获来自软件研发各环节的反馈
• 用户需求从来都不会冻结，需求捕获工作始终持续

理解问题域和目标

问题域: 问题 + 问题场景

• 当前用户真正面临的问题是什么？
• 当前用户问题发生的场景是什么？
• 除非你已经理解它，否则不要修改它
• 定义问题的方法：鱼骨图、直方图
  • 鱼骨图:是一种发现问题“根本原因”的方法; 分为问题性,原因性,对策性
  • 直方图:是一种对数据分布情况的图形表示，是一种二维统计图表，它的两个坐标分别是统计样本和该样本对应的某个属性的度量

目标

用户期待达到的效果

• 问题域与目标与用户达成共识(项目章程、合同)
• 一切项目需求始于问题，需求以问题或目标为核心来展开收集
• 软件需求是对“问题”以软件的方式进行求解的过程，即软件做什么或具备什么属性能解决问题

软件需求捕获准备

• 基础储备
  • 掌握基本业务术语(交流语言)
  • 掌握行业基础业务系统(如CTAIS)－基础业务知识
    • 以软件为学习支持，熟练掌握软件业务操作进而理解掌握业务
  • 了解用户业务范围和业务系统现状
    • 文档考古、实地观摩、用户学徒
• 交流准备
  • 针对问题域的项目视图和需求调研提纲
  • 需求团队
• 两个意识
  • 用户站位意识，站在用户的角度来看待和思考问题
  • 倾听的意识(辅助积极询问、引导和反馈)

需求团队

团队组成

• 具有编程背景的人,以获得描述所要求的准确性和精度
• 熟悉系统业务规则的人
• 了解系统具有决策权的人（能够决定放弃和保留）
• 如何应用的人（熟知在实际中如何使用系统的人）

人员素质

• 知识丰富
• 尽职尽责，坚定不移，态度积极
• 出色的沟通能力，不卑不亢
• 尊重他人的观点
• 丰富的判断力和一个实用可行的方法

调研准备

切入点

[相邻系统] (系统参与者有哪些)  -->  [业务事件](系统为参与者提供哪些服务) --> [业务用例](每个服务的处理环节业务规则如何规定)

概念

• 业务上下范围：由用户关注的问题域圈定
• 相邻系统：为待建系统提供数据和服务的系统，可能是人、组织或其他软件
• 业务事件：外部的服务请求(如在ATM执行转帐请求)，面向用户的
• 业务用例：响应业务事件的一系列执行步骤

方法

• 通过数据流关系找到相邻系统，定义业务事件和业务实体(DFD)
  • 绝大多数的应用系统本质上一个信息处理系统，系统的功能主要与数据处理相关
  • 相邻系统是数据的生产者或者消费者
  • 每个数据状态的变化可能与一个业务事件相关，用”无事件”来发现例外或遗漏事件
  • 通过业务事件定义业务用例
• 找到业务事件的真正起源，考察业务用例，定义需求边界
• 在业务用例中挖掘需求

概念实例

提纲

系统的用户对象是谁?
用户的组织架构？
每个用户和相邻系统触发的业务事件？
每个业务事件处理流程？相关业务实体数据
系统与现有其他的关系?(数据交换、业务协同)
系统的数据存储要求？
需求的非功能需求(安全、性能等)？
系统的约束与限制？
……
准备需求调研文档模板－需求调研内容的结构化

需求采集模板示例

需求采集文档关键项目

业务事件：与谁有关？
描述：业务意义是什么？
理由：解决什么问题？
来源：谁提出的，用于需求追溯
验收标准：明确具体，可能量化，与需求描述有关
冲突：需求关联关系
优先级：开发计划依据
以上项目均与问题域相关

用户交流

• 交流对象选择
  • 面谈对象与需求涉众相关，需求涉众是需求源泉
  • 面谈对象中要求有能对需求做最终确定的人
  • 面谈对象的组成：典型用户代表、业务专家和需求仲裁者
• 关注的问题－达成共识
  • 待建系统所有的相邻系统是否完整？
  • 所有相邻系统触发的业务事件是否完整？
  • 业务事件对应业务用例是否正确？
  • 确定需求边界
• 交流方式
  • 面谈或会议是最有效的方式，注意倾听，使用辅助工具加强理解
  • 实地参观和实践(用户学徒)，体验业务场景
  • 电话交流，适用于对需求的部分细节的交流和确认

用户交流之面谈和会议

• 循序渐进
  • 首先关心一般性、整体性问题，然后再讨论细节问题，(相邻系统－业务事件－业务用例)
• 客观、公正、主动、积极
  • 不应限制用户在回答问题过程中自由发挥，理解用户的思维过程
  • 充分沟通，要和用户打成一片，进行充分的合作，建立起良好的合作关系
  • 如果发现多个软件需求相互矛盾，要能找到仲裁人，或者决策人
• 总结
  • 问题汇总后应能反映软件或其子系统的全貌
  • 能覆盖用户对目标软件或其子系统在功能、行为、性能诸方面要求。
  • 及时反馈交流文档

区分客户需要和客户需求

• 客户需要（Needs）
  • 一种原始的、割裂的信息
  • 一般以问题解决方案的方式提交需求
  • 信息→（Elicit抽出）→客户需要
  • 形式：会议纪要、客户文档、调研报告、E-Mail
• 客户需求（Requirements）
  • 一种文档化的、完整的、自洽的信息
  • 通过用户描述(user story)反映《客户（用户）需求说明书》
  • 句式：作为(用户类型)，我们希望可以(能力)以便(业务价值)。

例：作为购书者，我们希望可以通过ISBN号码找到一本书，以便更快速地找到正确的书

• 从客户需要中抽象出真正的原始需求
• 通过客户表面需求理解更深层次需求(去技术化)

引导用户

• 需求交流比较高的层次，被动转主动，顾问的角色
• 需求范围的引导：在问题域涉及的业务上下文范围内
• 业务定义的引导：需求复用、其他行业或应用经验
• 业务启发的引导：需求复用、其他行业或应用经验
• 通过原型形式化或启发用户需求(*)
• 要求具备一定的抽象能力，将不同应用领域的共性总结出来
• 注意沟通表达方式，尊重用户，不可先入为主

捕获系统划分的派生需求

• 考虑用户问题域的复杂性，对问题域进行分解子问题域简化问题的有效方法，从软件构造层次，划分为多个子系统
• 需求捕获分别形成系统级需求或子系统需求
• 关注派生需求
  • 子系统需求：子需求必须满足，未必对用户有价值的需求
  • 子系统之间接口需求：子需求为完成整体工作，需要与其他子系统通信的需求
• 派生需求更多是由系统规划设计产生的，用户关心的是系统业务需求价值

创建整理需求采集文档

• 由于语言描述的多义性，促进需求沟通达成共识的唯一途径将需求文档化
• 需求采集参照文档模板使用用户理解业务语言来描述，尽可能去技术化，技术要素作为限制条件处理
• 需求采集文档的作用将用户需求规范化，开发出用户和需求分析设计人员都能理解的文档。

开发客户看得懂的需求

• 客户看不懂的: 功能, 产品结构,技术语言
• 客户看得懂的:
  • 界面、报告
  • 用户手册、使用说明书
  • “串联故事”、“活动描述”（用例）
  • 业务语言

需求捕获收尾

• 用户的问题域和目标可能随时变化调整，需求捕获一直持续
• 以合同工作说明书的内容作为需求捕获是否完成基准：90%确定
  • 重点审查用户优先级比较高的需求(全部覆盖)
  • 所有的需求是否在问题域范围之内
  • 所有的需求能否支持解决用户问题，达到用户目标
  • 有何风险
• 需求捕获评审
  • 用户方负责人、项目组确认
• 产出物
  • 用户需求用例说明书，供需求分析阶段建模使用
  • 建立用户需求基线

需求捕获总结

• 面向问题和用户，而不是面向技术
• 主要是做什么，而不是怎么做
• 考虑需求涉众，对用户群进行分类
• 同时考虑功能需求和非功能需求
• 讨论例外情况，把客户的假设解释清楚
• 需求文档化，设置优先级
• 需求验收标准量化
• 及时反馈
• 注意控制需求范围
• 合作才能成功

实例演练

需求能力提升

• 技术工作的熏陶
  • 技术视野和业务视野同样重要
• 掌握需求分析建模方法、工具、模板
  • 分析方法：
    • DFD, Data Flow Diagram数据流程图,Data Functional Diagram数据功能图
    • SC, 系统结构图
  • 建模方法：UC,DM,……
  • 工具:UML、MindManager…….
  • 积累一套有效的需求文档模板
• 培养沟通表达能力
• 要充满热情和兴趣地钻研行业领域知识
  • 需求能力通过行业领域知识才能体现价值
  • 仅仅掌握需求方法论是不够的，不能落地