The COSMIC Functional Size Measurement Method Version 4.1 Guideline on Non-Functional & Project Requirements How to consider non-functional and project requirements in software project performance measurement, benchmarking and estimating Version 1. November 2015 Version control Date Reviewer(s) Modifications / Additions March 2014 v0.1 followed by 15 iterations November See Acknowledgements First version 1. All Rights Reserved. The Common Software Measurement International Consortium (COSMIC).
Permission to copy all or part of this material is granted provided that the copies are not made or distributed for commercial advantage and that the title of the publication, its version number, and its date are cited and notice is given that copying is by permission of the Common Software Measurement International Consortium (COSMIC). To copy otherwise requires specific permission. Acknowledgements Authors and reviewers who have contributed to the development of v1.0 (alphabetical order) Alain Abran, Diana Baklizky Carol Buttle École de Technologie Supérieure, TI Metricas Safety and Security Engineering Université du Québec Council Brazil Canada United Kingdom Jean-Marc Desharnais Peter Fagg Cigdem Gencel École de Technologie Supérieure, Pentad Ltd DEISER Université du Québec United Kingdom Spain Canada Barbara Kitchenham, Arlan Lesterhuis Roberto Meli Keele University Data Processing Organization United Kingdom The Netherlands Italy Dylan Ren Luca Santillo Hassan Soubra Measures Agile Metrics Ecole Supérieure des Techniques China Italy Aéronautiques et de Construction Automobile France Charles Symons* Frank Vogelezang Chris Woodward Ordina CW Associates United Kingdom Netherlands United Kingdom Steve Woodward Cloud Perspective United States * Author of this guideline N. In addition to the Reviewers listed above, the definitions and classification scheme of Chapters 2 and 3, and the Glossary of Chapter 7 were developed jointly with members of the IFPUG ‘SNAP’ (Software Non-Functional Assessment Process) team under the leadership of Talmon Ben-Cnaan.
Foreword The COSMIC method aims to measure a ‘functional size’ of software based on its Functional User Requirements (FUR). In simple terms these specify ‘what’ a software product must do. The main uses of COSMIC-measured ‘functional sizes’ are in: measuring and comparing performance across projects of similar characteristics, e. using ‘productivity’ = (software functional size)/(project effort) estimating effort for projects, e.
from project effort = (new software estimated functional size) / (productivity from previous similar projects) This apparently simple process may be useful in practice because the ‘functional sizes’ are usually by far the largest driver of effort of software development projects. However, the success of this simple process depends heavily on what is meant by ‘similar’. Clearly many other factors than just the size of the functional requirements can affect project performance and may need to be taken into account in order to ensure fair, or ‘like-for-like’, comparisons. These same other factors may arise when estimating the project effort to develop some new software.
Examples of such ‘other factors’ are: varying ease-of-use or system response time requirements (system quality factors); varying numbers of users that the system must serve (environmental factors) varying requirements for the technology to be used or for the technical architecture (technical factors); varying skill-levels of the project teams or project constraints such as schedule compression factors (project factors). The Guideline begins by referring to these various system quality, environmental and technical requirements and constraints as ‘non-functional requirements’, abbreviated as ‘NFR’, and ‘project requirements and constraints’ abbreviated as ‘PRC’. In the late 1970’s when functional size measurement was first invented, few NFR were recognized and they did not vary much for all the projects within a given company, or even within the same domain e. of business applications.
The first methods of functional sizing attempted to account for a few NFR by an adjustment to the functional size. For example, Albrecht’s ‘Value Adjustment Factor’ for FPA recognized 10 factors, later increased to 14 factors by IFPUG. Since then, many more types of requirements are recognized as non-functional. With the enormous varieties of technology and software, taking them into account in the activities of project performance measurement, benchmarking and estimating can be much more difficult.
The purposes of this Guideline are to help understand and define the concepts of NFR and PRC; to propose a standard Glossary of terms and classification system for NFR and PRC; to provide practical guidance to users of the COSMIC FSM method on how to deal with NFR and PRC, as well as FUR, when making software project performance measurement comparisons, when developing benchmarks, and when estimating for new projects. The focus of the Guideline is on the NFR for the software deliverables of a project and on the PRC. (A project may also have to deliver other related products such as the hardware on which the software executes, business processes and training for human users of the software, and such-like, but these are only considered in passing.) The Guideline is structured as follows. Chapter 1 introduces the need for a coherent terminology and for methods of measuring or recording FUR, NFR and PRC consistently across the activities of software system project performance measurement, benchmarking and estimating, and starts to discuss how FUR, NFR and PRC affect measured software size and project effort.
Chapter 2 introduces a coherent set of definitions of all types of requirements, in a hierarchical structure. Chapter 3 introduces a classification system for NFR and PRC and gives the criteria for deciding which NFR and PRC terms were included in the Glossary. The classification system should also help understanding and make it easier to search for a particular NFR or PRC term. The classification and lists of NFR and PRC terms should be valuable as a checklist when defining requirements for a new software project.
Chapter 4 aims to give practical advice on how to deal with NFR and PRC in recording project data, comparing project performance, establishing internal benchmarks and estimating for new projects. Chapter 5 gives examples of quality requirements for a software system or product that initially appear as non-functional, but that evolve as a project progresses to requirements for software functionality. Most such functionality can be measured by the standard COSMIC method. Chapter 6 (to be written mostly in a later release) introduces standard ways of recording and measuring each of the NFR and PRC terms.
The Glossary of Chapter 7 lists NFR and PRC terms and their definitions, selected using the criteria of Chapter 3. The reader is assumed to have a general understanding of functional size measurement and of the COSMIC method. Much information about COSMIC and all documentation on the COSMIC method is available for free download from www. The COSMIC Measurement Practices Committee.
Table of Contents 1INTRODUCTION AND TERMINOLOGY.1 The need for coherent and consistent data across four activities.2 Towards a coherent terminology.1 The relationship between ‘requirements’ and ‘constraints’.2 What do requirements apply to?.3 NFR often evolve into FUR as a project progresses.3 Current practices in dealing with NFR in a system development project.4 Summary and conclusions from this chapter.7 2DEFINITIONS OF THE VARIOUS TYPES OF REQUIREMENTS.1 Functional User Requirements (FUR).2 Non-Functional Requirements (NFR).3 Project Requirements and Constraints (PRC).4 Summary model of requirements for a software systems project.10 3SELECTION AND CLASSIFICATION OF NFR AND PRC TERMS.1 Selection of NFR terms.2 System Environment Requirements.2 Selection of terms for Project Requirements and Constraints.15 4DEALING WITH NFR AND PRC FOR PROJECTS WITHIN AN ORGANIZATION.1 Commonality of NFR and PRC across an organization.2 Typical NFR and PRC to be recorded for business application projects.3 Typical NFR and PRC to be recorded for real-time embedded software projects.4 Establishing internal benchmarks.5 Dealing with NFR and PRC in software project estimating.19 5EXAMPLES OF FUNCTIONAL SIZE MEASUREMENT OF NFR.1 Measuring the FUR of application software arising from Quality NFR.2 A simple security NFR.4 NFR for a mobile e-mail system.26 6MEASUREMENT OF NFR.1 Sizing NFR collectively.2 Recording and measuring individual NFR and PRC.3 ISO/IEC standards for measuring individual Quality NFR.28 7GLOSSARY OF NFR AND PRC TERMS.1 Sources of ISO standard and other definitions.2 Glossary of Non-Functional Requirement terms.3 Glossary of Project Requirement and Constraint terms.4 Terms that have been excluded from the Glossary.45 APPENDIX: COSMIC CHANGE REQUEST AND COMMENT PROCEDURE.48 Acronyms The following acronyms are used in this Glossary CMMI® Capability Maturity Model Integration COBIT Control Objectives for Information and Related Technology, http://www.org/cobit/pages/default.aspx COSMIC Common Software Measurement International Consortium FSM Functional Size Measurement FUR Functional User Requirements IEEE Institute of Electrical and Electronics Engineers IEC International Electrotechnical Commission IFPUG International Function Point Users Group ISBSG International Software Benchmarking Standards Group ISO International Organization for Standardization NFR Non-Functional Requirements PMI® Project Management Institute PRC Project Requirements and Constraints PRINCE2 PRojects IN a Controlled Environment, Version 2 ROI Return on Investment SPICE Software Process Improvement and Capability Determination SQuaRE System and software product Quality Requirements and Evaluation 1 INTRODUCTION AND TERMINOLOGY The purpose of this Guideline is to establish common understanding and terminology across the activities of software sizing, software project performance measurement, benchmarking and software project estimating. The common subject linking these four activities are projects that develop or enhance software-intensive ‘systems’ (comprising software, hardware, data and maybe other deliverables) or just software products. For simplicity, when we do not need to be more precise, we will refer to all of these as ‘software system projects’ and their output as ‘software systems or software products’ (shortened to ’software system/product’ where convenient).1 The need for coherent and consistent data across four activities Figure 1.1 shows the dependencies across the four activities of recording and measuring requirements for a software system project, deriving project performance measures, using these to develop project benchmarks and estimating for a new project based on its requirements and comparable benchmark data from previous projects (broad arrows indicate dependency of activities). Recording & measuring software system project requirements Project Measuring Project data & benchmark project estimating repository performance Benchmarking Figure 1.1 - Inter-relationships of four activities that require coherent and consistent data and terminology COSMIC Guideline on Non-functional & Project Requirements, v.
1 All rights reserved. COSMIC We need coherent terminology to be used consistently across these four activities because typically: measures of the size of software system/product requirements are used with project effort data to produce project performance measures; these size and effort data are recorded together with the other characteristics of the project and of the software system/product that are needed to ensure like-for-like performance comparisons in a central project data repository; project performance measures are used to derive benchmark data for projects which are also classified according to their most significant project and software system/product characteristics; when an estimate of effort is needed for a new project, the software size is measured or estimated from its requirements and is combined with benchmark data for projects that had similar characteristics to produce the new project effort estimate, To fully understand these four activities, we must first recognize that a software system project has to consider three types of requirements, which affect the software size and the project effort in different ways: Functional User Requirements (FUR) may be roughly defined as ‘what the software must do’. They clearly affect the software size, which in turn affects project effort. Non-Functional Requirements (NFR) which are sometimes defined as ‘how the software must do it’.
Whether or not NFR affect software size is not immediately clear; they certainly affect project effort. Project Requirements and Constraints (PRC). These clearly affect project effort directly but do not affect software size. As regards measurements, in practice the only measures of software size that are used consistently across these four activities are either counts of Source Lines of Code (SLOC) or measurements of the FUR by a ‘Functional Size Measurement’ (FSM) method such as the ISO standard COSMIC method.
SLOC size measures have an advantage that they measure a software size that is the result of meeting all the FUR and NFR, but they have so many disadvantages we will not consider them further. Conventionally, FSM Methods do not now measure NFR. (Past attempts to do so, e.
