The biggest obstacles in requirements engineering
Nevertheless, practice repeatedly shows that requirement specifications not only contain comma errors, but simply miss the point. Essential needs are not known, basic functionalities are never provided, unrealistic expectations are raised, a too complex system with unnecessary gimmicks is planned, reality is not mapped correctly and non-functional business processes are designed.
This does not only happen if you ignore the known best practices of requirements engineering. If you don’t ask, you won’t get any information. Those who do not strive for an early, competent feasibility analysis or design a jack of all trades device without validation by the target group take an incalculable risk.
But you can also do everything correctly in formal terms and still be wrong about the content. In a work process and a requirement specification, form and content are not automatically equally good. Without a clean work process, the quality of the result is a matter of chance, if not completely impossible. However, the perfect process sometimes only ensures the form, not the content; it creates the chance for perfect specification, but no guarantee for it.
Two massive practical difficulties hardly appear in the textbooks:
- The success of a project is not the primary goal for every stakeholder.
- Are all those involved competent enough for their task?
Does everyone wants the project to succeed?
It is a taboo subject that there are stakeholders in projects who do not care about the success of the project or who even reject it. In their professional lives, everyone pursues their own goals, some of them even exclusively. And for which project are there only winners? Or in which company don’t different teams play against each other? Some deliberately sink a project just to spite someone who stands or could stand in their way.
That’s exactly why the expert makes a stakeholder analysis. Not only does he or she record names and telephone numbers, but the professional also reads between the lines, receives tips while smoking or taking a walk about those who are rushing against the project, collects information about the past history and keeps an eye on the critics. The gut feeling also points to discrepancies.
Even and especially in a politically difficult environment, it is the task of requirements engineering to identify the true intentions and needs of all (!) stakeholders at an early stage and to find a solution for conflicts. Here it is more difficult. Especially in the group workshop not all opinions come to the table. Individual discussions are particularly productive if one gains the trust of the stakeholders and treats unofficial tips either as confidential additional information or at least protects their source. In my experience, even project saboteurs often like to talk about their thoughts and fears. Good listening and asking is therefore an important virtue of the requirements analyst.
An example: I never learned what this employee had against the project. He was simply too busy to talk to me. I phoned him in vain for two weeks, several times a day. Unfortunately, this person was regarded as the central source of technical facts, and it gradually became urgent to get certain questions answered by him. Since everyone at the client assumed he was supporting the project, it looked like I was unreliable and forgot to contact him. I couldn’t have given any indications of a project sabotage, so I couldn’t officially ask for another contact person. Even when I realised his dismissive nature on the phone. He never found time for a real conversation and always forgot to send the promised documents. Ultimately, however, there is seldom really only one person with access to the critical facts. So I phoned through the data center and gathered the necessary information with the help of several helpful people who either had access to it or could simply ask their colleagues for it. Stubbornness is always helpful with such things, because in most cases the brakeman doesn’t dare to be too obvious in his project sabotage. With such a story I always remain friendly and make an innocent, unsuspecting face. So the saboteur’s way back into the team is still open.
Case studies about project saboteurs can be found here:
- Johann Rost: Political Reasons for Failed Software Projects
- Johann Rost, Robert L. Glass: The Dark Side of Software Engineering: Evil on Computing Projects
Is everyone competent enough?
Of course, all project participants are competent in something, but not necessarily in the task at hand. Requirements engineering and its sub-tasks are so complex and full of pitfalls that even with the best of intentions you can make surprisingly many mistakes. This is where experience makes you smarter. Without experience one is unfortunately not yet really good. Since the Requirements Engineer is the one who controls, drives and supervises the process of requirements collection, a person who is up to all the dodges is needed here. Not only project saboteurs, but also the complexity of the task itself require a sovereign chess player who overlooks several moves in advance. Questions that the Requirements Engineer does not ask are most likely not answered, conflicts that he does not discover do not resolve themselves and so on. Content knowledge about the application domain or the technology used is less decisive, because that is what experts contribute. Rather, they must master the tools of requirements engineering and stakeholder management.
Apropos experts: Numerous experts contribute their knowledge to the project both on the side of the client and on the side of the contractor. Some know the business processes to be supported inside out, others can predict the exact costs of a function or tame apparently unsolvable technical problems at an early stage in an enjoyable (or frightening) way. Sometimes, however, the consultant also comes across contact persons who themselves do not fully understand how they got to grips with this task. The most important thing is not to overtax this person and rather to use him as a mediator. Hopefully he knows his own limits and does not claim things he has no idea about in a convincing tone. To be on the safe side, the consultant should check assertions and assessments at random, i.e. ask another person about them. Almost everything can be checked on the basis of documents, conversations and prototypes. Better one notices it as early as possible, if errors were dished up to one.
Problem and solution areas
Ideally, you should only talk to people about the areas in which they are competent. A distinction between problem and solution areas helps here. Roughly speaking, the client or specialist side knows the problem to be solved, e.g. business processes to be supported, data to be managed, laws to be observed. However, they cannot draft technical solutions or user interface design. Nevertheless, they try it occasionally. They should leave that to the contractors and technical experts. Especially important is the separation between problem and solution areas when developing new software on a greenfield project. Technically, all possibilities are still open. In order to be able to use these, the technical side may only predefine the problem.
In order to save time and money, the end user is not asked or not all user groups are asked. Instead, they turn to a proxy user, also known as Product Owner. It is expected that this one person will be able to supply the requirements of all other stakeholders. But is that really the case?
An example: In a workshop, the boss explained the work process used in the company. This was documented in a manual and should also be enforced with software. An employee snorted at this point, crossed his arms in front of his chest, leaned back in his chair and did not speak a single word afterwards. Until I caught him in private during the break and asked if there was anything wrong with this work process. He explained his concerns to me. So far nobody has worked according to the manual, because the process did not work like that or would take much too long. Basically his argumentation sounded conclusive. But before I tried to discuss the concrete and clear instructions from above, I wanted to make sure that I wasn’t sitting on a project-damaging feint. I asked two of his colleagues with whom I had been working for some time. They confirmed the concerns and provided further arguments. The resolution of this conflict proved difficult, but important.
Bottom line
Even the requirements engineer himself/herself must know his/her limits. If, in order to save time, an assumption is made quickly, there is a risk of expensive mistakes. The same applies if he or she makes decisions independently or acts as a proxy user. But, as Jakob Nielsen correctly writes in his book Usability Engineering: “Your best guess is not good enough”, “Designers are not users” and “Vice presidents are not users”. But also: “The user is not always right”.
So always be careful and check all information.
Notes:
Here in our t2informatik Blog you can find more articles from her, including
Agile requirements engineering
What prevents creativity in requirements analysis?
Misunderstandings in requirements engineering
Dr Andrea Herrmann
Dr Andrea Herrmann has been a freelance trainer and consultant for software engineering since 2012. She has more than 28 years of professional experience in practice and research.
Dr Herrmann was most recently a deputy professor at Dortmund University of Applied Sciences and Arts, she has published more than 100 specialist publications and regularly gives conference presentations. She is an official supporter of the IREB Board and co-author of the IREB syllabus and handbook for the CPRE Advanced Level Certification in Requirements Management.