Function Points FAQs
Is the ability to restrict security access of users, considered to be a function or a feature of an application?
The Payroll Area is only accessible to authorised employees. The sensitivity of payroll information is protected by only allowing specific Payroll staff to access the salary records of employees. The Payroll Clerks record the time sheets, annual leave and overtime details. The Paymaster then calculates due pay according to each employee’s salary rate.
The user requires the computerised system to enforce the existing security arrangements for access to payroll data.This requirement is usually implemented by developing a User Security File that records the User ID and access rights of each user.Different functional areas are restricted to particular user access levels.The developer has recommended two strategies to address these requirements:
The Payroll area’s requirement to record access rights of their staff is considered to be a user business requirement and, as such, the security functionality should be counted. In this scenario, the User Security File should be counted as one ILF, with associated maintenance transactions.
Where system security is provided by an external application or utility it is not to be counted within the scope of the application being counted. Where system security has been custom built it is counted as follows:
Where they exist, one or both of the following files may be counted as ILFs:
A file that defines user attributes, their designated access profile (e.g. System Administrator), and in some cases the date and time that the user logs on and off the system.
A file which defines the functions and data that may be accessed by specific types of users, for example, Customer Service Representative, Supervisor, System Administrator, Senior Manager etc. This file identifies the possible types of user, and the system functions and data that are accessible to each.
Where system security requirements are complex, other types of security files may exist. These should all be assessed according to FPA guidelines.
Transactions: External Inputs
Where they exist, the following may be counted as External Inputs:
Note: The modification of an individual user’s access profile would usually be considered a separate business transaction to the general ‘modify’ transaction which covers changes to other user attributes such as, Address, Workstation Id, Printer Id. The transaction to Change the User Password is also counted as a separate transaction as it usually involves different processing eg the requirement for re-typing/user confirmation.
Transactions: External Outputs/External Enquiries
Where they exist, the following may be counted as External Enquiries or External Outputs for the Security Module:
Note: The Logon transaction is considered part of the enquiry on the User Security File, unless there is a specific business requirement to record and report user system accesses, in which case it is counted separately. (See Transactions: External Inputs.)
While there exists a requirement to restrict access to particular functions, this is logically considered to apply at user logon.It is assumed that when the user logs on, the system is configured for his use, as defined by his access profile.The User Security file is only to be counted as an FTR for its own maintenance and reporting functions and the Logon and Logoff Transactions. The User Security File is not counted as a separate FTR on every other system function.
There are cases where restriction of access to data is:
Contribution to VAF
The restriction of access to particular transactions is also assessed as a security feature of the application and considered in the GSC ‘Complex Processing’ in the Value Adjustment Factor.
Where restriction of access to data is due to the computerisation of the business function (e.g. restricted number of users permitted per software licence) this is assessed as contributing to ease of the ‘starting up’ of the software and considered in the GSC ‘Operational Ease’ in the Value Adjustment Factor.