Requirement gathering and analysis techniques

Requirement gathering and analysis (elicitation and analysis) is the requirements engineering activity in which analysts work with stakeholders to discover the application domain, the services the system must provide, its performance and other constraints, and then organise, prioritise and negotiate these requirements.

Techniques used

• Interviews (closed and open)
• Questionnaires and surveys
• Observation and ethnography
• Scenarios and use cases
• Prototyping
• Brainstorming and facilitated workshops (JAD, FAST)
• Viewpoint-oriented analysis
• Study of documents and existing systems

The analysis activities that follow are: requirements discovery → classification and organisation → prioritisation and negotiation → documentation, repeated in a spiral until the requirements are complete enough.

1. Interviewing

The requirements engineer asks stakeholders questions about the system they use now and the system to be developed.

• Closed interview: a predefined set of questions is answered.
• Open interview: no fixed agenda; the team explores a range of issues. Good interviewers are open-minded, avoid pre-conceived ideas, and use a "springboard" question or a draft proposal to start discussion.
• Advantages: gives detailed understanding of what stakeholders do and their problems.
• Limitations: users find it hard to explain domain knowledge they use every day, so tacit requirements may be missed. Example: interviewing a pharmacist about how medicines are dispensed, which records are kept and which reports are needed for a pharmacy system.

2. Scenarios and use cases

Scenarios are real-life examples of how the system will be used. A scenario describes the starting situation, the normal flow of events, what can go wrong, other concurrent activities and the state at the end. People relate more easily to concrete examples than to abstract descriptions. Use cases (UML) identify the actors and the interactions with the system; each use case is described by a set of scenarios.

                 Library system
             +----------------------+
             |  ( Search book )     |
  Member ----|  ( Reserve book )    |
             |  ( Issue book )      |---- Librarian
             |  ( Return book )     |
             |  ( Pay fine )        |
             +----------------------+

Example scenario "Issue book": member gives card, librarian scans card and book; system checks the member has fewer than 5 books and no unpaid fine; records issue with due date; prints slip. Exception: member has unpaid fine, so issue is refused.

3. Ethnography (observation)

An analyst spends time observing people at their actual work and notes the real tasks they perform. It helps to discover implicit requirements that reflect the real way people work rather than the formal procedures, and requirements arising from cooperation and awareness of other people's activities.

• Advantages: reveals tacit knowledge and real practices; uncovers requirements users forget to mention.
• Limitations: time consuming; focuses on existing practice, so it is weak for innovative features; people may behave differently when observed. Often combined with prototyping ("focused ethnography"). Example: observing bank tellers shows that they often serve two customers at once and keep frequent account numbers on paper, so the new system needs quick switching between customers and a recent-accounts list, which no teller had mentioned in interviews.

Combining these techniques (interview to get an overview, observation to see real work, use cases to describe agreed behaviour) gives a fuller and more accurate set of requirements than any single technique.