As a conference board member of the Swiss Requirements Day I was asked to answer some questions with regard to the profession of requirements engineering.

What are the main challenges for requirement engineers / system engineers / business analysts in the upcoming years?

Business analysts, requirements engineers or system analysts have an analytical mindset. They ask the tough questions and find the stumbling blocks within projects. Some organizations may see this as counterproductive or even hindering as they consider projects to be on track only when programmers are doing something. They base their opinion on the misinterpretation of modern (agile) methodologies and again define the programmer to be an analyst, a requirements engineer and an architect as well. Requirements engineers will have to find their place within agile teams and drive the main goals of true requirements engineers: to make a project save, to reduce project risks, and to provide a strong foundation for the development teams.

In your experience, what are the biggest mistakes made by organizations when it comes to requirements?

Organizations define the life cycle of requirements for each project and not the product or the organization itself. Once a project is over, the implemented requirements are usually forgotten or hidden in some Word or Excel document. In maintenance mode, new requirements are then added to the product in new documents without doing an impact analysis on existing requirements first and without defining a new baseline on the requirements. Also, organizations begin to discuss requirements long before they realize that these are actually requirements. Most often, the people in the organizations think in solutions and not in requirements. They think they already know the solution, without actually knowing what they want achieve with it, first. By doing this, they limit the solution space. They deliberately leave requirements engineers out of discussions because they believe that ‘requirements engineers just over-complicate things’. The result is that these early requirements are not managed, and decisions for or against certain requirements are not documented for the long term. By involving a professional requirements engineer or business analyst who manages the requirements and ensures that requirements do not conflict each other, organizations could utilize requirements engineering skills better.

Which question should you always ask your stakeholders?

Why?’ is most important question to always ask stakeholders, meaning ‘What do you want to achieve with this requirement?’

How can somebody gain excellence in requirement engineering?

A requirements engineer must be a translator among parties and an attorney for the stakeholders, almost like writing up a legal contract – even in agile environments. He or she must therefore be mentally flexible in order to understand different business and technical areas quickly. An excellent requirements engineer has to be objective. He or she must therefore be able differentiate between driving stakeholders to find a solution and influencing stakeholders to drive his or her own solution. A requirements engineer must be very methodical and be interested in the small details while at the same time always seeing the overall big picture. He or she must be mentally strong enough to ask tough questions and be willing to sometimes be looked at as an unknowing person. While IREB trainings and IIBA certifications ensure that a requirements engineer approaches challenges methodically, experience is the main driver to gain excellence.