Requirements Taxonomy

Objective

Requirements classifications may be compared to a famous one mentioned by Jorge Luis Borges from a Chinese Encyclopedia, Celestial Emporium of Benevolent Knowledge, which divides animals into fourteen categories, whose rationale and purpose have unfortunately been lost.

As illustrated by this example, taxonomies are symbolic tools that may serve a wide range of purposes, some practical, some speculative, some mythical. Faced with requirements capture, the purpose should be to clarify what is at stake and to identify the nature of subsequent engineering problems to be solved. Hence the search for a comprehensive, reasoned, and unequivocal taxonomy of requirements.

Initial Outcome

One way to be comprehensive is to start with a preposterous sample and look for some rational, and the Celestial Emporium of Benevolent Knowledge provides such an opportunity to try our hands:

1. Those that belong to the Emperor: business objectives.
2. Embalmed ones: mothballed requirements made obsolete by changes in organizational or technical contexts.
3. Those that are trained: additional requirements to existing applications.
4. Suckling pigs: additional requirements to projects still under development.
5. Mermaids: enticing requirements with no clear purpose or stakeholder.
6. Fabulous ones: ambitious requirements waiting for a technological breakthrough or a dream team.
7. Stray dogs: requirements with clear purpose but without identified stakeholders.
8. Those included in the present classification.
9. Those that tremble as if they were mad: shifting requirements that change when reviewed.
10. Innumerable ones: growing requirements that multiply when reviewed.
11. Those drawn with a very fine camel-hair brush: requirements expressed with a graphical modeling language.
12. Others: requirements that cannot be expressed in terms of symbolic contents.
13. Those that have just broken a flower vase: requirements associated with recent failures.
14. Those that from a long way off look like flies: vexing cloud of unclassified requirements that keep coming back and forth.

A Reasoned Consolidation

Except for the 11th and 12th, the outcomes of the first pass can be regrouped into five non overlapping categories:

• Business objectives (not to be confused with business requirements) that may be supported by functional requirements (1).
• Requirements under the authority of a unique owner or stakeholder (7)
• Requirements affecting applications under development or already deployed (3,4).
• Mothballed requirements (2,5,6)
• Requirements pending classification (9,10,13,14)

Setting apart business objectives (not to be directly considered as requirements), requirements already assigned (supposedly with proper classification), mothballed ones (in no need of classification), and pending ones (to be classified later on, once the taxonomy under consideration is stabilized), the symbolic criterion can be used to root the classification:

1. Requirements dealing with symbolic contents (aka Functional Requirements). Given that symbolic expressions can be reformulated, the granularity of these requirements can always be adjusted as to fall into single domains and therefore under the authority of a unique owner or stakeholder.
2. Requirements not dealing with symbolic contents (aka Non Functional Requirements). Since they cannot be uniquely tied to symbolic flows between systems and domains, nothing can be assumed regarding the number of stakeholders. Yet, as they target systems features and behaviors, they can be associated with architecture levels: enterprise, functional, technical.

That distinction makes perfect sense because, whatever their use, software systems are computing devices dedicated to the processing of symbolic representations. Given that their functionalities are not served in a vacuum but within  architectures combining human agents, physical equipment, and other software systems, requirements should make a clear distinction between (1) business objectives, (2) supporting systems functionalities, (3) how those functionalities are implemented, and (4) how they are operated.

Such a classification is both practical and useful.

Practical because it can be decided unambiguously with a four points profile:

• Is there a main owner or stakeholder with full authority on requirements and acceptance ?
• Are the requirements about specific contents of symbolic flows between system and context ?
• Are the requirements associated to system supporting functionalities ?
• Are the requirements and their acceptance directly associated with user experience ?

Useful because it supports the separation of concerns and responsibilities and indicates where and how requirements should be managed: portfolio (business objectives), projects (functional requirements), or architecture (non functional requirements).

Business Objectives and Functional Requirements

Business Objectives

Business objectives are set at enterprise level and expressed in terms of generic business achievements, either qualitative (e.g people, regulations) or quantitative (e.g space, time or money). Contrary to requirements, business objectives are not directly associated to systems capabilities: they do not describe business rules (like domains) or symbolic flows (like users requirements),  nor they address technical characteristics or quality of service. As a consequence they cannot be directly associated with acceptance tests.

Domain Requirements

Domain requirements deal with the semantics and rules of business objects and processes. While they are usually expressed with functional system requirements, they should be managed on their own, independently of the way they are meant to be supported by system functionalities.

Most importantly, domain requirements must fall unequivocally under the authority of a single owner and be organized around clearly identified business objects and processes. When that’s not possible they should be defined as business objectives (if not related to system capabilities) or as quality of service (if related to system capabilities).

System users requirements

Functional users requirements deal with the part played by supporting systems. They describe the symbolic contents exchanged between software systems, devices, and agents. For that purpose they combine (1) the subset of domain requirements corresponding to the system footprint and (2) organizational structures, rules and procedures set at enterprise level.

Assuming that the semantics and usage of symbolic flows can be uniquely assigned to business domains, functional requirements should always be managed by a single authority, usually but not necessarily the one in charge of domain requirements.

