如何编写一个好的需求.docx
《如何编写一个好的需求.docx》由会员分享,可在线阅读,更多相关《如何编写一个好的需求.docx(10页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、如何编写一个好的需求 如何编写高质量需求 Karl E iegerrocess Impact很多软件需求说明书(SS)写得特别糟糕。任何产品的质量须要其原始材料的质量保证,糟糕的软件需求说明书不行能产出优秀的软件。不幸的是,几乎没有开发人员受过与需求的抽象、分析、档、质检有关的教化。而且,没有特别多的需求可以借鉴学习,部分缘由是很少有工程可以找到一个的借鉴,其他缘由是公司不情愿将其产品说明书放在公共区域。这篇章描述了高质量需求叙述和说明的几个特性(特点)。我们将用这些观点检查一些有缺陷的需求,带着痛楚重新编写。而且我会谈一些如何编写的需求的提示。你或许想通过这些质量标准评估你的工程需求。对于修
2、订,或许迟了,但你会学到一些有用的东西,并帮助你的小组在下次编写出更的需求。不要期望能够编写出一份能体现需求应具备的全部特性的SS。无论你怎么细化、分析、评论和优化需求,都不行能达到完备。但是,假如你牢记这些特性,你就会编写出更的需求,生产出更的产品。一、高质量需求说明书的特性我们如何从一些有问题的需求中辨别出的软件需求?推断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品德为(特性),能够显现缺陷、冗余和模糊之处。? 正确:每个需求必需精确描述要交付的功能。正确性依据
3、于需求的来源,如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的(当然,系统需求说明书本身可能不正确)。只有用户的代表能够确定用户需求的正确性,这就是为什么在检查需求时,要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的:“这是没意义的”,“这可能是他们的意思”等众所周知的揣测。? 可行性:在已知的实力、有限的系统及其环境中每个需求必需是可实现的。为了避开需求的不行行性,在需求分析阶段应当有一个开发人员参加,在抽象阶段应当有市场人员参加。这个开发人员应能检查在技术上什么能做什么不能做,哪些须要须要额外的付出或者和其他的权衡。? 必要
4、性:每个需求应载明什么是客户的确须要的,什么要顺应于外部的需求,接口或标准。每个需求源于你认可、具有权说明需求的原始资料,这是考虑必需的另外情形(译注,此句翻译不顺,请参照原:nother way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements)。跟踪每个需求回溯到出处,如用例,系统需求,规章,或来自其他用户的看法。假如你不能标识出处,可能需求只是个镀金的例子,没有真正的必
5、需。? 优先权:为了表明在一个具体的产品版本中应包含哪些要点,须要为每个需求,特征,或用例安排实现的优先权。客户或其代理都应有剧烈的责任建立优先权。假如全部的需求都被视为同等重要,那么由于在开发中,预算削减,安排超时或组员的离开导致新的需求时, 项目经理将不能起到作用。优先权的作用是供应给客户的价值,实现的相关费用,实现相关联的有关技术风险。我是用3种级别的优先权:高优先权表明需求必需体现在下一个产品版本中,中优先权表明需求是必需的,但是假如须要可以推迟到晚一些的产品版本中,低优先权表明有它很,但我们必需相识到假如没有足够的时间或资源,它可以被放弃掉。? 明确:需求叙述的读者应只能从其得到唯一
6、的说明说明,同样,一个需求的多个读者也应达成共识。自然语言极易导致模糊。要避开运用一些对于SS作者很清晰但对于读者不清晰的主观词汇,如:用户友性,简单,简洁,快速,有效,几个,艺术级,改善的,最大,最小等等。每写一个须要都应简洁,简洁,直观的采纳用户熟知的语言,不要采纳计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查,依据需求写测试,建立用户的假想来说明产品某个特定部分预期的特性。? 可证明:看你是否能够做出测试安排或其他验证方式,如检查和实证,来确定在产品中每个需求是否正确的实现。假如需求是不行验证的,确定需求是不是正确的实现就成了推断的事。需求之间不一样,不行行,不明确也能导致不
7、行证明。任何需求假如说产品将要支持什么也是不行证明的。? 完整:不应当遗漏要求和必需的信息。完整性也是一个需求应具备的。发觉缺少的信息很难,因为根本不存在。在SS中将需求以分层书目方式组织,将帮助评审人员理解功能性描述的结构,使他们很简单指出遗失的东西。在需求抽象时,相对于系统功能,你过多的留意用户的业务,将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上,应用用例方法会发挥很的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。假如你知道已缺少一些信息,运用B(to be determined)标准标记可以突出这些缺陷,当你在构建产品的相关部分时,就可以从一个给
8、定的需求集中解决全部的缺陷。? 一样性:一样性需求就是不要于其他的软件需求或高级别的系统(商业)需求发生冲突。需求中的不一样必需在开发起先前得到解决。只有经过调研才能确定哪些是正确的。修改需求时肯定要谨慎,假如只审定修改的部分,没有审定于修改相关的部分,就可能导致不一样性。? 可修改性:当每个需求的要求修改了或维护其历史更改时,你必需能够审定SS。也就是说每个需求必需相对于其他需求有其单独的标示和分开的说明,便于清楚的查阅。通过良的组织可以使需求易于修改,如:将相关的需求分组,建立书目表,索引,以及前后参考(照)。? 可追踪:你应能将一个软件与其原始材料相对应,如高级系统需求,用例,用户的提议
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何 编写 一个 需求
限制150内