第三次软件工程作业——需求工程方法

[许舜宇202270294092]

一、需求工程定义

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。

二、需求分析步骤

1、获取和引导需求

找到软件的利益相关者，了解和挖掘他们的软件的需求，引导他们表达出真实的需求。《构建之法》这本书表示，需求可以从外界和软件企业内部两大方向上获取：

在外界寻找需求	直接与软件利益相关方沟通
	从类似项目和市场趋势中提取需求
在软件企业内部寻找需求	探寻企业自身的盈利需求
	开发团队本身的技术性需求

如何确定软件利益相关方呢？软件技术开发团队应该考虑以下人群：

用户	直接使用软件系统的人。用户群体可以依照其特点进一步细分为不同类型的客户
顾客	购买软件产品或根据合同规定接收软件产品的人。此群体不一定是软件的直接用户，但他们的利益与软件直接相关
市场分析者	代表“典型用户”的需求
监管机构	软件在具体领域内需符合该领域的政策规定
系统/应用集成商	为客户提供咨询、集成等服务的人。有些系统集成商会分解客户的需求后交付给下一级的服务团队
软件团队	具体完成某一特定软件或功能的团队
软件工程师	需求阶段的重要角色之一。软件各种约束、特性会影响到他们的工作效率

这些群体在软件开发的过程中也许互相之间根本不会见面，相互交流时也可能间隔了很多其他角色，如用户——客户——系统集成商——应用集成商——软件团队——工程师。但无论如何，即使软件一次不可能满足所有群体的要求，软件开发团队也应当积极听取相关角色的意见，切实弄明白这些角色群体到底想要什么，尽力朝这些方向去完善软件产品。

2、分析和定义需求

对各方汇聚而来的需求进行归类总结，定义需求的内涵，从各个角度将需求量化：需求实现的最后期限，实现需求大致所需的时间和资源成本，各个不同需求的优先级，需求带来的收益等。

对获取而来的需求，大致可以做以下四种分类：

（1）对产品功能性的需求：软件产品必须实现的功能。

（2）对产品开发过程的需求：对软件开发流程的约束条件。比如开发过程中必须产生某种类型的文档、在某时间点达到某状态等。

（3）非功能性需求：也称为“服务质量要求”，是为满足用户业务需求而必须具有且除功能需求以外的特性。未达到此类需求并不会导致用户的不满，但达成此类需求可以极大提升用户的满意度。对于功能性需求与非功能性需求，最简单的分辨方法就是用户说“必须”、“要”的功能是功能性需求，用户说“应该”、“最好”的功能是非功能性需求。

（4）综合要求：牵涉到现实中多个部门的功能与执行能力的需求，这类需求不是单凭一个软件模块就能满足的。

3、验证需求

通过分析报告、技术原型、用户调查或演示等形势向用户验证软件开发团队对于用户需求的认知是否正确。

4、在软件产品的生命周期中管理需求

在软件的生命周期中，需求在变化，技术也在发展，各种各样的变化层出不穷，这些都要求技术开发团队不断重新审视需求并对开发计划做相应的调整。
 

三、细说获取用户需求用户调研

1、用户调研

如同前文那条长长的“用户-工程师”沟通链条所表示的那样，用户的需求经常在这个“传话游戏”的过程中被曲解、失真。为减少这种情况带来的麻烦，软件工程领域存在以下几种成熟的用户需求获取方法：

方法名称	描述	优缺点
焦点小组	找到一群用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等	优点：应用广泛，是很常用的调研方法
		缺点：①受小组成员主观因素和表达能力影响大；②成员给出的建议受限于成员的知识水平；③易出现从众心理；④决策者常出于自身利益选择最终结果，所采纳的建议不一定是最好的
深入面谈	开发人员与用户一对一的详细面谈。甚至是直接让用户处理具体任务，供开发者观察、总结	优点：彻底消除了中间环节导致的需求失真
		缺点：①费时费力；②主持面谈的开发人员表达能力直接影响着面谈效果
卡片分类	将各种需求做成方便整理的小卡片，反复进行“讨论→明晰定义→归类→排序”的活动	优点：方便统一开发人员对需求的认知
		缺点：缺乏前瞻性、完备性，需结合用例。
用户调查问卷	向用户提供预设的问题，要求用户回答	优点：问题规范化，结果易懂
		缺点：问卷设计有门槛，拟定好的调查问卷需要技巧
用户日志研究	用户自行记录自己的日常工作生活中与软件相关的行为，供软件团队分析。或由由专门的跟踪程序进行记录	优点：方便开发团队掌握用户工作生活的一手资料，可以发现用户自己未注意到的需求
		缺点：①要求用户有较高的自律能力；②此方法牵涉到用户的个人隐私
