SE_01 需求分析

1. 需求分析介绍

搞清楚了 “要解决什么问题”！

1.1 需求分析主要涵盖哪些问题

为什么要设计该系统？
系统由谁使用？
系统要做什么？
系统涉及哪些信息？
对解决方案有何额外限制？
如何使用该系统？
质量需达到何种程度？

1.2 需求分析分类

1.2.1 按产品/过程分类

• 产品需求
  1）功能性需求：满足系统需求提供的功能，如：订票系统可以选位置，可以微信支付。
  2）非功能性需求：为满足系统功能需求要满足的其他约束条件；
  （1）质量需求：正常工作时需要满足的额外的与质量相关的服务，“提供的服务好到什么程度”
  如，订票系统响应时间要小于1分钟；
  （2）约束：质量约束、技术约束
• 过程需求（软件开发过程）
  实现系统需求，如系统API需要支持Java程序访问系统服务。

1.2.2 按需求层次划分

• 业务需求
  客户高层次要求，针对业务部门的分析人员，帮助企业达成组织目标的需求项目。
  如：携程旅行的业务需求是卖飞机票。
• 用户需求
  用户具体的需求，针对客户方、承包方的管理人员、最终用户、客户工程师、系统架构师，用户接受程度的需求。
  如：客户希望照相机背后有一个液晶屏幕，这样在拍照之后可以马上看到照片。
• 系统需求
  系统角度，针对最终用户、客户工程师、系统架构师、承包方的程序员，满足业务需求，从用户角度描述系统在做什么，与系统由什么软件和硬件实现无关。
  如：软件会使得汽车的启动速度加倍。
  还分为功能需求、非功能需求<如响应时间>
• 设计约束
  针对客户工程师参考、系统架构师、承包方程序员。
  如必须使用某浏览器等。

1.2.3 其他需求

• 依从性需求
  对国家法律、国际公约、社会法则、文化与政治习惯、标准等约束的满足。
• 体系结构设计需求
  系统环境要求，分布式约束、安装约束（如操作系统的要求）。
• 设计开发约束
  对软件系统设计的约束。
  包括：成本、周期、产品特征的变化性、可维护性、可重用性、可移植性。

1.3 设计约束及过程约束的问题

1.3.1 物理环境

设备放在哪？
单节点还是多节点？
是否对环境有要求？温度、湿度、电磁干扰等
系统规模有何限制？
电源、供电或空调有何限制？
是否重用已有系统的构件？对编程语言的要求

1.3.2 接口

输入是来自一个还是多个其他系统？
输出是来自一个还是多个其他系统？
输入、输出格式是否预定义？

1.3.3 用户

谁使用系统？
几类用户？
每类用户技术水平如何？

1.3.4 过程

资源、材料
系统构造需要哪些人员、技能
多少文档
在线还是本地？电子还是纸质
读者有哪些？
标准

1.4 需求规则

好的需求是可以度量的，能给出项目成功的必要条件。

单个需求项目的质量：
准确、正确、明确、可行、可证

整个需求集合的质量：
现实、精确、全面、一致

1.5 常见问题

产品设计目标不明确
干系人参与不足
干系人之间缺少共识
画蛇添足
需求快速变化
变更管理不足
需求分析不足

2. 获取需求

2.1 获取需求的途径

目标：主动与干系人协调工作，找出他们的需求，识别潜在的冲突，磋商解决矛盾，定义系统范围与边界。

2.1.1 通过干系人（沟通和交流的方式）

好处：系统信息及内容的丰富、系统信息质量的提升、系统生产率提升、客户对系统理解加深、与客户达成共识、客户更希望系统成功、增强成功信心、共同确定系统边界、需求质量提升、提高团队整体性。

• 什么是干系人
  任何和系统有关的人，对一件事有决策权的人。
• 如何找出干系人
  产品谁来用？输入谁提供？输出谁要？谁监管？影响谁？奖励谁？惩罚谁？
  补充：尽量找出所有干系人，多人角度获取更全面的需求。
• 分析干系人
  分析其隶属于四世界模型※的哪个世界，明确干系人的立足点，知道干系人更关注哪些方面。
  补充：四世界模型
  
  四个方面主要的待解决问题：
  主题世界：系统关注的主题内容。如，银行信息系统关注顾客、账号、交易；
  应用世界：系统未来的操作环境，关注人和企业流程，关注经理、职员、顾客、存款、取款等活动；
  开发世界：关注软件系统的开发过程，团队、人员、进度等；
  系统世界：系统在操作环境下的内部操作，包括系统要将操作记录保存到数据库中，统计账户交易报告、明细记录等。
• 干系人举例
  （1）用户：关心新系统特征和功能
  （2）设计师：想要构造完美的系统，尽量重用已有的代码
  （3）系统分析师：想要获取正确的需求
  （4）培训与用户支持人员：确保系统可用和可管理
  （5）业务分析师：想确保“我们做的比竞争对手好”
  （6）技术文档作者：为系统准备用户手册及其他相关文档
  （7）项目经理：希望按时、按预算、按目标完成项目
  （8）客户：为新系统买单的人
• 诱导干系人说出他想要的东西

2.2.2 通过业务过程（建模和分析的方法）

对现有业务过程的分析有助于识别业务问题并加以改进：

• 找出并列举当前业务过程中的问题
• 分析问题的本质（遗漏？不好用？新需求？）
• 分析改进的机会
• 分析改进的实质（自动化？流程改进？）

2.2.3 通过组织规章制度（文本阅读、文档处理等）

组织规章制度为我们提供了一个客观的、可参依据

• 规章制度定义当前最佳实践
• 分析规章制度有益于确定业务规则和约束条件
  1）业务规则：描述对业务过程的要求，如系统支撑的业务过程的结构、控制、行为效果
  2）约束：对系统开发过程的管理限制，主要涉及经济、政治、技术和环境四个方面，具体包括项目资源、时间、目标环境涉及系统本身
• 组织规章中往往还涉及过程自动化、工作流、关系、交互等内容

2.2.4 通过现有系统

用户手册、数据样本、界面描述、报告样本、截屏截图

2.2 获取需求的方法

常见的需求获取方法包