Scientists Andrew Newberg, M.D. and coach Mark Robert Waldman, in their book, Words Can Change Your Brain, have argued that the right words, spoken in the right way, can bring love, money and respect, while the wrong words - or even the right words spoken in the wrong way - have the potential to take a country to war. Especially in our professional environment of information technology, we know how important accurate communication is and that we need to describe sensitive issues such as problems clearly so that others understand us and we can work together to find a solution that will last in the long run. You can overcome poor project planning, you can overcome weak software coding, but no one has ever succeeded with vague requirements. When the wrong thing is identified, the wrong thing is built.
Unfortunately, business still sees requirements engineering (RE) as something that at best slows down software development and at worst is superfluous. The growing Agile buzz has heavily influenced and even suppressed RE for a while. Simply because most associate the term "requirement" with the approach in a classic waterfall project. The typical comment is, "We don't have requirements, we have user stories!" But no matter what name you give it, it is and remains a basis for your work that needs to be carefully elaborated and examined. In fact, the term "requirement" means, among other things, a documented representation of the needs or wishes of the stakeholders. It in no way implies a statement about the project-specific development model in which the team is working. This misperception that requirements and requirements engineering are only something for classic projects can lead to financial losses or stakeholder mistrust in agile projects.
Many agilists are surprised how close requirements engineering processes are to the agile mindset. The IREB has recognised this and in order to unite both worlds and clear up misunderstandings, the CRPE syllabus published in 2021 talks about work-products. Depending on the context, this means both the individual requirements and user stories as well as the descriptions of (external) interfaces, use cases, epics, etc.
Basic principles of Requirements Engineering
The known four main activities of requirements engineers are:
✔ Elicitation: Elicitating, particularizing and refining requirements
✔ Communication and Documentation: Describing requirements and putting them together in a clear and concise way, e.g. in prose or model based
✔ Validation and Consolidation: In order to ensure the quality of requirements
✔ Maintenance: Organizing and Managing requirement
The new syllabus replaces the familiar four main activities of the requirements engineer with nine fundamental principles. Chapter 2 deals exclusively with the topic, here only a brief insight:
1 Value orientation: Requirements are a means to an end, not an end in itself
2 Stakeholders: RE is about satisfying the stakeholders’ desires and needs
3 Shared understanding: Successful systems development is impossible without a common basis
4 Context: Systems cannot be understood in isolation
5 Problem, requirement, solution: An inevitably intertwined triple
6 Validation: Non-validated requirements are useless
7 Evolution: Changing requirements are no accident, but the normal case
8 Innovation: More of the same is not enough
9 Systematic and disciplined work: We can’t do without in RE
For professional requirements engineers, this is nothing new. These nine principles are similar to the Agile Manifesto, like a compass in the hectic everyday life of software production.
If I have convinced you that rethinking requirements could also be useful in your agile work routine, then my colleagues can give you lots of practical tips in our requirements engineering trainings.
