I saw this image for the first time many years ago, I would no longer know where it came from, it is stored on my computer and is the avatar I use when I log in to my workstation.
For me it expresses the closest mankind can imagine in understanding a legendary context, archaeologically placed around the second millennium BC. and referring to the ziggurat Etemenanki: the Tower in Balilonia. The pictorial representation of the Torre di Balele designed by Pieter Bruegel in 1563 is famous (source wikipedia, “a detail”).
Although a few thousand years have passed, the context I find it very current.
There is a discipline that tries to bring together “how the customer explained it” and “what the customer really needed”: Business Analysis (BA).
The role of Business Analysis to achieve a goal
The BA contains the set of tasks and techniques used to work, in agreement with Stakeholders. This is done in order to understand the structure, policies and operations of an Organization and to recommend solutions that allow that Organization to achieve a goal. You start with requirement to achieve a purpose.
A requirement is defined in the literature in many ways, here are some of them.
- Condition or ability necessary for a stakeholder to solve a problem or achieve an objective.
- Condition or ability that must be met or possessed by a solution or Component to satisfy a contract, standard, specification or other formally indicated in a document.
My favorite is: a high-level abstract description that indicates something a system must do or a constraint that must be observed.
From this it is understood that there is not a single type of requirement since it is in relation to the context in which it operates.
In the first instance, it is necessary to understand what to collect.
Mr. McConnell [graduated with a bachelor’s degree in philosophy (wonderful), minoring in computer science] says: The most difficult part of the requirements development activity of helping users figures out what they want.
In my opinion, elicitation is the heart of the BA, but I like to point out that soliciting is not collecting.
Requirements examination to achieve a purpose
Another fundamental aspect is the examination of all the right and real requirements.
Below I represent the linear path, as indicated by the approach described in the Babok v3 guide. It reformulates the principles of the previous version (Babok v2) which unifies requirements and designs by facilitating the cycle of analysis.
Once analyzed, a requirement must observe multiple characteristics, and all the requirements, absolutely everyone, must match the needs.
I too love to draw mind maps with extremely flexible classifications and groupings that allow me to “see” what is being built. However, I always maintain a link between the collected requirement, its analysis and subsequent specification.
Requirement is key to achieve a purpose, so what is the best way to formalize a requirement?
IREB defines it as boilerPlate to textually formalize a requirement when building an information system.
It aims to reduce the ambiguities and inconsistencies that arise when applying the techniques envisaged in the elicitation and requirements analysis areas (Babok v2).
The greatest advantage in my opinion is to facilitate the interaction between the business analyst and the stakeholders.
I am curious to know statistics on how widespread this practice is and what main difficulties it encounters.