如何编写一个好的需求

1、如何编写一个好的需求【各位读友,本文仅供参考,望各位读 者知悉,如假设喜欢或者需要本文,可点 击下载下载本文,谢谢！】祝大家工作顺利】如何编写高质量需求Karl E WiegerProcess Impact许多软件需求说明书写得非常糟 糕.任何产品的质量需要其原始材料的 质量保证,糟糕的软件需求说明书不可 能产出优秀的软件.不幸的是,几乎没 有开发人员受过与需求的抽象、分析、 文档、质检有关的教育.而且,没有非 常多的好需求可以借鉴学习,局部原因 是很少有工程可以找到一个好的借鉴, 其他原因是公司不愿意将其产品说明书 放在公共区域.这篇文章描述了高质量需求表达和 说明的几个特性.我们将用这些观

2、点检 查一些有缺陷的需求,带着痛楚重新编 写.而且我会谈一些如何编写好的需求 的提示.你也许想通过这些质量标准评 估你的工程需求.对于修订,也许迟了, 但你会学到一些有用的东西,并帮助你 的小组在下次编写出更好的需求.不要期望能够编写出一份能表达需 求应具备的所有特性的 SRS.无论你怎 么细化、分析、评论和优化需求,都不 可能到达完美.但是,如果你牢记这些 特性,你就会编写出更好的需求,生产 出更好的产品.一、高质量需求说明书的特性我们如何从一些有问题的需求中分 辨出好的软件需求判断每个需求是否 具备应有的特性的一种方式是由持有不 同观点的工程资金治理人所作的正规检 查.另一种有力的方法是在

3、编写代码前 依据需求编写测试例子.测试例子能够 明确显现在需求中描述的产品行为,能 够显现缺陷、冗余和模糊之处.?正确：每个需求必须精确描述要交付的功 能.正确性依据于需求的来源,如真实 的客户或高级别的系统需求说明书.一 个软件需求与其对应的系统需求说明书 相抵触是不正确的.只有用户的代表能够决定用户需求 的正确性,这就是为什么在检查需求时, 要包括他们或他们的代理的关键所在. 不包括用户的需求检查就会导致开发人 员的：这是没意义的,这可能是他们的意思等众所周知 的猜测.?可行性：在的水平、有限的系统及其环 境中每个需求必须是可实现的.为了避 免需求的不可行性,在需求分析阶段应 该有一个开发

4、人员参与,在抽象阶段应 该有市场人员参与.这个开发人员应能 检查在技术上什么能做什么不能做,哪 些需要需要额外的付出或者和其他的权 衡.?必要性： 最新财经经济资料 感谢阅读每个需求应载明什么是客户确实需 要的,什么要顺应于外部的需求,接口 或标准.每个需求源于你认可、具有权 说明需求的原始资料,这是考虑必需的 另外情形.跟踪每个需求回溯到出处, 如用例,系统需求,规章,或来自其他 用户的意见.如果你不能标识出处,可 能需求只是个镀金的例子,没有真正的 必须.?优先权：为了说明在一个详细的产品版本中 应包含哪些要点,需要为每个需求,特 征,或用例分配实现的优先权.客户或 其代理都应有强烈的责任

5、建立优先权. 如果所有的需求都被视为同等重要,那 么由于在开发中,预算削减,方案超时 或组员的离开导致新的需求时,工程经理将不能起到作用.优先权的作用是提 供给客户的价值,实现的相关费用,实 现相关联的有关技术风险.我是用3种级别的优先权：高优先 权说明需求必须表达在下一个产品版本 最新财经经济资料 感谢阅读 4 中,中优先权说明需求是必须的,但是 如果需要可以推迟到晚一些的产品版本 中,低优先权说明有它很好,但我们必 须熟悉到如果没有充足的时间或资源, 它可以被放弃掉.?明确：需求表达的读者应只能从其得到唯 一的解释说明,同样,一个需求的多个 读者也应达成共识.自然语言极易导致 模糊.要预防

