需求阶段

需求管理( RM )

SG1 管理需求

SP1.1 理解需求:与需求的提供者对需求的含义达成一致

SP1.2 获得对需求的承诺:获得项目组成员对需求的承诺

SP1.3 管理需求的变更:在项目进行中,管理需求的变更

SP1.4 维护需求的双向可跟踪性:维护需求和工作产品之间的双向可跟踪性

SP1.5 确定项目工作和需求间的差异:识别项目计划、工作产品和需求之间的不一致

常见问题

1.因为项目进度赶等原因,在很多需求还没有明确情况下,便开始开发的工作。
2.开始客户只能提出模糊的需求,客户喜欢先让你做个东西给他看,然后他才可能逐渐提出真正的需求,而需求调研人员,对此没有什么好的处理办法。
3.客户以种种原因不签需求,项目组在不签需求的情况下,便开始开发工作。
4.客户不承认之前提出来的需求,项目组又不能得失客户,项目成员苦不堪言。
5.需求经常变化,无法控制。
6.设计、代码与需求不对应,特别是需求变更时,不知道应该修改哪部分,也不知道会有哪些影响。

SG1

管理需求并且识别出需求与项目计划、工作产品不一致的地方。

1.需求要被管理,被管理的意思又有两层:一是需求要被确认,二是要控制需求变更

2.需求要用来指导下游的工作产品,如:计划、设计、测试等

SP1.1:理解需求。

Develop an understanding with the requirements providers on the meaning of the requirements.

开发者应该理解客户的需求,如果这点做不到,后面的工作是没有意义的。所以,那种在没有理解需求的情况下,就仓促开发的做法是不合适的。

当然,如果想通过做原型来获取需求不在此列,另外,大家也千万不要误解,在没有完全理解需求前一定不能开展开发工作,如果部分需求已经掌握,有部分需求还没有掌握,那也是可以先开展已掌握部分需求的设计、编码工作的,这时需要考虑没有确定部分的需求对这些工作可能带来的影响。

SP1.2:确认需求

Obtain commitment to the requirements from the project participants.

就是要和客户签署需求。

我想大家都非常理解这点的重要性,但大家可能会说,说得容易,客户就是不签,咋办?客户不签需求,主要是两方面的原因:

1)客户不确定需求。

2)客户担心签了需求后,他就不好变了。

把SP1理解需求做好,可以参考需求开发(RD)

消除客户的顾虑,签署需求是双方约束,另外需求是可以变的,现在签署只是标志着当前的一个工作里程碑,当前签订的需求作为后续工作的基准。

SP1.3:管理需求变更

Manage changes to the requirements as they evolve during the project.

需求不是不可以变,只不过需要管理。

1.要充分理解客户提出来的需求变更,深究其原因,不能客户一说变就变,超过一半的客户变更要求,其实都是不合理的,或者是有其它更好的替代办法的。

2.变更要求,要有记录和确认

3.需求变更的影响,包括增加的工作量,风险等。要有清单并确认

4.需求变更导致项目成本和进度变化太大,走决策

SP1.4 :维护需求的双向跟踪

Maintain bidirectional traceability among the requirements and the project plans and work products.

需求是用来指导后续工作的,所以需求与计划、设计、编码、测试等后续工作都需要维护好对应的关系,与SP1.3关系密切

双向跟踪是指纵向和横向跟踪,纵向跟踪的意思是上下游工作产品之间的跟踪关系。而横向跟踪指的是需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等。其中一个需求变化了,有可能影响另外一些需求,其中一个设计变了也可能影响另外一些设计。

这是个双向跟踪网络,任何一点发生变化,能找出全部受牵连的地方。

SP1.5:识别出需求与下游工作产品不一致的地方

Identify inconsistencies between the project plans and work products and the requirements.

1.需求变更时,利用双向跟踪表找出需要修改的地方,并用跟踪表来发现不一致的地方并调整。

2.编写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品的时候,要注意要与需求保持一致。

需求开发( RD )

内容:

​ SG1 开发客户需求:收集共同利益者的需求、期望、限制条件和接口,并且把它们转换成客户需求。

