CMMI讲座分享之二——需求工程
自上一篇CMMI讲座分享已经过去很长时间了,CMMI能力评估准备工作也有条不紊的进行中,相信参评项目的小伙伴已经收到了文档准备的要求。在CMMI框架下的过程改进也在持续进行中,新的体系文件、手册、模板、作业指导书相信也会不久就与大家见面。这一篇就接续上一篇,来讲讲CMMI理解的需求工程。
什么是需求
在经济学中,需求指在一定的时期,在一既定的价格水平下,消费者愿意并且能够购买的商品数量。在心理学中,需求是指人体内部一种不平衡的状态,对维持发展生命所必须的客观条件的反应。
而在软件开发中的需求则是
IEEE定义:
(1)用户解决问题或达到目标所需的条件或能力。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
(3)一种反映上面(1)或(2)所描述的条件或能力的文档说明。
需求从何而来?
问题领域
所有的需求,都来自于实际问题。
例子:大量的纸质记录不便于维护和统计。现有手机使用非常不方便。在不同的办公地点间无法传输文件。
涉众需要
涉众:在任何问题的解决中,都涉及到很多的人和事。这些人和事都与问题的解决有或多或少的利益关系。
典型涉众:如修建公路时,司机,公路局,建筑公司是涉众,同时,如修路时需要拆迁的住户,牵扯到历史古迹可能涉及到文物管理部门等
从产品角度来说,深刻了解用户和获取用户的核心需求才是做产品的王道。
痛点分析:
用户在体验产品或服务过程中原本的期望没有得到满足而造成的心理落差或不满
我们在获取需求的时候一般都会遵循问题域、涉众、痛点分析的顺序。
痛点分析案例
寻求解决方案
面对客户的问题,该如何解决?
客户想要复印:
1. 帮客户复印。
2. 提供一台复印机。
3. 提供很多台复印机。
4. 提供完整的复印打印一体化办公解决方案。
确定解决方案之后,需要明确我们要开发的系统需要提供哪些特性,包括功能和非功能属性。
需求在此刻开始逐步清晰。
对需求的一些认识
获取软件需求的过程,是一个剥茧抽丝,步步精进的过程。每一步都必须有准确的认识,才能获得完美的需求。
从另一个角度来说,需求是一个从无到有的过程,客户只关注问题的解决,我们不能要求客户给出明确的需求!
面对客户“想要更快的交通工具”的需求,福特给出的不是更快的马车、自行车,而是汽车。面对客户“想要更多功能的手机”的需求,乔布斯给出的是舍弃键盘的智能机iPhone。
不同生命周期中的需求
在传统的瀑布模型(v模型)中,需求是所有开发过程的开端,诱导需求,编写需求文档,是所有设计开发工作的基础。在轻量级开发过程(极限编程)等模式中,需求是持续的,与其他开发过程相对平行的过程。
如果只有一堆邮件、贴条、会谈过几次或一些零碎的对话,你就确信你已明白用户的需求,那完全是自欺欺人。真正的“需求”实际上在人们的脑海中。任何文档形式的需求仅是一个模型,一种叙述方式。我们需要确保所有项目相关共利益者在描述需求的那些名词的理解上务必达成共识。这也是需求工程的需要做的工作
需求工程:
一般指应用已证实有效的原理、方法,通过合适的工具和记号,系统地描述出待开发系统及其行为特征和相关约束,通常是一些过程的集合:需求获取、需求分析和编写规格说明书及验证。
一句话概括需求工程:一个为系统的需求进行启发、组织、建档的系统方法,一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。
需求工程中的活动可分为两大类需求开发、需求管理
需求开发和需求管理之间的区别:
因为与一个系统相关的需求即使没有上千条,也至少有上百条,因此把它们合理的组织起来非常重要。因为我们无法永久记忆太多的信息,因此为需求建档能有效地支持涉众之间的沟通,必须把需求以易于理解的方式记录:文档、模板、数据库或白板上的列表
对于复杂项目,一系列有组织,标准化,系统化的过程和技术是需求管理的内涵。
需求的层次
通过对需求进行分层,建立针对不同层次需求的需求管理过程。
从客户角度出发决定业务需求。
从使用者角度出发决定用户需求。
最终决定系统需具备的功能需求。
◆ ◆ ◆
需求的三个层次
业务层需求(business requirement)从问题域而来,反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。
用户层需求(user requirement)描述了用户使用产品必须要完成的任务,这在用例(use case)文档或场景(scenario)说明中予以说明。
功能层需求(functional requirement)定义了开发人员必须实现的产品功能,使得用户能完成他们的任务,从而满足了业务需求。
◆ ◆ ◆
需求的分类
功能需求:
功能需求定义了系统实现的功能。系统功能提供了某些行为,行为所产生的结果,就是功能需求所关注的。通常会从功能需求,行为需求,数据需求三方面进行描述。
质量需求:
质量需求包括可靠性、可用性、可移植性、易维护性、数据计算精度等等
质量需求描述了待开发系统对质量的要求,通常会比功能性需求更影响系统架构。质量需求考虑到了功能需求所没有覆盖的地方。质量需求所反映出的质量特性,是客户对软件系统的最直观感受。
两个案例:
12306网站
淘宝双11
两者的用户体验不同,都说明的质量需求的重要性。
质量决定用户体验,决定用户对产品的“感觉”,所以应当重视质量需求,将其应用到需求开发过程中。
质量需求相对难把握,尽量用量化的指标来描述质量需求。
约束条件
“系统必须使用某项技术”
“该系统必须于20XX年XX月XX日前上线”
约束条件与功能需求和质量需求的不同之处,在于约束条件并不需要被实现。但是会附着于其他需求之上,而影响系统本身,影响开发过程。
需求过程支撑不同生命周期模型
研究软件工程的意义,在于将复杂的非线性过程,用适当模型进行表述。从早期的瀑布模型到现代的迭代,增量模型,甚至敏捷开发,开发和管理需求过程应该能够支撑所有开发模型。
增量开发模型中的需求
迭代模型中的需求
需求的开发和管理过程
◆ ◆ ◆
系统、系统环境和边界
任何系统都不是孤立的存在。对于需求工程而言,必须识别出周边环境中会对待开发系统造成影响的部分。
系统的需求源和对系统需求的论证取决于待开发系统的系统环境。需求源包括所有的初始需求定义或影响需求定义的各个环境方面。
在系统环境中的需求源
人(利益相关者和利益相关者群)
运营系统(技术系统,软件和硬件系统)
过程(技术或者物理过程,业务过程)
事件(技术上的或者物理上的)
文档(如法律,标准,系统文档)
系统边界的功能在于定义待开发系统将要包含哪些方面,哪些方面是该系统环境的一部分。
环境边界界定与待开发系统有连接的环境部分。
◆ ◆ ◆
边界的变化
1. 系统边界的变化
待开发系统的边界常常是不确定的:例如:当项目处于初始阶段,对待开发系统的功能和质量并不完全清楚,此时无法定义合适的系统边界。系统边界可能在一个“灰色地带”中。除了系统边界之外,“灰色地带”本身也可能会移动。
2. 环境边界的变化
环境边界也可以随时间而改变。例如:某系统的开发,会遵循某项法令的要求。此时可以确定一个环境边界。但是如果该项法律发生了变化,那么环境边界可能随着该法律内容的变化而扩展或缩小。
◆ ◆ ◆
定义系统与环境边界
1. 定义系统边界时,需做出以下决定:
与系统有关的哪些方面会被开发?那些方面属于系统环境?
确定系统边界,就是将待开发系统与所处的环境分离开来。通常,在开发过程中,可以被修改的部分,会被纳入系统边界之内,而开发过程无法修改的部分,会被视为系统边界之外。在系统边界确定后,通常需要考虑系统与外界之间的接口。通过接口,系统可以向所处的环境提供功能,监控环境的变化,影响环境中的参数。
2. 定义环境边界,需考虑以下问题:
哪些方面属于系统环境,那些特性是无关的?
将环境中与待开发系统相关的部分与无关的部分分离开,从而确定环境边界。在需求活动开始,可能会对系统环境识别的不够充分,随着需求开发的继续,需求工程师应重视对环境边界的划分。
描述系统环境
用户用例图:明确表现出系统边界,以及与边界外用户和其他系统的交互。
数据流图:通过描述数据的起点和终点而建立的模型,从而体现出数据在系统环境中的变化。
-END-
本文是“东航信息部IT百分百”原创,转载需注明出处
转载须保持以上所有内容完整。
文丨质量控制部