软件项目需求分析

1.软件需求分析简介（是什么）

需求管理流程，如图所示

2.软件需求分析难点（有哪些问题）

问题复杂性，随着信息技术发展，软件功能越来越强大，导致软件需求复杂性提高，表现在：

3.需求分析要点（关键点是什么）

   3.1做什么-需求分析主要工作

   3.2什么成果-需求分析目标

   3.3需求分析6大原则

   3.4需求价值判断

   3.5 SCQA分析模型

   3.6 5W2H分析法

4.需求呈现（做什么）

4.1需求规格说明书：

软件需求说明书是指在研究用户要求的基础上，完成可行性分析和投资效益分析以后，由软件工程师或分析员编写的说明书。它详细定义了信息流和界面，功能需求，设计要求和限制，测试准则和质量保证要求。它的作用是作为用户和软件开发人员达成的技术协议书，作为着手进行设计工作的基础和依据，系统开发完成以后，为产品的验收提供了依据。

功能名称	手机端查看门禁机心跳状态操作需求说明
需求ID	无
功能描述	在上清寺项目中施工人员在现场调试门禁机时需要确认门禁机是否有“心跳”，以确认门禁机可以上传数据。需要设计一个门禁机状态查询的wap页面，让施工人员在现场就可以通过手机浏览器搜索查询门禁机“心跳”状态。
功能要求	查询页面设置成自适应，以满足手机端和PC端查询界面的友好展示； 查询关键字为单元门名称，支持模糊查询； 关键字为空或者搜索结果不存在时进行友好提示； 查询结果列表显示所在小区/社区、楼栋、单元门、心跳状态； 需要有帐号登录才可以进行查询，避免恶意查询的安全隐患。 门禁机有心跳时显示“在线”，门禁机无心跳时显示“掉线”。
操作角色	登录用户
输入	单元门名称
输出	与关键字匹配的单元门门禁机心跳状态；
约束	搜索关键字不能为空
业务流程图	【登录帐号】——【查询单元门关键字】——【显示门禁机状态】
操作流程图	无
界面规划
补充说明	帐号登录的目的是为了防止恶意查询，如果不存在此问题可以不需要设置帐号登录限制。

4.2原型图：

原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。 原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物，它 使得相关方可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。

4.3系统交互图：

系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。系统交互图往往需要配备文字来更加详实地描述系统需求。

4.4思维导图：

思维导图。把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。使用思维导图可以反映系统的组成部分和功能结构。

4.5流程图：

流程图，也称过程图，用流程图描述一个生产过程怎样从开始走到结束，以及中间各步骤之间的相互关系，有助于分析过程中的哪个或哪几个环节的需求。用流程图可以描述系统操作的各个步骤及之间的逻辑关系。

4.6敏捷：用户故事：

用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。

一个完整的用户故事包含三个要素：

4.7KANO模型：

KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

4.8需求决策：

需求收集-需求分析->需求评审/确认

需求调研记录表-需求文档-需求确认文档

大多数项目中，起决决策角色一般都是管理者或者客户方领导，在需求决策时需要积极沟通和引导客户完成需求确认工作。在定制的外部项目时，尤其需要注意收集和分析客户方领导的需求。最关键的是获得需求签字确认。

需求评审，就是产品经理通过向团队其他成员（开发、测试、运营）对需求的相关内容进行阐述、说明或者演示，使团队成员对需求的理解保持一致，统一整个产品团队的目标，从而使得产品达到预期效果。

在系统交互方式和界面设计方面，经常采用投票的方式来实现团队对需求的统一认可。可以通过微信群或者在线投票软件实现快速的投票和结果统计。

四象限法则是时间管理理论的一个重要观念是应有重点地把主要的精力和时间集中地放在处理那些重要但不紧急的工作上，这样可以做到未雨绸缪，防患于未然。

可以通过四象限法则来对需求进行优先级排序，同时识别重要的需求，剔除不合理和价值低的需求。

5.软件需求分析流程（怎么做）

5.1需求分析标准化步骤

用户访谈主要是通过和用户交谈，了解到用户对本项目的理解以及他们的一些想法和愿望。通过这些基础素材，需求人员可以对信息进行整理，从而为后续的分析收集到更多有价值的素材。

