Objective
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
As already noted, requirements can be classified with regard to targeted architecture layers, possibly within a model driven engineering framework:
- 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.
Feasibility & capabilities
A feasibility assessment is based on the implicit assumption of slack architecture capabilities. But since capabilities are set with regard to several dimensions, architectures boundaries cannot be taken for granted and decisions may even entail some arbitrage between business requirements and engineering constraints.
Taking from Zachman’s framework, generic architectures capabilities can be set with regard to roles (who), activities (how), locations (where), control (when), and contents (what), and declined along layers for business and organization, systems functionalities, and platforms.
Depending on priorities, feasibility could then be assessed according to layer:
- Focusing on system functionalities (e.g with use cases) implies that system boundaries are already identified and that the business logic will be defined along with users’ interfaces.
- Starting with business requirements puts business domains and logic on the driving seat, making room for variations in system functionalities and boundaries .
- 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.
In any case a distinction should be made between requirements and engineering feasibility, the former set with regard to architecture capabilities, the latter with regard to development resources and budget constraints.
BUSINESS REQUIREMENTS & CAPABILITIES
To begin with, the feasibility of business and operational objectives (the “Why” of the Zachman framework) can be assessed as the outer range and mapped to architecture capabilities.
Use cases are meant to describe the part played by supporting supporting systems independently of the platforms implementation. As such they can be used to factor out shared business objects, processes and logic supposed to be already supported by the functional architecture.
The feasibility of business requirements could then be assessed with regard to the consolidation and/or extension of existing functionalities.
Functional 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.
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.
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).
Technical FEASIBILITY
Finally, the feasibility of business and functional requirements under the constraints set by non functional requirements has to be translated in terms of ROI, and for that purpose the business value has to be compared to the cost of engineering the solution given the resources (people and tools), technical requirements, and budgetary constraints.
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.
There’s some emerging technology that addresses the following problem:
“Objective Development processes start with requirements and wind up in code; in between there isn’t much of a consensus about what happens”
It’s called Executable English. The idea is to narrow the gap between requirements and code. Here are some examples:
http://www.reengineeringllc.com/rule_examples.html
Totally agree withy Doug’s comment and there has been instances where this is overlooked..
In large organizations if solutions are developed without looking at the “whole operational process” you can end up with a number of insolated systems that don’t integrate easily in the future. Knowing how the current project fits into the larger picture needs to be a key component of the project.
My understanding is that contrary to “some”, “most” doesn’t have to be necessarily associated with specific sources, but it seems to reflect opinions expressed in different group discussions.
The same reasoning goes for “opinions depart”, by which I just want to say that there are differences, whatever they may be.
“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.”
Would you have some sources you could use to support this statement? Who is “most”, and whose “opinions depart”?
IMHO, you start to consider system functionality in any way, you are no longer dealing with requirements, so I agree with “the whole operational process” opinion.
The following may be of interest — Social Executable English Knowledge for Explainable Database Question Answering.
You can write database apps by typing Executable English knowledge into a browser, using your own words, jargon and phrases.
Then, you can run your app over large networked databases, and get English explanations of the results. Think evidence-based medicine, food security, energy independence, etc.
The data are there, what’s missing is the knowledge to use it.
You can Google Executable English to find this, or go directly to http://www.reengineeringllc.com .
Shared use is free, and there are no advertisements.