Page 98 - Software and Systems Requirements Engineering in Practice

68 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

e.g., review the new requirements primarily for compatibility with
the prior system. Depending on the project type, advanced techniques
such as dynamic tracing [Cleland-Huang 2005] can be used to assist
with impact analysis. Some general suggestions when defining the
requirements for incremental improvement to a system for which
requirements do not exist are:
1. Where cost effective, reverse-engineer a set of high-level
requirements and use it as a starting point. User guides and
help files are an excellent source of such requirements.
2. Identify any programmatic interfaces, document them, and
treat them as new requirements.
3. Be sure to review all new requirements, considering
downward compatibility and the sensitivities of users. A very
common complaint for new releases is “I liked the old system
better.”

3.9 Tips for Gathering Requirements
The following set of tips was learned through trial and error and was
based on input from SCR staff members and some of our academic
colleagues. It is not intended to be inclusive, but rather to provide a
starting point.
• Add a “smart ignoramus” to your requirements analysis team.
• Include stakeholders in requirements elicitation sessions who
can speak with authority for the organization, and be sure to
differentiate the “user” from the “customer” when describing
stakeholders.
• Record the level of information and the stakeholder source of
requirements during elicitation sessions.
• Separate context and background from stakeholder requests.
• Plan a project such that access to subject matter experts is
scheduled.
• Where appropriate, start a project by creating marketing
literature, a user manual, or lightweight specification sheets for
the product to help clarify incomplete or undefined customer
needs.
• Force requirements engineers with deep domain expertise to
communicate with external stakeholders, especially for a
domain where technology is changing.
• Wherever possible, use visual techniques, including
models, diagrams, and tables, to communicate important
requirements concepts.