需求分析是架构设计的基石,方向错了,后面的努力可能都白费。虽然需求分析工作在业界很多公司中通常由产品经理主导,但还需项目经理、架构师、开发代表、测试等关键角色一起深度参与。而架构师在其中的主要职责包括:1)了解项目的范围或系统的边界,了解用户的核心诉求,确保架构设计解决真正的问题,即"做正确的事";2)评估技术可行性和风险;3)基于自身技术功底和业务经验,在方案选型中作出合理的技术权衡,并支撑工作量评估。对需求的敏感性和把控能力也是架构师的一项基本素质。
可能有人会说,需求分析不就是走访一下客户,把获取到的客户诉求记录下来就可以了吗?甚至还可以直接让客户把需求描述远程发过来。这当然是不够的,只能算作需求分析中的初级阶段------需求信息收集。由于人和人之间沟通时存在认知和理解偏差,很可能导致信息在传递过程中失真或遗漏,因此做好需求分析需要一套有效方法,规范分析过程、并将分析结果结构化,从而正真做到与利益相关者达成一致,避免表达失真。
需求分析得到的需求清单在后续各开发环节中还需持续进行管理,包括优先级排序,计划制定和变更控制等,确保按照预期落地实现。
1、背景
1)基本概念
需求分析 : 需求分析是软件开发过程中的关键阶段,旨在明确系统或产品需要实现的功能、需要满足的性能及其他约束条件。其核心在于理解用户或利益相关者的真实需求,并将其转化为清晰、可执行的技术规格。需求分析不仅是技术活动,更涉及沟通、协调与验证。
需求管理 : 需求管理是跟踪和把控项目或产品需求的实现过程,确保最终交付物满足利益相关者的期望。其核心在于平衡需求的范围、时间、成本和质量约束。
2)需求的分类
- 功能需求: 系统应具备的行为和能力,即在特定情形下,针对特定的输入,系统如何响应。
- 非功能需求: 系统应具备的质量属性和约束,包括:
- 用户视角质量属性------性能、可靠性、安全性、易用性等质量属性
- 厂商自身视角质量属性------可扩展性、可定位性、可维护性、复用性等质量属性
- 约束------如部署规格,网络环境等。
3)需求的特点
需求具有以下特点,在需求分析时可根据情况采取相应的策略:
- 双重性: 一般来说,需求描述既包括问题场景,又包括期望目标
- 颗粒度: 需求描述的层级可大可小。分析时需要根据场景、意图,结合支撑开发的目标来确定合适的颗粒度(并非越细越好,那会造成额外的开销和成本)。
- 潜在性: 收集到的原始需求,往往表面看到的冰山一角。需要通过深挖信息,分析潜藏的因素,推敲用户真实意图,而不仅仅是客户说什么就照做什么。
- 多维性: 事物本身具有多个方面,需求往往也会表达多方面的意图。需求分析则需要采用结构化的手法,每次只分析1个维度。
- 时效性和演进性: 用户的问题场景和期望目标都具有一定的时效性,是以特定时期为前提的,随着时间的推移和外部条件的变化可能随之演进。因此分析时需要为此类需求预留一定的变化空间;如果分析周期较长,则在分析过程中要保持沟通,根据最新的信息及时更新需求。
- 关联性: 用户的多个需求之间往往具有一定的关联性。对于这些需求,建议先按一定维度聚类形成多个需求集,再按需求集的维度进行分析,给出整体的解决方案。
2、需求分析
可能有人会说,需求分析不就是走访一下客户,把获取到的客户诉求记录下来就可以了吗?甚至还可以直接让客户把需求描述远程发过来。这当然是不够的,只能算作需求分析中的初级阶段------需求信息收集。由于人和人之间沟通时存在认知和理解偏差,很可能导致信息在传递过程中失真或遗漏,因此做好需求分析需要一套有效方法,规范分析过程、并将分析结果结构化,从而正真做到与利益相关者达成一致,避免表达失真。
同时,做好需求分析也是保障最终交付质量的关键。需求分析的输出结果(需求分析说明书)将是后续开发/测试/交付/验收等各项工作的基准,直接影响后续质量。
系统开发交付过程中,每个阶段的缺陷都会传递到后续阶段,并且修复成本会层层放大。需求分析是整个系统开发交付流程中最靠前的阶段,因此需求分析不彻底引起的后期需求变更,将会带来非常大的代价。各种缺陷阶段与修复代价比例关系大致如下(相对于开发阶段缺陷代价):
缺陷阶段 | 修复代价 |
---|---|
需求分析 | 0.1~0.2 |
设计 | 0.5 |
开发 | 1 |
测试 | 2~5 |
维护 | 10~20 |
需求分析过程主要包括以下步骤:
- 收集初始需求
- 对收集到的需求信息进行整理和分析,将客户化需求描述转化为产品化需求
- 形成需求分析说明书(将文字形式的需求描述转化为形式化的需求规约)
1)收集需求
针对不同的需求来源(利益相关者)进行需求收集。
客户侧:
通过标书、访谈、头脑风暴、对现有系统问卷调查等方式获取利益相关者的初始需求,明确功能性和非功能性需求。
注意的是,对客户的需求收集可能需要多轮。在需求分析过程中可针对梳理出来的过程结果及时与用户进行沟通交流,持续收集反馈信息,进一步完善需求。
通过将收集的信息结构化,使用工具如流程图、数据流图或用户故事(User Story)进行可视化表达,有利于跟客户进行更好的交流。
自身业务驱动:
通过行业分析,竞争分析,制定竞争力目标和发展计划,形成相关版本的需求输入。
自身技术驱动:
基于产品技术演进规划,行业技术规范等,形成相关版本的需求输入。
2)分析需求
通过一系列步骤和方法,对收集的需求信息进行整理和分析,得到系统功能及非功能需求清单。大体可以分为以下几步:
Step-1 目标确认
明确客户对该系统的总体目标诉求,即搞清楚客户的意图。
Step-2 特性分析
即场景分析,用自然语言的形式对各个场景功能进行定性的描述。
推荐用5W 1H方法进行分析和描述:
- Who(谁用)
- What(做什么)
- Why(为何做)
- When(何时用)
- Where(何地用)
- How(如何实现)
Step-3 功能分析
功能分析主要用的方法是功能分解,即将特性分解成几大功能模块。如果是基于现有系统的增量需求开发,那么就把这些分解的功能映射到现有系统的功能模块上,或者是增加的新的功能模块;如果是全新搭建一个系统,则是将初始需求进行一定程度的拆解、然后再聚类,形成新的功能模块规划。
注意这个设置的系统对外呈现的功能模块,而不是内部的设计架构。
Step-4 用例分析
针对各个功能模块,对其中涉及到的用例一个个进行细化分析,即Use Case分析。
用例描述了在不同的条件下,系统对参与者的请求做出的响应。用例通常通过一个发起者Actor(谁)向系统做出请求(要做什么,触发事件),系统根据参与者的请求,在不同的条件下,执行某一行为序列(系统怎么满足)。每一个行为序列可以称之为一个场景(Scenario),一个用例包含多个场景,场景也可以称之为用例的一个实例(Instance)。
用例分析主要步骤如下:
- 确定边界------与当前系统有关的外部系统或外部环境有哪些
- 识别actor------当前系统行为的发起者有那些
- 识别用例------该功能模块中由actor触发的系统行为有哪些,目标是什么
- 场景分析------在不同条件下系统的行为方式和结果是什么
- 结构化描述------用例的结构化的形式描述每个用例。参考格式:
描述字段 | 说明 |
---|---|
用例名(Title) | 用例目标 |
ID | 唯一编码,便于检索 |
名称(Title) | 用例目标 |
简要描述(Goal in Context) | 简要描述用例流程和目标 |
前置条件(Precondition) | 执行系统行为之前已经达到的条件 |
触发事件(Trigger) | 触发系统行为的事件 |
成功保证(Success Guarantees) | 完成目标时的系统状态 |
最小保证(Minimal Guarantees) | 无论目标成功与否,系统都会达到的状态 |
主成功场景(Main Success Scenario) | 完成目标的主要步骤 |
扩展场景(Extention Scenario) | 可能出现的其他情况,包括异常情况 |
规格约束(Specification) | 性能、容量等规格要求,环境等约束条件 |
DFX特性(DFX) | 易用性、可扩展性、可维护性等诉求 |
关于需求分析的几点经验:
- 从客户视角分析:以客户的业务化语言描述其功能/非功能的诉求,同时考虑客户的组织结构、业务场景、组网和部署环境等客观情况;切记不能以研发人员视角用内部技术语言进行描述。
- 考虑技术可行性及实现成本:需求分析不仅是产品经理投入,还需要技术专家、测试和维护等相关技术负责人一起参与分析。
- 多轮澄清和迭代:分析过程中,梳理出来的需求信息要及时与客户进行交流澄清,消除理解偏差。可以借助各种工具和图表,如流程图、用例图、数据流图、组网图、界面原型等等,根据客户反馈快速更新需求描述,再进行交流澄清,经过多轮迭代后达成一致。
3)形成结构化文档
通过以上步骤的需求分析,我们得到了关于这个系统的各项需求的描述信息。为了后续交流、参考和作为最终交付标准,还需要将各部分的信息用一种结构化的方式描述出来,即形成需求分析说明书。
需求分析说明书的参考大纲模板如下:
bash
背景(包括简介范、需求范围、约束等等)
系统上下文
特性1、xxxx,主要的用户场景、竞争力和主要的实现原理
初始需求澄清
功能1.1 xxxx,功能模块划分和职责描述
Use-case xxx, 按use case模板进行分析和输出和非功能性需求。
Use-case xxx, 按use case模板进行分析和输出和非功能性需求。
功能1.2 xxxx,功能模块划分和职责描述
......
特性2、xxxx,主要的用户场景、竞争力和主要的实现原理
......
需求清单汇总(表格)
对于最终得出的需求清单里的每条需求,关键质量要求包括:
- 明确------无二义性。
- 可度量------有显式的测试验收标准。
- 可实现------即技术风险可控,不存在技术准备度不足的情况。
- 成本代价合理------作为商业组织,实现这些需求的成本和代价是可接受的。
- 可落地跟踪------已和开发团队确认了可投入的开发资源和交付计划。
3、需求管理
1)需求排序和计划
在特定时间内的研发资源(人力/设备/环境等)总是有限的,如何在有限的资源下最大程度的降低需求如期交付的风险,或者达成更好的客户满意度?通常的做法就是根据业务价值、技术可行性和风险等因素对需求进行排序,先交付优先级高的需求。
常用排序方法包括:
- MoSCoW模型:将需求按照必须有、应该有、可以有、不需要几种类型进行归类和排序。
- KANO模型:将需求分为基本型(必备功能)、期望型(用户明确提出的需求)和兴奋型(超出预期的亮点),依次进行优先排序;后期还可指导产品进行差异化设计。
- 需求打分:按照用户的重要程度和对公司业务格局、收入、竞争力、战略发展、成本、技术风险等维度对需求进行打分,最后按照分值高低进行排序。
排序后的需求清单和研发资源匹配后,就可以制定相应的交付计划,纳入基线化管理。
需求跟踪与协作的工具:JIRA、Confluence、Trello、ReqView等。
2)需求跟踪
将需求清单里的需求条目与需求实现各环境进行关联,建立需求跟踪矩阵(RTM),关联需求与设计、开发、测试等环节。从而,使每一条在需求在研发流程中端到端可跟踪,进度和状态可视,确保整体如期交付。
在需求跟踪过程中,要重点关注被依赖较多的Use Case,避免形成瓶颈。
3)变更控制
需求的变更包括需求中各种要素的改变,如需求范围、规格约束、交付时间等,一旦完成需求基线之后,需求变更就必须严格受控(有一定代价) ,不能随意变更。
变更提出一方需要先评估影响,然后收集各方的意见,然后向变更控制委员会(CCB)提交变更请求。如审批通过,则各方需要共同遵照执行变更结论。
CCB一般由各方代表组成,包括产品经理、项目经理、架构师、开发代表、测试等。
常用工具与方法
工具 :JIRA、Confluence、Trello、ReqView等支持需求跟踪与协作。
方法:敏捷中的Backlog管理、瀑布模型中的基线化需求文档。
4、需求引导技巧
需求是平衡与妥协的结果。当开发团队由于的资源投入、时间计划、技术储备、战略规划等方面与客户需求不匹配时,或者在开发过程中遇到排期或技术问题时,可以采用一些技巧跟客户进行沟通,引导做些改变,从客户项目视角和公司长期经营视角实现双方的平衡。
几点经验可供参考:
1)延期
将客户的需求划分为几个阶段,形成一个整体的规划;将客户关切的核心诉求优先安排在前面阶段(按期交付),其他非核心问题则作为规划放入后续阶段,同时给出合理的原因解释。
这样既维护了客户的利益,又让客户能看到整体规划和承诺,一般来说是容易得到客户的理解的。
2)交换
当发现某些需求存在较大的技术难度,或者需要较高的代价才能实现时,可以思考近似的替代方案,并通过将替代方案的某些方面做得更好(如易用性/可维护性/成本费用)的策略与客户进行沟通,达成利益交换。
3)做大
若通过洞察发现某些需求加以改进或扩展可以帮助客户扩大格局、获得更大的机会点,并且也符合厂商自身利益,可以跟客户沟通,调整需求和方案,双方共同做大蛋糕,实现共赢。甚至可以讨论出一种利益分成方案,实现双方利益的最大化。