Since 1968, the year in which the NATO conference was held in Garmisch during which the term “Software Engineering” was coined, the various disciplines related to the different phases of the software life cycle have gradually specialized. They include Analysis & Design, Project Management and others. Among this others there is Measurement, as most recently implemented in the SWEBOK (Software Engineering Body of Knowledge) project, today the ISO/IEC 19759:2015 standard.
On the one hand these ‘specializations’ have generated the birth of many sector associations by deepening their respective knowledge. On the other hand they have not always favored the creation of ‘bridges’ between associations, leaving many ‘parallel’ domains of knowledge. Retracing the phases of a life cycle of any project (not necessarily software) from a ‘waterfall’ perspective, the Analysis & Design and Measurement/Estimate phases have many points of contact. Let’s see which…
GUFPI-ISMA: who we are and the collaboration with IIBA-Italy
GUFPI (the Function Point Italy User Group) was born in Rome in 1990 to introduce Function Point Analysis (FPA) in Italy. GUFPI spread the culture of software measurement by organizing events, webinars and original white papers. In 2001 it expanded its scope of intervention to the measurement of software tout court (not only FPA…). It became GUFPI-ISMA (Italia Function Point User Group – Italian Software Metrics Association). It started its own positioning and collaboration also outside the national borders with the major software measurement (IFPUG, COSMIC, NESMA, FISMA, UKSMA…) and benchmarking (ISBSG) associations.
In 2013 he then began a series of collaborations with a number of Italian associations including IIBA-Italy, PMI Italy Chapters, AICQ, itSMF Italia and others. For 10 years, our associations have been promoting each other. We hosted speakers from one association at each other’s events (as also in the last BAWI 2022). We created new contents of common interest. The ground for collaboration is therefore to make user requirements measurable and to improve the processes related to Business Analysis. This blog is a further collaboration tool, where experience from the world of Software Measurement and reflections on Business Analysis find a common space of expression.
The requirements iceberg and the ‘cone of uncertainty’
As Tom Demarco said, ‘You cannot control what you cannot measure‘, but taking a step back it is true that ‘you cannot measure what you cannot define‘. Finally with a last step back we can say that ‘you cannot define what you don ‘t know‘… So the problem (and the relative solution) to manage a good estimation process in a project lies in a correct elicitation and definition of user requirements. Starting from the definition of the actors (stakeholders) involved. And avoiding getting stuck in the requirements iceberg as indicated in Figure 1. This involves an increasingly reduced RE (relative error) as the ambiguous/non-granular and implicit requirements decrease, with a parallel reduction of the so-called ‘cone of uncertainty’.
How to classify requirements?
The “ABC Schema”
A taxonomy for classifying requirements, created in 2012, is the so-called ‘ABC schema‘. As indicated in the figure, it provides for the distinction of requirements into three types: A (functional product requirements – FUR: Functional User Requirements), B (non-functional product requirements – NFR: Non-Functional Requirements) , C (organisational/project requirements and constraints).
Each of the three streams uses appropriate units of measurement to determine the quantities (Q) which allow – through the respective levels of productivity (p) – to determine/refine the estimates relating to working times (T) – which can be expressed in Effort (E) and Duration (D) – and which in turn make it possible to determine the costs and economic considerations (C).
Function Points (FP) are the unit of measurement generally used in software projects for type A requirements (product FUR), while there are several possible methods and standards that can be considered for non-functional units of measurement (IFPUG SNAP and ISO/IEC 25010 for software product quality, ISO/IEC 25012 for data quality, …) to quantify type B requirements (product NFR).
Finally, for type C requirements there is currently no ‘standard’ unit of measurement, but a direct estimate per effort (dd/p) is generally made. Therefore, the scope of a project must consider all three areas and the sum of the effort and costs/payments. Simple and logical as saying… ABC!
The taxonomy of the BABOK v3 and the mapping with the ABC schema
The BABOK v3 proposes in section 2.3 a different classification scheme of the requirements. Figure 3 tries to create a mapping between the two models:
Starting to verify these correspondences in a double-faced way can help both communities with ideas for improvement starting from a different perspective from the one of origin… in short, unity is strength, as they say!
An application linked to Testing can be, for example, the one indicated in Figure 4. Here the second traceability matrix (Specifications vs Test Cases – TC) can benefit from the classification of requirements (in this case the ‘ABC’ one) to verify the levels of coverage in a test plan for continuous improvement starting from any thematic findings:
The “123 pattern”: a product is not a service (and vice versa…)
The classification of requirements, as precious in Measurement as in Business Analysis, however, must not be an end in itself. But it is to be placed in the context of the three main macro-phases of a service project (not exclusively product development).
The “123 Schema “, as indicated in Figure 5, in fact highlights (1) the development; (2) exercise; (3) the maintenance of the service (also through its products/outcomes). The figure also includes the three types of ABC requirements in order to indicate at any time which requirements are present (and the related professional figures) in order to make the appropriate estimates.
As can be seen, the Function Points (FP) – derived from user functional requirements (FUR), i.e. those of type A – are not present either in the supply/exercise phase, or in the corrective maintenance phase, since there is no no change in FUR at those points in time, unlike Type B/C requirements.
This allows a team to appropriately modulate workloads and time/cost estimates in each macro-time phase of a project. Not necessarily always and only reasoning on assumptions of ‘average’ values of productivity, costs and margins .
Roles vs Skills: UNI 11621-2 and 11621-6, points of contact, united towards the eCF!
‘Last but not least‘, the issue of skills is becoming increasingly important because the Agile/DevOps paradigm requires professional figures possibly in the shape of a “T”, i.e. “T-shaped“, as indicated in Figure 6, or one of its variants.
In the context of the so-called ‘unregulated professions‘, after the issue of the UNI 11621-2 standard (which includes Business Analysts), GUFPI-ISMA recently contributed to the creation of the UNI 11621-6 standard relating to the skills of a ‘measurement specialist‘.
This rule underlines the need to collapse the typical skills and knowledge of an analyst/measurer/statistician into a single professional figure, highlighting what our two associations can do together in the coming years. The figure of Business Analysis & Measurement specialist is born.
In particular, it will be possible to contribute together to the future evolutions of the eCF (European Competence Framework) and to the inclusion of composite profiles in the specifications and public and private calls for tenders, to the benefit of all the stakeholders involved.
Some conclusions…
Business Analysis (BA) and Measurement are complementary areas of knowledge and expertise. A measurer has to dimension a requirement. But the management of a requirement – without a dimension – has difficulty contributing to the time and cost estimation process towards a PM/PMO. And the classification of requirements is important to produce ever more correct planning and estimates .
The BABOK and the ABC scheme propose different but both valid and integrabile classifications. The objective is to seek an ever better coverage of the scope of the project, thus avoiding the so-called “scope creep”.
eCF requires new e-competences for the next few years. The UNI 11621-x standards at the Italian level represent the right starting point for pursuing this objective for public and private contracts.
And the collaboration between IIBA-Italy (Business Analysis) and GUFPI-ISMA (Measurement), could be a harbinger of excellent contributions.