Requirements Engineering Basics
The importance of Requirements Engineering (RM) for the succesfull, customer satisfying development of software systems can not be ignored by now. It must be considered as an key discipline of system development and is material for the success of a project.
Definition and tasks
To make a go of a development projekt, it is important to know what the concrete requirements are – and they must be documented in an adequate manner. But what is a requirement exactly?
It is a condition, which is required by an user (person or system) to solve a certain task or problem or to reach a goal.
On of the central aspects are the stakeholders. They are those persons who influence the requirements directly or inderictly and serve as a source for information. Ignoring a stakeholder often leads to wrong or incomplete definitions.
The first step in the process of requirements engineering is to identify the concerns of all stakeholders and possible other sources. There are several techniques to get the necessary informations through interviews, creativity sessions, out of analysing existing processes or by monitoring users and systems.
After gathering all requirements, they must be documented in a structured and adequate manner. A documentation or specification can contain natural language based prose or a more formal notation like UML diagrams.
Documented requirements must be validated and verified to play safe they fit all quality criteria. After all points are accepted by all stakeholders, the specification can be considered as complete and passed on to the system architects and developers.
The process of managing the requirements spins over the complete specification and development process. It enfolds all necessary measures for structuring and preparing the requirements.
The Requirements Engineer
The Requirements Engineer is at the center of events. He is in close contact to all stakeholders and has the possibility and responsibility to learn the ropes of the systems realm. One of his most important tasks is to recognize the needs of all involved parties and prepare and document them for the project. His job can be seen as a kind of interpreter for transforming the stakeholders requirements to a level that fits the architects and developers language.
To master this task, the engineer needs a lot more than just technical and methodical skills: Analytical thinking for getting into unknown topics fast. Empathy to recognize what the stakeholders really want. Communication skills, as gathering requirements and managing them is all about listening and asking the right questins at the right time. Solving conflicts within stakeholders and other involved parites. Beeing an advocat for the requirements and represent them to architects and the management board.
Classification of requirements
Basically, there are three different types of requirements:
- Functional requirements define the functionality the system must provide to its users or external systems. Typically, they are subdivided into functional, beahvioral and structural requirments.
- Quality requirements determine quality based criteria. They influence the shape of the system and usually have some impact on the functional points and reference performance, availability, scalability, portability, reliability and usability issues. They are often described as non-functional requirements.
- Framework requirements can not be influenced by the projects participants. They apply to neighborhood systems or the process as a whole. Compared to functional and quality requirements, they will not be implemented but constrain the development and architectural decisions.
There are also more classifications based on attributes, priorisation or the level of detail.
Embedded engineering and management
Over the entire term of a development process, the requirements specification is the basis for different tasks:
- Planning: Milestones and work packages can be defined based on the specification.
- Architectural design: The detailed requirements (and the constraints) are used for designing the systems architecture.
- Implementation: Based on the design, the software is implemented
- Testing: Testcases are developed, following the requirements.
- Change management: If change requests appear, their impact on the system can be estimated while analysing the requirements.
- System usage, maintenance: Probelms that occur after releasing the system can be analysed according to the specification to determine whether it is an user, requriement or implementation error.
- Legal issues: The requirements specification ca be used as the main object of agreement between the client and the contractor.
Leave a Reply