​ SP1.1 获得客户需求:导出产品生存周期所有阶段共利同益者的需求、期望、限制条件和接口。

​ SP1.2 生成客户需求:把共同利益者的需求、期望、限制条件和接口转换成客户需求。

​ SG2 开发产品需求:对客户需求加以精炼和细化,以便开发产品生存周期中的产品和产品构件需求。

​ SP2.1 建立产品需求和构件需求:根据客户需求,为保证产品和产品构件的有效性和可提供性,确定产品和产品构件需求。

​ SP2.2 分配产品构件需求:为每个产品构件分配需求。

​ SP2.3 确定接口需求:确定功能之间或对象之间的接口。

​ SG3 分析和确认需求:对各项需求进行分析和确认,并且开发所要求的功能度的定义。

​ SP3.1 建立操作概念和场景:建立并维护操作概念和场景。

​ SP3.2 定义功能需求:建立并维护所要求的功能度的定义。

​ SP3.3 分析需求:分析派生的需求,确保它们是必要的和充分的。

​ SP3.4 平衡需求:分析需求,平衡共同利益者的需求和约束。

​ SP3.5 确认需求:在适当时候,采用多种技术确认需求,以确保将要产生的产品能在预计的用户环境中恰当运行。

需求开发没有做好的原因

大部分是没有把握好客户需求,直接进入软件的细节,去讨论要做什么功能,界面要怎样设计去了,而忘记了软件的根本目的是为了解决什么问题。

当我们明确客户需求后,就应该把客户需求转变成产品需求和产品组件需求,客户需求一般都是比较高层次的,而且描述也会比较简单,不能作为日后验收的标准,我们需要对软件的规格进行说明。一般来说,我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候,要注意产品需求和产品组件需求,必须和客户需求对应起来,通常是多对多的关系。为什么要对应起来?我们要保证,软件的每一个界面,每一个功能都是有用的,都是“源自”客户需求的,这样才能保证我们做的事情都是正确的事情,防止被不相干的事情干扰。

我们经常抱怨客户的需求在变,其实80%的原因是没有把握住客户需求,其实客户经常变的是产品需求或者是产品组件需求,客户需求是很少变的,就是因为我们没有把握住客户到底想要什么、需要什么,导致我们认为客户太难“服侍”了。只有把握住客户真正的需求,我们才能抓住根本,万变不离其中

需求管理强调的是需求的确认以及需求变更的控制,而需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。
以上两个关于需求开发的例子,都是反面教材,都没有能很好地把握需求,一个没有抓住问题的关键,一个没有能找到真正的需求提供者来获取需求。

理解好需求开发

需要先理解清楚以下几个关键的概念:
1)客户需求(Customer Requirements)
2)产品需求(Product Requirements)
3)产品组件需求(Product Component Requirements)

客户需求是可以理解成客户为什么要做本系统,要解决什么问题,客户对系统有怎样的期望,希望能具备一些怎样的特点,简单的说,就是客户的需要是什么。
产品需求是能满足客户需求,并对软件产品规格进行了详细描述的需求,软件设计师可以根据产品需求进行设计、编码等工作。
产品组件需求,是对产品需求的进一步细化,产品可能会分割成几个子系统、几个部分,每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等,这些可以认为是产品组件需求。

从另外一个角度,需求可以分为功能性需求和非功能性需求两类,功能性需求就是系统具备怎样的功能,能做什么事情,而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求,都会包含功能需求和非功能需求。

各项内容说明

SG1: 干系人的需要、期望、约束和接口要求被收集并转化为客户需求

Stakeholder needs,expectations,constraints,and interfaces are collected and translated into customer requirements.

SP 1.1: 导出干系人对整个产品生命周期各阶段的需要、期望、约束和接口要求等

