好的产品需求规格说明书有如下属性:正确、清楚、无二义性、一致、必要完备、可实现、可验证。
正确
需求规格说明书应当正确地反映用户的真实意图,“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的,那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“您要什么”和“不要什么”。为确保需求是正确的,开发方和用户必须对《需求规格说明书》进行确认。
清楚
清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚:
(1)文档的结构、段落是否乱七八糟?上下文是否不连贯?
(2)文档的语句是否糊其词、罗里罗嗦?
(3)是否看了半天还不明白需求究竟是什么?
无二义性
“无二义性”是指每个需求只有惟一的 义。如果一个人说的话,不同的人可能有不同的理解,那么这句话就有二义性。如果需求存在二义性,将会导致人们误解需求而开发出偏离需求的产品。为了使需求无二义性,人们在写《产品需求规格说明书》时措词应当准确,切勿模棱两可。
一致
“一致”是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。
必要
《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。我们可以把“必要”比喻为“雪中送炭”。“必要”往前一步,要么是“画蛇添足”要么是“锦上添花”。“画蛇添足”显然是坏事,会导致开发人员多干一些费力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的 那些需求。“锦上添花”是好事,可能会让用户获得比期望更多的喜悦,但是眼前用户不会为此多付钱。开发者应当集中精力先完成 必要的需求,如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒,应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。
完备
“完备”(Complete)是指《产品需求规格说明书》中没有遗漏一些必要的需求。不完备的《产品需求规格说明书》将导致产生功能不完整的软件,用户在使用该软件时可能无法完成预期的任务。人们往往倾向于关注系统的特色功能,而忽视了其他一些不起眼的但却是必需的功能。
可实现
《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的。“可实现”意味着在技术上是可行的,并且满足时间、费用、质量等约束。营销人员和用户谈生意时,为了能拿到“单子”,他们往往 对用户提出的需求“来者不拒”。吹牛皮虽然不犯法,但是《产品需求规格说明书》可是白纸黑字啊。经过双方确认的《产品需求规格说明书》相当于商业合同,如果开发方不能够实现《产品需求规格说明书》中的内容,那就是违约,可能会被罚款的。对于合同项目,如果开发方不能确信某些需求是否可实现, 则应事先与用户协商,达成一致的处理意见,避免将来发生商业 纠纷。
可验证
《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的。如果需求是不可验证的,那么用户就无法验收软件,可能会发生商业纠纷。
确定优先级
为什么要确定需求的“优先级”?理论上讲,软件的所有需求都应当被实现。但是在现实之中项目存在进度、费用、人力资源等诸多因索的限制。在项目刚开始的时候,开发方和客户比较乐观,什么都要做,可是做着做着,人们常常会面临进度延误、费用超支、人员不足等问题,这时就乱套了。久病成医,人们想出了“取舍”的办法:先做优先级高的需 求,后做(甚至放弃)优先级低的需求,这样可以将风险降到最低。 需求的优先级其实就是需求“轻重缓急”的分级表述,例如划分为“高、中、低”三级。一般地,由用户和开发方共同确定需求的优先级。 阐述“做什么”而不是“怎么做”《产品需求规格说明书》的重点是阐述“做什么”,而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。 国内的很多软件公司里,开发人员常常身兼致职,可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时,自然会想到“怎么做”,这并没有什么过错。如果在调查、定义需求时想好了“怎么做”,当然应该写下来,否则岂不浪费!关键是不要将“怎么做”写到需求规格说明 书里面,记录在其他文档里就行了。
节选自:《软件工程与项目管理解析》
微信号:IdeaofSE
联系客服