用户访谈表

被访人员信息 姓名： XX                             部门：糖尿病专科 职位： 无                             级别：无

用户访谈记录

患者：我就是希望能得到医生一对一的治疗，这样的话治疗质量高，效果好。 访谈者：如果我们开发一套系统，让您可以自己填写每天的病情，让医生每天都给您医嘱，您觉得怎么样？ 患者：要是那样就太好了。如果医生能够不仅给我医嘱，还能和我面对面的诊断，就更好了。 访谈者：可以的，我们的软件系统也支持远程诊断功能。 患者：如果那样，真是太方便了。

整理故事

患者希望能在本系统的电子病历中录入各项指标，可以查看社区医生和专家医生的医嘱，可以与专家医生远程视频诊断

整理人：XX 访谈用户确认：XX 负责人确认：XX

岗位职责分析，主要是分析被访者的岗位和相关职责信息，而下一步系统用户分析做准备。

岗位	职责	备注
（被访者岗位）	（主要工作职责）	无
社区主任医生	可以向专家医生申请协助治疗	无
社区普通医生	可以查看患者信息并给出医嘱	无
知名专家医生	对患者进行远程视频诊断	无
普通专家医生	可以查看患者病历，对疑难病症给予医嘱	无

用户访谈主要是通过和用户交谈，了解到用户对本项目的理解以及他们的一些想法和愿望。通过这些基础素材，需求人员可以对信息进行整理，从而为后续的分析收集到更多有价值的素材。

岗位	职责	系统用户	业务需求
岗位1	（职责描述）	通过总结，提炼出系统用户	通过抽象提炼出系统用户的需求
岗位2	（职责描述）
	（职责描述）
糖尿病患者	在电子病历中录入各项指标	患者	患者可以在电子病历中录入自己各项指标，并能够查看社区医生和专家医生的医嘱，还可以于专家医生远程视频诊断。
糖尿病患者	可以查看社区医生和专家医生的医嘱
	可以与专家医生远程视频诊断
普通专家医生	可以查看患者病历，对疑难病症给予医嘱

用户场景分析主要分为总场景分析和分场景分析，其中总场景分析是根据表3总结出的系统角色，将对应的业务需求分解成为几个用户场景；分场景分析是进一步将每个场景进行详细描述。

系统角色	业务需求	用户场景
患者	患者可以在电子病历中录入自己各项指标，并能够查看社区医生和专家医生的医嘱，还可以于专家医生远程视频诊断。	患者打开系统，进入自己的电子病例页面，录入各项指标，保存后退出电子病例。
		患者登陆系统后，打开自己的电子病历、查看社区医生给自己的医嘱后，保存电子病历
		患者登陆系统后，打开自己的电子病历、查看专家医生给自己的医嘱后，保存电子病历
		患者登陆系统，打开远程视频诊断，与专家医生进行视频诊断后，关闭视频诊断

用户用例分析是进一步将每个分场景再细分成用户用例，

根据分析得到的各个系统用户，先概况性的说明各个系统用户需要做哪些事，然后再进一步详细分析每个功能点的具体功能，既计算机将要帮助用户完成哪些任务。注意：最好以计算机式的语言加以描述，避免用文学语言进行描述。

系统用户名称	用户需求	具体涉及到的功能点
（系统用户1）	（概况用户1需求）	功能点1
		功能点2
（系统用户2）	（概况用户2需求）	功能点1
		功能点2

非功能需求包括性能需求、安全需求和构架需求等等，除了功能性需求以外的内容都可以放在这里进行分析。

非功能性需求	性能需求	具体非功能点1，2，3
	安全需求	具体非功能点1，2，3
	架构需求	具体非功能点1，2，3
	其他需求	具体非功能点1，2，3

系统功能需求=功能+非功能

将以上的分析内容加以合并，适当裁剪，就形成了一份内容详实及格式标准的需求规格说明书。

需求规格说明书
1 引言	1.1 编写目的	（编写目的及预期读者）
	1.2 编写背景	（介绍本项目的背景知识）
	1.3 名词定义	（本项目的一些名词需要加以解释）
	1.4 参加资料	（列出在写作过程中参考的资料）
