软件需求学习小结

转自：http://blog.csdn.net/byxdaz/archive/2009/10/05/4633853.aspx

 

需求层次:

层次
 内容描述
 呈现方式
 
业务需求
 组织机构或客户对系统、产品高层次的目标要求。
 项目视图与范围文档中予以说明
 
用户需求
 用户使用产品必须要完成的任务
 Use Case
 
功能需求
 必须实现的软件功能
 需求规格说明文档中功能需求说明
 
非功能需求
 系统展现给用户的行为和执行的操作等，包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
 需求规格说明文档中非功能需求说明
 

 

需求开发过程

0、  开发过程

 

1、  需求收集：

定义项目的视图和范围。

学习与了解本行业的知识，这样与用户比较容易沟通。

访问有潜力的用户,对用户进行分类并找各自合适的代表，找出新软件产品的用户需求。注意与用户沟通技巧。

对目前市场上竞争产品进行研究，进行功能提取与解决方案分析，写成文档。

收集了用户在使用现有系统过程中所遇到问题的信息，还接受了用户关于系统改进的想法。

市场调查和用户问卷调查。

观察正在工作的用户，预见用户在使用当前系统时所遇到的问题，并能分析新的系统可有效支持工作流程与功能。

做用户的学徒，揭示有意识和无意识的需求，如果用户因为“太忙”而无法交谈，这种方法很有用。

业务事件研讨会，产生业务规则与目标。

头脑风暴，召集一组聪明的、有意愿的、不同学科背景、不同经验的人，让他们对新产品产生尽可能多的想法。

用录像记录用户和需求分析师参加的研讨会和头脑风暴的过程，录像的作用有：记录、确认、备忘。

2、  需求分析：

绘制关联图

创建开发原型

确定需求优先级

为需求建立模型，需求原型是对需求模拟的模型，设计目的是帮助了解更多用户需求。需求原型有三种：

1）低保真原型是一种快速模拟产品的方式，使用熟悉的技术，诸如笔、纸、白板等。低保真原型有助于将注意力集中在产品做什么上，而不是产品看起来如何，他们有助于发现遗漏的功能和测试产品的范围。

2）高保真原型使用做原型的工具来给出非常真实的外观，他们对于发现易用性需求是特别有效的。

3）场景模型是一项是抽象主题变得生动的技巧，它通过对一个特定实例讲故事的方式来做到这一点。这些模型能有效地帮助人们将注意力集中在细节上，并发现其他情况可能会遗漏的异常。

编写数据字典

通过用例提取与分析需求，如果用例编写恰当，可以准确地对系统必须做什么进行详细的描述。用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。用例只是收集了所有需求中的一部分。

3、  编写规格说明书

  采用软件需求规格说明模版，可以采用CMMI中的需求规格说明模版。

  正确的、完整的表达所描述的需求。

 

4、  需求验证

对需求进行审查

用测试用例来验证需求

验收判断标准表

方面
 验收判断标准
 
功能性需求
 确保功能被正确地执行
 
非功能性需求
 量化度量，引入该产品的3个月之内，60%的用户将用它来完整规定的工作。在这些用户之中，将有75%对产品表示赞许。
 
客户
 询问客户一个关键问题来确定，这个问题是：“什么会被认为是满足需求失败？”。
 
测试
 产品将不会让测试组的80%的人感觉到被冒犯。
 
观感需求
 界面的兼容性作为验收标准
 
易用性需求
 经过一天培训之后，10个用户中有9个能够成功地完成选择的任务。
 
性能需求
 在95%的情况下，响应时间将不超过1.5秒，在其他情况下不超过4秒。
 
可操作性需求
 对要求的环境下使用是否容易或使用是否成功的量化标准。
 
可维护性需求
 新的用户将能被加入系统，并且对现存用户的打断不超过5分钟。
 
安全性需求
 产品的数据必须与数据的权威来源保持一致。
 
文化和政策需求
 基于谁将认证产品是可接受的。
 
法律需求
 法律部门/公司的律师将认证产品符合相关法律。
 
用例需求
 所有相关需求的意图的总和。
 
限制条件
 度量
 

 

 

需求管理方法以及常用需求管理工具管理需求：

需求管理的策略：包括变更控制，需求跟踪（跟踪矩阵、需求状态跟踪如已建议，已批准，已实现，已验证，已删除）和变更的影响分析。

需求管理的主要活动：

 

需求管理工具

RequisitePro

CaliberRM

DOORS

 

附录：

1、  在工作中找些项目或者找些开源项目来分析与开发系统需求，积累经验，从成功中获益并避免导致失败的失误。

2、如何编写一个好的用例

想学会如何阅读用例是很容易的，但是学会编写一个好的用例却不容易。编写者必须掌握三个概念：

范围：真正被谈论的系统是什么？

主执行者：谁有要实现的目标？

层次：目标的层次是高还是低？

用例格式有很多中，比如完整正式的用例格式、非正式的用例格式、单列表格格式、RUP格式等。

完整正式的用例格式：

 

RUP格式：

 

 

 

举例：

买东西（非正式版本）