6、使用一些对于 SRS作者很 清楚但对于读者不清楚的主观词汇,如: 用户友好性,容易,简单,快速,有效, 几个,艺术级,改善的,最大,最小等 等.每写一个需要都应简洁,简单,直 观的采用用户熟知的语言,不要采用计 算机术语.检查需求模糊的有效方式包 括需求说明书的正规检查,根据需求写 测试,建立用户的假想来说明产品某个 特定局部预期的特性.?可证实：看你是否能够做出测试方案或其他 验证方式,如检查和实证,来决定在产 最新财经经济资料 感谢阅读 品中每个需求是否正确的实现.如果需 求是不可验证的,决定需求是不是正确 的实现就成了判断的事.需求之间不一 致,不可行,不明确也能导致不可证实. 任何需求

7、如果说产品将要支持什么也是 不可证实的.?完整：不应该遗漏要求和必需的信息.完 整性也是一个需求应具备的.发现缺少 的信息很难,由于根本不存在.在 SRS 中将需求以分层目录方式组织,将帮助 评审人员理解功能性描述的结构,使他 们很容易指出遗失的东西.在需求抽象时,相对于系统功能, 你过多的注意用户的业务,将导致在需 求的全局观和引进不是真正必需的需求 上显得缺乏.在需求抽象上,应用用例 方法会发挥很好的作用.能够从不同角 度观察需求的图形分析模型也可以检查 出不完整性.如果你知道已缺少一些信息,使用 TBD标准标志可以突出这些缺陷,当你 最新财经经济资料 感谢阅读6在构建产品的相关局部时,就

8、可以从一 个给定的需求集中解决所有的缺陷.? 一致性：一致性需求就是不要于其他的软件 需求或高级别的系统需求发生冲突.需 求中的不一致必须在开发开始前得到解 决.只有经过调研才能确定哪些是正确 的.修改需求时一定要谨慎,如果只审 定修改的局部,没有审定于修改相关的 局部,就可能导致不一致性.?可修改性：当每个需求的要求修改了或维护其 历史更改时,你必须能够审定 SRS.也 就是说每个需求必须相对于其他需求有 其单独的标示和分开的说明,便于清楚 的查阅.通过良好的组织可以使需求易 于修改,如：将相关的需求分组,建立 目录表,索引,以及前后参考.?可追踪：你应能将一个软件与其原始材料相 对应,如高

9、级系统需求,用例,用户的 提议等.也能够将软件需求与设计元素, 最新财经经济资料 感谢阅读7 源代码,用于构造实现和验证需求的测 试相对应.可追踪的需求应该具有独立 标示,细密和结构化的编写,不应过大, 不应是表达性的文字和公告式的列表.二、需求质量的评审这些有关需求质量的特性的描述在 理论上都是非常好的,但一个好的需求 到底是个什么样子的呢为了表达得更 切合实际,我们做个小练习.下面有几 个从实际的工程选出的需求,依据上面 的质量标准,评估每个需求,看看有什 么问题,然后用更好的方式重写.我将 对每个例子都提出自己的分析和改进的 建议.也欢迎你提出不同的见解.我所 占优的只是我知道每个需求的

10、出处.因 为你我都不是真正的客户,我们只能猜 测每个需求的意图.例1.产品应在不少于每60秒的正 常周期内提供状态信息这个需求是不完整的：状态信息是 什么,如何显示给用户.这个需求有几 处模糊.我们在谈论产品的哪局部状 最新财经经济资料 感谢阅读8态信息间隔真的假定为不少于 60秒,甚者每10年显示一条新的状态信息也可 以也许它的意图是消息间隔不应超过60秒,那么1毫秒是不是太短 每这 个词导致了不确定性.问题的后果,就 是需求的不可证实.弥补缺陷,重写需求的一种方法：X状态信息1.1 后台任务治理器因该以误差上下不超过10秒的60秒间隔,在用户界 面的指定位置显示状态信息1.2 如果后台进程

11、处理正常,那么应 该显示任务已完成的百分数/比1.3 任务完成时,应显示相关的信息1.4 后台任务出错应该显示错误信为了分别测试和追踪,我将其分成 了多个需求.如果将几个需求串接在一 节中,在构造和测试时就很容易漏掉一 个.例2.产品应瞬间在显示和隐藏不 可打印字符间切换 最新财经经济资料 感谢阅读计算机在瞬间不能做任何事,所以 这个需求不切实可行.它的不完整性表 现在没有声明触发状态切换的条件.软 件要在某些条件下更改自己或者用户 为了模仿更改要做一些动作而且,在 文档中改变显示的范围是多大：选中的 文本,整个的文档,或其他的这也是 个模糊的问题.不可打印字符合隐藏字 符一样吗或者是一些属性

