Requirements gathering

Overview

People, in general, know that new machines can be connected in new arrangements to produce new benefits for their users. Anyone presented with an opportunity to make life better by doing this 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,
• operational concept definition,
• system engineering,
• requirements specfication, or
• requirements engineering.

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

Completing a "requirements engineering" task is a challenge. In the first place, it is not easy to identify all the stakeholders, give them all an appropriate form of input, and document all their input 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.

In the rush of enthusiasm associated with a new project, there is always a temptation to downplay the importance of requirements analysis. However, studies of previous projects reveal that costs and technical risks can be reduced through rigorous and thorough up-front requirements engineering.

And there are other barriers:

• the right people with adequate experience, technical expertise, and language skills may not be available to lead the requirements engineering activities,
• the initial ideas about what is needed are often incomplete, wildly optimistic, and firmly entrenched by the acquisition process, and
• the difficulty of using the complex tools and diverse methods associated with this phase of the work may negate the benefits hoped for.

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.

New systems change the environment and the relationships 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 the users 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 which items, revision numbers (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 focus the information and understand its implications.

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. An iterative procedure is used: each analysis reveals problems in the requirements statements, discussions with the stakeholders lead to changes to resolve these problems, and further analysis confirms that the problems have been solved. Then the cycle is repeated. Ideally this should continue until all problems are eliminated. In the real world the requirements specialist avoids "analysis paralysis", and makes do with resolving the most significant problems first and leaving the minor items as issues to be resolved as the work progresses.

Techniques, Methods, and Conventions

Requirements are approved by the stakeholders, and then implemented by the developers. Simple, structured natural language (i.e. English, French) works best for this purpose. The non-programmer stakeholders can understand its natural meaning, while the developer's make use of its organization and detail to guide the development work. Each manadatory feature is specified in a simple, clear sentence containing the word "shall". For example:

 The library shall store 1,000,000 or more documents.

Critical analysis of such statements is primarily concerned with:

• is the feature really needed as specified (and have all the needed features been listed), and
• is the feature verifiable.

Need must be investigated by the requirements specialist with an understanding of the user's domain and the limits of technology. Amounts, limits, rates, colours, accuracies, formats, and protocols all have to be questionned to determine the user's sensitivity to these factors, and their reasonable values.

Verification must be investigated to make the developer's job possible. The developers will demonstrate that they have completed their work by showing that the requirements have been met. Both the stakeholders and the developers must have a common understanding of what this involves. The means for reaching agreement about the final system being acceptable must be decided up front. The best approach is to define the tests that will be used for acceptance. Requirements analysis leads to acceptance test definition.

Given thousands of requirements and hundreds of tests, how can a stakeholder be convinced that all the requirements have been addressed. To answer such questions, the requirements are each given a unique identifier which persists throughout the life cycle of the system. For example:

 [01.04.17] The library shall store 1,000,000 or more documents.

Here, "01.04.17" is the unique requirement identifier. Using these identifiers, cross reference tables can be constructed linking requirements to their tests. Such tables can be queried to automatically report all requirements that do not have tests. With techniques like this, the user can gain confidence that the system is thoroughly tested, and therefore complete enough to accept. A set of requirements that is fully labelled and analyzable in this manner is said to be "traceable". This is an essential characteristic of a finalized set of requirements.

External Links

Requirements Engineering: A Roadmap (http://www-dse.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf)
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 (http://www.swebok.org/)
Project Champion: Leonard Tripp
Executive Editors: Alain Abran, James W. Moore
Editors: Pierre Bourque, Robert Dupuis
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.
  

Writing High Quality Requirement Specifications (http://www.stc-online.org/cd-rom/1999/slides/MethWrit.pdf)
Author: Dr. Linda Rosenberg (SATC, NASA)
Abstract: The requirements specification establishes the basis for all of the project’s engineering management and assurance functions. If the quality of the requirements specification is poor, it can give rise to risks in all areas of the project. This workshop will educate project managers and software developers in effective development of quality requirement specifications. It will also provide them with ideas and methods they can incorporate immediately into their project plan and find a productive return in documentation evaluation and comprehension.
Date: 1999