The simplified requirements management

Requirements management is a rather complex topic in projects. In the technical literature it is often described in a very academic way, so that for many projects it is inappropriately complicated and therefore difficult to handle. Often the insufficient management of requirements is one of the main causes for project crises. The Standish Group’s CHAOS report speaks of “Lack of User Input”, “Incomplete Requirements & Specifications”, “Changing Requirements & Specifications”, “Unclear Objectives” and “Lack of Executive Support”.

I would like to explain to you a requirements management approach that works in every project; at least it works better than the omitted or completely inadequate requirements management, which unfortunately is still very common in many projects. The Simplified Requirements Management leads to an effective risk mitigation, because by applying the approach the probability and the size of a potential damage can be reduced significantly.

The insufficient management of requirements

Let’s just ask ourselves the following question: Why are requirements in projects often insufficiently managed? The typical cocktail of causes is all too human:

• Effort
  Requirements management means effort, sometimes a great deal of time and personnel effort and thus costs. This is where people like to “save money”, requirements are implemented quickly and without delay under the time and cost pressure of the project without first being thoroughly analysed and properly documented. One saves the work of analysis and documentation, often this is even done under the guise or even with abuse of the “agile procedures”, which by the way I appreciate very much if they are applied wisely. It goes without saying that this is a boomerang in terms of effort, which returns at the latest in the User Acceptance Test.
• Processes
  There are no fixed processes for requirements management in the company, or the existing processes are outdated or insufficient and are therefore bypassed or even ignored.
• Skills
  No one in the project team has the necessary knowledge and skills to adequately manage requirements of the project situation; there is a lack of training and experience or leadership.
• Tools
  There is a lack of useful tools such as RM databases; the use of Word, Excel and Sharepoint out of necessity quickly leads to frustration, sometimes to the point of chaos, and thus to the complete abandonment of requirements management, especially with many changes.
• Complexity
  The IT requirements that are documented are so complex or described in such a complicated and unillustrated way that the stakeholders on the customer side do not understand them and therefore do not deal with them.

Let us now put ourselves in a situation where all the unfortunate circumstances come together. The project is under time pressure, there are no binding processes, nobody really knows how to proceed and there is no RM database. What is the least you should do in such a situation? This is where the Simplified Requirements Management approach helps.

The rules in simplified requirements management

Simplified requirements anagement consists of a few rules that must be strictly adhered to:

1. Attributes for requirements are defined, mandatory and optional.
2. Each requirement is documented in a database using these attributes.
3. Process steps for requirements are defined and executed, mandatory and optional.
4. Each execution of a process step is documented in the database.

Ok, we have a problem: there is no database in our scenario! This is a problem you – I’m sorry – have to solve. Without RM database you are lost! You absolutely need a database that can map n:m relationships, also known as many-to-many relations; without this feature, you cannot manage requirements properly. With Excel this is difficult, with Access it is already better and with any SQL database it usually works great. So before you start to capture requirements in Word files or simple Excel sheets, make sure you have a database at hand. With the above rules, a simple data model for our database is now quickly formed in our minds, consisting of a few core entities for the database records.

The “requirement” entity

Before we start documenting requirements, we need to determine how the requirements are documented. The Business Analysis Body of Knowlege – BABOK – suggests the following attributes.

• Absolute reference: provides a unique identifier. The reference is not altered or reused if the requirement is moved, changed, or deleted.
• Author: provides the name of the person who needs to be consulted should the requirement later be found to be ambiguous, unclear, or in conflict.
• Complexity: indicates how difficult the requirement will be to implement.
• Ownership: indicates the individual or group that needs the requirement or will be the business owner after the solution is implemented.
• Priority: indicates relative importance of requirements. Priority can refer to the relative value of a requirement or to the sequence in which it will be implemented.
• Risks: identifies uncertain events that may impact requirements.
• Source: identifies the origin of the requirement. The source is often consulted if the requirement changes or if more information regarding the requirement or the need that drove the requirement has to be obtained.
• Stability: indicates the maturity of the requirement.
• Status: indicates the state of the requirement, whether it is proposed, accepted, verified, postponed, cancelled, or implemented.
• Urgency: indicates how soon the requirement is needed. It is usually only necessary to specify this

