分类： 项目管理
2012-04-29 16:11:58
需求层次:
层次 | 内容描述 | 呈现方式 |
业务需求 | 组织机构或客户对系统、产品高层次的目标要求。 | 项目视图与范围文档中予以说明 |
用户需求 | 用户使用产品必须要完成的任务 | 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） | |
编写规格说明书 | • 采用软件需求规格说明模版 • 指明需求来源 • 为每项需求注上标号 • 记录业务规范 • 创建需求跟踪能力矩阵 | |
验 证 | • 审查需求文档 • 依据需求编写测试用例 • 编写用户手册 • 确定合格的标准 | |
需求工程注重应用“最佳方法”。这些方法适用于一些项目，但是不适用于另一些项目，所以需要裁剪一些方法适用于所
