Importance of requirement engineering; elicitation techniques

Requirements engineering (RE) is the process of discovering, analysing, documenting, validating and managing the services and constraints of a system. It includes feasibility study, requirements elicitation and analysis, specification, validation and requirements management.

Importance of requirement engineering

1. Foundation for all later work. Design, coding, testing and maintenance are all based on requirements. Wrong requirements produce the wrong system, however well it is built.
2. Reduces cost of errors. Errors fixed during requirements cost very little; the same error found after delivery can cost 100 times or more, because design, code, tests and documents must all change.
3. Prevents project failure. Surveys of failed projects repeatedly list incomplete requirements, lack of user involvement and changing requirements as top causes.
4. Common understanding. RE creates an agreed statement between customer and developer, reducing disputes; the SRS can serve as a contract.
5. Basis for estimation and planning. Cost, effort and schedule estimates (e.g. function points, COCOMO) need clear requirements.
6. Basis for testing and acceptance. Test cases and acceptance criteria are derived from requirements.
7. Controls change. Requirements management and traceability make the impact of a change visible before it is approved.
8. Improves user satisfaction, since users are involved from the start.

Requirement elicitation techniques

1. Interviews (closed and open): talking to stakeholders with prepared or free questions.
2. Questionnaires / surveys: written questions to many users.
3. Observation and ethnography: watching users do their real work to find implicit requirements.
4. Facilitated workshops / JAD (Joint Application Development): structured meetings of users and developers with a facilitator.
5. Brainstorming: generating many ideas in a group.
6. Prototyping: users try an early version and give feedback.
7. Scenarios and use cases: describing example interactions step by step.
8. Document / record analysis: studying existing forms, reports, manuals and systems.
9. Viewpoint-oriented elicitation: collecting requirements from different stakeholder viewpoints (e.g. VORD).
10. FAST and QFD: Facilitated Application Specification Techniques and Quality Function Deployment (normal, expected and exciting requirements).

Problems in formation of requirements

Pressman groups the problems into three classes:

Sommerville lists the following difficulties in elicitation and analysis:

1. Stakeholders do not know what they really want, or find it hard to say; they may ask for unrealistic things without knowing the cost.
2. Stakeholders express requirements in their own terms with implicit domain knowledge that engineers do not understand.
3. Different stakeholders have conflicting requirements, for example the manager wants detailed monitoring while staff want simplicity.
4. Political and organisational factors influence requirements, e.g. a manager asks for features that increase his or her influence.
5. The business environment changes during analysis; new stakeholders appear and priorities change.

Other common problems:

• Poor communication between users and analysts; different vocabularies.
• Requirements that are ambiguous, incomplete or inconsistent.
• Missing non-functional requirements (performance, security), which are noticed only late.
• Users not available, or the wrong people consulted.
• Gold plating: adding features nobody asked for.
• Difficulty in prioritising requirements within budget and time.

Example: in a hospital system, doctors want quick access to full patient history, the administration wants strict billing controls and the IT department wants to reuse the old database. Without proper elicitation, negotiation and documentation, these conflicting and implicit needs lead to an SRS that pleases nobody. A structured RE process with interviews, observation of ward routines, a JAD workshop to resolve conflicts and a prototype of key screens would produce clear, agreed and prioritised requirements.