Requirements engineering is one of the daily project life topics which are discussed extremely diverse. In project management training sessions and during studies, requirements engineering and management are served to the participants as a must have and “there is no way” around topics. As soon as the theory is replaced by reality, you will see that most of the project teams dislike this topic due to different reasons. In the following article, I want to give you a generic view on this topic and show you the most common reservations and real advantages of requirement engineering.

Great! But how do requirements relate to a system architect??

Interesting formulation … the counter question “How do the requirements of a project not relate to anyone in the project or even the entire company??”

I agree, my counter question is a stereotype, an answer which stops every critical discussion. This is not the goal here. Coming back to the initial question – “ How do requirements affect the system architect?” – well, system requirements describe how the contractor understood the task and plan to realize customers requirements. It is the translation of generic customer wishes to specific realization steps. Therefore, if you are on the contractor side and in the role of a system architect it is your task to create the system requirements.

Requirements engineering is a task of a system architect…. Really? Shit!

As a system architect, you are responsible for the technical realization of the product. Your daily work is the coordination of all technical sub-parts like software, hardware, mechanics, tests, technical suppliers and many more. But not only the coordination but cooperative working on concepts and architectures considering all technical aspects of the project. You will be the one who sits together with the customer and discusses alternative solutions if something cannot be realized as expected. You will also be the one who is acting as a technical expert towards the management (yours and of the customer) especially in critical discussions. You will attend financial negotiation rounds to support your sales colleagues. And in the end, you will be the one who has to show that the product was developed as it was specified, by planning and heading the system test and providing the project documentation.

For all the mentioned steps you are well advised to be properly prepared with hard facts instead of vague formulations. Memories are not enough!

„I have a great relationship to my customer and we had also to be fast, therefore we didn‘t create a specification“ - Every Second Project Leader

If your memory is extraordinary, you may remember all the chats with the customer, workshops with your team and external suppliers, all decisions made in the management. But the crucial point here is, as soon as it comes to a showdown no one will rely on memories only, not even your boss and your colleagues who were fully supporting you all the time. In Germany, there is a proverb “paper is patient”, in the current century it is more the digital one, but the essence stays the same. The key targets and functionalities of a planned product have

  1. To be formulated and written down by the customer
  2. To be formulated and written down by you (your team)
  3. Signed by both

Why is that important? Think about your last brilliant idea you had about any topic. In your head, all the advantages, disadvantages, functionalities, business cases, implementation details, design aspects, and all other nuances seem to be very clear and simple. Now try to explain your idea to someone else, if you want it easy choose someone with a comparable mindset and background as you, if you like the pain choose someone from a totally different discipline.

What you will observe is that it is extremely difficult to transport all your thoughts to your opponent verbal. To close the gaps you can now try to write it down and draw also some picture and diagrams. Now you will start to bring more structure, simplify parts, group them, reference to already available pictures and paragraphs, etc. This is exactly the reason why your customer has to write down his wishes (customer requirements).

Fine … you have described your idea to your opposite, now ask him to explain what he understood. You will see that the explanation of your opponent will differ in many points, also in the most important ones. Ask him to write down, draw and sketch the idea. If your previous sketches are still on the table you will mention that you opposite will start to copy them. If this is the case, ask him about some small details about what he just copied. Very likely you will get an “I don’t know, you shall know it better” or an explanation which didn’t fit to what was initially meant by you. This is what is called “implicit knowledge” and this is exactly the reason why the system requirements shall never be acopy of the customer requirement, even if they are obvious. Always formulate the requirements in your own words, you will see that even the irrelevant small details can discover hidden needs.

And last but not least, go for a signature from both sides. In the first place, it is a legal obligation and shows your partner that you take it seriously. And in the second, which is more important than the legal topics, as soon as your opposite sign the specification he commits the details not only to you but also to himself and will defend his decisions together with you in a critical situation. Therefore you will win an additional team member and a strong relationship with your customer.

Requirements Engineering is not a one-time task

