Requirement Engineering - For whom and what for?

Dear Jenny, 

We occasionally use our blog to give an insight into our trainings. What is it, who needs it and what exactly can I use it for in my everyday life? Thank you for being available for a short interview!
 

The first question: What do I understand by requirements engineering

Requirements Engineering is a process that should be defined and managed. The IREB training deals in detail with the configuration of a customized RE process, taking into account influencing factors from the project environment and facets of processes (goal, purpose (prescriptive/explorative) and time). 

This is followed by an explanation of requirements management, which implies the entire lifecycle of requirements. In the course we talk about versioning, configurations, baselines and prioritization or for example traceability (in all conceivable directions: backwards, forwards and horizontally).

That sounds quite theoretical. What does the training actually help me to achieve in practice?

You get a roadmap and an overview of what needs to be done.  Stakeholder wants and needs are understood and the right people in the appropriate stakeholder roles are identified. After all, it is only when you properly engage them and create collaboration that RE can be truly successful.

We also provide course participants with nine principles that summarize all tasks, activities and practices. This already helps a lot to get a framework that can be followed in practice.

The techniques and considerations for requirements elicitation, documentation, and review have been identified and described by practitioners so that they can be used in any practice, albeit in an adapted form.

And, thinking practically, the IREB also covers prototypes! Exploratory ones (such as wireframes, mock-ups), but also experimental and evolutionary ones. 

Understood. But still, in our understanding, RE remains indeed first a lot of documentation! You surely know the objection that this is too much work for one or the other, especially agile, project?

The essence of RE is common understanding (also one of the principles), so documentation must be seen as a support for this central principle. A complete description is impossible in our complex world.

However, the IREB gives concrete support on which level of abstraction certain work products should be and what level of detail they should have. Their scope depends on their lifetime and the development model. In the course, I try to convey exactly that: How to adapt documentation to the project context and thus keep it Lean or Agile (minimal documentation). 

The approach to documentation is based on structure, so that the overview is there and the documentation can therefore remain minimal. In all aspects, one of the principles "value orientation" is paramount.

Are the requirements available as continuous text or is there also something like a condensed text here?

The IREB gives concrete instructions to provide structures in advance that support the description of the requirement. This is done by means of templates, formulation aids and the definition of a glossary for the consistent use of terms and a uniform terminology. What to look for, such as: short sentences, only one requirement in a sentence, sensible structure (sentence templates to assist), and which phrases to avoid (e.g., specific rather than general reference). I also teach five quality criteria for all work products: Adequate, Necessary, Clear, Complete, Understandable, and Verifiable. What is meant by this and how to implement it can be learned in our course.

Nevertheless, I would like to ask again more concretely: Can graphical representations or models be derived from the natural language requirements?

One can reduce extensive requirements by compression/aggregation and by selection in order to be able to derive which model or models are suitable to visualize the requirements and thereby make them easier to understand for all stakeholders. Some examples: 

1. I would like to visualize how the data flows through the system, through the business case. According to the original idea of IREB, the flow can be modeled using an activity diagram. 

2. I would like to derive and represent the interaction with the system under consideration from the use case specification. The IREB looks at the different perspectives using the use case diagrams (UML), but these need to be supplemented with other diagrams to provide a more complete perspective on the future system. 

3. I want to model the data of my system. The IREB introduces UML class diagrams. A class describes a set of objects, an attribute describes the property of the class. 

In the training, the basic notation elements and the different diagrams (activity diagram, state diagram, condition diagram) are explained with practical examples and exercises.

And where do I get the requirements from? Do they only exist as a result of the requirements engineers' work?

No. Most requirements actually exist, they just have to be collected, organized and explicitly formulated as such. The IREB divides the requirements sources into three main categories: stakeholders (onion model according to Ian Alexander, personas), documents and other systems. In addition, it selects elicitation techniques based on the Kano model, such as elicitation techniques (interview, collaboration, observation, artifact-based) and design techniques in more depth.

IREB also addresses the resolution of requirements conflicts that arise when different stakeholders have different or even conflicting views on certain requirements. Ways of identifying conflicts, analyzing them, resolving them, and documenting the resolution of the conflicts are highlighted.

Are there also tools for RE that make the work easier?

The tools that have an important supporting role in RE are covered in a separate chapter in the IREB. These are tools for managing requirements on the one hand, and for supporting the RE process on the other. I also outline how RE tools should be introduced in an organization and what lifecycle costs are associated with them. I also provide guidance on how to evaluate a tool against defined criteria.

Thank you Jenny for your explanations! 

PS: For those who have read to the end and are still interested in the course, go to the trendig IREB training schedule here.