Guest Post by

Efficient assignment of requirements engineers

Even in small IT projects it may take 2-3 developers several months to develop the required artifacts with costs easily adding up to a several 100k €. A lack of adequate preparation of what is needed as well as inadequate support by the subject matter experts during the development phase can lead to failure in meeting the defined business goals. In this scenario all project partners lose: the project client has spent money without getting the expected value for it and the customer receives software that does not meet their needs. Even the development teams have invested energy and time that could have been spent more efficiently which results in unnecessary stress. So motivation is down and frustration has increased for all project partners.

requirements engineers effizient eingesetzt

Even small projects can benefit by support from a requirements engineer

To develop software, the support of a requirements engineer (RE) or business analyst (BA) role is quite useful. Without this role the risk of failure increases, since complete and well documented requirements are key criteria for project success. Project managers or subject matter experts are usually not able to take on the RE role with the same positive results, as I’ve already pointed out in another blog post. Because both roles may well lack the necessary knowledge and experience with RE methods. So assuming they can simply take on the RE role on the fly could be a risky assumption. Plus, they are likely to focus on their subject and usually don’t consider details that are required for other tasks up- or downstream within the overall process

To assign RE responsibility to the developer is not always a good option either. Josef Falk has pointed that out in his blog post. It might be possible for developers to manage the requirements, but they probably will not be able to provide dedicated RE support, which can be very beneficial in a project-context. The cost for a dedicated RE will easily be offset by the increased quality of the results by the dev team. In addition high-quality RE support for a team of developers requires a dedicated skill set: managing different stakeholders, uncovering and validating their requirements, documenting them, discussing the test cases, etc. can also be time-consuming, which might consume valuable time needed for the actual coding if the developers are trying to fill both roles. Once the number of developers increases the RE tasks will consume a big share of their time. Coordinating multiple different project partners, synchronizing the different requests, understanding the business context of the topic at hand, facilitating workshops etc. will leave little time to focus on the IT point of view, let alone for the actual coding. Additionally, the way developers and requirements engineers work is very different.

For a developer is desirable to have:

  • Extended concentration time
  • Few changes in context
  • Agreed and validated business requirements

Geek productivity in reality

Requirements engineers usually need to function in a different work environment:

  • Frequent change of context/topic
  • Focus on incoming requests from different project partners instead of an inward focus
  • Neither agreed nor validated business requirements to begin with (the mission is to reach this stage)
  • Conflicting requirements by various stakeholder that need to be consolidated

When taking all of these facts into account it seems a beneficial idea to have a dedicated requirements engineer role for the project, so the person responsible will have the necessary time and the professional skill set to help make the project successful.

The skill set of an experienced requirements engineer

The exact impact of requirements engineering on the success of a project is sometimes difficult to quantify. However, the RE facilitates and supports the following key components:

  • Alignment of the project work with the business goals
  • Smooth running of refinement workshops
  • Liaising with the project partner to agree on business and systems requirements
  • Creation of test cases for the implementation of the business requirements etc.

In my experience an experienced requirements engineer can coordinate and support 5-8 developers / testers when working full time (40h per week), irrespective of whether these developers are working in one team or in several teams and on different projects. The main responsibilities of a requirements engineer in this context are (see Rupp et al. Requirements Engineering Fundamentals):

  • Requirements analysis
  • Requirements validation
  • Requirements consolidation
  • Requirement documentation