Elicit stakeholder needs,expectations,constrains,and interfaces for all phases of the product life cycle.
1)干系人:干系人除了指甲方的领导、系统的最终用户,还包括使用本系统的第三方以及与本系统有交互的第三方系统的拥有者、使用者等。
2)产品生命周期各阶段:干系人对系统的期望不一定只限于软件功能的,可能还包括数据的整理、资料录入、安装培训、维护要求等,干系人可能对软件生产的过程阶段都会提出他的要求,获取需求的时候,要注意干系人在软件生命周期不同阶段有什么要求。
3)需要、期望、约束、接口要求:甲方一般会对系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性,满足一些什么接口要求和约束条件等,都会有大致的想法。需求调研工作,首先要注意搞清楚这些内容。
4)导出:客户的原始想法可能是不明确的,或者是客户一时难表达完整的,我们需要用一定的方法,让客户能完整无遗漏准确地表达出他的想法。通常我们可以通过原型、图示、类比、问卷等办法来导出客户的需求。

SP 1.2: 转化干系人的需要、期望、约束和接口要求为客户需求

Transform stakeholder needs,expectations,constraints,and interfaces into customer requirements.

SP1.1讲述的是通过一些方法记录客户原始的需求信息,而SP1.2讲述的就是把客户原始的需求信息整理成正式的客户需求,通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。

SG2: 客户需求是精确和详细的,以用来开发产品需求和产品组件需求

Customer requirements are refined and elaborated to develop product and product-components requirements.

SG1讲述的是导出客户需求,而SG2讲述的是由客户需求到产品需求、产品组件需求的过程。

SP 2.1: 建立和维护产品和产品组件需求,这些产品和产品组件需求是基于客户需求的

Establish and maintain product and product-component requirements,which are based on the customer requirements.
产品和产品组件需求,是比较细致的需求,会详细描述软件与用户是怎样交互的,用户需要输入什么,系统会输出什么等都会比较详细描述出来。而客户需求一般只描述能实现什么功能、解决什么问题等,比较高层次。
客户需求一般是难以验证是否已实现的,而产品需求和产品组件需求是对软件规格的描述,是可以用来做为验收的标准的。

SP 2.2: 分配需求给每一个产品组件

Allocate the requirements for each product component.

这个SP将需求开发与技术解决方案联系起来,所有的需求应该与设计的产品组件对应起来,保证需求驱动后续的设计工作,同时也保证设计都是为了需求服务的。SP2.2是对SP2.1的进一步细化。

SP 2.3: 定义接口需求

Identify interface requirements
接口需求包括系统与第三方的系统的接口要求,也包括系统本身各组件、各子系统、各部分之间的接口要求。通常这些接口需求在客户需求级别的时候,并不是很明细,需要对客户需求进一步细分成产品需求、产品组件需求,然后发掘出接口需求。SP2.3也是对SP2.1的进一步深化。

SG3:需求被分析和确认,并定义出具体的功能性需求

The requirements are analyzed and validated,and a definition of required functionality is developed.

SP 3.1: 建立和维护操作场景及相关情景

Establish and maintain operational concepts and associated scenarios.

SP 3.2: 建立和维护功能定义

Establish and maintain a definition of required functionality.

SP3.1和SP3.2是对需求描述的要求,要求描述出具体需求的操作场景、上下文,具体的操作步骤,对功能的详细描述等。通常我们可以通过UML的Use Case图或者是序列图等来表达这些内容。

SP 3.3: 分析需求以确认需求是必须和充分的

Analyze requirements to ensure that they are necessary and sufficient.

SP 3.4: 分析需求平衡以平衡干系人的需要和约束

Analyze requirements to balance stakeholder needs and constrains.

SP3.3和SP3.4是对需求的准确性、全面性、可实现性方面的要求,除了要取得全面准确地需求,还需要平衡约束条件,保证需求在约束条件下是可实现的。

SP 3.5: 用各种合适的方法确认需求,确保最终产品能在用户的环境中按照设想运行

Validate requirements to ensure the resulting product will perform as intended in the user’s environment using multiple techniques as appropriate.

这是需求开发的最后一步了,需求导出过程中尽管用了很多办法,但需求确认的时候,仍然需要采取办法确保获取的需求是符合最终的使用场景要求。

SP3.3、SP3.4和SP3.5,通常是通过需求评审来满足的。