请求者发起一个请求，并把这个请求送给她的批准者。批准者首先检查预算中是否还有资金，然后核对货物的价格，接着完成提交请求，并将请求发送给买者。买者查阅仓库目录，找出最好的货物供应商。认证者验证批准者的签名。买者完成订购请求的各项工作，向供货商发出PO（订单）。供货商把货物发送给接收者，并得到发货收据（这一点超出了本系统的设计范围）。接收者记录交货情况，并把货物发送给请求者。请求者设置请求已被满足标志。

    在获得货物前的任意时刻，请求者都可以修改或取消请求。取消意味着把此请求从任何执行处理中取消（从系统中删除它吗？）。降低货物价格不影响对其进行的处理过程；提高价格则需要将请求重新发回给批准者。
 
 

 

 

 

 

买东西（完整正式版本）

主执行者：请求者

语境中的目标：请求者通过系统买东西，并得到说买的东西。不包括付款方面的内容。

范围：业务——整个购买机制，包括电子的和非电子的，正如人们在公司中说见到的一样。

层次：概要

项目相关人员和利益：

请求者：希望得到她订购的东西，并且操作要简单。

公司：希望控制花费，但允许必要的购买。

供货商：希望得到任何已发货物的货款。

前置条件：无

最小保证：每一个发出的订单都已经获得有效认证者的许可。订单具有可跟踪性，以便公司只对收到的有效货物开账单。

成功保证：请求者得到货物，修改预算，记入借方。

触发事件：请求者决定买东西。

主成功场景：

1．  请求者：发起一个请求。

2．  批准者：检查预算中的资金，检查货物的价格，完成提交请求。

3．  买者：检查仓库的存货，找出最好的供货商。

4．  认证者：验证批准者的签名。

5．  买者：完成订购请求，向供货商发出PO（订单）。

6．  供货商：把货物发送给接收者，得到发货收据（这一点超出了本系统的设计范围）。

7．  接收者：记录发货情况；向请求者发送货物。

8．  请求者：设置请求已被满足标志。

扩展：

1a）请求者不知道供货商和货物价格：不填写这些内容，然后继续。

1b）在收到货物之前的任意时刻，请求者都可以修改或取消请求：

如果取消，则把这个请求从执行处理中取消。（从系统中删除吗？）

如果降低价格，则不影响其处理过程。

如果提高价格，则把请求送回批准者。

2a）批准者不知道供货商或货物价格：不填写这些内容，留待买者填写或返回。

2b）批准者不是请求者的经理：只是批准者签名仍然可行。

2c）批准者拒绝申请：送回给请求者，要其修改或删除。

3a）买者在仓库中找到货物：将存货先发出，并从申请者要求的总购买者中减去已经发出的这部分货物量，然后继续。

3b）买者填写在前面活动中没有填写的供货商和价格信息：请求重新发回给批准者。

4a）认证者拒绝批准者：发回请求者，并将此请求从执行处理中取消。

5a）请求涉及到多个供货商：买者创建多个PO

5b）买者将多个请求合并：相同的过程，但是用被合并的请求标记PO

6a）供货商没有按时发货：系统发出没有发货警告。

7a）部分发货：接收者在PO上做部分发货标记，然后继续。

7b）多个请求PO的部分发货：接收者给每个请求分配货物数量，然后继续。

8a）货物不对或质量不合格：请求者拒绝接收所发送的货物。

8b）请求者已经离开公司：买者同请求者的经理进行核实，或者重新指派申请者，或者返还货物并取消请求。

技术和数据变动列表：无

优先级：多种

发行版本：几个

响应时间：多样

使用频率：3/天

主执行者的渠道：网络浏览器、邮件系统或类似系统

次要执行者：供货商

次要执行者的渠道：传真、电话或汽车

未解决的问题：

    什么时候从系统中删除被取消的请求？

    要取消一个请求需要那些权限？

    谁能修改一个请求的内容？

    请求中需要保留哪些修改历史记录？

    当请求者拒绝已经发送的货物时，会发生什么情况？

    申请和订货在运作上有什么不同？

    订购如何参考和使用内部存货？
 

3、需求工程推荐方法

知

识

技

能
 • 培训需求分析人员

• 培训用户代表和管理人员

• 培训应用领域的开发人员

• 汇编术语
 
需

求

管

理
 • 确定变更控制过程

• 建立变更控制委员会

• 进行变更影响分析

• 跟踪影响工作产品的每项

• 编写需求文档的基准版本

• 维护变更历史记录

• 跟踪需求状态

• 衡量需求稳定性

• 使用需求管理工具
 
项

目

管

理
 • 选择合适的生存周期

• 确定需求的基本计划

• 协商约定

• 管理需求风险

• 跟踪需求工作
 
需

求

开

发
 获 取
 • 编写项目视图与范围

• 确定需求开发过程

• 用户群分类

• 选择产品代表

• 建立核心队伍

• 确定使用实例

• 召开应用程序开发

• 联系（J A D）会议

• 分析用户工作流程

• 确定质量属性

• 检查问题报告

• 需求重用
 
分 析
 • 绘制关联图

• 创建开发原型

• 分析可行性

• 确定需求优先级

• 为需求建立模型

• 编写数据字典

• 应用质量功能调配

（Q F D）
 
编写规格说明书
 • 采用软件需求规格说明模版

• 指明需求来源

• 为每项需求注上标号

• 记录业务规范

• 创建需求跟踪能力矩阵
 
验 证
 • 审查需求文档

• 依据需求编写测试用例

• 编写用户手册

• 确定合格的标准
 

需求工程注重应用“最佳方法”。这些方法适用于一些项目，但是不适用于另一些项目，所以需要裁剪一些方法适用于所有项目。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/byxdaz/archive/2009/10/05/4633853.aspx