Page 72 - Software and Systems Requirements Engineering in Practice

44 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

Unfortunately, while the meeting information is available, the names
of the customers requesting the features were never recorded. Thus,
the information needed for prioritization and release scheduling is
missing. So, it is very important to record stakeholder information
when collecting product requests.
Problems Separating Context from Requirement
Eliciting stakeholder requests to create requirements can be a difficult
task when stakeholders ramble. Sometimes, stakeholders will confuse
background with need. For example,
“We need to have cars stop at the intersection when the light
changes in order to avoid accidents. Drivers should therefore be
able to see the signal from at least 50 feet away in the rain, and
then apply their brakes if the light is red. We do not want drivers
going through red lights.”
In the preceding paragraph there is only one real potential
requirement, that the drivers should be able to see the signal from at
least 50 feet away. Everything else is either wishful thinking or out of
scope for requirements for a signaling system. It is possible that a
township might insist on a contract clause that states “after installation
of the signaling system there will be no more accidents caused by cars
running red lights.” However, it is not physically possible for any
commercial traffic signal system to guarantee that there will not be
any accidents, since drivers and their cars are not controlled by the
system and furthermore, even if they were, no system can have perfect
reliability.
One way to prevent the intermixing of requests and requirements
with need is to carefully separate context and background from
stakeholder requests. Requests are something that the system shall do.
Context might include information about the way the environment
will be impacted by the system after installation. Context might also
include background information about the reason the system is being
purchased or created; it might include background information
describing the environment. We recommend that background
information be kept in separate documents or, at the least, in separate
sections of a document, e.g., sections on what the customer would like
to accomplish, and the customer’s environment before and after the
system being proposed is operational. Under no circumstances should
the “will” statements appear in a requirements specification.
Specifications may become part of binding contracts, and it is important
to avoid having wishful thinking or expected external behavior
contractually guaranteed by a supplier.

Failure to Collect Enough Information
Some stakeholders or domain experts can be difficult to track down
and meet with. Problems of elicitation can be exacerbated if a key