If you are new to requirements engineering your first thought could be “How hard can it be? I have just to write it down once and we can start to work.” … Well, I have bad news for you. Requirements are a living organism of your projects. Especially in agile projects, which a very common in the current world, but not only.

It is not a one time task

At the very beginning of the project, you will face a lot of uncertainties and will not be able to specify functionalities in the detail you want. During the project life, you will drop some of them and new ones will replace them. You will refine requirements due to new findings, change functionalities. Some of the less important issues become major functionalities, others will see a decrease in priorities.

To support this versatility you will need a strategy and a toolchain which allows you to manage, track, trace, change, delete, reference, publish, fix, etc. the requirements. You will have the need to create customer-friendly, management-friendly nice looking documents for negotiations and reports. You will face the need to work collaboratively with your teammates on the topics. You will discover the need for change request management and claim management. Choose both the strategy and the toolchain together with your team to get full support from internal. Do not believe that a new and fancy tool will fix your issues automatically. If you do not know how to smash a nail in a piece of wood you will fail even with a super usable, super strong hammer. On the other side if you know that you have to hit the nail head you will manage it even with a stone.

If you are new to requirements engineering choose a toolchain you already know and learn how to gather and write the requirements. As soon as you are more familiar with requirements engineering you can think about adapting your tools. There is nothing bad with excel, word or even simple text files if you are good at it.

Insight comes late

Requirements management has a bad reputation. The accusation:

  • It is monotone due to the documentation work. I want to build the damn thing!!
  • You stop the team from productive working and it is unrewarding
  • It is annoying for the customer to be asked the same questions again and again

In my 10 years of professional working experience, I’ve met exactly 1 person who had real skills to collect, document, manage, explain and maintain a requirements document in a real project. All trainers and professors know how to do it in theory but the ones who did it, in reality, are very rare.

Insights come late for requirements engineering

This guy was also the one I’ve learned from that all the above accusations are becoming obsolete during the project lifetime. Point number 3 for example, yes it is annoying for the customer to answer the same questions again and again. The reason is simple but difficult to transport to the customer, you are not working in customers domain, you do not have all the hidden knowledge, you don’t know the real reason for decisions, you are not working with his colleagues. The strategy you follow with your questions is to get a better understanding of customer needs this is exactly what I explain ever a time when I start asking and disassemble the requirements in single pieces. What I’ve learned in the past years is that reflection of previous sessions/answers helps a lot to get acceptance and understatement for the questions. The reflective part shows the customer that you really listen and process his explanation from the past and not asking because you are too lazy to think and remember. If you are doing it right, you will significantly change the mood of the customer. It will turn from being annoying to having a review and feedback partner who supports me to make the right decision and not simply implement every new function to get the money.

Also, the feeling of making an unrewarding work will stop immediately as soon as the first issues, misunderstandings, change requests and hidden claims for additional functionality will appear. You do not need to decline the claims but make visible that it is an additional effort which was not included in the previous price. To prove your statement, make the customer aware of his written customer requirements and the signed system specification. Do it to substantiate your change request offer but do it especially when you do not plan to charge the customer any additional costs. Thanks to the previous steps of writing and signing, convincing your customer to pay extra will be easier.

But not only for the extra payment but also for critical discussions the requirements document can be the decisive criterion. Those who had the chance to participate in a project which is very close to being finalized will confirm that the following situation happens in nearly every project.

Your team is performing the tests and create the documentation for the customer. Everything runs smooth and you decide to show the customer the testing results. What is happening then on the customer is that he start to ask for more and more testing trying to cover every aspect of the products life cycle, which is often not possible. Your testing effort and costs are rising fast. The only justification of the customer is “I can not use the product in the field if this test (and the next, and the next….) was not performed” or “I can not give my final acceptance until I do not know whether the product fulfills my requirements”. Test methodology (also called verification), as well as the acceptance criteria (also called validation), are, together with a description, the minimal content of every requirement. Verification contains a detailed explanation of how you want to prove the functionality or a reference to a test case in the testing document. Acceptance criteria contain the criteria which have to be reached to see the market requirement as being fulfilled. As long as the customer officially approved the specification and as soon you are able to show that major acceptance criteria are fulfilled, the project is officially done.