人类学调查	可简单理解为与用户“同吃同住同劳动”	优点：开发人员走入真实生活，可以获得比用户日志更加详细、生动的需求
		缺点：①更加费时费力；②使用条件苛刻，受限于用户所在行业和生活环境与开发人员的专业知识水平间的差距
A/B测试	也称对照试验，在同一时间维度下，用现有用户群体测试产品的两个版本，根据设定的目标，采纳较好的版本	优点：业界接受程度高，应用广泛
		缺点：①测试成本随时间的推移而增大；②只能看到用户的交互行为，看不到用户的情绪反应和其他反馈；③有流失用户的风险

 

2、竞争性需求分析

理论上的需求分析都是在只有一家软件公司在提供服务，按部就班地走完“引导、捕捉、分析”需求，但现实工作中，往往同时有几家互为竞争对手的软件公司在提供服务。想在这种激烈的竞争中脱颖而出，我们需要用创新来增强竞争力。如何提出创新想法，并说服客户自己的创意是靠谱的，NABCD模型是一个有效的方法。

（1）N (Need，需求)：这个创意解决了用户的什么需求。不仅是看用户已知的、被不同程度满足过的需求，还要去寻找“不使用本产品的用户”不使用的原因，找出他们想要却没有的功能。

（2）A (Approach，做法)：获取需求后，用什么独特的招数解决用户的痛点呢？这个招数可以是技术上的独特，也可以是商业模式、地域、人脉、行业、成本等方面上的独特。

（3）B (Benefit，好处)：无利不起早，这个独特方法做出的产品能给用户或客户带来什么好处呢？以及，这个好处是否足够大，能否抵消用户抛弃原产品选择本产品所付出的时间与金钱？

（4）C (Competitors，竞争)：了解当前市场里的竞争对手，看清我方优势（人无我有）、劣势（人有我无）、平手（人有我有）的方面。

（5）D (Delivery＆Data，推广与数据)：酒香也怕巷子深，如何让目标用户都知道这款产品呢，运用什么方法在哪些平台上去推广？同时，要通过各种数据证明这种创新带来了多少收益。

 

四、细说分析和定义需求——功能的定位和优先级

在获取了需求后，技术开发团队就要考虑去实现是这些需求。但事有轻重缓急，需求也是如此。在资源有限的情况下，怎样才能保证获得较大的回报呢？

根据10X原则，要吸引竞争对手的用户，开发团队自己的产品需要有一个差异化的焦点，然后在此焦点上要比别人做得好10倍。这个焦点的功能也被称为“杀手功能”，非杀手功能的则被称为“外围功能”。

另外，由功能性需求和非功能性需求又可产生出的两类功能：“必要需求”和“辅助需求”。

以这四种划分为坐标轴，我们就能够得到分类需求的坐标图：

 此坐标轴可以让开发团队清楚看到目标功能处在哪个地位，差异化处理所收集到的需求。谨记一点，不要把资源像摊大饼一样把资源均分到所有象限中，要把资源向能够产生差异化和独特用户价值的地方。

第一象限：差异化，产生同类产品不能比拟的功能和优势。
第二象限：抵消，快速地达到“足够好”、“和竞争对手差不多”
第三象限：维持，以最低成本维持此功能
第四象限：维持，或者暂时搁置，等待未来好的时机或小规模实验

 

（更多内容待补充）

 

用户故事（User Story）——敏捷开发的利器

与面向对象方法不同，敏捷开发将需求叙述为一个个的用户故事，而不是用例。用户故事只专注于在用户的角度分析他的需求，所以与用例相比用户故事没有记录详细的细节，也没有详细的预先需求规格说明。这是因为用户故事是为了快速获得用户反馈而让产品加入小的增量所设置的，有益于迭代开发，并能够让用户和开发人员在对需求都有良好了解的情况下完善细节。

用户故事始终关注客户需求的实现（商业目标）,而非系统属性的实现。

组成部分

用户故事包含三个组成部分：卡片(Card)、交谈(Conversation)和确认(Confirmation)，可简称为“3C”。

1、卡片（Card）

简单来说，卡片就是一段简短的文字描述。卡片记载每个用户故事，用户故事卡上都有一个简短的句子和足够的文字来提醒每个人故事是关于什么的。卡片的模板是“作为<角色>，我想要<功能>，以实现<商业价值>（As a [user role] I want to [goal] so I can [reason]）”。

举个例子，比如：“作为一个驾驶员，我希望手机导航能进行语音播报，以便我在驾驶的过程中更安全地使用手机导航。”

2、交谈（Conversation）

交谈是故事的需求细节，用于具体化故事细节。它表现为在卡片下方的几句注释。

依然以上面的例子为例，注释可以是标注“语音播报该采用什么语言”、“语音播报在到达目标地点的前多少秒播放”等。

