SNAP is the acronym for "Software Non-functional Assessment Process," a measurement of the size of the software derived by quantifying the non-functional user requirements for the software. The SNAP sizing method complements ISO/IEC 20926:2009, which defines a method for the sizing of functional software user requirements. 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 (https://standards.ieee.org/standard/2430-2019.html). 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.

Introduction

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 functionality 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.” Their size is measured by SNAP. The IFPUG APM[3] details how to size the non-functional user requirement aspects of software applications. 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 user requirements, together with the non-functional size of the software user requirements, should be used for measuring the user requirement 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 user requirements for the software 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-functional user requirement portion 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 user requirement 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 software user requirement portion (the functional and the non-functional) of the software project 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
2. Interface Design
2.1.      User Interfaces
2.2.      Help Methods 
2.3.      Multiple Input Methods 
2.4.      Multiple Output Formats
3. Technical Environment
3.1.      Multiple Platform 
3.2.      Database Technology 
3.3.      Batch Processes
4. Architecture
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 software derived by quantifying the non-functional user requirements for the 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.

See also

Bibliography

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.

References

  1. ↑ IFPUG, “Function Point Counting Practices Manual” v. 4.3, Princeton Junction, NJ, 08550 USA 2009.
  2. ↑ International Organization for Standardization, ISO/IEC 20926:2009, https://www.iso.org/standard/51717.html, Geneva, Switzerland, 2009.
  3. ↑ IFPUG, “Software Non-functional Assessment Process Assessment Practices Manual” v. 2.4, Princeton Junction, NJ, 08550 USA 2017.
  4. ↑ ISO/IEC 25010:2011, Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models.
  5. ↑ 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.
  6. ↑ 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 article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.