As already announced, since March 2021 we are giving IREB Certified Professional for Requirements Engineering (CPRE) Foundation Level training according to the new syllabus 3.0. In this article, I highlight some of the changes and give feedback as a trainer.
The previous syllabus, version 2.2 from 2017, would certainly last for a few more years. But I think it’s great that IREB doesn’t wait until the content and methods are outdated. Like a true influencer, IREB goes with the times and sets new trends for the domain.
Power of the Word
Scientists Andrew Newberg, M.D. and Coach Mark Robert Waldman have collected evidence that words can literally change the brain. They claim that the cause of conversational deficits is underdeveloped brains rather than poor education. In their book, Words Can Change Your Brain, they write: “The right words, spoken in the right way, can bring us love, money and respect, while the wrong words — or even the right words spoken in the wrong way — can lead a country to war.” No one in IT knows how important it is to find the real problem and to describe it in a right way better than people who work with requirements analysis. You can overcome poor project planning, you can overcome weak software coding, but nobody has ever succeeded with vague requirements. If you have elicited the wrong things, you will build the wrong solution.
Unfortunately business still sees RE as something that slows down software development in best case and regard it as redundant in worst case. Trending Agile buzz strongly influenced and even suppressed RE for some time. As a consultant, trainer and coach I have seen too many agile teams struggling with poor requirements and topics around them. Just because most of the people 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!” You can call a child many names, but one stays true to all of them — you have to take care of the child no matter what name you gave them. In fact the term “requirement” means, among other things, a documented representation of the needs or wishes of the stakeholders. In no case does it imply a statement about the project-specific development model in which the team works. This misperception that requirements and requirements engineering are only for classical projects can lead to financial losses or distrust from stakeholders in agile projects.
Many agilists, who come to the CRPE training, are surprised how close the requirements engineering processes are to the Agile mindset. IREB has recognised how to unite both worlds and eliminate misunderstandings, the new CRPE syllabus for instance talks about work-products. Depending on the context, both the individual requirements and user stories as well as the descriptions of (external) interfaces, use cases, epics, etc. are understood.
Basic principles of Requirements Engineering
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. I see these nine principles, similar to the Agile Manifesto, as a reminder during hectic everyday software production, as a lighthouse in the storm that shows us the way.
See you soon!
I hope I have made you curious and would be happy to meet you in one of our training sessions and tell you more about requirements engineering.
