Last week I was proud to teach the first preparation course for the CBAP certification after the change of the certification model carried out by the IIBA (New CBAP available).
One of the issues that generated the greatest issues on the course was the BABOK v3 Guide separating the concepts of requirements and design. The BABOK Guide itself insists that “the distinction between requirements and designs is not always clear” and that depending on the type of project carried out, the responsibility of the business analyst in design is greater or less.
The BABOK Guide defines requirement as “a usable representation of a need. The requirements are focused on the understanding of what type of value could be delivered if a requirement is fulfilled“. In other words, requirements are the link with the business need and develop from the highest level (business objectives) with a greater level of detail as greater knowledge of the solution and the expected value is acquired. Depending on the level of detail and the focus of the requirements, there are different types of requirements: business, stakeholder, solution (functional and non-functional), and transition. However, regardless of the level of detail and the way of representing them, the requirements are focused on the value provided to the business.
Design is defined as “a usable representation of a solution. Designs are based on the understanding of how value could be created by a solution if it is constructed“. That is, design serves to shape requirements in a solution which may be implementable. The design therefore focuses on how the system will be constructed, not how it will work. It is similar to the difference between a plan created by an architect which shows how the building will be in terms of layout, rooms, etc. (requirements) and the engineer’s building plans which show how the building will be built (design).
It is common in IT projects to make the distinction between functional and non-functional solution requirements (which describe the characteristics and functionalities that the solution must possess), and the technical design (which describes how it will be implemented technically, including the physical design of databases, the structure of code components, etc.). Normally, in this type of project the analyst’s work is limited to the level of performance expected of the solution, and architects or technical experts define the technical design.
In agile projects, it is common for the development in the level of detail of the requirements to be made through the deconstruction of User stories and designs, in the form of prototypes and diagrams, allowing understanding and approval from business stakeholders and technicians on how to implement the solution.
However, the definition given in the BABOK Guide is broader: from initial business requirements, a design (for example, in the form of process workflow or a mockup of a user interface) may allow the identification or discovery of new requirements for the solution, which in turn lead to a design oriented toward technical components. That is, the design allows an advance in the discovery of requirements at a greater level of detail, while orienting and allowing the implementation of the solution.
Ultimately, the only thing that matters is that the implementation responds to the design and fulfils requirements. From the analyst’s point of view, we must ensure that the solution implemented provides the expected value to the client and resolves their initial need, and we must therefore “use” both requirements and designs.