If no requirements document was written and approved, I as a customer would always try to extend the functionality, get more confidence and get a warranty from you about lifetime, quality, etc. Sure it is often hard to specify tests and acceptance criteria at the beginning of the project but the effort is worth it.

Requirements Engineering hits agile or vice versa

The killer argument number one in every discussion about requirements engineering is : “We are working agile, there the main paradigms are -customer collaboration over contract negotiation- and -working software over comprehensive documentation-, that's why we do not need requirements” It is true, these two paradigms are with two others the main headers stated in the “Manifesto for Agile Software Development

Sounds like an unbeatable fact … ahhm No … only as long as your only knowledge about agile development is coming from the fancy posters with the already mentioned 4 headers. But there is a more detailed view on this point on the same web site, just a click away ... “Principles behind the Agile Manifesto„.

Classic vs. Agile

Let‘s have a look at the principles. Paragraph #2 says „Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.“

“Ohh hell they are talking about requirements … in the agile manifesto …”

There is mine interpretation of the sentence. Requirement changes are welcome … my main question is how to discover the changes if you did not even have the requirements documented? Can you really rely on your memory only?

Next point...I guess you are not a Samaritan and not doing all the work for free. You are running a company and have to pay your employees and your bills every month. Based on which reliable factors will you decide whether the change, the customer wants to have implemented, have to be paid or not? Right, you have to have some kind of change management on your … requirements.

Let's continue with the principles, principle #11 “The best architectures, requirements, and designs emerge from self-organizing teams.”. There it is again… the bad “r” word. I guess with this statement it shall be clear that the requirements gathering is an important jigsaw piece in the agile manifesto.

The other aspect besides the knowledge of the agile manifesto is the working experience … if you ever worked in a team using an agile framework (e.g. scrum, kanban) you will remember that besides the implementation phase there are also some other phases. What I’m interested in is the phase before the implementation. In scrum, it is called backlog grooming (also called backlog refinement or story time). In this phase the team is refining the work packets for the next sprint, they are discussing, asking questions and write user stories until all team members have the feeling that they have understood each and every aspect of the work package.

This is requirements engineering!! More precise ... the requirements gathering.

Very often the results are written down as an issue in Jira, a web-based tool for ticket management often used for project organization. Depending on the team habits Jira is also used for every type of communication (commenting, assigning to other team members, change the status, etc.) regarding the issues.This is requirements management!!

Change requests on requirements are handled in the same way as normal requirements, an issue is created for each of them, the only difference is that there is a link to the old one which allows proper tracking and change management.

Summary

Requirements engineering sounds very technical and complicated and may scary the one or the other with the workload but at the end, it is nothing more than a set of methods to understand your customer in a better way and therefore to build a product which really fits their needs. Having a closer look at the discipline you will learn • interview techniques (what to ask your customer, when to ask, who to ask) • psychology (how to formulate your questions to improve collaboration and avoid protective behavior) • writing techniques (templates how to formulate your requirements)

Further, the need for requirements engineering is not dead due to agile methods … it is the other way around. Agile methods encourage and support you in getting in closer contact with your customer. The process of formulating and writing down the requirements is hidden behind user stories but is still there. And to be honest, as soon as you have written your first 30-40 requirements your brain will start working automatically on this task. Means • You will separate each market requirement or customer’s use case in atomic system requirements in a short time • You will discover improper and insufficient formulations within customer’s requirements and ask for a better explanation • You will formulate the system requirements using the proper scheme without thinking about it
• You will start discovering references (bad and good ones) in between the requirements • You will have an enormous amount of questions for your customer … and this will be not only questions about the project itself, but you will gain also the interest for the background information and for customer’s work

It is true that at the beginning the work feels like a stupid work creation program for the new guy in the team. But doing this you will become an important interface between the customer and the development team. You will be the one who knows the targets of the customer and how they are realized by your team. I will become a consultant for your management to discuss further development of the partnership with your customer.

Previous Post