数极客首页

用户研究:深入探讨什么是需求

一、什么是需求

软件需求

用户研讨:深化讨论什么是需求

对大多数人来说,若要建一幢数百万元的房子,他一定会与建房者细致
讨论各种细节,他们都明白竣工

以后的修正
会构成

损失,以及变卦
细节的危害性。但是
,触及
到软件开发,人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求剖析

阶段埋下的“祸根”(Leffingwell 1997)。可许多组织仍在那些基本

的项目功用
上采用一些不合规范

的办法

,这样招致
的结果
便是一条鸿沟(希冀
差别

)—开发者开发的与用户所想得到的软件存在着庞大

希冀
差别

在软件工程中,一切
的风险承担

者(stakeholder)(这个词很有意义
,原义是赌金保管者。我看过很多的翻译,有翻译成涉众的,也有的翻译成参与者的,但是我想他的主要意义
就是和这个项目有密切

相关利益的人)都感兴味
的就是需求剖析

阶段。这些风险承担

者包括客户、用户、业务或需求剖析

员(担任
搜集
客户需求并编写文档,以及担任
客户与开发机构之间联络
沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分

工作若处置
好了,能开发出很出色的产品,同时会使客户感到称心

,开发者也倍感满足、充实。若处置
不好,则会招致
误解、迂回

、障碍以及潜在质量和业务价值上的要挟
。由于
需求剖析

奠定了软件工程和项目管理的基础

,所以一切
风险承担

者最好是采用有效的需求剖析

过程。

软件需求的定义

IEEE软件工程规范

词汇表(1997年)中定义需求为:

(1)用户处置

问题或抵达

目的
所需的条件或权能(Capability)。

(2)系统或系统部件要满足合同、规范

、规范

或其它正式规则
文档所需具有的条件或权能。

(3)一种反映上面(1)或(2)所描画

的条件或权能的文档阐明

需求的层次

下面这些定义是需求工程范畴
中常见术语的定义阐明

软件需求包括三个不同的层次—业务需求、用户需求和功用
需求—也包括非功用
需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目的
央求

,它们在项目视图与范围文档中予以阐明

。用户需求(user requirement) 文档描画

了用户运用
产品必需求

完成的任务,这在运用
实例(use case)文档或计划

脚本(scenario)阐明

中予以阐明

。功用
需求(functional requirement)定义了开发人员必需
完成
的软件功用
,使得用户能完成他们的任务,从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功用
需求的汇合

,给用户提供处置
才干

并满足业务需求。软件需求各组成部分

之间的关系如图所示。

作为补充,软件需求规格阐明

还应包括非功用
需求,它描画

了系统展示

给用户的行为和执行的操作等。它包括产品必需
服从
的规范

、规范

和合约;外部界面的细致

细节;性能央求

;设计或完成
的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和结构

上的限制。质量属性是经过
多种角度对产品的特性
中止

描画

,从而反映产品功用
。多角度描画

产品对用户和开发人员都极为重要。

值得留意
的一点是,需求并未包括设计细节、完成
细节、项目计划

信息或测试信息。需求与这些没有关系,它关注的是充沛

阐明

你究竟

想开发什么。

Frederick Brooks在他1987年的经典的文章“No Silver Bullet:Essence and Accidents ofSoftware Engineering ”中充沛

阐明

了需求过程在软件项目中扮演的重要角色:

开发软件系统最为艰难

的部分

就是精确

阐明

开发什么。最为艰难

的概念性工作便是编写出细致
技术需求,这包括一切
面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错,将最终会给系统带来极大损伤
的部分

,并且以后再对它中止

修正
也极为艰难

为什么这么说呢,由于
在大多数的软件系统中,最终用户可能都不分明

他的需求是什么,这是千真万确的。假定

你的用户通知
你需求就是这些了,不要置信
他,继续寻根究底
,直到你们都精疲力竭

了。

固然
听上去有些不可思议,但这是阅历

之谈,在我从事的项目之中,没有一个用户在软件接近完成的时分
打电话对我说,我看了你们的软件,我想我必需
改动一些中央
。在那些日子中,我致使

得了一种电话铃音恐惧症。

需求风险

下面列出了在做需求剖析

时一些很风险
的做法,假定

你发现你的一些做法与之相似

,那么,给自己

一些时间,好好思索

一下,这些做法会对你的软件产生致命的影响。

1. 无足够用户参与

客户经常不明白为什么搜集
需求和确保需求质量需破费

那么多功夫,开发人员可能也不注重
用户的参与。究其缘由
:一是由于
与用户协作
不如编写代码有意义
;二是由于
开发人员觉得曾经
明白用户的需求了。在某些状况

下,与理论

运用
产品的用户直接接触很艰难

,而客户也不太明白自己

的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中,并一同阅历
整个开发过程。

最重要的就是用户必需求

注重
他的软件,必需
让他明白:假定

失败,他的损失最大(当然你的损失也不小,但这时分
你必需
让他注重
这项工作)。假定

用户不够注重
,想办法

处置

,否则你就不用再继续了。

2. 用户需求的不时
增加

在开发中若不时
地补充需求,项目就越变越庞大致使
超越
其计划

及预算范围。这使得问题更难处置

。理论

上,问题本源

在于用户需求的改动
和开发者对新需求所作的修正
。要想把需求变卦
范围控制到最小,必需
一开端
就对项目视图、范围、目的
、约束限制和胜利

规范

给予明白
阐明

,并将此阐明

作为评价需求变卦
和新特性的参照框架。阐明

中包括了对每种变卦
中止

变卦
影响要素
剖析

的变卦
控制过程,有助于一切
风险承担

者明白业务决策的合理性,即为何中止

某些变卦
,相应耗费

的时间、资源或特性上的折中。

产品开发中不时
持续
的变卦
会使其整体结构

日渐紊乱,补丁代码也使得整个程序难以了解

和维护。插入补丁代码使模块违犯
强内聚、松耦合的设计准绳
,特别是假定

项目配置管理工作不完善的话,收回变卦
和删除特性会带来问题。假定

你尽早地域
别这些可能带来变卦
的特性,你就能开发一个更为强壮

的结构

,并能更好地顺应
它。这样设计阶段需求变卦
不会直接招致
补丁代码,同时也有利于减少因变卦
招致
质量的降落

最糟糕的莫过于用户觉得假定

不再加点什么功用
就对不起自己

。我曾经看过一个数据仓库的一期工程,在设计阶段没有很好的定义范围,当我向项目管理者提出这个问题的时分
,他以为
都曾经
说好了,合同上也写分明

了,并没有加以注重
。可是最终
,用户提出的修正
意见曾经
远远超出了范围,项目时间也延长了一倍。整个的项目组成员疲惫不堪,可是却不时
的接到用户投诉说项目失败。

3. 不置可否

的需求

不置可否

是需求规格阐明

中最为可怕的问题(Lawrence 1996)。它的一层含义是指诸多读者对需求阐明

产生了不同的了解

;另一层含义是指单个读者能用不止一个方式来解释某个需求阐明

不置可否

的需求会使不同的风险承担

者产生不同的希冀
,它会使开发人员为错误问题而糜费
时间,并且使测试者与开发者所希冀
的不分歧
。一位系统测试人员曾通知
我,她所在的测试组经常对需求了解

有误,致使
不得不重写许多测试用例并重做许多测试。

不置可否

的需求带来不可避免

的结果
便是返工—重做一些你以为
已做好的事情。返工会耗费

开发总费用的40%,而70%~85%的重做是由于需求方面的错误所招致
的(leffingwell 1997)。想像一下假定

你能减少一半的返工会是怎样的状况

?你能更快地开发出产品,在同样的时间内开发更多、更好的产品,致使

能偶尔

回家休息休息。

处置
不置可否

需求的一种办法

是组织好担任
从不同角度检查
需求的队伍。仅仅简单阅读
一下需求文档是不能处置

不置可否

问题的。假定

不同的评审者从不同的角度对需求阐明

给予解释,但每个评审人员都真正了解

需求文档,这样二义性就不会直到项目后期才被发现,那时再发现的话会使得更正代价很大。

4. 不用
要的特性

“弄巧成拙
”是指开发人员力图增加一些“用户观赏

”但需求规格阐明

中并未触及
的新功用
。经常发作
的状况

是用户并不以为
这些功用
性很有用,致使
在其上耗费

的努力“白搭”了。

开发人员应当为客户构思计划

并为他们提供一些具有创新认识
的思绪
,细致

提供哪些功用
要在客户所需与开发人员在允许时限内的技术可行性之间求得均衡

,开发人员应努力使功用
简单易用,而不要未经客户同意,擅自脱离客户央求

,自作主张。

同样,客户有时也可能央求

一些看上去很“酷”,但缺乏适用
价值的功用
,而完成
这些功用
只能徒耗时间和本钱
。为了将“弄巧成拙
”的危害尽量减小,应确信:你明白为什么要包括这些功用
,以及这些功用
的“来龙去脉”,这样使得需求剖析

过程不时

是注重那些能运用
户完成他们业务任务的中心
功用

时辰
记住:软件胜利

的规范

是能否
处置

用户的问题,而不是它有多Cool的功用

5. 过于精简的规格阐明

有时,客户并不明白需求剖析

有如此重要,于是只作一份简单
之至的规格阐明

,仅触及
了产品概念上的内容,然后让开发人员在项目停顿
中去完善,结果很可能呈现
的是开发人员先树立
产品的结构

之后再完成需求阐明

。这种办法

可能适合

于尖端研讨
性的产品或需求自身

就十分

灵活

的状况

(McConnell 1996),不过商业应用大多都不是这种状况

。在大多数状况

下,这会给开发人员带来迂回

(使他们在不正确的假定
前提和极端
有限的指导下工作),也会给客户带来懊恼

(他们无法得到他们所想象
的产品)。

6. 疏忽

了用户分类

大多数产品是由不同的人运用
其不同的特性,运用
频繁水平

也有所差别

,运用
者受教育水平

和阅历

水平

也不尽相同。假定

你不能在项目早期就针对一切
这些主要用户中止

分类的话,必然招致
有的用户对产品感到失望

。例如,菜单驱动操作对高级用户太低效了,但含义不清的命令和快捷键又会使不熟练

的用户感到艰难

7. 不精确

的计划

“上述是我对新产品的见地
,好,往常

你能通知
我你什么时分
能完成吗?”许多开发人员都遇到这种难题。对需求剖析

缺乏了解

会招致
过火
悲观
的估量
,而当不可避免

的超支发作
时,会带来颇多省事

。据报道,招致
需求过程中软件本钱
估量
极不精确

的缘由
主要有以下五点:频繁的需求变卦
、遗漏的需求、与用户交流不够、质量低下的需求规格阐明

和不完善的需求剖析

(Davis 1995)。

对不精确

的央求

所提问

题的正确响应是“等我真正明白你的需求时,我就会来通知
你”。基于不充沛

信息和未经深思的对需求不成熟的估量
很容易为一些要素
左右。要作出估量
时,最好还是给出一个范围(如最好的状况

下,很可能的,最坏状况

下)或一个可信任
的水平

(我有9 0 %的把握,我能在8周内完成)。未经准备的估量
通常是作为一种猜测

给出的,听者却以为
是一种承诺。因而

我们要尽力给出可抵达

的目的
并坚持完成它。

什么是优秀的需求

讨论软件需求的文章有很多,关于
需求的规范

也不尽相同,这里我想用NASA的软件开发过程中的概念,软件需求过程的规范

是:分明

(Clear)、完好
(Complete)、分歧
(Consistent)、可测试(Testable),此外还有其他的概念,如可跟踪的、可修正
的等等。

分明

:目前大多数的需求剖析

采用的依然

是自然言语
(由于
假定

采用方式
化言语
的话,和用户的沟通将成为一个大问题,这意味着客户在开发软件之前必需
先中止

方式
化言语
培训,这是不理想
的)。自然言语
对需求剖析

最大的弊病就是它的二义性。所以我们不得不对需求剖析

中采用的言语
做某些限制。例如尽量采用主语+动作的简单表达方式。说白了,需求剖析

中的描画

让人看上去像是刚学习写作的小孩子就对了,千万不要采用疑问句、修饰这些华美
的表达方式。

除了言语
的二义性之外,主见

不要运用
行话,就是计算机术语。需求剖析

最重要的是和用户沟通,可是用户多半不是计算机的专业人士,假定

在需求剖析

中运用
了行话,就会构成

用户了解

上的艰难

打个比如

,假定

你要做一个银行的信誉
卡系统,你就能够

这样描画

软件需求:银行的卡部管理信誉
卡,每张信誉
卡只属于一个帐户。信誉
卡有卡号、余额。一张信誉
卡有多笔的买卖
记载

完好
:再也没有什么比软件开发接近完成是发现遗漏了一项需求更糟的事情了。需求的完好
性是十分

十分

重要的,想象一下遗漏需求而不得不返工,这简直

就是恶梦。可是令人遗憾的是,需求的遗漏是很经常发作
的事情,不只
仅是你的问题,更多的问题发作
在用户那里,他们不知道

该做些什么。要做到需求的完好
性是很艰难

的一件事情,它触及
到需求剖析

过程的各方各面,贯串
了整个过程,从最初的计划

制定到最终
的需求评审。至于完好
性的细致
讨论,我们会在下面的章节中讨论,往常

你只需求
拼命的想象缺乏完好
性的坏处

,直到你出了一身的冷汗。出了吗?好,那我们继续。

分歧
:分歧
性也是一个比较

大的概念,很难用几句话讲分明

。还记得我们在开端
的时分
提到的需求的层次吗?简单的来说,就是用户需求必需
和业务需求分歧
,功用
需求必需
和用户需求分歧
。严厉
的恪守

不同层次间的分歧
性关系,就能够

保证最终
开发出来的软件系统不会偏离最初的完成
目的
。在完成
过程中,我们还必需
把分歧
性关系细化。比如

说用户需求不能超出先前指定的范围。

可测试:大家觉得一个项目的测试从什么时分
开端
呢?有人说从编码完成后开端
。更分明

一点的说是编码的时分
同时中止

单元测试,编码完成后中止

系统测试。这些都没有错。但是理论

上测试是从需求剖析

过程就开端
了。需求剖析

是测试计划

的输入和参照。这就央求

需求剖析

是可测试的。什么是可测试呢?“我们要用新的系统完成报表自动化处置
”,你觉得这个需求是可测试的吗?当然不是,报表包括哪些?自动化处置
的规范

是什么?这些在需求中都没有阐明

。因而

这项需求是无法测试的,就是不具有可测试性。说到这里,大家可能就会明白之前的需求的几项规范

都是为了保证需求的可测试性的。事实就是这样,只需

系统的一切
需求是能够

被测试的,才能够

保证软件不时

盘绕
着用户的需求
,保证软件系统是胜利

的。大家真正在应用一些科学的办法

的时分
也应该记住,任何的办法

都是为了保证软件的胜利

,不要偏离这个目的
,千万不要走火入魔了,呵呵,很容易的。

本文来源于火龙果软件

给大家举荐

我国新一代大数据用户行为剖析

与数据智能平台:数极客(https://www.shujike.com),是支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式,整合剖析

用户行为数据和业务数据,能够

自动监测网站、APP、小程序等多种渠道推行
效果剖析

,是增长黑客们必备的互联网数据剖析

软件。数极客支持实时多维剖析

、漏斗剖析

、留存剖析

、途径
剖析

等十大数据剖析

办法

以及APP数据剖析

网站统计网站剖析

小程序数据统计用户画像等应用场景,业内首创了六种提升转化率的数据剖析

模型,是用户行为剖析

范畴
首款应用定量剖析

与定性剖析

办法

数据剖析

产品

发表评论

评论已关闭。

相关文章