• the stakeholders can understand it and confirm that this is what they want, and
• the developers can follow it to 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.

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 in the minds of the people leading the acquisition process; and
• the difficulty of using the complex tools and diverse methods associated requirements gathering may negate the hoped for benefits of a complete and detailed approach.

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 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.

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, leaving the minor items as issues to be resolved as the work progresses.

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

How the feature will be verified 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 established 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.