Non Functional Requirements

From a pragmatic point of view, requirements that cannot be anchored to objects or processes clearly identified within business contexts are usually regrouped under the label “Non functional”, or FURPS, for Functionality (confusingly…), Usability, Reliability, Performance, and Supportability.

More formally, those requirements deal with the support of interactions between systems and contexts independently of the specific contents of symbolic flows. As a consequence, even if some may be associated with specific operational processes, those requirements should be mapped to systems capabilities and managed accordingly:

• Quality of service requirements refer to supporting systems capabilities independently of functional contents.
• Technical requirements refer to the implementation of systems capabilities independently of their specific functional contents.

It must be reminded that the classification is not about the intrinsic nature of requirements but about their management. As a consequence, the same kind of requirements (e.g costs) may appear separately as technical (development costs) and as a quality of service (cost of ownership).

Quality of Service Requirements

If the quality of service is to be directly verified at operational level the corresponding requirements are to be associated to standard (i.e non specific) systems capabilities, in particular:

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

Depending on capabilities, quality of service requirements may address:

• Balance resources / capacities: response time, volumes, etc.
• Level of service: availability, maintenance.
• Reliability: failures and recovery, fault tolerance.
• Security: confidentiality, integrity.
• Scalability
• Interoperability, compatibility, compliance with regulations.
• Usability: ease-of-use, learning curve, documentation, customization.
• Costs: ownership, use.

Technical Requirements

Whereas they may ultimately address the same concerns, technical requirements should not be confused with quality of service. Contrary to services, whose quality is observable at system boundaries, technical requirements target system components along  the different tiers of systems architecture:

• Persistent business components supporting shared access.
• Transient business components supporting shared access.
• Transient business components supporting single access.
• Communication mechanisms.

Depending on tiers, technical requirements may address:

• The nature of the resources to be used to implement the components.
• Components internal qualities: traceability, maintenance, reusability, etc.
• Components external qualities: portability, compliance with technical standards, etc.
• Costs: products, development.

Assessment

Classifications are tools made on purpose, and they should be assessed accordingly. On a notional basis the proposed taxonomy seems to support the separation of concerns both for customers (stakeholders and users) and providers (development and exploitation). On a practical basis it must also be applied to sample requirements and tested for practicality, accuracy, and effectiveness:

1. Practicality and accuracy, measured by the percentage of requirements that can be classified unequivocally.
2. Effectiveness, measured by the percentage of unclassified requirements that can be reformulated and classified unequivocally.

On a broader perspective, this taxonomy may be especially useful for cloud-based applications as it distinguishes “grounded” requirements from those to be supported by clouds.

A simple case study is introduced to illustrate the approach. Sample requirements can also be proposed through comments.

Case Study: The Emperor Garage

All the following requirements can be unequivocally classified using the table above, even if some answers remain undecided.

1. The business of the emperor garage is to serve the palace vehicles as well as those belonging to the nobility.
2. The Garage may repair vehicles from private customers if more than 20% of mechanics are unemployed for more than a week (f).
3. The Garage may park vehicles from private customers if occupancy rate is less than 75% (k).
4. The garage shall be able to serve at least 3 interventions a day (b).
5. Interventions should be scheduled in the best interests of the high nobility (l).
6. Interventions should give priority to officers from nomarchs and above (l).
7. The position of service trucks shall be checked twice a day (a).
8. A service truck shall get at the incident location no later than the day after a request for intervention is accepted (b).
9. Requests for intervention are immediately recorded and dispatched (c).
10. Mechanics are assigned on the basis of availability (d).
11. Mechanics are assigned on the basis of skills as assessed by managers (d).
12. Payment by hand-shakes are accepted (e).
13. The Emperor Garage may repair vehicles from private customers if occupancy rate is less than 70% (f).
14. Payment by  hand-shakes are accepted up to 100 pounds (e).
15. Technical documentation used by mechanics shall be retrieved in less than half a day (d).
16. Details of intervention and time spent must be recorded immediately after completion (f).
17. Intervention files shall be retrieved in less than five minutes (g).
18. Customers shall acknowledge the state of their vehicle before checking out (h).
19. Customers shall be identified using their recorded portrait (g);
20. Customers portraits shall be draw by registered artists (g);
21. Lifts shall be operated by voice and sign commands (i).
22. Lifts shall measure at least 8 by 8 standard cubits and bear the weight of 15 men (i)
23. Lift control units shall know the last stop of the lift and its direction if it is moving (j).
24. Fences at floors shall remain locked until the lift is stopped and aligned (k).
25. Fences at floors shall be made of oak (k).
26. Oxen pulling service trucks shall be at least 4 standard cubits high (b).
27. Fences at floors shall unlock themselves when the lift is stopped and aligned (k).
28. Fences at floors shall lock themselves when the lift leaves its alignment (k).
29. Repaired vehicles shall be retrieved two weeks at most after completion (h).
30. Owners of repaired vehicles shall be informed within two days of completion (m).
31. The status of vehicles in repair shall be established daily (f).
32. The monthly turnover of the workforce processing the lift shall be less than 50 % (i).