2 任务概述	2.1 目标	（主要要实现哪些功能该，解决哪些实际问题）
	2.2 用户特点	（用户试用软件的喜好和特点）
	2.3 假定和约束	（说明在项目中的工期成本质量等约束条件）
3 需求分析	3.1 功能需求分析	（直接利用第6步的分析结果）（核心部分）
	3.2 非功能需求分析	（直接利用第7步的分析结果）（核心部分）
	3.3 数据管理要求	（本项目对数据精读及输入输出的要求）
	3.4 故障处理要求	（对故障处理方式及时间等的要求）
	3.5 其他要求	（列举其他要求）
4 运行环境	4.1 设备	（本项目所需要的设备）
	4.2 支持软件	（本项目所需要的基础性软件如操作系统中间件等）
	4.3 接口	（本系统与其他系统的接口需求情况）

总结：

需求分析的目的就是使用各种分析方法，结合需求采集信息，总结归纳，并完成需求呈现和最终确认。

• Step8需求规格说明书
• Step7非功能需求分析
• Step6功能需求分析
• Step5用户用例分析
• Step4用户场景分析：
• Step3系统用户分析：
• Step2岗位职责分析：
• Step1用户访谈：
• 四象限法则
• 投票：快速的实现投票和结果统计：
• 需求评审会，内部/外部评审：
• 领导说了算，获得需求签字确认：
• 角色（who）：谁要使用这个
• 活动（what）：要完成什么活动
• 价值（value）：为什么要这么做，这么做能带来什么价值
• 
• WHAT——是什么？目的是什么？做什么工作？
• HOW ——怎么做？如何提高效率？如何实施？方法怎样？
• WHY——为什么？为什么要这么做？理由何在？原因是什么？造成这样的结果为什么？
• WHEN——何时？什么时间完成？什么时机最适宜？
• WHERE——何处？在哪里做？从哪里入手？
• WHO——谁？由谁来承担？谁来完成？谁负责？
• HOW MUCH——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？
• 情景-描述事物当前背景、状况等事实
• 冲突-已经发生或者破坏现状的问题
• 问题-提出问题中心，最需要解决的疑问
• 答案-根据疑问找出最有说服力的解决手段
• 广度-受众
• 频率-周期是多少
• 强度-用户需求
• 时机-当下技术、规划、环境是否适合
• 永远必要显得比客户更聪明
• 尊重客户的现实选择
• 转述需求的人也是客户
• 客户和用户要区别对待
• 用最简单的方式展现需求
• 天下没有免费的午餐
• 有形的：文档、文字
• 客观的：没有个人情感、主观臆断
• 可描述：用图表、文字清晰简单的描述
• 可检验：需求可以进行使用检验
• 问题识别：要解决哪些问题
• 定义范围：这个需求的深度，具体准确的定义描述
• 可行性评估：技术可行性+成本可行性（技术能不能做到，资金是否充裕）
• 需求优先级别：懂得提炼哪些是核心功能、哪些功能的优先级是最大的、后者、其次
• 编写需求分析文档：包括以上四点的总结
• 模糊性：客户对需求有一定了解，但不是很清晰，导致需求模糊
• 不确定性：经过需求分析，客户不知道经过分析后的需求是否符合要求
• 易变性：软件开发是持续的过程，即使客户需求已经是明确的，但不代表就不会发生变动。
• 主观性：以主体自身的需求或标准为基础去衡量和对待客体。主观判断形成的原因：
  • 因知识面局部导致主观印象
  • 因情感导致的个人偏见
  • 因职业经历形成的经验导致衡量人的侧重性
  • 因信息收集方法错误导致的认知局限
• 沟通障碍：我们不管身为哪方都需要用对方能够理解的语言进行描述和传递；微信、短信等信息方式进行留底；电话则是进行简单的确认、扯皮
• 功能越来越复杂-带宽的增加，功能越来越多
• 流程和场景越来越多-从只能在电脑前到现在任何地方都可以使用
• 设计人员越来越多-开发部门负责设计，不代表就是使用软件的人员
• 操作界面越来越多-PC端、APP端、小程序
• 用户体验越来越高-界面设计、交互
• 复杂性：简单->复杂