SNAP Points

Key takeaways

SNAP Points belongs to computer science; place it in that map before memorising details.
Learn the definition first, then one example that makes the definition concrete.
Connect SNAP Points to a quantity you can measure, compute or draw — that is where exam questions come from.
Reproduce the core statement of SNAP Points from memory before moving on to harder problems.

Reference excerpt

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 ([1]). 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. More information about SNAP can be found by going to YouTube and searching for "IFPUG SNAP;" which 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 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,” (FSM ISO/IEC 20926:2009), 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 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”. 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).” 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

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”.

… excerpt ends here. Continue reading the full article.

Worked examples

Example 1 — a first encounter with SNAP Points

Start with the simplest possible case. Write down what SNAP Points claims or describes in one sentence, then invent the smallest concrete situation in which that sentence is true. In computer science, the smallest case is usually a single object, a single equation or a single measurement. Check that every symbol or term in your sentence has a meaning in that case.

Example 2 — changing one variable

Take the situation from Example 1 and change exactly one quantity: double it, halve it, or set it to zero. Predict what should happen to SNAP Points before you calculate. Comparing your prediction with the result is the fastest way to find out whether you understand the idea or only the words.

Example 3 — an exam-style question

Typical questions about SNAP Points ask you to (a) state it precisely, (b) apply it to given data, and (c) explain a limitation. Practise writing all three answers in under five minutes; the third part is what separates a full-mark answer from an average one.

Applications of SNAP Points

In research: SNAP Points appears in computer science research whenever the underlying quantities have to be modelled precisely. Papers usually cite it as a starting assumption and then explore where it breaks down.
In technology and industry: Engineering practice reuses SNAP Points in design rules, simulations and safety margins. Knowing the idea lets you read a specification sheet and understand why the numbers look the way they do.
In the classroom: SNAP Points is common in secondary-school and first-year university syllabi. It links to neighbouring topics Software metrics, so understanding it makes those chapters shorter.
In everyday life: Look for SNAP Points outside the textbook — in sport, cooking, traffic, electronics or the sky above you. An example you found yourself is remembered far longer than one you were given.

How to study SNAP Points in 20 minutes

Read the reference excerpt below once, without taking notes.
Close the page and write down what SNAP Points means in your own words.
Compare your version with the excerpt and mark what you missed.
Work through the three examples above with pen and paper.
Explain SNAP Points out loud to somebody else — or to Teacher Smith in the lgStudy chat.

Frequently asked questions

What is SNAP Points in simple terms?

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.

Why does SNAP Points matter?

Because it connects several computer science ideas at once: it gives you a definition you can apply, a quantity you can calculate, and a way to check whether a result is plausible.

How should I study SNAP Points?

Read the excerpt, restate it from memory, then work through the examples and applications listed on this page. The five-step study plan above takes about twenty minutes.

What does this page cover?

It gives you a compact reference excerpt plus original lgStudy explanations, examples, applications and study material on SNAP Points.