从用户的视角研发软件规模度量

用户视角的定义

用户视角表示使用用户的语言对用户业务需求进行的一种正规描述。开发人员将用户信息转换成信息技术语言以便提供解决方案。

功能点计数是通过使用用户和开发人员都通用的语言信息来完成的。

用户视角：

· 是一个业务功能的描述

· 是被用户认可的

· 可以用来计算功能点

· 可以在物理形式上变化的（例如：事务处理目录、建议书、需求文档、外部规格说明、详细规格说明、用户手册）

 

研发生命周期中软件规模度量

用户需求在项目的初期阶段可能发生快速变化。必须由用户和开发人员共同决定哪些功能需要包含在被开发的应用系统中。这些关于项目功能的决定可能会受到以下因素的影响：

· 不同组织的需要（初创公司、政府部分、金融机构、电信公司……）

· 与项目关联的风险（业务和技术上的）

· 组织中可用于项目的资源（如：预算、人员）

· 组织中可用的软件技术

· 用户或者开发人员通过意见和建议产生的影响

随着需求的不断深入，用户提出越来越准确的需求。用户将和软件开发人员共同讨论以生成详细的需求。软件开发人员可以根据可行性研究提前开始他们自己的开发和实现需求。用户和软件开发人员之间的讨论也会导致增加需求。开发过程在不同组织中是不一样的。为了阐明目的，需要考虑三种需求文档的模型：

· 初始用户需求

· 初始技术需求

· 最终功能需求

 

初始用户需求

该阶段表示在用户和软件开发人员召开会议之前的用户需求。它可能具有以下特点：

· 不完整

例如，初始用户需求可能缺少提供完整性参考的功能要求。

· 缺少“实用”功能性

例如，重要的验证报告或查询可能缺失。

· 不能实现或很难使用

例如，用户可能要求一个需要CPU处理一个小时的在线查询。

· 过于通用

例如，需求中可能不包括域的数目。

· 不断变化的功能需求，特别是如果一个以上的用户负责该项目

例如，一个特定项目的需求可能随着一个个用户而改变，特别是他们没有相同的功能需要。

· 不考虑应用系统边界就提出的需求

例如，现有和/或者将来的应用系统边界可能不被考虑到。

· · 用不同的上下文或使用与功能点分析不兼容的术语表达

例如，初始用户需求可能提到系统的物理或者手工操作方面。

示例

在一个组织的人力资源部门，用户将他的需求表达为：

“无论什么时候，我可以对任何一个雇员，我只要能够通过输入他或她的名字就可以查看雇员的信息。”

这个需求意指一个查询界面和一组雇员数据的开发。（为了使例子简单化，假设雇员数据组由其他的雇员功能进行内部维护，比如创建，更新和删除雇员，在此不作说明）

初始用户需求功能示例：

EQ 一个特定雇员的查询。

ILF雇员数据组。

 

初始技术需求

这个阶段从可行性研究的结果总结出软件开发人员视角的需求观点。在开发人员的任务中，有一个是将可能有的需求组织到现有的应用系统中。初始技术需求可能包括实现中必要的但是不在功能点计数中使用的元素（例如：临时文件，索引，等等）。这个阶段可能有以下特点：

· 技术依赖

例如，根据数据库环境改变的物理文件。

· 错误识别用户功能需求

例如，软件开发人员可能添加没有被用户所要求的功能。

· 用户不熟悉的术语

例如，软件开发人员可能提及物理文件而不是数据逻辑组。

· 可能会通过过于强制的技术限制来确定功能

例如，一些开发人员试图通过关注组织内当前可用的计算机容量来限制需求的范围。

· 根据组织内其他应用系统的技术架构来决定边界。

例如，对于客户和服务器可能有各自的技术要求，但是在功能点计数时，它们可能包含在同一个应用系统中。

示例

继续同一个示例，开发人员说：

“我找出了一个雇员查询的需要。有必要建立一个索引来加速检索特定雇员信息。”

初始技术需求功能可能被确认为：

EQ 特定雇员的查询

ILF雇员数据组

ILF* 雇员文件的索引

*索引文件是不被计数的。在此例中，索引文件被误认为是一个ILF，用来举例说明软件开发人员一个潜在的计数错误。

 

最终功能需求

该阶段的需求是用户和软件开发人员通过召开联合会议的方式得到的。联合会议对于达到一致和完整的应用系统功能需求是很有必要的。该阶段是功能需求在开发阶段开始前的最后一个版本，具有以下特点：

· 包含同时可以被用户和软件开发人员所理解的术语

· 包含了所有用户需求的完整描述，包括不同用户之间的需求

· 足够完整和一致，从而可以准确计算功能点

· 每个流程和数据组都是由用户认可的

· 可行性和可用性都被软件开发人员认可

示例

继续相同的例子：

用户：“无论什么时候当我与一个雇员工作时，我想要能够通过输入他或她的名字来查看雇员的信息。”

开发人员：“我找出了一个雇员查询的需求，但是许多雇员可能同名。不可能通过输入他/她的姓名就确定一个雇员，因此，我建议创建一个在线雇员名单（姓名、位置和社会保障号）可以从中选择一个雇员。有必要建立一个索引来加速检索特定雇员信息。”

用户：“我同意在这种情况下有必要创建一个雇员选择名单，并且它可以用于除选择雇员以外的目的。”

用户和开发人员的讨论结果：

· 在功能需求和功能点计数中增加在线雇员名单

· 把雇员索引排除在功能点计数之外，因为它是一个技术解决方案

最终功能需求功能示例：

EQ 一个特定雇员查询

EQ 在线雇员名单

ILF 雇员数据组

最终功能需求文件是在开发阶段开始前需求的最终版本。此时，最终的需求被认同为完整的、正式的和被认可的。假设没有另外的范围改变，功能点数应当与开发完成时的点数一致。（www.parawork.com）