Why RDM?

Requirements Definition and Management (RDM)

We at Visure, the requirements expert company, want to share our vision for Requirements Definition and Management (Requirements Definition and Management, RDM).

How can we explain the high incidence of failures in projects? Why do so many projects fall victim to delays, budget overruns and so many quality problems? Are Requirements Engineering activities taken into account during project planning? Requirements Definition and Management has a critical effect on the costs and quality of the software that is being developed.

But what do we understand by Requirements Definition and Management and Requirements Engineering? We can define Requirements Definition and Management as a global set of different activities, where requirements specification (what is known as “writing requirements”) and subsequent management thereof are not sufficient, so that other activities are required such as requirements Capture, Analysis, Verification and Validation, without forgetting to carry out adequate Change Configuration and Control Management, in addition to the traceability of the requirements to the rest of the project elements.

There are basic aspects that must be taken into consideration for adequate Requirements Definition and Management, some of which include:

• The Requirements Definition and Management process:

It is important to differentiate between having a process and using a process. A defined process does not guarantee use thereof in itself, due to which it is vital to implement control mechanisms that will objectively inform us of the process use and the results obtained from said use. To this end, we must use metrics and dashboards, as well as different control mechanism such as audits or evaluations. 

• Lifecycle:

The lifecycle is directly related to Requirements Definition and Management; we can use different methodologies: agile, cascading, object-oriented, etc. but always taking Requirements Engineering into account.
The lifecycle must be sufficiently flexible to allow the “automation” of certain activities in order to guarantee effectiveness and achieve maximum efficiency, as manual work, apart from increasing costs to unfeasible limits, exponentially increases the possibility of incorporating errors.
It is fundamental that Requirements Definition and identification of test cases be carried out in an integrated manner. 

• Models:

There are different models and standards on the market that help organizations to structure their development processes, particularly those related to Requirements Engineering. Internationally recognized models such as CMMI or SPICE are an example of these.
The problem with these models is their generality; they provide Requirements Engineering-related practices but do not go into detail and their use does not guarantee adequate Requirements Definition and Management.
The company should be aware of the degree of effectiveness and efficiency of their Requirements Engineering process, its strong points (to maintain and increase them) and what is failing in order to improve it and obtain future benefits. Visure has a model for determining the maturity of the requirements process, The Capability Requirements Model, RCM. Link to the RCM web page. 

• Tools:

Practically all Requirements Definition and Management-related activities can be carried out manually, but thought must be given to the effectiveness and efficiency they provide.
Implementing Change Management or maintaining Traceability are not very complex activities but do require automation and use of tools.
Possible integrations with different tools: modeling, testing, etc. should be taken into account in order to be able to reuse requirements and other elements, as well as using dashboards and reports that provide objective data.
 

• Stakeholders:

Requirements Definition and Management is not exclusive to analysts, but rather involves different profiles, including technical personnel, business experts, users and, in general, all the stakeholders involved in the system.
It is fundamental that all the roles involved have the necessary skills to fulfill these: good language skills, confidence, collaboration, assertiveness, empathy, etc., as well as the required infrastructure (tools, templates, standards, models, etc.) Include a link to the IRQA web page. Strengthening these skills in the different roles is fundamental. Link to the Training page. 

• Communication:

Communication and understanding between the different departments and areas of the company, such as business, users and technology, are key elements for guaranteeing project success and are vital for Requirements Definition and Management. However, they are also highly susceptible to incorporating comprehension errors, due to which global solutions that will minimize these errors and guarantee the comprehension of the requirements throughout their lifecycle is essential.
Requirements are not only text; other models and prototypes may also be required to ensure an adequate level of communication between all the parties involved. 

• Traceability:

Traceability is not new or excessively complicated. All analysts “mentally trace requirements” when they write requirements specifications but if done manually it is a very tedious task which is often abandoned halfway through the project. Use of a requirements tool that expedites management thereof is essential in order to guarantee traceability.

Famous quotes

• “If you do not have time to do it properly the first time round, you will need the time to do it twice”, Colin Hood.
• "He who runs faster does not arrive earlier, but rather he who knows where he is going", Seneca.
• “If one does not know to which port is sailing, no wind is favorable”, Seneca.
• “If you don’t know where you’re going, you probably won’t get there“, Forrest Gump.
• “It isn’t that they can’t see the solution. It’s that they can’t see the problem”, G.K. Chesterton.
• “Walking on water and developing software from a specification are easy if both are frozen”, Howard V. Berard.
• “Investing in putting bad requirements into management tools is a lot like rearranging the deck chairs on the Titanic”, Ivy Hooks.
• ”The purpose of war is not the battle but rather the victory" or: The purpose of analysis is not modeling but rather comprehension", Sun Tzu, The Art of War, ca. 500 BC.
• “When a man speaks he does so because he believes that he can say what he thinks. However, this is illusory. Language is limited. He says, more or less, part of what he thinks and raises an impassable wall to the transfusion of the rest (……). Docile before the deeply-rooted prejudice that it is through talking that people understand each other, we speak and listen in such good faith that we end up misunderstanding much more than if we tried to guess each other’s thoughts. Moreover: as our thoughts are ascribed to language to a large degree…, it so happens that thinking is talking to oneself and, consequently, misunderstanding oneself and running the risk of getting confused”, Ortega y Gasset.