Security

Function Points FAQs

Security

Home

ISSUE

Is the ability to restrict security access of users, considered to be a function or a feature of an application?

SAMPLE SCENARIO

User Requirement

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.

Technical Design

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:

Implement a User Security File (User ID, Security Access Level, Password) which is maintainable by a user with administrative access privileges. The User Security File is checked before each function is activated.Access is either granted or denied.
Implement the User Security File as above, but check the access rights at logon and block or release transactions appropriate to the user's security access level (e.g. block menu items by disabling the buttons).

Scenario Resolution

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.

Home

General Discussion

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:

Files

Where they exist, one or both of the following files may be counted as ILFs:

User Security File

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.

Access Profile File

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:

Maintenance transactions on each of the above files.

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.

Logon/Logoff transactions when user system accesses are required to be recorded and reported upon. Logon and Logoff transactions should be counted separately.

Transactions: External Outputs/External Enquiries

Where they exist, the following may be counted as External Enquiries or External Outputs for the Security Module:

Enquiries on the above data.

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

Security reports or warnings.

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:

for business reasons (e.g. restricted access to sensitive business data). In this situation, the security transactions and files are counted as previously described. The security feature is also considered in the GSCs.
manifested by the computerisation of the business (restricted number of users for the software licence).In this situation no transactions or files are counted, but the logon feature may be considered in the GSCs.

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.