系统分析师:软件需求工程的需求定义、需求验证和需求管理

目录

一、需求定义

[1.1 需求定义方法](#1.1 需求定义方法)

[1.2 软件需求规格说明书](#1.2 软件需求规格说明书)

[1.2.1 SRS的编写方法](#1.2.1 SRS的编写方法)

[1.2.2 SRS的内容和格式](#1.2.2 SRS的内容和格式)

二、需求验证

三、需求管理

[3.1 需求变更](#3.1 需求变更)

[3.2 需求跟踪](#3.2 需求跟踪)

相关推荐


一、需求定义

需求定义(软件需求规格说明书SRS):是需求开发活动的产物,编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解,使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一,对于任何规模和性质的软件项目都不应该缺少。

1.1 需求定义方法

(1)严格定义也称为预先定义,需求的严格定义建立在以下的基本假设之上:所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采用图形(或文字)可以充分体现最终系统。

(2)原型方法,迭代的循环型开发方式,需要注意的问题:并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难,原型提供了克该服困难的一个手段。特点:需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的,需求一旦确定,就应遵从严格的方法。

1.2 软件需求规格说明书

1.2.1 SRS的编写方法

(1)用好的结构化和自然语言编写文本型文档。
(2)建立图形化模型,这些模型可以描述转换过程、系统状态及其变化、数据关系、逻辑流、对象类及其关系。
(3)编写形式化规格说明,这可以通过使用数学上精确的形式化逻辑语言来定义需求。

1.2.2 SRS的内容和格式

在国家标准《计算机软件文档编制规范》(GB/T8567一2006)中,提供了一个SRS的文档模板和编写指南,其中规定SRS应该包括以下几部分内容:范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解、附录。

二、需求验证

目的是与用户一起确认需求无误,对需求规格说明书SAS进行评审和测试,包括需求评审和需求测试。

需求评审:在软件开发的每个阶段结束前,都需要进行技术评审。可以分为三种类型:

  • (1)评审。是指一次正式的会议,在会议上向用户或其他项目干系人介绍一个或一组工作产品,以征求对方的意见和批准。
  • (2)检查。是一种正式的评估方法,将由非制作者本人的个人或小组详细检查工作产品,以验证是否有错误、是否违反开发标准、是否存在其他问题。
  • (3)走查。是一个评审过程,由某个开发人员领导一个或多个开发团队成员对其工作产品进行检查,由其他成员针对技术、风格、可能的错误、是否违反开发标准和是否存在其他问题提出意见。

在实际工作中,技术评审可以分为正式评审和非正式评审。

做好需求评审工作的经验:分层次评审、正式评审和非正式评审结合、分阶段评审、静心挑选评审人员、对评审人员进行培训、充分利用需求评审检查单、建立标准的评审流程、做好评审后的跟踪工作、充分准备评审。

需求测试:设计概念测试用例。

需求验证通过后,要请用户签字确认,作为验收标准之一,此时,这个需求规格说明书就是需求基线,不可以再随意更新,如果需要更改必须走需求变更流程。

三、需求管理

需求管理是一个对系统需求变更、了解和控制的过程,包括变更控制、版本控制、需求跟踪等活动。

3.1 需求变更

变更控制过程用来跟踪已建议变更的状态,使已建议的变更确保不会丢失或疏忽。一旦确定了需求基线,应该使所有已建议的变更都遵循变更控制过程。

(1)问题分析和变更描述:当提出一份变更提议后,需要对该提议做进一步的问题分析,检查它的有效性,从而产生一个更明确的需求变更提议。

(2)变更分析和成本计算:当接受该变更提议后,需要对需求变更提议进行影响分析和评估。

(3)变更实现:当确定执行该变更后,需要根据该变更的影响范围,按照开发的过程模型执行相应的变更。

变更控制委员会9CCB)是项目所有者权益代表,负责裁定接受哪些变更。CCB由项目所涉及的多方成员共同组成,通常包括用户和实施方的决策人员。CCB是决策机构,不是作业机构,通常CCB的工作是通过评审手段来决定项目是否能变更,但不提出变更方案。

CCB决策过程:制定决策------交流情况------重新协商约定。

3.2 需求跟踪

需求跟踪包括编制每个需求同系统元素之间的联系文档,这些元素包括其他需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等。需求跟踪提供了由需求到产品实现整个过程范围的明确查阅能力。需求跟踪的目的是建立与维护"需求-设计-编程-测试"之间的一致性,确保所有的工作成果符合用户需求。

需求跟踪有两种方式:

  • (1)正向跟踪。检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。
  • (2)逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书中找到出处。

正向跟踪和逆向跟踪合称为双向跟踪。不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。

相关推荐

软件需求工程的软件需求概述、需求获取、需求分析

系统规划与分析的业务流程分析、业务流程图、数据与数据流程分析和系统方案建议

相关推荐
粟悟饭&龟波功14 小时前
【软考系统架构设计师】八、软件可靠性
系统架构·软件工程
Crystal32819 小时前
图片懒加载
前端·javascript·代码规范
SoftwareTeacher20 小时前
现代软件工程教学方法的三种视角分析
软件工程
雾江流1 天前
洛雪音乐PC版2.12.1.beta1 | 支持歌曲无损下载,汇集全网音乐资源,界面简洁操作简便
软件工程
Clover W1 天前
短视频工厂软件使用指南
软件工程
听*雨声1 天前
11_软考_软件工程
软件工程
白狐_7981 天前
软件工程期末复习指南
软件工程
疯疯癫癫才自由1 天前
26华南理工大学软件工程考研复试辅dao
考研·软件工程
workflower2 天前
用户体验的要素
状态模式·需求分析·个人开发·ux·规格说明书·极限编程