The outcome of requirements engineering can be different in various projects, but usually produces the following artifacts (in random order)

  • Interface description (GUI wireframes/mockup or API description from a business point of view
  • Information about the required data (input, output and how it should be processed)
  • Definition of actions to be performed by the system or the user
  • Definition of business rules and logic
  • Consensus on non-functional requirements
  • Test cases
  • Documentation for project partners

Mission types and workload of a requirements engineer

As a requirements engineer you are responsible for completing different tasks in different phases of a project. At the beginning of a project the focus lies more on facilitating workshops and discussions to reach a shared understanding among the project partners about the business and project goals, users, systems and how all components work together to generate the desired business value. At this time a lot of information is gathered which needs to be validated, consolidated as well as structured and documented (with UML/BPMN diagrams, wireframes etc.) for the different specific project partners. As the project progresses both the workload and its intensity decrease on average, with peaks when reaching important milestones or towards the end of the project. It is not only the different project phases that determine the workload and content the requirements engineer will provide during a project.  The type of responsibility and support also has a major impact on the role of the requirements engineer. I have put together a list of possible mission types (this list is not exhaustive):

Supporting a Product Owner (PO)

The Product Owner Certification enables people to take on the Scrum PO role in IT projects. However, the Product Owner Certification is not sufficient to provide the Product Owner with the necessary requirements engineering skills to also perform the requirements engineering role in IT projects. A RE skill set assigning a dedicated requirements engineer to assist the Product Owner will be a good investment. In this PO-RE team set-up it can be sufficient if the requirements engineer only works part-time for the PO. There may be no need to attend all dailies or sprint planning meetings etc. The requirements engineer provides on demand support for the PO including roughly the following tasks:

  • Assisting in RE-workshops, refinements
  • Tactical, more requirements-focused aspects of the stakeholder management.
  • Doing the requirements engineering groundwork

With the groundwork for the requirements management done by the requirements engineer the PO uses the findings/results for the release and sprint planning. This team set-up can free up PO time to focus on more strategic aspects of project partner management, budget management and strategic product development, sales etc. (if you understand the Product Owner not only as Scrum Product Owner, but as product manager with a stronger business focus.)

Business Analysis / Concept work

Before starting an IT project, it can be quite helpful to understand the current processes (which often are not documented anywhere) or to create an initial concept or backlog without including descriptions of specific features, system specification or GUI in too much detail. In those cases, the experience of a requirements engineer can be helpful for facilitating workshops and to consolidate, validate and document the findings. The information gathered in an initial concept or backlog will then serve as the starting point for further discussions. If the requirements engineer supports with business analysis and conceptual tasks he may well only be needed for a few weeks or months. In this case, however, the actual workload may not be 100%, since waiting for board decisions or the availability of SMEs usually causes delays.

Requirements engineer as a substitute Product Owner

In this scenario the requirements engineer is responsible for the full spectrum of PO work incl. preparing/ facilitating all Scrum meetings as well as strategic product development. The size of the development team should be limited as the workload can become quite intense with the responsibility of serving in both capacities.

Requirements engineer as a system support

In addition to working in projects with a defined start and end date requirements engineers can also support a running system with their skill set. This usually involves the handling of bugs and smaller to medium feature requests. The workload is more evenly distributed over time (compared to project work with bigger topics and higher workload at the beginning and towards the end). The pressure is also usually not as intense, since day-to-day business often receives less management attention than highly visible projects.

How many requirements engineers are needed?

Answering the following questions will help you with an initial estimate of how many requirements engineers are necessary for your project:

1. How many developers will the requirements engineer work for?

As described about 5-8 developers can be supported by an individual requirements engineer who is working full-time. If there are less developers, a requirements engineer working part-time for the project may be sufficient.

2. How fast-moving are the project organization and/or the organization as such?
Especially in large or highly bureaucratic organizations organizational processes are often moving more slowly than would be ideal for an IT project (and it  does not matter whether you call them classic or agile projects). The following issues can slow down progress and cause delays in IT projects thus interrupting the otherwise continuous workload of the RE:

  • Workshops with multiple key team members need to be set up several weeks in advance due to a full calendar (usually regular meetings)
  • Project partners take their time with feedback if the IT project does not have high enough priority
  • Decision makers (board meeting) only meet on a monthly or quarterly basis

In this scenario the requirements engineer must work in “burst mode” and quickly gain a solid understanding of the project partners’ requirements and goals as s/he has to compensate any periods without proper feedback or other delays by creating a constant flow of requirements and keep the developers busy working towards the project goal. This is even more important if you have a highly skilled or a large developer team with a high demand for requirements. Not being able to supply them with requirements to implement would be counterproductive, since motivation and focus would fade quickly and might be difficult to regain.

3. In what capacity will the RE support the project?

Does the requirements engineer simply support the Product Owner or is s/he taking the lead on the product development project? Leading the project as a substitute for the Product Owner will include substantially more work and responsibility and is more likely to require a full-time assignment. On the other hand, supporting a PO with more traditional RE-specific know-how like facilitating workshops is something that would require less time.

4. If the project has already started, what phase is it currently in?
At the beginning of a project the workload and the intensity of the work is quite high. There will be multiple workshops within a short period of time, plus a myriad of information needs to be discovered, consolidated, validated and documented according to the project partners’ needs and goals. Later on over the course of a project this workload decreases, even though there is still RE-work to be done as we keep uncovering information which needs to be refined etc. When supporting a running system on a day-to-day basis on the other hand the workload is spread more evenly, and time periods with higher workload are less frequent and usually not as intense.

Work organization – Are the right things being done?

It is not merely the skills and the experience of the requirements engineer that have an impact on the success of the project, it is also essential to select the right things to work on at the right time. I’ve already described the talents a requirements engineer needs for that in a former blog post.

Are the required artifacts delivered at the appropriate level of detail at the right time? Creating detailed documents without a prior agreement by both the business and technical side of things and with a planned development date in the remote future is a waste of time. Once the development phase eventually begins the information is most likely already outdated, and the team is forced to do the brainwork all over again. Time is spent much more efficiently if you create the right level of detail at the right time (just in time). This way the project team is in control of their time without doing work twice.

However, there is a fine line of good enough preparation and not doing your job. Not properly thinking through the goals and the requirements before and during the project can lead to nasty surprises toward the end of the project if the software does not meet the business requirements. In a situation like this the resulting management attention will consume a lot of time with status reports and escalation meetings on top of all the rework which has to be done.

Summary

The support of a requirements engineering or business analyst role is beneficial for IT projects. However, one role does not equate to one person. Depending on your setting you might require different types of RE-support,

  • Temporary assignment for creating a basic understanding of the current situation or a rough concept of what you need
  • Long-term support by temporarily assisting a Product Owner with RE know-how for specific tasks
  • Long-term assignment as a Product Owner substitute with responsibility for the full spectrum of RE and PO responsibility or supporting an operational system

Taking a closer look at your specific needs will help you utilize your RE-capacities in a more efficient way and support more projects with RE know-how. As an added bonus you can apply your best practice across multiple organizational units or projects. The broader knowledge of systems and people will also improve the solution design since a more thorough understanding of the overall system will have positive effects on the design of a specific system.

If the available RE staff are assigned more efficiently the company will also then be able to support more projects with the RE skill set. As a consequence, sourcing, staff planning or controlling may also have to rethink their approach. Working across multiple business units requires flexible controlling and a certain degree of trust in the self-managing skills of the requirements engineer to meet the demands from multiple clients. It also requires more flexibility from management to not primarily consider the requirements engineer as their employee but rather as a shared source of skill and knowledge.

Happy engineering!

Check out my website at http://www.requireminds.de/

Requireminds

René Busch is a freelance requirements engineer and supports customers with his expertise in requirements engineering. He offers RE workshops facilitation ad RE processes audits amongst other things. In almost ten years, he has collected extensive experience in various IT project in Germany and abroad.

EN Subscribe to our newsletter
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *