Requirements & Architecture Capabilities

Objective

Development processes start with requirements and wind up in code; in between there isn’t much of a consensus about what happens.

cc

How to match requirements with architecture Capabilities (Bernd Hillabecher)

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.

Requirements Taxonomy and Architecture Layers

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

Requirements may be governed by business logic (a), system functionalities (b), or operational needs (c).

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.

Functional or Not: Where the Wares Divide

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

Business Logic & Architectural Capabilities

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.

Use Cases & Functional Architecture

Technical Requirements

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.

Technical requirements

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.

Quality of Service & Architectural Capabilities

6 Responses to “Requirements & Architecture Capabilities”

  1. Adrian Walker Says:

    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.

  2. David Wright (@dwwright99) Says:

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

  3. caminao Says:

    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.

  4. Doug Edmondson Says:

    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.

  5. Kiran Fujiwara Says:

    Totally agree withy Doug’s comment and there has been instances where this is overlooked..

  6. Adrian Walker Says:

    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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: