Requirements

Objectives and Pitfalls

Requirements reflect colored business concerns. Once properly analyzed they describe what a system is meant to do; as such they have to meet a dual purpose: (1) they provide the main input for system architects and engineers and, (2) they should be the basis for tests and acceptance.

On both accounts, requirements must be expressed in languages familiar to users and free of any ambiguity.

Given those objectives, some guidelines and handrails may be useful in order to guard against misconceptions and pitfalls:

• Requirements are by nature partial (mind your own business), biased (business opportunities are specific) and volatile (the point is to stay ahead of competition).
• Requirements describe actual processes (hic et nunc), physical or symbolic. Abstractions are best banned if misguided generalizations based on specific points of view are to be avoided.
• The languages to be used are necessarily specific, as set by users, be they bean counters or fighter pilots. Moreover, different users may be involved, each with his own expertise and/or specific language, some of them very formal, other less so. Yet, traceability between requirements and system models will have to be achieved.
• Consistency and clarity are of primary importance: partial descriptions are always to be preferred to ambiguous ones.
• Requirements are decisions, and as such they entice risks. As a corollary, the principle of “last responsible moment” should apply and commitments should be delayed until failing to decide affect the scope of choices.
• Since the sooner errors are identified, the lesser their cost,  at early stages controversy is more useful than consensus. Consequently, requirements should be formulated in a way open to refutation if misunderstandings are to be eliminated as soon as possible.
• Eventually, requirements will have to be incremental (to support complements and iterative development), modular(to support changes),  and hierarchical (to facilitate architecture and design decisions).

Those guidelines and handrails will be further developed into requirements analysis and weaving patterns.

Contents

By convention, the term “requirements” covers what the system is meant to do to support business processes. As a matter of precision, the taxonomy should distinguish between “functional requirements” for system supporting functionalities whatever the business, and “non functional requirements” which would refer to system capability whatever the business under consideration.

Requirements address three different concerns:

• System interfaces: how the system under consideration is to interact with its environment, including users, mechanical devices, or other symbolic machines.
• Symbolic functionalities: how business objects and processes are to be described.
• Non functional requirements: system expected capabilities and performances on one hand; tools and resources available on the second-hand.

If we concentrate on symbolic concerns and interfaces, requirements should be organized along the standard levels of persistency:

• If business continuity and consistency are to be achieved, requirements should first and foremost be anchored to persistency units, i.e individual objects whose business lifespan has to be  managed independently of the associated business processes. Semantics and consistency constraints of persistency units are set by domains.  Assuming a formal definition of their structure and consistency constraints, those objects don’t have to be fully defined  upfront but instead developed by increments. Along that perspective, persistency units may be referenced through services. Requirements about persistency units are introduced with CIMs and consolidated into functional architectures (PIMs).
• Execution units are requirements’ building block, best represented by use cases. Whereas they are by nature specific, biased, and volatile, they nonetheless should be soundly identified by their triggering conditions, namely external events and agents. It must be noted that the identification of  execution units (e.g use cases) can only use elements known before they start. As for persistency units, properly structured execution units can be developed iteratively, adding users, execution paths, or views. Requirements about execution units are introduced with CIMs and consolidated into functional architectures (PIMs).

• Interaction units are a special case of execution units as they can only be bound to single agents, that is, and contrary to business execution units, they are not shared. As a corollary, while they clearly depend on system architecture, they are not part of it and may be changed without affecting the system supporting them. That is often the source of misconceptions since, whereas user interfaces are requirements’ visual identity, they don’t belong to CIMs or PIMs layers. As a matter of fact, a single use case defined at CIM and PIM levels may be reused for different requirements and therefore implemented by different PSMs. To keep them on track (from requirements to PSMs), user interfaces should therefore be identified by variants of execution units as defined by resources (technical architecture), agents’ authorizations (aka roles) or decisions (execution paths).

Given a backbone of individual units characterized by semantics and identification principles, requirements should include some orthogonal repository for the semantics of associated features, operations, and business rules.

On a broader perspective, requirements are meant to describe the behaviors of systems seen as black-boxes, whatever it is that interact with them. While that can be done with use cases or any other formalism, textual or not, it should be always possible, even recommended, to include contractual definitions of services whenever it is practical.

Business, functional, and non functional requirements

Whereas there is a broad consensus about functional requirements, opinions may diverge when business and non functional requirements are mentioned. A practical approach could be to distinguish between:

• Business requirements, which describe business goals and stakeholders expectations. (e.g customer with a specific demand should be introduced to a broader variety of products or services).
• Functional requirements, which specify how the system is expected to contribute to business goals, more precisely, how the targeted subset of business requirements is to be supported. (e.g the system will select a list of products or services based upon customer profile and associations frequently observed).
• Use cases describe functional requirements as interactions between system and users. (e.g online customer visits, or point-of-sale appointment with staff).
• Non functional requirements, which range from standards to platforms and resources, with performances and security in between. (lists should be displayed within 10 seconds; regulations require that no trace will remain of customer’s requests).

It must be noted that, depending on the business (e.g avionics vs insurance claims processing) requirements like standards or response-time may be seen as technical or regulatory, and therefore classified as functional or non functional.

