SNAP is the acronym for "Software Non-functional Assessment Process," a measurement of the size of non-functional software. The SNAP sizing method complements ISO/IEC 20926:2009, which defines a method for the sizing of functional software. SNAP is a product of the International Function Point Users Group (IFPUG), and is sized using the “Software Non-functional Assessment Process (SNAP) Assessment Practices Manual” (APM) now in version 2.4. Reference “IEEE 2430-2019-IEEE Trial-Use Standard for Non-Functional Sizing Measurements,” published October 19, 2019 (). Also reference ISO standard “Software engineering — Trial use standard for software non-functional sizing measurements,” (https://www.iso.org/standard/81913.html), published October 2021. For more information about SNAP please visit YouTube and search for "IFPUG SNAP;" this will provide a series of videos overviewing the SNAP methodology.
A software application can provide two aspects of value to its users. In this context, the first aspect is "what" the software will do, specifically, "A subset of the user requirements. Requirements that describe what the software shall do, in terms of tasks and services." (ISO/IEC 14143-1 definition) This can be defined as its "functionality." One metric used to measure the size of one unit of this functional software is the “function point.” By using an ISO-standard functional sizing metric (FSM) such as that in the IFPUG “Function Point Counting Practices Manual,”[1] (FSM ISO/IEC 20926:2009),[2] a function point counting specialist can examine the software application’s functional user requirement portion and measure its functional size in units of function points.
For more detail on the function point metric, and other organizations’ functional software sizing metrics, see the bibliography, the Wikipedia article “function point,” and numerous references in the literature.
A software user requirement also may specify "how" the software will do it, specifically "A software requirement that describes not what the software will do but how the software will do it." (ISO/IEC/IEEE 24765:2010 definition) These types of software are defined by IFPUG as being “non-functional.” The corresponding software size is measured by SNAP. The IFPUG APM[3] details how to size the application's non-functional software. The non-functional aspects are defined and classified in ISO/IEC 25010:2011, “Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models”.[4]
The functional size of the software, together with the non-functional size of the software, should be used for measuring the total software size of software projects. The two sizes should be used to measure the performance of the software project, setting benchmarks, and estimating the cost and duration of software projects.
The Non-functional User Requirement Sizing Method
Similar to function point sizing, one unit of non-functionality is the “SNAP point.” The size of the software derived by quantifying the non-functional portion of an application can be measured by using the procedure in the APM. Similar to function points, by using the IFPUG APM, a SNAP point counting specialist can examine the software application and measure the size of its non-functionality in units of SNAP points. Also like function points, the number of SNAP points in an application correlates with the work effort to develop the non-functional software portion of that application. The original research detailing this correlation is in CrossTalk The Journal of Defense Software Engineering, as the paper “A New Software Metric to Complement Function Points The Software Non-functional Assessment Process (SNAP).”[5]
Each aspect of software (the functional and the non-functional) requires work effort to develop, which is proportional to their sizes. Software development organizations can use their correlations between function points and their work effort, and between SNAP points and their work effort, to help forecast their software development costs and schedules and to audit projects to determine how well funding was spent and schedules were managed
SNAP recognizes four categories and 14 subcategories of non-functional user requirements. These are in the below table from the APM.
1. Data Operations
1.1.Data Entry Validations 1.2.Logical and Mathematical Operations 1.3.Data Formatting 1.4.Internal Data Movements 1.5.Delivering Added Value to Users by Data Configuration
4.1.Component Based Software 4.2.Multiple Input / Output interfaces
For example, software development to change the field sizes for data in a data table does not represent changes in functionality according to the IFPUG methods. However, this development requires work effort. Data Formatting is considered non-functional, and is countable under SNAP subcategory 1.3.
Help Methods (subcategory 2.2) are usually considered non-functional. When compared to the function point process, which requires data to cross an application’s boundary and maintain an internal logical file, the Help data may be coded to reside internally as part of the application development and be accessed upon command from the user. This access can be anything from bubble help over an icon on a screen, to access of part of an internally stored application operations manual. Data is not being processed per se, so Help is usually considered non-functional.
Function points and SNAP points measure two different aspects of software sizing, and therefore are not added together. For example, an application of 500 function points and 300 SNAP points cannot be considered to be the size 800 of some metric; function points and SNAP points are intended to be orthogonal. A good reference for further detailed information regarding the relationship between functionality and non-functionality is in the document “Glossary of Terms for Non-Functional Requirements and Project Requirements Used in Software Project Performance Measurement, Benchmarking and Estimating”.[6]
Benefits
SNAP provides users and software development teams many benefits additional to the sole use of function points. Below are six of many examples.
Measuring the size of the non-functional software improves the work effort estimation of software development based on functional user requirement sizing alone.
Measures the size of algorithms, using subcategory 1.2.
This improved work effort estimation should also lead to better estimates of scheduling, resource allocation, and risks.
Including the SNAP size improves the work effort estimation to maintain the software after it is deployed.
The productivity rates of project teams can be better determined because more factors are included in their measured work output.
Including both functional and non-functional work products better demonstrates value delivered to the user.
Further, some software development efforts might be measured as having zero function points. For example, an Agile software maintenance sprint might be required only to change the length of data fields in data tables. This would be measured to have zero function points because it is non-functional; however, that work would be accountable in SNAP. SNAP at least partly solves the “0 function point” problem.
Areas for future research
The SNAP beta test in 2012 was conducted using 48 applications. More research will hopefully improve the calibration of the subcategory weighting factors to yield an even stronger statistical correlation. It is recommended that future research results be submitted to IFPUG’s Non-functional Sizing Standards Committee (NFSSC) for review.
Buglione, Luigi, and Santillo, Luca, “NFR: L”Altra Meta Della Mela,” Newlsetter, Gruppo Utenti Function Point Italia Italian Software Metrics Association, www.gufpi-isma.org, December 2011.
International Function Point Users Group, “How Function Points and SNAP Work Together,” MetricViews, www.ifpug.org, Princeton Junction, NJ, 08550, USA, August 2015.
Jones, Capers, “A Guide to Selecting Software Measures and Metrics,” CRC Press, Boca Rotan, FL, 33487, USA, 2017.
Jones, Capers, “Quantifying Software Global and Industry Perspectives,” CRC Press, Boca Rotan, FL, 33487, USA 2018.
Related Research Articles
Software testing is the act of checking whether software satisfies expectations.
Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.
Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program's source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced.
In the context of software engineering, software quality refers to two related but distinct notions:
ISO/IEC 9126Software engineering — Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011.
NFR need a framework for compaction. The analysis begins with softgoals that represent NFR which stakeholders agree upon. Softgoals are goals that are hard to express, but tend to be global qualities of a software system. These could be usability, performance, security and flexibility in a given system. If the team starts collecting them it often finds a great many of them. In order to reduce the number to a manageable quantity, structuring is a valuable approach. There are several frameworks available that are useful as structure.
In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.
IEC 61508 is an international standard published by the International Electrotechnical Commission (IEC) consisting of methods on how to apply, design, deploy and maintain automatic protection systems called safety-related systems. It is titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems.
The function point is a "unit of measurement" to express the amount of business functionality an information system provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost of a single unit is calculated from past projects.
The International Function Point Users Group (IFPUG) is a US-based organization with worldwide chapters of Function point analysis metric software users. It is a non-profit, member-governed organization founded in 1986.
In software development, functional testing is a form of software system testing that verifies whether software matches its design.
Software sizing or software size estimation is an activity in software engineering that is used to determine or estimate the size of a software application or component in order to be able to implement other software project management activities. Size is an inherent characteristic of a piece of software just like weight is an inherent characteristic of a tangible material.
Software measurement is a quantified attribute of a characteristic of a software product or the software process. It is a discipline within software engineering. The process of software measurement is defined and governed by ISO Standard ISO 15939.
In software engineering, a software development process or software development life cycle is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.
Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely systematic errors, hardware failures and operational/environmental stress.
ISO 26262, titled "Road vehicles – Functional safety", is an international standard for functional safety of electrical and/or electronic systems that are installed in serial production road vehicles, defined by the International Organization for Standardization (ISO) in 2011, and revised in 2018.
The MK II Method is one of the software sizing methods in functional point group of measurements. This is a method for analysis and measurement of information processing applications based on end user functional view of the system. The MK II Method is one of five currently recognized ISO standards for Functionally sizing software.
Parasoft C/C++test is an integrated set of tools for testing C and C++ source code that software developers use to analyze, test, find defects, and measure the quality and security of their applications. It supports software development practices that are part of development testing, including static code analysis, dynamic code analysis, unit test case generation and execution, code coverage analysis, regression testing, runtime error detection, requirements traceability, and code review. It's a commercial tool that supports operation on Linux, Windows, and Solaris platforms as well as support for on-target embedded testing and cross compilers.
COSMIC functional size measurement is a method to measure a standard functional size of a piece of software. COSMIC is an acronym of COmmon Software Measurement International Consortium, a voluntary organization that has developed the method and is still expanding its use to more software domains.
References
↑ IFPUG, “Function Point Counting Practices Manual” v. 4.3, Princeton Junction, NJ, 08550 USA 2009.
↑ IFPUG, “Software Non-functional Assessment Process Assessment Practices Manual” v. 2.4, Princeton Junction, NJ, 08550 USA 2017.
↑ ISO/IEC 25010:2011, Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models.
↑ CrossTalk The Journal of Defense Software Engineering, “A New Software Metric to Compliment Function Points The Software Non-functional Assessment Process,” Ogden ALC/TISE, Hill Air Force Base, Utah, July-August 2013.
↑ COSMIC, IFPUG, “Glossary of Terms for Non-Functional Requirements and Project Requirements Used in Software Project Performance Measurement, Benchmarking and Estimating,” v. 1.0, September 2015.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