3、确认（Confirmation）

确认也称为用户故事的验收标准，是一种测试用户故事是否完整并且与预期相一致的测试准则，一般写在卡片的反面。在讨论需求的过程中，客户不仅告诉分析师他/她想要什么，还确认在什么条件和标准下接受或拒绝工作软件。定义的案例以确认书的形式书写。但应注意，确认关注于验证相应用户描述工作的正确性，是针对用户故事的。它不是一个对软件的集成测试。

INVEST：用户故事应具备的特征

可行的用户故事都有5点共性：独立的（Idependent）、可协商的（Negotiable）、有价值的（Valuable）、可评估的（Estimatable）、小的（Small）、可测试的（Testable），简称为“INVEST”

1、独立的（Idependent）

尽可能的让一个用户故事独立于其他的用户故事。用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大小估算所涉及的范围更清晰，从而估算偏差更小。

如果失去独立性，故事与故事之间产生依赖关系，就会使用户故事变得不可测试（因为测试只针对一个用户故事，而这个故事的完成却取决于其他故事），进而导致无法进行确认（Confirmation）。

2、可协商的（Negotiable）

首先，用户故事的内容要是可协商、实时、能随时修改的，写用户故事不是拟定合同，不会“一锤定音”。

其次，为了达到可协商的目标，用户故事通常写为一个结构化的简短描述，不包括太多的细节。具体的细节在沟通阶段产出。如果一个用户故事带有了太多的细节，实际上会限制用户、团队的想法和沟通。

3、有价值的（Valuable）

敏捷团队的目标很简单：在给定现有时间和资源的情况下提供最大价值限制。所以，每个用户故事必须为产品的用户、客户或利益相关者提供一些价值。

为了确保这一点，用户故事需要站在用户的角度去编写。这个特点也会促使团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。

4、可评估的（Estimatable）

一个好的用户故事是可以估计的。为了一个用户故事在迭代中的开发和测试，开发团队应该评估完成它所需的复杂度和工作量。但在实际评估过程中，遇到困难是在所难免的。让开发者难以估计故事的问题主要来自：对于领域知识的缺乏，或者故事太大了。

如果缺乏相关领域的知识，就需要与用户更多的沟通。如果团队无法估计用户故事，则通常表明故事太大或不确定。如果用户故事过大导致无法估计，则应将其拆分为较小的故事。

5、小的（Small）

一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量。这样的目的是确保这个故事至少要在一个迭代中能够完成。用户故事越大，在安排计划，工作量估算等方面的不确定性和风险就会越大。

6、可测试的（Testable）

一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够被测试，那就无法知道它什么时候可以完成，也无法知道是否了达到用户的要求。故事不可测试的原因可能是形成不良，过于复杂，或者可能依赖于其他用户故事。

在测试时要额外小心诸如“漂亮”、“更好”、“方便”等非常主观的词，这些词无法测试。对于这些词修饰的要求一定要和用户沟通，转换成能够客观评价的标准。

优秀用户故事的三点共性

除了以上6点是用户故事必须遵守的以外，还有三个准则可以帮助我们产出更好的用户故事。这三个准则分别是：一个用户、完整价值、不依赖。

1、一个用户

因为多个用户常常有细微的差别，所以一个用户故事只包含一个用户，用户故事卡片的主语只有一个。典型的用户，常常有共同的某类需求。

2、完整价值

完整地交付一个客户价值。一个完整的用户故事意味着这个故事完成后，用户可以达成一个明确的、有意义的目标。

3、不依赖

依赖性的三种常见类型是：重叠、顺序和包含。

（1）用户故事的大部分问题是重叠依赖带来的，需要避免故事之间功能点相互重叠；特别是多个用户故事包含多个不同的重叠部分时，很难找到一组用户故事可以代表该最小可行产品的功能集合。

解决方式一般有三种：将重叠部分单独剥离出来做为独立的用户故事；合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中；使用Scrum开发模式。

（2）顺序依赖是指某个用户故事完成，要以另外一个或多个用户故事的完成为条件。顺序依赖在现实中普遍存在，但在多数情况下可以通过一些手段解决。

解决方式也有三种：在一次迭代内，用户故事尽量做到没有顺序依赖；如果顺序依赖不可避免，保持迭代之间只有单向依赖，在时间上只有后面迭代的故事对前面迭代故事的单向依赖（前向依赖）；剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。

（3）包含依赖是指在组织用户故事时使用有层级的管理，一个特性包含多个用户故事，这样就构成了特性对其属下故事的包含依赖。包含依赖会提升系统复杂性，需要注意它对排定发布和迭代计划的影响。

解决方式有：用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划，特性一级可以用来做发布计划；特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去；遵从最小可行产品的理念，一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。