Requirements gathering
Overview
People, in general, know that machines can be connected to exchange information and operate in a coordinated manner, producing benefits for the users. There are many examples of such systems, making it obvious that new machines can be connected in new ways to produce new benefits. Anyone presented with an opportunity to make life better in this way is faced an initial question:
What benefits do you want?
Answering this question in a way that makes it possible to construct the new system is called:
- requirements gathering,
- requirements engineering,
- system engineering,
- requirements specfication, or
- operational concept definition.
Answering this question clearly and in a technically competent manner is a task for a specialist. The result is a definition of what the stakeholders want the new system to do. If the specialist does a good job, then the definition explains what is needed such that:
- the stakeholders can understand it and confirm that this is what they want, and
- the developers can construct a new system that acts in the expected manner.
The Challenge
Conducting a "requirements engineering" task is challenging. In the first place, it is not easy to identify all the stakeholders, give them all an appropriate form of input, and document all this information in a clear and concise format. And there are constraints. The requirements engineer is expected to determine whether or not the new system is:
- feasible,
- schedulable,
- affordable,
- legal, and
- ethical.
How the Challenge is Met
The requirements specialists do their work by talking to people, documenting their findings, analyzing the collected information to discover inconsistencies and oversights, and then talking to people again. This process can go on for a while, and may continue throughout the life-cycle of a system.
Talking to people is fundamental aspect of this work. New systems change the environment and the relationships that exist between people, so it is important to identify all the stakeholders and make sure that they understand what is in store for them. The objective is to get the stakeholders to like the new system. Frequently, this objective is not met because:
- there is not enough talking and important needs are overlooked when the system is implemented, and/or
- there is not enough descriptive feedback and user are disappointed by the new system's characteristics.
To keep all these discussions well organized and efficient, the evolving requirements must be documented. This is usually accomplished by storing them as enumerated items in a database, along with attributes such as which stakeholders want the item, revision number (and the text of all previous versions), and relationships to each other that allow similar items to be grouped in different ways for analysis. There can be thousands of items in a requirements database. Reports extracted from this data are used to view the content of this information and understand its meaning.
Once documented in a database, the evolving requirements become a subject for analysis. Analysis techniques range from simple procedures, such as having the stakeholders review the captured text, through complicated approaches such as the construction and evaluation of a prototype implementation. This analysis leads to improvements in the requirements. If a good job is done at this level, the implementation and deployment phases will be uneventful.
External Links
Requirements Engineering: A Roadmap
Authors: B. Nuseibeh, S. Easterbrook
Abstract: This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future.
Date: 2000
Guide to the Software Engineering Body of Knowledge
Authors:
Abstract: The objectives of the Guide to the Software Engineering Body of Knowledge project are to:
- characterize the contents of the Software Engineering Body of Knowledge;
- provide a topical access to the Software Engineering Body of Knowledge;
- promote a consistent view of software engineering worldwide;
- clarify the place of, and set the boundary of, software engineering with respect to other disciplines such as computer science, project management, computer engineering and mathematics;
- provide a foundation for curriculum development and individual certification and licensing material.
Date: 2001