Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29881: FiSMA Functional Size Measurement — Principles and Engineering Practice
A technical guide to the FiSMA functional size measurement method, its service taxonomy, comparison with COSMIC and IFPUG, and practical estimation applications
ISO/IEC 29881 defines the FiSMA (Finnish Software Measurement Association) functional size measurement method, a standardized approach for quantifying the functional size of software from a user perspective. Unlike traditional lines-of-code metrics, FiSMA measures software size based on the number and complexity of functional services provided to users, enabling more accurate project estimation, productivity benchmarking, and contract management throughout the software development lifecycle.
FiSMA was originally developed as the Finnish software industry standard for functional size measurement and was later adopted as an ISO standard to provide an alternative to the COSMIC (ISO/IEC 19761) and IFPUG (ISO/IEC 20926) functional size measurement methods. FiSMA is particularly well suited for modern agile and service-oriented architectures.
FiSMA Measurement Principles and Service Types
FiSMA measures functional size by identifying and classifying the services that a software system provides to its users. The standard defines four base service types: interactive services (dialog-based user interactions involving input, output, and navigation), internal data services (data storage and retrieval operations), interface services (communication with external systems), and data manipulation services (batch processing and transformation operations). Each service is assigned a functional size unit (FSU) based on its complexity, determined by the number of data elements, data groups, and validation rules involved.
The FiSMA measurement process comprises four phases: purpose definition (establishing the scope and viewpoint of measurement), service identification (identifying all user-visible services from requirements or design specifications), service classification and sizing (assigning FSU values based on complexity), and result aggregation (summarizing sizes by service category and total).
| Service Type | Description | Complexity Factors | Typical FSU Range |
|---|---|---|---|
| Interactive service | User dialog with input/output fields | Field count, validation rules, navigation depth | 4–25 FSU per service |
| Internal data service | Persistent data read/write/delete | Entity count, relationship complexity | 3–18 FSU per service |
| Interface service | External system communication | Message types, protocol complexity, mapping rules | 5–30 FSU per service |
| Data manipulation | Batch processing and calculation | Algorithm complexity, data volume | 3–20 FSU per service |
FiSMA is particularly effective for sizing microservice architectures, where each microservice typically maps to one or a small number of FiSMA service types. An e-commerce payment microservice might include one interactive service (payment form), two internal data services (transaction record, refund status), and two interface services (payment gateway, fraud detection). This service-level granularity provides more meaningful sizing than counting lines of code across distributed repositories.
Comparison with COSMIC and IFPUG Methods
Each functional size measurement method has distinct characteristics. IFPUG (ISO/IEC 20926) focuses on counting five function types: external inputs, outputs, inquiries, internal logical files, and external interface files. COSMIC (ISO/IEC 19761) measures data movements — entry, exit, read, write — triggered by functional processes. FiSMA differs by measuring services as the primary unit of size, providing better alignment with service-oriented and event-driven architectures.
FiSMA’s service-oriented approach offers advantages for modern development paradigms: it naturally accommodates RESTful API sizing (each endpoint is a service), microservice decomposition (services map directly to bounded contexts), and agile user story estimation (user stories typically encompass one or two services). Empirical studies show that FiSMA sizing correlates with development effort with R² values of 0.82–0.91 across different project types, comparable to or slightly better than COSMIC and IFPUG.
The choice between FiSMA, COSMIC, and IFPUG can significantly affect reported functional size. A project measured at 1000 FSU using FiSMA might measure at 800–1200 COSMIC function points or 600–1500 IFPUG function points, depending on architectural style. Never mix sizing data from different methods without applying a calibrated conversion model. The standard provides conversion guidelines but emphasizes that different methods serve different analytical purposes.
Practical Application in Estimation and Benchmarking
FiSMA functional size is most valuable when used as an input to parametric estimation models. The standard recommends building organizational productivity baselines by dividing actual development effort (in person-hours) by the functional size of delivered services. Once calibrated, these baselines enable effort estimation with typical accuracy of ±25% for new development projects — substantially better than expert judgment alone (typically ±40–60%).
For contract management, FiSMA provides a technology-independent specification of what the software should do. Fixed-price contracts based on FiSMA sizing reduce ambiguity in scope statements and provide an objective basis for change order negotiations. The standard includes a contract annex template with sizing conventions, escalation procedures for disputed measurements, and acceptance criteria tied to delivered functional size.
Functional size measurement is not a substitute for technical complexity assessment. A 100-FSU service implementing a complex cryptographic algorithm requires substantially more effort than a 100-FSU service providing simple CRUD operations. FiSMA explicitly notes that size must be complemented by technical complexity factors, team capability, and quality requirements to produce reliable effort estimates. Relying solely on functional size for project planning will result in significant estimation errors.
Frequently Asked Questions
Q: Can FiSMA be applied to non-functional requirements?
A: No. FiSMA explicitly measures functional size — what the software does for its users. Non-functional requirements (performance, security, scalability) must be captured separately and incorporated into estimation models as cost drivers or complexity multipliers. The standard recommends using ISO/IEC 25010 for structuring non-functional requirement portfolios.
Q: How does FiSMA handle reuse and COTS components?
A: When a service is implemented using a commercial off-the-shelf (COTS) component or reused from an existing system, the functional size of that service is still counted in full, as the user-perceived functionality remains unchanged. However, the development effort required may be reduced — this distinction is handled at the estimation modeling stage rather than the sizing stage.
Q: Is FiSMA suitable for agile and DevOps projects?
A: Yes. FiSMA’s service-oriented measurement aligns well with agile user story mapping and iterative delivery. The standard recommends decomposing the total functional size into increments aligned with sprint releases, enabling velocity tracking and release planning. The service-level granularity also supports continuous measurement as features evolve across sprints.
Q: What training and certification is available for FiSMA?
A: FiSMA maintains a certification program for functional size measurement practitioners. The standard recommends that organizations designate certified FiSMA measurers for contract-critical measurements, ensuring consistency and compliance with the measurement rules defined in ISO/IEC 29881. Certification involves demonstrated competence in service identification, classification, and sizing through written examination and practical case studies.
