如何编写软件需求规格书（4）
How to write a software requirements specification
如何编写软件需求规格书
by Robert Japenga
__________________________________________________________________________________________
What are the characteristics of a great SRS?
优秀的SRS有何特点？
Again from the IEEE standard:
An SRS should be
a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
再次来自于IEEE标准：
SRS应具有以下特性：
a) 正确
b) 无歧义
c) 完整
d) 一致
e) 按重要性和/或稳定性进行排列
f) 可验证
g) 可更改
h) 可追踪
Correct - This is like motherhood and apple pie. Of course you want the specification to be correct. No one writes a specification that they know is incorrect. We like to say - "Correct and Ever Correcting." The discipline is keeping the specification up to date when you find things that are not correct.
正确——这就像是十全十美。你当让期望规格书没有错误。没有人明知错误，却将该错误写到规格书中。我们更倾向于说——“更正并持续更正”。这条规则就是说，一旦你发现规格书中存在的那么，那么及时进行更正。
Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. Again, easier said than done. Spending time on this area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix them.
无歧义——如果，仅当每个需求仅有一种解释，那么SRS是无歧义的。再者，说起来容易做起来难。SRS发布之前，这方面下功夫是很耗时间的。但是一旦你发现歧义——进行修正。
Complete - A simple judge of this is that is should be all that is needed by the software designers to create the software.
完整——这一条要说明的是，软件设计人员设计该软件时必须设计的内容。
Consistent - The SRS should be consistent within itself and consistent to its reference documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.
一致——SRS文档本身应该具有一致性，同时跟其他参考文献也应具有一致性。如果你在一个地方调用一个输入“启动并停止”，那么就不要在另一个地方调用“启动/停止”
Ranked for Importance - Very often a new system has requirements that are really marketing wish lists. Some may not be achievable. It is useful provide this information in the SRS.
按重要性和/或稳定性进行排列——通常，新系统中的需求即真正的市场心愿单，有一些可能无法实现，因此需要在SRS提供这样的信息。
Verifiable - Don't put in requirements like - "It should provide the user a fast response." Another of my favorites is - "The system should never crash." Instead, provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds."
可验证——不要在需求中有诸如“应向用户提供快速响应”此类的需求，或者还有“该系统将永远不会崩溃”。实际上，需要提供可量化的指标，例如“每次击键的反应时间在100ms以内”。
Modifiable - Having the same requirement in more than one place may not be wrong - but tends to make the document not maintainable.
可更改——在多处存在相同的需求并不是什么错误，但是文档维护的工作量会增加。
Traceable - Often, this is not important in a non-politicized environment. However, in most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document. Why do we need this requirement?
可追踪——通常，在非政治性的环境中并不需要可追踪性。不过，在大多数公司中，将SRS中的需求与上级文档中的内容关联起来是非常有用的，这样就知道为什么会有这些需求。[译者注：需求追踪工具可以采用Excel格式的跟踪矩阵，还有就是商业的Reqtify工具]
如何编写软件需求规格书（1）
如何编写软件需求规格书（2）
如何编写软件需求规格书（3）
如何编写软件需求规格书（4）
如何编写软件需求规格书（5）
如何编写软件需求规格书（6）
如何编写软件需求规格书（7）