4 useful practices in requirements definition

4 useful practices in requirements definition

Last week we told you how important it was to properly define requirements when developing software. A few months ago we were analysing standard best practices in this area and found the following useful tools:

V-Model

A quick Google search offers many variations of the V-Model for requirements definition, with any number of different levels or phases. In this model, the definition of requirements is split into three phases, with each subsequent phase going into more detail than the last:

1. Specification of general requirements: what is the end goal of the software being developed?
2. Specification of functional requirements: what does the software need to be able to do?
3. Specification of design requirements: for instance, what features should the user interface have, or what kind of database is needed for the software to function?

The idea behind splitting the specification into different phases is two-fold. Firstly, it focuses attention on each of the different aspects of software development, bringing the necessary detail to each. Secondly, it establishes the people involved at each level, and allows conversations to be carried out with the right people: there’s no point in talking about the design requirements with the sales team, and equally no reason to bother the technical team with questions about the overall business goals.

CATWOE analysis

The CATWOE analysis is part of the soft systems methodology, and focuses on identifying the key factors to the success of a project as a starting point for establishing development requirements. Specifically, CATWOE is a mnemonic representing the following six elements:C:Customers, those who will benefit from the software being developed.A:Actors, those who will play an active role when using the software.T:Transformation process, which refers to the changes the software will lead to within the organisation.W:Weltanschauung, which refers to the wider impacts implementing the software will have.O:Owner, which is about identifying and understanding the needs of the owner of the process the software is being designed for.E:Environmental constraints, which asks about the possible external factors that might impact on the success of the project.

BPMN diagram

BPMN diagrams are not specifically meant for requirements definition, but they are an interesting tool that can help establish a productive dialogue with clients. The aim of a BPMN diagram is to represent the business processes that the software must support. Activities are represented with round-cornered rectangles, events are represented with a circle (for instance, the start and end of the process, and waiting times), and what are known as “gateways”, marking a potential forking or merging of paths, are represented with a diamond shape. In a software context, these gateways represent points in the process which might need an exception to the normal workflow to be devised and programmed.

Key Performance Indicators (KPIs)

Again, although KPIS are not a tool specifically devised for requirements definition, they are essential for clearly establishing what business objectives the software being developed must achieve and how this will be measured. For example, one of Dropbox’s KPIs will be the bandwidth its servers can provide: there’s no point in Dropbox boasting an elegant and intuitive design, if the bandwidth tops out at 1kb/s.

These are the four best practices in this area that we thought were the most useful, along with the 3 laws of requirement definition: concision, clarity and precision. Drawing on our past and present projects to give it all context, elements of all them now form part of our internal procedures for requirements definition. And, true to style, we continually update and improve these procedures with each new experience. If you’re interested in finding out more, just ask!