Requirements engineering Guide, Meaning , Facts, Information and Description
Requirements engineering, in software engineering, is a term used to describe all the tasks that go into the instigation, scoping and definition of a new or altered computer system.
Requirements engineering is also known under other names:
- requirements gathering
- requirements capture
- operational concept documenting
- system engineering
- requirements specification
| Table of contents |
|
2 The challenge 3 How the challenge is met 4 Techniques, methods, and conventions 5 External links |
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 with an initial question:
A requirements engineer, not surprisingly, is a specialist tasked with answering this question clearly and in a technically competent manner. The result of the requirements engineer's work is a definition of what the stakeholders want the new system to do, called :
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:
Overview
Requirements engineering is the task of answering this question in a way that makes it possible to construct the new system and allow the organisation to understand what it is spending money on.
If the specialist does a good job, then the definition explains what is needed such that:
The challenge
There are other barriers as well:
- 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 whether 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.
Requirements are approved by the stakeholders, and then implemented by the developers. Simple, structured natural language (e.g. English, French) works best for this purpose. The non-programmer stakeholders can understand its natural meaning, while the developers 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:
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:
This is an Article on Requirements engineering. Page Contains Information, Facts Details or Explanation Guide About Requirements engineering Techniques, methods, and conventions
Critical analysis of such statements is primarily concerned with:
The need for each feature 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 questioned to determine the user's sensitivity to these factors, and their reasonable values.
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