学习笔记-需求工程最佳实践

1)成立甲乙双方参与的需求控制组

项目的成功不单是乙方的成功,更是甲方的成功,甲乙双方紧密配合、互相理解、互相合作才能成功。

为避免一方具有绝对控制权的现象,成立甲乙双方参与的需求控制组是避免需求蔓延的有效手段。

该组织具有对需求的决策权,对每项需求的增删改查都是平衡了进度、质量、投入后才确定。

该组织不是一个流于形式的组织,应切实地参与需求的获取、描述、分析、确认、变更等活动。

2)识别合适的需求提供者,尤其不要遗漏最终用户 

在获取需求时首先识别谁是最可能有需求,识别出合适的需求提供者

需求的提供者包括了客户、最终用户、间接用户。客户是掏钱买软件的人;最终用户是使用软件的人;间接用户对软件有影响力,但可能不使用软件,也不掏钱买软件。三种角色可能有重合,不同的用户对需求的作用不同,必要忽略任何一种类型的需求提供者

在很多项目中往往忽略最终用户的需求,而导致操作层面的需求捕获不全,系统上线后返工很大

3)在项目初期引导客户如何实施一个软件项目

客户引导是一个大问题,尤其是一个没有IT经验的客户。如果客户缺乏正确的实施IT项目的观点,那么他就不知道如何去提出需求,如何控制需求范围,如何管理IT项目。

客户的需求是项目的输入,如果需求不明确,需求有遗漏,需求总是不切实际,需求没有划分优先级,则对整个项目的成本影响重大。因此需要在项目初期对客户实施引导,告诉客户项目成败的关键因素是什么,在项目的进展过程中客户需要注意什么

4)引导用户划分需求优先级

用户往往不关注需求的优先级,认为所有的需求都是重要的。需求工程师需要引导用户划分需求的优先级,而不是单刀直入地让用户划分优先等级。可以通过以下的启发式问题引导客户划分需求优先级。

在谈到的需求中,最重要的3项需求是什么?

这个需求比另外一个需求更重要么?

这个需求是否可以考虑采用其他的解决方案,而不是通过系统来实现?或是简单实现?

如果推迟或是不实现这个需求,是否对项目的目标有影响?

如果推迟或是不实现这个需求,会对哪些业务、哪些人员有怎样的影响?

5)采用用户故事+验收准则描述用户需求

用户故事是敏捷开发方法中描述用户需求的方法,该方法采用三段论的方式描述需求:

作为一个家庭主妇,我需要一个30平米的餐厅,以便招待10个朋友进餐

作为一个系统管理员,我希望系统能够自动备份重要的数据,以便在发生灾难时可以自动恢复。

通过这个描述,可以帮助我们确定每个需求的重要性,同时提供了一个伸缩的弹性,即这个需求的细节特征可能有比较大的协调空间,可以方便我们进行需求、质量、进度、投入的平衡。

仅仅描述了用户故事还不足以让开发人员准确了解需求,还需要描述每个故事的验收标准。通过验收标准来细化需求,在开发者与用户之间达成对需求的一致理解。比如:

餐厅要灯光明亮

餐厅要靠近厨房

餐厅面积要5米X6米;

。。。。。。

非敏捷的传统开发项目,也需要明确描述需求的验收标准。验收标准代表了客户的最低要求,通过编写验收标准可以发现需求中不明确的地方,凡是不能写出验收标准的需求通常是模糊的需求,通过编写验收标准可以起到对需求的补充完善作用。

6)需求描述中至少包括:业务流程图、用例、界面原型、非功能性需求与需求优先级。

业务流程图描述客户的业务处理流程,对于理解需求者提供了一个很好的背景信息,可以从业务流程图中提取出功能性需求与非功能性需求。

用例描述了人机交互的流程,划分了人与系统的职责,清晰刻画了正常与异常的事件流,无论是与客户还是与技术人员都很容易沟通,是描述功能需求的一种有效方式。

界面原型将软件的功能直观地展示出来。一图胜千言,便于引导客户提出更细致、更准确的需求,也便于与技术人员沟通。在需求获取与分析时,应该尽早构造出界面原型。并非需要针对所有的需求构造原型,只是核心的,难以理解的需求需要构造原型。

非功能性需求是用户容易忽略的需求,需求分析人员需要引导客户提出客户提出非功能需求,如果客户不能提出,需求分析人员要根据历史的经验定义出非功能性需求并和客户确认。非功能性需求一定要描述出来,不能想当然地认为应该如何如何,而没有文档化。非功能性需求能量化则量化,不能量化可采用原型描述。

需求的优先级一般最多划分为3级,优先级最高的最先实现。需求的优先级为采用迭代方法提供了一个基础,也为平衡进度、质量、需求、投入提供了决策。

在描述需求时,不仅仅局限这5个方面,还有项目的目标,涉及的用户角色、系统的运行环境、处理数据等等,但是上面的5个方面往往是最容易出问题的地方。

7)测试人员参与需求评审,确保需求的可测试性

需求的描述详细到可测试的程度。所谓的测试,即测试人员阅读了需求以后可以编写出测试用例,能够识别出输入、操作流程、处理逻辑,以及预期的输出。测试人员参与需求的评审,关注的就是需求的可测试性,如果一个需求不可测试,则说明该需求描述地不够明确

8)采用功能点方法度量软件规模,确保需求描述的明确性

功能点方法不仅仅是一种规模度量模型,还是一种需求验证的方法,如果存在两位功能点分析师对同一需求计算出的功能点不一致,往往是由于需求的描述不够明确而导致的。在需求的阶段,通过度量软件的规模可以促进对需求的沟通和理解,从而发现需求中模糊、有争议的地方。

9)通过给客户讲解需求及演示界面原型的方式让客户确认需求

需求每经过一次传递,就会发生一次误传,要么信息有遗漏,要么信息有错误。通过需求的确认,可以及时发现这些错误。开发人员给客户讲解需求的理解,给客户演示界面原型,以及在开发过程中阶段性演示半成品,都是需求确认方式。人们只有看到实际的软件才能提出更多的需求,这是客观现实,因此应该多用原型法来确认需求,这也是敏捷方法中频繁交付这条实践的来源。

 对客户的需求可以确认多次。比如,首先是初步的需求访谈记录确认,然后是界面原型的确认,再进行高保真的界面原型确认。在项目开发过程中,可以不断地对软件半成品进行确认,指导最后的验收确认。

10)无论大小需求的变更都应纳入变更控制的流程

需求总是渐变的,对于大变更、小变更都应纳入需求变更流程。很多项目往往忽略了对晓变更的控制,积少成多,最终导致需求、设计、代码的不一样。需求的变更可以分级控制,明确划分不同级别的需求变更,级别不同,审批的流程与权限可以不同。

11)针对非功能性需求执行QFD(质量功能部署)

针对非功能性需求执行QFD,即建立非功能性需求与设计方案之间的映射关系、非功能性需求与测试用例之间的映射关系。在实际项中,项目组往往只会关注功能性需求的实现与测试,而忽略非功能性需求的实现与测试,通过该实践可以规避对非功能性需求的实现风险。

你可能感兴趣的:(学习笔记-需求工程最佳实践)