发信人: songmk()
整理人: majorsun(2000-06-01 08:05:55), 站内信件
|
All too often, software requirements are badly written and hard to fol
low. Clarifying your specifications will benefit everyone involved.
by Karl Wiegers. Software Development Magazine, May, 1999
It looks like your project is off to a good start. Your team had custo
mers involved in the requirements elicitation stage and you actually w
rote a software requirements specification. The specification was big,
but the customers signed off on it, so it must have been O.K.
Now you’re designing one of the features and you’ve found some probl
ems with the requirements: You can interpret requirement 15 a couple d
ifferent ways. Requirement 9 states precisely the opposite of requirem
ent 21; which should you believe? Requirement 24 is so vague that you
don’t have a clue what it means. You just had an hour-long discussion
with two other developers about requirement 30 because all three of y
ou thought it meant something different. And the only customer who can
clarify these points won’t return your calls. You’re forced to gues
s what many of the requirements mean, and you can count on doing a lot
of rework if you guess wrong.
Many software requirements specifications (SRS) are filled with badly
written requirements. Because the quality of any product depends on th
e quality of its raw materials, poor requirements cannot lead to excel
lent software. Sadly, few software developers have been educated about
how to elicit, analyze, document, and verify requirement quality. The
re aren’t many examples of good requirements to learn from, partly be
cause few projects have good ones to share, and partly because few com
panies are willing to place their product specifications in the public
domain.
This article describes several characteristics of high-quality softwar
e requirement statements and specifications. I will examine some less-
than-perfect requirements from these perspectives and take a stab at r
ewriting them. I’ve also included some general tips on how to write g
ood requirements. Evaluate your project’s requirements against these
quality criteria. It may be too late to revise them, but you might lea
rn how to help your team write better requirements next time.
Don’t expect to create a SRS in which every requirement exhibits ever
y desired characteristic. No matter how much you scrub, analyze, revie
w, and refine requirements, they will never be perfect. However, if yo
u keep these characteristics in mind, you will produce better requirem
ents documents and you will build better products.
Characteristics of Quality Requirement Statements
How can you distinguish good software requirements from problematic on
es? Individual requirement statements should exhibit six characteristi
cs. A formal inspection of the SRS by project stakeholders with differ
ent perspectives is one way to determine whether or not each requireme
nt has these desired attributes. Another powerful quality technique is
writing test cases against the requirements before you cut a single l
ine of code. Test cases crystallize your vision of the product’s beha
vior as specified in the requirements and can reveal omissions and amb
iguities.
Characteristic #1: They must be correct. Each requirement must accurat
ely describe the functionality to be delivered. The reference for corr
ectness is the source of the requirement, such as an actual customer o
r a higher-level system requirements specification. A software require
ment that conflicts with a corresponding system requirement is not cor
rect (of course, the system specification could be incorrect, too).
Only users can determine whether the user requirements are correct, wh
ich is why it’s essential to include actual users, or surrogate users
, in requirements inspections. Requirements inspections that do not in
volve users can lead to developers saying, “That doesn’t make sense.
This is probably what they meant.” This is also known as “guessing.
”
Characteristic #2: They must be feasible. You must be able to implemen
t each requirement within the known capabilities and limitations of th
e system and its environment. To avoid infeasible requirements, have a
developer work with the requirements analysts or marketing personnel
throughout the elicitation process. This developer can provide a reali
ty check on what can and cannot be done technically, and what can be d
one only at excessive cost or with other trade-offs.
Characteristic #3: They must be necessary for the project. Each requir
ement should document something the customers need or something you ne
ed to conform to an external requirement, an external interface, or a
standard. You can think of “necessary” as meaning each requirement o
riginated from a source you know has the authority to specify requirem
ents. Trace each requirement back to its origin, such as a use case, s
ystem requirement, regulation, or some other voice-of-the-customer inp
ut. If you cannot identify the origin, perhaps the requirement is an e
xample of gold-plating and isn’t really necessary.
Characteristic #4: They must be prioritized. Assign an implementation
priority to each requirement, feature, or use case to indicate how ess
ential it is to a particular product release. Customers or their surro
gates have the lion’s share of the responsibility for establishing pr
iorities. If all the unprioritized requirements are equally important,
so is the project manager’s ability to react to new requirements add
ed during development, budget cuts, schedule overruns, or a team membe
r’s departure. You can determine priority by considering the requirem
ent’s value to the customer, the relative implementation cost, and th
e relative technical risk of implementing it.
Many groups use three levels of priority. High priority means you must
incorporate the requirement in the next product release. Medium prior
ity means the requirement is necessary but you can defer it to a later
release if necessary. Low priority means it would be nice to have, bu
t you might have to drop it because of insufficient time or resources.
Characteristic #5: They must be unambiguous. The reader of a requireme
nt statement should draw only one interpretation of it. Also, multiple
readers of a requirement should arrive at the same interpretation. Na
tural language is highly prone to ambiguity. Avoid subjective terms li
ke user-friendly, easy, simple, rapid, efficient, several, state-of-th
e-art, improved, maximize, and minimize. Write each requirement in suc
cinct, simple, straightforward language of the user domain, not in tec
hnical jargon. You can reveal ambiguity through formal requirements sp
ecifications inspections, writing test cases from requirements, and cr
eating user scenarios that illustrate the expected behavior of a speci
fic portion of the product.
Characteristic #6: They must be verifiable. See whether you can devise
tests or use other verification approaches, such as inspection or dem
onstration, to verify that the product properly implements each requir
ement. If you can’t verify a requirement, determining whether or not
it was correctly implemented is a matter of opinion. Requirements that
aren’t consistent, feasible, or unambiguous are also not verifiable.
Any requirement that the product shall “support” something isn’t v
erifiable.
Characteristics of Quality Requirements Specifications
A complete SRS is more than a long list of functional requirements. It
also includes external interface descriptions and nonfunctional requi
rements, such as quality attributes and performance expectations. Look
for the following characteristics of a high-quality SRS.
Characteristic #1: It is complete. The SRS shouldn’t be missing any r
equirements or necessary information. Individual requirements should a
lso be complete. It is hard to spot missing requirements, because they
aren’t there. Organize your SRS’s requirements hierarchically to he
lp reviewers understand the structure of the described functionality.
This makes it easier to tell if something is missing.
If you focus on user tasks rather than on system functions when gather
ing requirements, you’re less likely to overlook requirements or incl
ude requirements that aren’t really necessary. The use case method wo
rks well for this purpose. Graphical analysis models that represent di
fferent views of the requirements will also reveal incompleteness.
If you know you are lacking certain information, use “TBD” (to be de
termined) as a standard flag to highlight these gaps. Resolve all TBDs
before you construct the product.
Characteristic #2: It is consistent. Consistent requirements do not co
nflict with other software requirements or with higher level (system o
r business) requirements. You must resolve disagreements before you ca
n proceed with development. You may not know which (if any) is correct
until you do some research it. Be careful when modifying the requirem
ents; inconsistencies can slip in undetected if you review only the sp
ecific change and not related requirements.
Characteristic #3: It is modifiable. You must be able to revise the SR
S when necessary and maintain a history of changes made to each requir
ement. You must give each requirement a unique label and express it se
parately from other requirements, so you can refer to it clearly. You
can make a SRS more modifiable by grouping related requirements, and b
y creating a table of contents, index, and cross-reference listing.
Characteristic #4: It is traceable. You should be able to link each so
ftware requirement to its source, which could be a higher-level system
requirement, a use case, or a voice-of-the-customer statement. Also,
link each software requirement to the design elements, source code, an
d test cases that implement and verify it. Traceable requirements are
uniquely labeled and written in a structured, fine-grained way. Bullet
lists are not traceable.
The difficulty developers will have understanding poorly written requi
rements is a strong argument for having both developers and customers
review requirements documents before they are approved. Detailed inspe
ction of large requirements documents is not fun, but it’s worth ever
y minute you spend. It’s much cheaper to fix the defects at that stag
e than later in the development process or when the customer calls.
If you observe the guidelines for writing quality requirements (see si
debar) and if you review the requirements formally and informally, ear
ly and often, your requirements will provide a better foundation for p
roduct construction, system testing, and ultimate customer satisfactio
n. And remember that without high-quality requirements, software is li
ke a box of chocolates: you never know what you’re going to get.
Guidelines for Writing Quality Requirements
There is no simple formula for writing excellent requirements. It is l
argely a matter of experience and learning from past requirements prob
lems. Here are a few guidelines to keep in mind as you document softwa
re requirements.
* Keep sentences and paragraphs short. Use the active voice. Use prope
r grammar, spelling, and punctuation. Use terms consistently and defin
e them in a glossary.
*To see if a requirement statement is sufficiently well-defined, read
it from the developer’s perspective. Mentally add the phrase, “call
me when you’re done” to the end of the requirement and see if that m
akes you nervous. In other words, would you need additional clarificat
ion from the SRS author to understand the requirement well enough to d
esign and implement it? If so, elaborate on that requirement before yo
u proceed.
* Requirement authors often struggle to find the right level of granul
arity. Avoid long narrative paragraphs that contain multiple requireme
nts. Write individually testable requirements. If you can think of a s
mall number of related tests to verify a requirement’s implementation
, it’s probably written at the right level of detail. If you envision
many different kinds of tests, perhaps several requirements have been
lumped together and should be separated.
* Watch out for multiple requirements that have been aggregated into a
single statement. Conjunctions like “and” and “or” in a requireme
nt suggest that several requirements have been combined. Never use “a
nd/or” or “etc.” in a requirement statement.
* Write requirements at a consistent level of detail throughout the do
cument. I have seen requirements specifications that varied widely in
their scope. For example, “A valid color code shall be R for red” an
d “A valid color code shall be G for green” might be split into sepa
rate requirements, while “The product shall respond to editing direct
ives entered by voice” describes an entire subsystem, not a single fu
nctional requirement.
* Avoid stating requirements redundantly in the SRS. While including t
he same requirement in multiple places may make the document easier to
read, it also makes it more difficult to maintain. You must update mu
ltiple instances of the requirement at the same time to avoid inconsis
tency.
—Karl Wiegers
Home
--
\\\|///
\\ - - //
( @ @ )
+-------------------oOOo-(_)-oOOo-------------------+
| Jack Song email:[email protected] icq:18613011 |
+---------------------------------------------------+
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.191.124]
|
|