A more principled (but less practical) approach could use the classic distinction between problem space, solution space, and operations:

• Problem requirements deal with business objects and rules independently of system support.
• Solution (functional) requirements describe symbolic representations, algorithms and interactions on a standalone basis.
• Operational (non functional) requirements deal with scale, performances, resources or security concerns.

Those approaches may also be associated with targeted architectures:

• Business requirements deal with objectives, assets and organization associated with the continuity of corporate identity and capabilities within a given regulatory and market environment (enterprise architecture).
• Functional requirements deal with the support of business processes (functional architecture).
• Non functional requirements deals with the deployment of system functionalities and the economics of systems operations (technical architecture).

In any case, what was once methodological recommendations may be soon replaced by compelling obligations when applications migrate to the “Cloud”: if tasks are delegated to application servers running on anonymous and interchangeable systems, requirements can only “blind date” those systems through Service Oriented Architectures. And the best way to do that is to sort out functional requirements depending on their footprint and responsibilities:

• Non functional requirements: constraints on resources and services that can be expressed independently of business contents.
• Cross functional requirements: system functionalities supporting different business processes.
• Application specific: system functionalities confined to a single business process.

Along that reasoning a more systematic approach can be used to define a comprehensive and unequivocal taxonomy of requirements.

Requirements & Model Driven Engineering

If system engineering is to take a leaf out of industrial engineering regarding lean, fit, and just-in-time processing, the first thing to do is to properly characterize development flows, in other words sort out model contents depending on processing rules.

Whereas the design (downward) side of the modelling process has seen significant achievements, there is no such advances on the analysis (upward) side, where the foothills of requirements remain a serious impediment. Setting requirements as a principled base camp for MDE can therefore help to figure out the CIM-to-PIM conundrum and by the way, bring strong leverage to the results already obtained with the PIM-to-PSM transition.

• First of all, requirements must describe physical objects and agents, including legacy systems. Also required is the description of events and actual processes to be supported by targeted systems.
• At the same physical level, one should find the requirement regarding the resources available to and the performances of targeted systems.
• At CIM level, requirements should describe symbolic objects and activities: recorded information, messages, roles, processing rules, etc.
• PIM requirements describe the functional resources available, e.g services, and the standards and patterns to be used.
• PSM requirements do the same for technical platforms and standards.

From Requirements to Analysis

Whatever the terminology (business, functional, non functional, …), requirements must cover contexts, symbolic objects, and system expected behavior. If traceability is to avoid the spaghetti syndrome, requirements are to be weaved along consistent threads recognizable across models all along the development process. That may be achieved with customized UML tools and stereotypes.

Such diagrams provide views on development workflows which can be used as sequencing tools, building a bridge between requirements capture and system analysis. For that purpose Caminao combines two perspectives:

• A domain driven perspective looks at persistency units, ie symbolic representations that must be recorded independently across activities, be it for actual or symbolic objects, or the recording of events and process states.

  

• A use case perspective tallies activities and associated transient representations: functional or execution units, agents, roles, and events.

  

Providing that requirements and analysis are rooted to the same persistency and execution units, actual objects and behaviours on one hand, symbolic representations on the other hand, can be specified and consolidated iteratively.

Requirements as Rules

Whereas model driven development fosters phased approaches and scripted transitions (from requirements to analysis, to design …), it may be argued that all requirements can be boiled down to rules. One step further, and that would open the way to requirements engineering that could even bypass the traditional modeling framework. Without going all along that path, there are obvious benefits to a principled approach to rules specification, setting apart rules whose footprint could affect functional architecture from those than can be managed locally.

Quality

Requirements quality should be considered as a dual undertaking: (1) requirements correctness and consistency are to be checked against business needs and technical capabilities and, (2) data sets and test procedures should be devised, to be used for functional validation and system acceptance. For that purpose requirements must be organized adequately:

• As projections into some future state of affairs, requirements are built on goals and assumptions regarding the evolution of business and technological environments. Those assumptions must be explicit and properly weighted by risks.
• Traceability being a necessary condition for quality management, requirements must be organized along model layers and architectural tiers. That will let the results be duly associated with supporting goals and assumptions, both upstream (business contexts) and downstream (implementation platforms).
• Most importantly, when use cases are based upon representation patterns, requirements consistency can be checked in terms of functional architecture.

Traceability, transparency, and justification of requirements will greatly enhance the effectiveness  of validation procedures:

• Reviews and inspections can be organized selectively, depending on aspects, responsibilities and expertise.
• Dedicated simulations and prototyping, targeting objects consistency, dynamic behaviors, or user interfaces.
• Formal validation targeting circumscribed subsets expressed with non ambiguous specific languages.

Last but not least, test cases and scripts can be tailored as to fit requirements to deliverables  and ensure non regression.

• Context requirements (actual objects, agents, events, and processes) provide the basis for system tests and acceptance. They will also bu used to verify the conformity of symbolic representations.
• Test files should be defined with CIM requirements. They will be used to validate platform independent models on one hand, to test unit components on the other hand.
• Test files associated with context and CIM requirements may also be used for integration and maintenance tests.