12、标志或一些 限制字符问题的后果,就是需求的不 可证实.象这样编写需求也许更好一些：用 户能够在一个由特定触发条件激活处于 编辑的文档中在显示和隐藏所有 HTML 标记间切换.现在就很清楚,不可打印 字符是HTML标记.由于没有定义触发 条件,需求对设计没有约束力.只有设 计人员选定了触发条件后,你才能编写 测试验证触发的正确操作.例3 "HTM分析器可以产生HTML 标记错误报告,帮助HTML入门者快速 解决错误.单词快速使其模糊,没有加进错 误报告的定义也是其部完整.我不知道, 你怎么验证这个需求.找一个自称为 HTML的入门者,看看能不能根据错误 报告快速解决错误试试这个：“ H

13、TML分析器可以产生 一个错误报告,错误报告包含有在被分 析文件中出错的HTML文本和行号以及 错误的描述.如果没有错误,就不会产 生错误报告.现在我们知道了,什么会 被加到出错报告中,但是出错报告是个 什么样子,那么留由设计人员决定.我们 还指定了一个例外：如果没有发现错误, 不产生错误报告.例4如果可能,主管号应通过联 机校验,而不是通过主全体主管号列 表校验.真到绝望,什么是 如果可能：如 果技术上可行如果主全体主管号列 表可以联机获得要预防象 应该的这 类不确切的词.客户是需要这个功能性 还是不需要.我曾看过一些需求说明书, 最新财经经济资料 感谢阅读11采用诸如：应,将,应该/将要等

14、一些词 描述优先级的细微差异.但我更喜欢用应清楚的说明需求的意图,指明优先 级.这是修改后的：系统应校验输入的 主管号而不通过联机的主全体主官号 码列表.如果在列表中没有发现主管号 码,将会显示一条错误信息,也不接受 指令.在理解各个已完成的糟糕需求上, 开发人员将会遇到的难题是：开发人员 与客户将会在审核需求,未达成共识前 发生剧烈的争论.详细检查大的需求文 档不是一件轻松的事情.我清楚有人做 过,而且他们花在检查上的每一分钟都 是值得的.相对于开发阶段和用户的抱 怨 ,在这个阶段修补缺陷是廉价的,编写质量需求的方针编写优秀的需求是没有公式化的方 法的.这需要大量的经验,要从你在过 去的文档

15、中发现的问题学习.请在组织 软件需求文档时,严格遵从这些方针.?句子和段落要短.采用主动语气. 最新财经经济资料 感谢阅读12使用正确的语法,拼写,标点.使用术 语,要保持一致性,并在术语表或数据字典 中定义它们?要看需求是否被有效的定义,可 以以开发人员的观点看看.在内心将 当 你们做完了找我这句加到文档尾部,看看能 不能是你紧张起来.换句话说,你是否 需要SRS的编写者的额外解释帮助开发 人员很好的理解需求,以便于设计和实 现如果是的话,在继续工作前,需求还 需要细化.?需求编写者还要努力正确地把握 细化程度.要预防包含多个需求的长的 表达段落.有帮助的提示是编写独立的可测试 的需求.如果你认为一小局部测试可以 验证一个需求的正确,那么它已经正确 的细化了.如果你预想到多种不同类的 测试,几个需求可能已挤到了一起,需 最新财经经济资料感谢阅读13要拆分开.?密切关注多个需求合成了单个需 求.一个需求中的连接词 和" /或“建议 几个需求合并.不要在一个需求中使用和域1?通篇文档细节上要保持一致.我 曾看见过多个需求说明书前后不一致. 如：对于红色合法的颜色代码应是 R'及对 于绿色合法的颜色代码应是 G就有可以 以分散的需求别离开,而产品应能对来 自语音编辑指示做出反响应作为一个 子系统,不应作为单个的功能性需求.?预防在SRS中过多的申