软件需求学习小结

最新推荐文章于 2021-12-28 21:29:18 发布

ajian005

最新推荐文章于 2021-12-28 21:29:18 发布

阅读量1.1k

点赞数

分类专栏： 1.1.1.7 程序语言-框架 1.2.1.1 职业规划 1.1.1.8 软件工程

1.1.1.8 软件工程同时被 3 个专栏收录

133 篇文章 0 订阅

订阅专栏

1.2.1.1 职业规划

96 篇文章 2 订阅

订阅专栏

1.1.1.7 程序语言-框架

89 篇文章 0 订阅

订阅专栏

需求层次:

层次	内容描述	呈现方式
业务需求	组织机构或客户对系统、产品高层次的目标要求。	项目视图与范围文档中予以说明
用户需求	用户使用产品必须要完成的任务	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（订单）。供货商把货物发送给接收者，并得到发货收据（这一点超出了本系统的设计范围）。接收者记录交货情况，并把货物发送给请求者。请求者设置请求已被满足标志。

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

买东西（完整正式版本）

主执行者：请求者

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

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

层次：概要

项目相关人员和利益：

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

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

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

前置条件：无

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