Objective
Projects start with requirements but must be built on more than expectations. Hence the need of sound assessments setting apart the problem to be solved and the alternative solutions, if any.
Yet, those assessments are meant to be done upfront, prior any significant effort is committed to analysis and design; and that would be easier with a clear-cut distinction between business and systems requirements, and more generally between enterprise and functional architectures.
Taking a leaf from the MDA book, the objective here is to consider how to redefine function points with regard to computing and platform independent models (respectively CIMs and PIMs).
Function Points Primer
In principle, software metrics must deal with a double target: the problem and the solution. That distinction is both straightforward and necessary as requirements may have to be ranked with regard to business value, and alternative solutions assessed with regard to effectiveness and engineering concerns. Moreover, measurements should target the intrinsic size and complexity of problems and solutions independently of development effort.
While some advances have been achieved with functions points, practical solutions usually rely on personal expertise (for the assessment of raw function points) and statistical inferences covering the whole development process (for the adjustment). The first objective is therefore to replace coarse rankings (low, average, high) with clear, objective and traceable variables, and to compile samples of their relative weight.
To begin with, current functions can be mapped to Caminao stereotypes. With regard to data:
- Internal Logical files (ILFs) are symbolic objects whose life-cycle is bound to applications using them. They are computed at application level.
- External Interface Files (EIFs) are symbolic objects used or referenced by the application yet whose life-cycle is managed independently. They must be consolidated into persistent objects and associated function points computed at domain level.
With regard to transactions:
- External Inputs (EIs) are local (non shared) activities processing information from outside application boundaries.
- External Outputs (EOs) are local (non shared) activities providing derived information outside application boundaries.
- External Inquiries (EQs) are local (non shared) activities providing non derived information outside application boundaries.
Those five functions are valued along three levels (low, average, and high) depending on the number of features, structures (for data), and referenced file types (for transactions).
That approach has two main limitations:
- Estimations are not much more than informed guesses that can be disproportionately affected by business, organizational, or technical context.
- Whatever estimations accuracy, function points, including for transactions, are based on data size and complexity, overlooking other dimensions whose impact is lumped together as adjustment variables.
Yet, those flaws can be curtailed by using objective parameters for business, functional, and non functional requirements.
Functional Requirements and Metrics
If objective measurements are to replace informed guesses, function points must be based on stable and unbiased parameters that will not depend on methodological or design options.
To begin with, requirements should be bound to artifacts identified within the enterprise architecture: business objects, activities, or roles. Since those anchors are not supposed to be significantly affected by requirements analysis, they provide a solid ground for further refinement.
The next step is to take into account the features, variants, and dependencies of those identified units. While that step clearly belongs to requirements analysis, it can be done in a limited amount of time if the focus is on clearly defined constructs.
Function points can then be redefined accordingly :
- Estimations are anchored to artifacts identified at architecture level (#).
- The number of data element types (DET) is the sum of features (attributes and operations) for the target and its composites.
- The number of record element types (RET) is the sum of composites and aggregates accessible from the target.
- The level of coupling is the number of links (connectors and containment) with functional integrity constraints (structural ones are taken into account by aggregates and composites).
- The number of variants is the sum of subsets defined by partitions.
And those measures can be applied indifferently to different kinds of artifacts, objects or behaviors.
Non Functional Requirements and General System Characteristics
In theory function points are supposed to be weighted by a value adjustment factor (VAF) computed from 14 general system characteristics (GSCs), each set between 1 to 5. In practice this adjustment procedure is seldom used, the main reason being that it compounds the shortcomings of the primary computation:
- The fuzziness of initial guesses is increased by guesses about general characteristics.
- Those “general” characteristics lump together different kinds of concerns: business (e.g complex processing), functional (e.g end-user efficiency), operational (distributed locations, maintainability), or development effort (e.g reusability).
The remedy to those drawbacks is to chart system characteristics according requirements taxonomy.
Assuming that primary function points target functional requirements, the so-called “non functional” requirements cover a wide range of constraints that may be regrouped in two categories, depending on their nature:
- Operational and quality of service requirements relate to the way supporting systems are operated and used, independently of specific business contents.
- Technical requirements relate to the way supporting systems are implemented, assuming other requirements are satisfied.
Assuming moreover that technical requirements are set independently of operational and quality of service requirements, they should not be taken into account for functional adjustment. That’s not always the case for constraints on quality of service and operations as they may entail some arbitrage against functionalities, as illustrated by ease of use, security, response time, compliance, etc. In order to sort out adjustment factors, those constraints will have to be examined depending on their target.
Functional requirements targeting identified artifacts in business domains, activities, and users’ transactions can be directly measured using function points (respectively DFP, AFP, and UCFP).
Constraints (aka non functional requirements) targeting specific domains (e.g privacy) or activities (e.g transaction rate) should be either incorporated into primary function points (when translated into adjusted functionalities), or ignored (when taken care of at operational level).
Operational requirements are set at enterprise level but are meant to be supported by technical architectures. As a consequence the corresponding adjustment factors should not be introduced until development effort is considered.
Capabilities and Adjustment Factors
The apportionment of quality of service requirements is less definite as they may impact functional complexity as well as operational context. As already noted, adjustment factors for quality of service should only consider constraints that cannot be attached to specific functional requirements. As a corollary, the corresponding adjustment factors can be analyzed with regard to architecture capabilities:
- Interactions (Who): symbolic (roles) and non symbolic (devices) interfaces.
- Domains (What): persistence and access to symbolic representations.
- Activities (How): description of business logic
- Locations (Where): distribution of uses and resources.
- Processes control (When): events management and level of service.
Adjustment factors can then be computed for cross constraints between capabilities (intrinsic complexity is already measured by primary function points):
- Locations: coupling (channels), locations with active objects, distributed storage, distributed access, real-time connections, distributed processing, distributed control.
- Active objects: real-time updates on status, authentication, real-time synchronization, complexity of data processing, complexity of control.
- Symbolic objects: coupling (references), authorizations, triggers (cascading updates), complexity of algorithms, knowledge based control.
- Actors: real-time constraints on interactions, complexity of interactions contents, complexity of interactions control.
- Events: complexity of events processing, triggers (cascading events).
- Business logic: coupling (data and control flows), synchronization of operations (ACID).
- Process execution: coupling (state transitions).
Those 25 ( (7*6)/2+4) characteristics can then be weighted like the original 14 ones on a scale from 0 (low) to 5 (high).
When and How to Adjust Function Points
As noted above, adjustment factors have two different objectives, (1) to adjust problem size and complexity for non functional requirements and, (2) to estimate development effort based on problem size and complexity. As the latter clearly depends on organizational and technical contexts, the focus here is on the former objective. For instance:
- Function points for business domains (DFP) will have to be adjusted for cross integrity constraints.
- With regard to application logic (independently of processes execution), adjustment of function points (AFP) will take into account targeted domains and constraints on flows.
- Use case function points (UCFP) will be adjusted for location, active objects (other than users or systems), domains, application logic, and control.
- Function points for full application will be adjusted for all aspects.
Further Reading
- Requirements taxonomy
- Requirements metrics matter
- Functional size measurements
- Connectors patterns
- Partitions
- Power-types
- UML# Manifesto
- Requirements and architecture capabilities