Requirements Engineering

Almost all software development processes one way or another stress requirements analysis and specification as one of their core workflows. The reasons are simple. It is necessary to manage requirements as well as possible because a small change to requirements can profoundly affect the project's cost and schedule, since their definition underlies all design and implementation. Unfortunately, in most practical projects it is not possible to freeze the requirements at the beginning of the project and not to change them. Requirements develop over time, and their development is a learning process, rather than a gathering one. The intended result of this process is a structured but evolving set of agreed, well understood, and carefully documented requirements.This implies the need for requirements traceability the ability to describe and follow the life of a requirement, in both a forward and backward
direction, ideally through the whole system's life cycle.

The importance of constantly involving the users in the process of requirements analysis and specifications cannot be overemphasized. Only the users know their domain properly, and for that reason they should certainly participate in defining the system's functions, designing them, and evaluating their implementation and testing. The users should also participate in creating, verifying, and updating the requirements specification document for the project. The users should share with the developers the responsibility for the requirements' completeness and consistency. It is the project managers' duty to establish and maintain good relations with the users throughout the development process, as well as to consult them whenever the project gets stuck due to the development team's lack of domain understanding.
There is a wide spectrum of techniques for requirements engineering. Whatever technique is applied, it is always desirable to involve the user to increase the correctness of the requirements specification.

Some of the techniques are:
• structured interviews and questionnaires that the user fills in inquirybased requirements gathering.
• diagram-based requirements analysis using multiple diagrams to sketch relevant parts of the user's work process and describe the requirements graphically.
• using metaphors of the user's work process the office metaphor, or the agent/agency metaphor.
• scenario analysis scenario is a typical sequence of activities characterizing the user's work process, hence it reflects what the user will do with the system and helps define the test procedures.
• using special-purpose software tools for requirements gathering some of them can be simulation-based.
• requirements completeness and consistency checks some of them can be automated, others must be performed manually.
• using special-purpose requirements-specification languages in order to describe requirements more formally and hence provide more automated requirements tracing.
• prototype system development, in order to make the requirements clear and to establish better mutual understanding with the users.
• analyzing videotaped user's work process. When managing software development according to the Unified Process, requirements are captured mostly through the use cases and use-case diagrams. A use case can be described as a specific way of using the system from a user’s perspective .