Most, if not all CFPS (Certified Function Point Specialists) have encountered projects that sit outside the organizational norm with significant development requirements for non-functional work. Function points are, of course, focused on delivered functionality, not non-functional development. Therefore, SNAP (Software Non-functional Assessment Process) has been developed to supplement the FP sizing methodology and provide a sizing technique for the non-functional component. This report explains SNAP and how it can be used to measure non-functional requirements. The report is available for download here: http://www.softwarevalue.com/insights/publications/ta-archives/how-to-measure-non-functional-requirements/ To access more Trusted Advisor articles, visit: http://www.softwarevalue.com/insights/publications/#trustedadvisor

1. ©2011 David Consulting Group Page 1 of
4 v1
“How do I size my non-functional software?”
October 2014
Scope of this Report
 What is the definition of non-functional software?
 When do I need to use a non-functional size measure?
 What non-functional size measure(s) should I use?
 How do we implement non-functional sizing?
 How do we implement non-functional estimating?
 Do estimating products cover non-functional changes?
What is the definition of non-functional software?
Non-functional characteristics of software include items such as compatibility, maintainability, usability,
portability, security, performance efficiency and functional stability and reliability.
In simple terms, functional requirements describe what the software will deliver to the user, while non-
functional requirements indicate how the software will implement that user functionality
When do I need to use a non-functional size measure?
If your organization is using Functional sizing as a metric to monitor productivity, then, where a
significant proportion of project effort relates to that non-functional development, productivity clearly
appears reduced and this leads to difficult discussions within the project.
When examining that apparent productivity loss due to non-functional requirements, you must take a
careful look at a project before using a separate measure. Bear in mind that IFPUG and other functional
sizing methods assume that some part of project effort will be devoted to non-functional activities, as
do benchmarking databases, so you must decide what makes a project exceptional.
Also, there is a level of variation in productivity between projects that is to be expected, for example
due to changes in staff or complexity of algorithms and you must decide what makes an exception
before you turn to using non-functional sizing methods.
When we look at the project consider the purpose of the release was it based on requirements to meet
any of compatibility, maintainability, usability, portability, security, performance efficiency and
functional stability?

2. ©2014 David Consulting Group Page 2 of 4 v1
If you are using IFPUG function points then the following are just some of the common software
development activities excluded by the IFPUG counting rules. They deliver no change to the functional
process or are done for purely technical reasons and usually have limited business meaning.
 Creation of static code tables or parameter files
 Addition of new reference data entries to an existing table
 Database changes for performance reasons
 User Interface (UI) changes for cosmetic reasons
 Performance improvements (streaming batch jobs or adding database indexes)
While these activities may be technically necessary, they can significantly increase effort and cost and
therefore negatively impact a project’s productivity or perceived performance.
Note this isn’t a failing or a gap in the Function point methodology but a different perspective
altogether.
It is this situation that best lends itself to using a non-functional measure.
We should consider the non-functional size measure in conjunction with a functional size measure to
 Provide overall insight into the delivery of projects and maintenance of applications,
 Assist in project estimating
 Provide insights for the analysis of quality and productivity performance.
What non-functional size measure(s) should I use?
The IFPUG approach is SNAP - a methodology developed by IFPUG to meet the needs of the industry to
have a generic sizing process for non-functional requirements or functional requirements not captured
by function points.
SNAP is divided into 4 major categories and a number of sub-categories
 Data Operations -The Data Operations Category relates to how data is processed within the
Snap Counting Unit to meet the Non-Functional requirements in the Application.
 Interface Design-Interface Design assesses the design of UI processes and methods that allow
the user to interface with the application.
 Technical Environment-Technical Environment assesses technology as well as changes to
internal data and configuration that do not provide added or changed functionality from a
Function Points perspective.
 Architecture-Architecture relates to the design and coding techniques utilized to build and
enhance the application. SNAPs assesses the complexities of modular and/or component based
development
Alternatively it is feasible to use your own metrics and size measures to capture the non-functional
requirements. For example, if your organization uses reference stories to set consistent story point
sizing across Agile teams and projects then it may make a reasonable initial size measure for non-
functional requirements.

3. ©2014 David Consulting Group Page 3 of 4 v1
The benefit is they may be recognized already by SMEs in your organization and historical data may be
available but the downside is the challenge of ensuring a consistent application of the measure and the
inability to compare with industry data.
Our preference would be SNAP. Indeed, one large organization challenged us to match up their non-
functional requirements across a number of platforms and SNAP covered them!
How do we implement non-functional sizing?
Once you determine the scope of the metrics capture, then consider the following steps.
 Determine if organizational historical data is available or can be reasonably derived.
 Consider how many metric types you may have that can represent the population, for example
SNAP gives its view of distinct categories you might consider.
 Identify future projects where you can capture the relevant size metrics by category and build a
historical repository for those types.
 When planning projects separate the non-functional development tasks from the functional
tasks in the work breakdown structure. This gives a much more balanced view of a project’s
productivity and ensures you are comparing like with like.
 Be aware that you may have multiple categories apply to the same process.
 Decide if you want to implement on all projects or projects which are atypical with a large non-
functional component.
 Gather data across different technologies to set benchmarks for future estimating.
 Test if the size metric you are using can be used for early sizing or estimating as the benefit will
be severely dented if not.
How do we implement non-functional estimating?
As far as possible you should use the same process as your functional estimating. We are simply using a
different size metric and should consider similar additional factors to produce the estimate, for example
duration, technology (in most cases), experience will have an impact.
You may find some changes have a fixed effort/duration like a regression pack or code compile and
delivery and can be estimated/included as such from historical data and excluded from the size metric.
Changes such as UI standardization will be variable based on the number of UI changes and so analysis
of the historical data should show a pattern which can be used for future estimating.
Do estimating products cover non-functional requirements?
Common tools such as SEER-SIM and SLIM1
allow you to use custom alternate size metrics so you can
adapt the tools to use your own organizational data.
1
SEER-SIM is a registered trademark of Galorath, Inc. SLIM is a registered trademark of Quantitative Software
Management, Inc.

4. ©2014 David Consulting Group Page 4 of 4 v1
There is a benefit using tooling that takes into account the differences in timescale/size and other
mitigating factors that are difficult to include in experience based estimating.
Conclusion
With SNAP there is now an industry size metric that can be used to measure non-functional changes
however, you can use your own metrics as well.
In many projects it is unnecessary to use a non-functional measure such as SNAP, as the amount of non-
functional change impacted is not out of the ordinary (or typical for those projects used as a
benchmark/ comparison) but the benefit is found when the degree of non-functional change is likely to
skew the total effort needed to deliver the project and by extension have an untoward impact of
productivity.
Non-functional metrics will enhance your overall project metrics to give a more complete view of
project size which greatly benefits the understanding of project performance and ultimately effort
estimation.