This is a very short course in the International Function Point Users Group’s (IFPUG’s) Software Non-Functional Assessment Process (SNAP). It is offered in the same spirit as A Very Short Course in Function Point Analysis. As I begin this post, I am reminded of an experience that I had in graduate school about 30 years ago. I had been assigned to do some research and give a 3 minute presentation on it. I gave the presentation, but I took about 5 minutes. The professor said, “Your presentation was interesting. But, if you really knew what you were talking about, you could have summarized it in the 3 minutes that I assigned you.” We will see if I know what I am talking about when it comes to SNAP.
Obviously, there is a an introduction that should be given to SNAP. This is a story of committees and impact studies, rewrites and certifications. What you really need to understand is that SNAP is the result of about a quarter of a century of function point counters talking to unhappy project managers. Project managers would describe in painful detail how a batch job worked. The counter would ask, “Does anything cross the boundary?” If the answer was no, there was no function point credit given. Sometimes the counter would sugar coat it by saying that some other functional transaction really covered this functionality. Sometimes the counter would be told about some non-functional requirement and explain that the effort was covered by one of the General System Characteristics. The manager was seldom satisfied. SNAP addresses these concerns.
There are fourteen sub-categories of non-functionality that make up a SNAP assessment. Basically, you must understand each one. There is some consistency between them, but not as much as you might expect. In addition, several of them are applied differently when a functional or non-functional capability is being added to an application, than when changes are being made. Many of the sub-categories are are based on elementary processes. These are business processes that make sense to the user. People familiar with function points know that External Inputs (EIs), External Outputs (EOs) and External Inquiries (EQs) are all elementary processes. However, not all elementary processes are EIs, EOs or EQs. An example would be a business process that does not cause data to cross the application boundary.
Data Entry Validation and Logical and Mathematical Operations are two subcategories that coexist with functional transactions. An input screen would probably be an EI. In addition to the function points for an EI, the input might also have SNAP points for data entry validations. The number of SNAP points is a function of the nesting level and the number of data element types (DETs). Nesting level is the number of inter-field validations. For example, if county is validated based on state, there is a nesting level of 2. Logical and Mathematical Operations works in a similar fashion. Any report is likely to be an EO. However, if it requires complicated math, like the solution of simultaneous equations, then it may also be awarded SNAP points for that complexity.
Data Formatting and User Interfaces applies to elementary processing and appears that they should be like the above two sub-categories. They are not. Data Formatting is primarily involved with encryption. It may involve displaying sensitive personal information formatted with asterisks. It might also involve algroithms that encrypt data before writing or transmitting it. In any case, some people consider it a gray area in regards to functionality. If function points are awarded for the change, then SNAP points are not. When they are awarded, they are a function of the type of encryption and the number of DETs. User Interfaces is for situations where a screen is being changed without a functional change. For example, if the font size of screen elements is changing, there is no functional change to count as function points. This is when the Data Formatting sub-category comes into play. SNAP points are awarded based on the number of user interface elements and DETs. This means that Data Formatting does not come into play for new development or changes that have a functional component.
SNAP assessments use the same application boundaries as a function point count of the same application. However, SNAP introduces the concept of a partition. The partition is technical in nature. A client-server application may have two partitions: client and server. An application build using a three-tier architecture may have three partitions. A batch partition or a special server, like a fax server, that offloads some processing might be considered a partition. The Internal Data Movements sub-category captures the SNAP points associated with sending data from one partition to another. The complexity is a function of the number of File Types Referenced (FTRs) and the number of DETs. Remember that these internal data movements are not functional because they do not cross the application boundary. However, they certainly add to the effort required to implement the application.
Delivering Added Values to Users by Data Configuration is a subcategory that comes into play for applications that use configuration tables to add additional capabilities. For example, a company might want their application to be easily modified every time they entered a new market. The functionality for each new market may be the same, but there will be changes to things like addresses. There might also be promotions that are applicable to one market, but not the others. These might all be set up as tables. There can be no function points awarded for this because only new rows are being added to tables, not new columns. However, the new configurations have to be setup, entered and tested. SNAP points are awarded for this. The points are a function of the number of elementary processes that depend upon these configuration files, the number of records that are added the files and the number of attributes in each record.
Help Methods is a SNAP sub-category. It is evaluated at the application, but its complexity is calculated based on the type of help and the number of help items actually implemented. Type of help can range from user manuals to online text to context sensitive help. Some estimators are not satisfied with this. Help is basically writing content while the rest of the application involves writing software. Some organizations have a separate technical writing group that has their own approach to estimating and this content. For these people, help should be separately estimated.
Multiple Input Methods and Multiple Output Methods are two SNAP sub-categories that are strongly related to some function point concepts. Multiple Input / Output Interfaces is a sub-category that sounds like it should be related, but is different. First, Multiple Input Methods covers situation the where an input may be entered using multiple methods. For example, a product id might be entered into a keypad by someone doing inventory or scanned by a bar-code reader. The same is true for Multiple Output Methods. The same report might go to a printer or sent to a recipient by email. Here is the complication, from a function point perspective are these one elementary process or multiple ones. IFPUG allows either interpretation, as long as it is documented. Now, from a SNAP perspective, no SNAP points are awarded if function points have been. Otherwise, the SNAP points are a function of the number of DETs in the input or output as well as the number of additional inputs or outputs. The Multiple Input / Output Interfaces sub-category is for situations where additional inputs or outputs are added because of increased usage. For example, a company might have a joint marketing agreement with another company. It would accept a file of that company’s customers and perform some type of marketing with them. The company might enter into this same relationship with an additional company. The format and logic of the additional input would be the same, so there is no additional functionality. However, there is effort to incorporate this new partner into the system. This is where this sub-category comes into play. Like the multiple methods subcategories, the SNAP points are a function of the number of DETs, as well as the number of additional inputs and outputs.
Multiple Platforms sub-category awards SNAP credit when a duplication of effort is necessary to deliver functionality in more than one technical platform. Internet browsers is an obvious case of this. If the same website must work in Internet Explorer and Chrome, then SNAP points will be awarded for each elementary process that is delivered as such. The points are a function of the number of platforms and whether the platforms are in the same family. For example, delivering functionality in both an expert system shell and a procedural language would be a case where different families of software platform were used.
Database Technology sub-category basically serves two purposes. The first purpose is to award SNAP points for database related adds or changes that do not get functional credit. Examples include any database that is added or changed strictly for performance reasons or changing the order of fields in a file. Remember that changes that get function point credit do not get SNAP credit. Also this sub-category is captured at the elementary process level, not at the file level. Therefore, if 5 physical files are changed in order to increase the performance of the Create Order process, then the SNAP credit is a single value associated with Create Order, not 5 values associated with the 5 files. The amount of SNAP credit is a function of the number of maximum number of RETs in the files changed and the number of changes made. The other purpose of this sub-category is for code tables. Code tables are tables that capture abbreviations in an application. An example would be the codes associated with airports. EWR is the code for Newark Liberty International Airport. Using the abbreviation is simpler and cuts down on data entry errors. Conceptually, it does not change the application. For purposes of SNAP, all of the code data in an application is considered to be in a single logical file. The complexity of the code table is based on the number of functions that it performs. It might be used for substitution, to validate data entry or for static data. Again, the number of changes are considered.
Batch Processing is used to award credit for batch processing that was not awarded functional credit. Batch processing that accepted data from outside of the application boundary, or produced data that crossed the application boundary, were considered function point transactions and counted as such. These will not get SNAP points. However, there were often batch process that ran at the end of the day that would update logical files without crossing the application boundary. These are awarded SNAP points. The number of SNAP points is a function of the number of files that are read or updated by the batch process and the number of DETs that are processed.
Component Based Software is a sub-category to assign SNAP points for components that are used in software development. This is common in websites. A page my require that a form be filled out to allow email addresses to be captured and maintained. This functionality may be supplied by a third party plugin. There would be an elementary process for the underlying page as well as the non-functional credit for using a component in the development. The complexity of this sub-category is based on whether the component was developed in house or is a third party component. The latter are considered to be more complex.