“21天好习惯” 第一期-20

软件需求——第3章  需求工程的推荐方法

知  识	需求管理		项目管理
培训需求分析员 对用户代表和管理者进行需求培训 对开发者进行应用领域相关的培训 创建术语表	定义需求变更控制进程 成立变更控制委员会 分析需求变更的影响 控制需求版本并为其建立基线 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 使用需求管理工具 创建需求跟踪矩阵		选择合适的开发周期 根据需求制订项目计划 重新协商权利或义务 管理需求风险 跟踪需求耗费的人力物力 回顾以往的教训
需求获取	需求分析	编写规格说明		需求验证
定义需求开发过程 定义项目前景和范围 确定用户群 选择用户代言人 建立核心队伍 确定用例 确定系统事件和响应 举行进一步需求获取的讨论 观察用户如何工作 检查问题报告 重用需求	绘制关联图 创建原型 分析可行性 确定需求优先级 为需求建模 创建数据字典 将需求分配至各子系统 应用质量功能调度	采用SRS模板 确定需求来源 惟一标识每项需求 记录业务规范 定义质量属性		审查需求文档 测试需求 确定合格标准

 3.1  知 识 技 能

• 开发者也应该了解产品应用领域中的基本概念和术语。
• 培训需求分析员
• 对用户代表和管理者进行软件需求培训。
• 对开发人员进行应用领域的相关培训。
• 创建项目术语表定义应用领域专业名称的术语表可以减少误解。

 3.2  需 求 获 取

• 项目范围内的业务需求不能排斥任何必要的用户需求，每项功能需求都应该可以追溯到对应的用户需求。
• 定义需求开发过程：如何获取和分析需求、编写规格说明和验证需求的步骤编写成文档。
• 编写前景和范围文档：前景和范围(vision and scope)文档包含了产品的业务需求。
• 确定用户群和他们的特点：将产品的用户分成组，以避免出现某一用户群的需求被忽略的情况。
• 为每类用户选择代言人：为每类用户选择至少一位能够准确反映其需求的代言人。
• 建立典型用户的中心小组：把产品早期版本或同类产品的用户代表召集起来，收集他们对正在开发的产品的功能和质量特性的意见。

3.3  需 求 分 析

• 需求分析包括对需求进行推敲和润色以保证所有的涉众人都能够理解需求，以及仔细检查找其中的错误、疏漏和其他缺陷。
• 分析包括将高层的需求分解成具体细节、创建开发原型，以及评估可行性和协商需求优先级。
• 绘制关联图 关联图是显示新系统如何适应它的环境的一个简单的分析模型 。
• 创建用户界面和技术原型 当开发人员或用户对需求不能确定时，可构建一个开发原型。
• 分析需求的可行性 在允许的成本和性能要求下，分析在指定的运行环境下实现每项需求的可行性。
• 确定需求优先级 可采用分析方法确定产品功能、用例或单项需求的相对实现优先级。
• 为需求建模 模型包括数据流图、实体关系图、状态转换图或状态图、对话图、类图、序列图、交互作用图、决策表和决策树等。
• 创建数据字典 数据字典中包括系统用到的所有数据项和结构的定义。
• 将需求分解到子系统 将多个子系统的复杂产品的需求分配到各个软件、硬件以及人员子系统和部件中去(Nelsen 1990)。
• 应用质量功能调配 质量功能调配(QFD)是一种高级系统技术，它将产品功能、属性与客户的重要性联系起来(Zultner 1993;Pardee 1996)。

 3.4  需 求 验 证

•  需求验证可确保需求声明是正确的、具备了所需的质量属性，而且能够满足客户的需要。
• 审查需求文档 对需求文档进行正式审查是保证软件质量的有效手段之一。
• 测试需求 根据用户需求推导出功能测试用例，以便记录产品在特定条件下应有的行为。
• 定义合格标准 让用户描述决定产品是否满足他们的需求并适合使用的标准。

3.5  需求开发过程 

 

 需求开发是一个迭代的过程

 给出了一个可用于(或经过适当调整后)很多项目的需求开发过程框架