Development processes start with requirements and wind up in code; in between there isn’t much of a consensus about what happens.
Misunderstandings start as soon as requirements capture, when requirements are to be qualified as functional or not. While most will agree that functional requirements must be set off from user experience, opinions depart about the extend of the experience to be considered: the whole operational process or the parts supported by system functionalities. With the former understanding it is assumed that the divide between software and hardware is not yet settled, with the latter requirements take system boundaries for granted.
Naturally, the same debate reappears with non functional requirements, often understood as a default category, a catch-all for remnants of what cannot be directly perceived as system functionality. But even when non functional requirements explicitly target quality of service and implementation constraints, these criteria are not always easy to apply, and that’s the crux of the matter: how to set apart functional requirements if and where the software/hardware divide is not fully settled. Could that pitfall be managed if requirements were first set at enterprise level and mapped to architectural capabilities ?
Requirements and Architectures
- Domain (aka business) requirements deal with business contents independently of supporting systems. They can be translated into Computation Independent Models (CIMs).
- Functional requirements describe how systems are expected to support business processes independently of implementation technologies. They can be translated into Platform Independent Models (PIMs).
- Technical requirements describe how functionalities should be implemented: testability, traceability, maintainability, portability, etc. They can be translated into Platform Specific Models (PSMs).
- Quality of Service requirements deal with operational constraints on functionalities: reliability, usability, efficiency, etc.
Yet, requirements items do not necessarily fit into reasoned taxonomies as they often mix concerns from different perspectives, for instance:
- Depending on domain and/or users, authorization and confidentiality requirements (Quality of Service) may require different hardware/software solutions (system boundaries and functionalities).
- Depending on regulatory environments, security requirements (Quality of Service) may require different encryption solutions (system implementation) between domains (system functionalities).
- Performance requirements (Quality of Service) may depend on design (system implementation) of specific business operations and data flows (e.g high-frequency trading).
As a consequence, the nature of system boundaries (with human, hardware, or other systems) and communication architecture cannot be fully fixed until further requirements analysis is achieved. Moreover, those decisions may be affected by the way requirements are labelled and analyzed:
- Focusing on system functionalities (e.g with use cases) means that system boundaries are already identified and that the business logic will be defined along with users’ interfaces (b>c>a).
- Starting with business requirements puts business domains and logic on the driving seat, making room for variations in system functionalities and boundaries (a>b>c).
- Operational requirements (physical environments, events, and processes execution) put the emphasis on a mix of business processes and quality of service, thus making software functionalities a dependent variable (a>c>b).
That’s especially meaningful for business logic and quality of services which, depending on requirements taxonomy, could be lumped respectively with enterprise and technical architectures. On a broader perspective, this divide can also be seen as the fault line between business value and system costs.
Where the Wares Divide
Business is conducted in both actual and symbolic worlds, and the aim of supporting applications is to bridge the gap between actual objects and processes on one hand, their system surrogates on the other hand. Yet, at inception the footprint of software functionalities may not be fully defined which means that some kind of no man’s land may remain between functional and non functional requirements.
Assuredly, some requirements can be firmly allocated: requirements grounded in organization should always govern functional architecture, and technical requirements should always govern components design. But the eventual assignment of requirements regarding business logic or quality of service may be suspended to governance or architectural options.
Hence, besides the typical scenario (b>c>a) that takes system boundaries for granted and start with functional requirements, two more specific ones should be considered respectively when business logic is to be dealt with on its own (a>b>c), and when operational concerns must receive preeminence (a>c>b).
Business Logic & Architectural Capabilities
The aim of functional architecture is to provide services (authentication, authorization, persistency, etc.) and access to shared resources. From the application perspective, those functionalities are meant to be “stable” i.e, relative to applications’ life-cycle, supporting services seem to be everlasting whatever the changes that may occur to technical architectures behind.
Hence the business logic conundrum: on one hand applications are anchored to business objects whose continuity and consistency are managed at corporate level, on the other hand features and business rules are bound to change with market opportunities and should therefore be managed independently of functional architecture, supposedly lest prone to business contingencies. How that conundrum is overcome depends on technical architecture, e.g:
- Solutions based on enterprise service bus (ESB) consolidate systems functionalities as they are.
- Enterprise resource planning (ERP) systems provide integrated solutions supporting customization.
- Rules engines factor out the management and execution of business rules.
Whatever the solution, organizing requirements around business logic will have direct consequences on both functional and technical architecture.
Once business rules are anchored to objects and processes identified by the functional architecture, some critical criteria must be considered:
- Rules whose execution requires authority (human agents) will require dedicated user interfaces with specific authentication capabilities (a,c).
- Rules whose execution is bound to time will call for specific interfaces and communication architecture (b,c).
- Rules whose execution is triggered by actual changes (as opposed to changes in symbolic representations) or affecting them will call for specific interfaces (c).
- Rules with cross domains footprint will call for logical synchronization mechanisms (d).
- Rules whose execution is triggered by change (push), as opposed to those triggered by need (pull), will call for specific synchronization mechanisms and communication architecture (b,d,e).
Clearly, those requirements cannot be neatly arranged along the functional and non functional distinction as many of them may fall on different sides of the divide and their implementation will have to balance functionalities against quality of service.
Use Cases & Functional Architecture
Use cases epitomize functional requirements by describing expectations at system boundaries notwithstanding what supporting systems will have to do.
Yet, if the reasoning is to be pushed further, use cases should factor out shared business objects, processes and logic supposed to be already supported by the functional architecture. How new use cases can be realized (by consolidation and/or extension) of existing functionalities will be determined by requirements analysis.
Except when lumped together with quality of service into the so-called “non functional” category, technical requirements are probably the easiest group to delineate. As a matter of fact one may even argue that the expression is an oxymoron because requirements are supposed to describe external specifications notwithstanding technical implementations.
Assuming that the objective of technical requirements is to set constraints on the implementation of system functionalities, they can be directly mapped to architecture capabilities.
Quality of Service & Architecture Capabilities
Contrary to business and functional requirement, quality of service is supposed to be defined independently of specific business operations; but contrary to technical requirements, quality of service is supposed to directly affect user experience as expressed by use cases or user stories. That separation of concerns may be practical for data intensive workflow or transactional applications, but it may turn to be highly hypothetical when functionalities (e.g fast trading or target acquisition) are specifically bound to operational requirements like real-time constraints or availability.
In that case the quality of service cannot be defined and managed uniformly across applications, and architects and engineers may be faced with tough trade-offs between common interests and architectures on one hand, specific needs and configurations on the other hand.
Yet, the corresponding decisions can be helped if quality of service requirements targeting specific functionalities can be mapped to architecture capabilities.