Friday, November 6, 2009
Chapter 13: How Much Detail do you Need?
Chapter 13: How Much Detail do you Need?
Requirements
analysts often wonder how detailed their requirements need to be.
There's no single correct answer to this question, even assuming we
could agree on just exactly how to measure requirements "detail." I can
give you some ways to think about how much detail is appropriate in a
given situation, though.
Who Makes the Call?
The central question to consider when deciding how detailed to make the requirements is: Who do you want to have making decisions about requirements details and when?
If you're willing to defer many of the ultimate decisions about product
capabilities and characteristics to the developers, you don't need to
include as much information in the requirements documentation. However,
if you want to describe exactly what you expect to be delivered, more
complete specifications are necessary. You need to balance cost and
risk. It costs more to develop requirements in greater detail than to
leave them more general. Choosing the appropriate amount of detail to
include depends upon the risk associated with leaving decisions about
specifics to developers.
Let me give you an illustration about requirements
detail. My house has a security alarm system. To disarm the system, I
enter my passcode on a numeric keypad. At one level, we could state a
requirement for this function quite simply: "When the alarm system is
armed and a sensor is triggered, the user shall be able to enter a
numeric passcode to disarm the system." This statement conveys the
general intent, but it isn't enough information for the developer to
know just what to design and build. Here are some questions that arise
when considering the implications of this functional requirement:
What are the minimum and maximum numbers of digits allowed in a passcode?
How should the system conclude that the user has
finished entering the passcode so that it can evaluate the passcode? Or
should the user somehow indicate that the passcode has been fully
entered so as to trigger passcode evaluation?How can the homeowner set and change his passcode? Is there a default?
How long does the system wait for the user to enter the correct passcode before it sounds the alarm?
What does the system do if the user enters an incorrect passcode before the timer runs out?
How many entry attempts does the user get? Or
perhaps it's a function of time: Can the user make as many attempts as
he likes within a fixed time interval?If the user enters the wrong passcode, does the timer reset to zero or does the count-down continue toward sounding the alarm?
What does the system do if the user does, or does not, enter the correct passcode within the specified time interval?
Clearly, someone has to answer these questions. If the
analyst doesn't supply this sort of high-resolution information in the
SRS, responsibility falls to the developer to identify all the
pertinent questions and either track down the answers or make decisions
based on his own judgment. Every analyst needs to decide whether he
wants the developer to come up with answers for such questions on the
fly at design and construction time, or whether he'd rather have
customers and subject matter experts record the necessary information
in the requirements specification.
Customers sometimes balk at taking the time needed to
think through these kinds of issues carefully and make decisions. My
response to this hesitation is to ask the customer, "If you don't want
to make these decisions now, who do you think should make them and
when?" Developers sometimes are comfortable with vague and incomplete
specifications because it gives them the opportunity to interpret the
requirements in whatever way they want at the moment. However, remember
Cosmic Truth #9 from Chapter 2: "The requirements might be vague, but the product will be specific." The central issue is who the specificity comes from. Figure 13-1
identifies some situations in which you need more detail in the
requirements documentation and other cases where less rigor will
suffice.
Less Detail Needed | More Detail Needed |
|---|---|
|
|
Figure 13-1: Some factors that influence how much requirements detail is needed.
No comments:
Post a Comment