Share This Post

Don’t write requirements, model them

While helping a client improve their requirements gathering practices, our team had the opportunity to communicate the details and impact of our work at the end of the project. As we stood back and surveyed the many activities that had taken place, we found that the vast majority of project teams we worked with were following a process, but that process lacked focus on the pre-requirements work that forms the basis for successful projects.

Stated most generally, rushing through the early stages of elicitation limits the depth of understanding that can be created between business stakeholders, who own the concept and vision for the product, and IT stakeholders, who own the execution of the project. In our experience, the best and most efficient way to encourage a collaboration between these two groups is through enhanced elicitation and collaborative requirements creation.

Categories of Models

Typically, the time spent working with stakeholders, modeling features from an Objectives, People, Systems, and Data (OPSD) perspective constitutes a massive share (often up to 45%) of our total activity, but also has the greatest impact when it comes time put pen to paper and capture Business, User, and Functional requirements (or in our case, epic stories and user stories supported by acceptance criteria).

But requirements alone aren’t enough.  The real key to this approach lies in the use of models and bidirectional traceability to create additional context around our requirements. Initially, we create tent-pole models to define the project’s scope, and work inward, generating models that cover each of the OPSD perspectives on a project. Finally, with all of these visual artifacts built and validated collaboratively by both business and IT users, we build traceability links between our artifacts, ensuring that we have a complete picture of both the current and future state of a release.

Objective Chain Model

With all of these artifacts assembled into a framework, writing excellent requirements becomes easy. Project teams working with a limited number of interfaces and existing system can use this process to catch and fill missing requirements with relative ease; but with every added system and interface comes added complexity that challenges a manual, excel-based analysis system. A requirements management tool becomes the obvious solution, especially in cases where Project Owners need to connect a large number of dispersed users and their related requirements artifacts, and identify any breaks in the traceability chain.

Whether using a tool or a simple spreadsheet, the investment of time and resources into improving elicitation and analysis, the business is able to deliver clearer, more detailed information to IT, resulting in quicker releases of the right product.

We have an entire suite of visual models templates available for download here.

Don’t write requirements, model them

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage