Page 70 - Software and Systems Requirements Engineering in Practice

42 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

The Wrong Stakeholders
A stakeholder or subject matter expert may not speak for an entire
organization. It is important during elicitation that the team capturing
the data understands the relationship of the expert to the organization
and project; i.e.:

• Is the expert speaking for the entire organization?
• Are there differences of opinion regarding functionality or
issues that have not been resolved?
• Are the stakeholders knowledgeable about the domain under
discussion?

Untrained Analysts
An untrained analyst may be a very senior, skilled, or business-savvy
person. However, the job of the analyst is to capture organization,
project, or product needs, and not to engage in wishful thinking or
make solution decisions.
On occasion, we have used software developers or database staff
to assist in capturing stakeholder requests (note: requests are not
requirements until they have gone through a review process and been
accepted). It can be very difficult for an untrained person to separate
need from solution. For example, database analysts might think of
database configurations as they conduct interviews and place their
thoughts in with the stakeholder requests. For example: “There shall
be a table for storing customer names and addresses” rather than
“The new system shall store customer names and addresses.”
Similarly, developers will naturally try to design as they capture
needs or define requirements: “The customer names shall be cached
to ensure rapid retrieval” as opposed to “The new system shall be
able to rapidly retrieve customer names and addresses.”
Not Identifying Requirements Level
Requirements are often captured at different levels of detail (see
Figure 3.1). For example, “The car shall have power steering”
recorded alongside “The power steering coupling shall use metric

Business Requirements: Why do we develop the product?
Captured in a vision and scope document (V&S)
Problem Space Customers Requirements: What are customers’ expectations?
(RE Scope) Captured in a customers requirements specification (CRS)

Solution Space System Architecture/Design
Captured in architecture documentation
(not RE Scope)
FIGURE 3.1 Requirements pyramid