Whether these attributes are suitable or sufficient for your requirements in your project should be assessed together with your team and stakeholders. Of course, you may also define your own attributes, just make sure that it is clear in the project how requirements are documented. It is also possible to add new attributes to the “Requirement” entity at a later date.

The “task” entity

A task is simply a step in a requirements management process. Of course, you can also call a task action, step or process. The terminology used should only be unambiguous and understood within the company. A task, such as ” verify requirements” in this context is always executed for or with a requirement or group of requirements, i.e. the task changes the requirement, it takes the requirement a step further in its development. There is now an n:m relation between the entities requirement and task, i.e. a task can be applied to many requirements and a requirement can be handled with many tasks.

Requirement Task Relation in the Crowfoot Notation

The BABOK also provides a first list of attributes for a task:

• Purpose
• Description
• Inputs
• Elements
• Guidelines/Tools
• Techniques
• Stakeholders
• Outputs

Here, too, you should make a binding specification in your company as to which necessary and optional attributes a task is represented with. How many tasks you provide for in your company is your decision. In BABOK there are 30 tasks, ” verify requirements” is one of them. It is certainly a good starting point for a requirements management process, but certainly needs to be adapted to the concrete conditions in the company. Here too, it is important to determine which tasks are “mandatory” and which are “optional”.

Further aspects of requirements management

Traceability

There are different requirements, the Project Management Institute – PMI – and the International Institute of Business Analysis – IIBA – basically agree and categorise requirements into four to six different main groups, I will reduce this here to the most important ones:

• Business Requirements
• Stakeholder Requirements
• Solution Requirements
• Transition Requirements

These requirements are of course interrelated, i.e. solution requirements are the implementation, i.e. the “solution” for business or stakeholder requirements. Here, too, we have an n:m relationship, this time even between requirements. By the way, this is where Excel gets out, these relationships can no longer be mapped in Excel. Traceability here means the traceability of requirements, both starting from the business requirement to identify all relevant solution requirements, and starting from a solution requirement to find the relevant business requirements. Traceability is needed in many situations in requirements management, for planning, prioritisation, impact assessment in case of changes and many other use cases up to test management, where test cases are related to the requirements.

Requirements and Traceability, Source: BABOK, masVenta Business Analysis Curriculum

Requirements Lifecycle

The requirement attribute “Status” deserves special consideration. While most of us immediately think of a state machine when we hear the word status, the status of requirements is not a transitional status. It is best to compare RM status values with bit bars, i.e. a series of flags that are set or not set. For example, a requirement can have the status bits “verified ” and “validated ” simultaneously, which is not a transition status. Thus, requirements are developed in the RM process by executing one task after the other (incidentally, in an unspecified order) and thus setting the respective status bit until all necessary bits can be set, i.e. the requirement is “complete”. In concrete terms this could mean that the requirement is implemented, tested and running in production, depending on the definition of your RM process.

Conclusion

With the few rules of the Simplied Requirements Management approach, you can build a simple requirements management as a process in your company with the help of a simple database, the definition of a few core entities and a defined set of tasks. In this way you significantly reduce the risks in contrast to a lack of management. The Simplified Requirements Management approach describes the few core principles of requirements management that everyone involved with requirements should know. This approach is independent of the fact how “agile” a project and the requirements management in it is. Instead of requirement an entity can be called an epic or user story, the principles remain the same. In an agile project, the database then contains the product backlog, the tracking of the executed tasks is done in burn-down charts. In principle no difference.

Notes:

Under the direction of Mr. Wendt, masVenta Business GmbH organises an annual conference for business analysis and requirements engineering, the European Business Analysis Day, in short BA-DAY. In contrast to other conference formats in these fields, this event is consistently international in scope and offers many opportunities for networking with the international BA and RE community, in addition to presentations by excellent speakers from all over Europe, America and Canada.

Rainer Wendt has published two more articles in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.