Thread: Requirements

Preamble

Requirements are arguably the cornerstone of the whole system engineering process, so much so that their processing is sometimes identified with the engineering process itself.

To begin with, some preliminary issues should be clarified:

• Language used for capture: formal, domain specific, or natural.
• Format used for capture: text, users’ stories, use cases, etc.
• Scope: system (people, equipment, software) or software.
• Taxonomy: business, functional, non-functional.
• Metrics: users’ value or function points

Yet, the main point is to establish the basic responsibilities with regard to business and system concepts and stakes:

• Business: stakeholders set objectives, analysts define objects and activities, users describe what is expected from supporting systems.
• Systems: analysts specify functionalities of supporting systems, architects consolidate existing functionalities with the ones to be developed, engineers design and develop the latter.
• Project managers put together and manage business value and time-to-market on one hand, engineering constraints and development costs on the other hand.

Those responsibilities can only be defined within organizational and technical contexts which necessarily differ depending on activities and corporate history, identity and culture. Nonetheless, requirements can be squared in a 2*2 enterprise frame depending on their nature (business or systems) and footprint (business unit or enterprise):

That would help to determine the development model:

• How requirements are to be documented: formal statements to be managed and reused, or declarations of intents to be processed “on the fly”
• How requirements are to be engineered: phased or iterative development.

Requirements & Value Chain

Taking from Porter’s generic model, the concept of value chain  is meant to draw swim-lanes according to business specific categories for primary and support activities.

Whatever its merits, the approach is essentially static and falls short when the objective is to trace changes induced by business developments; and that flaw may become critical with the generalization of digital business environments:

• Given the role and ubiquity of software components (not to mention smart ones), predefined categories are of little use for impact analysis.
• When changes in value chains are considered, the shift of corporate governance towards enterprise architecture puts the focus on assets contribution, cutting down the relevance of activities.

Hence the need of taking into account requirements shelf life.

Notwithstanding the constraints of strategic planning, business processes are by nature opportunistic, and their ability to be adjusted to circumstances is becoming all the more critical with the generalization of digital business environments.

Broadly speaking, the squaring of supporting applications to business value can be done continuously or by phases:

• Phased alignments start with some written agreements with regard to features, delivery, and prices before proceeding with development phases.
• Continuous alignment relies on direct collaboration and iterative development to shape applications according to business needs.

Beyond sectarian controversies, each approach has its use:

• Continuous schemes are clearly better at harnessing value chains, providing that project teams be allowed full project ownership, with decision-making freed of external dependencies or delivery constraints.
• Phased schemes are necessary when value chains cannot be uniquely sourced as they take roots in different organizational units, or if deliveries are contingent on technical constraints.

In any case, it’s not a black-and-white alternative as work units and projects’ granularity can be aligned with differentiated expectations and commitments.

Requirements Capture

Requirements capture is the first step on project paths, when neither words nor things can be taken for granted: names may not be adequately fixed to denoted objects or phenomena, and those ones being pointed at may still be anonymous, waiting to be named. Hence the importance of the language being used:

• Formal language (e.g maths or logic), shared between business analysts and software engineers.
• Specific language (e.g law, accounting or insurance), supposedly unknown to software engineers.
• Natural language (e.g media, games), supposedly shared between business analysts and software engineers, but not necessarily with consistent semantics.

Taking for granted that requirements must be grounded in actual business concerns, trying to apprehend them directly as “conceptual” models would contradict the rationale behind requirements capture and analysis. On that basis, and templates set apart, user stories and use cases are the preferred methods for requirements capture. Both put the focus on user experience and non formal descriptions of concrete objects and activities, with use cases focusing at once on interactions between agents and systems, and users’ stories taking a broader perspective and introducing interactions along the course of refinements. That makes them complementary:

• Use cases would be the method of choice when new functionalities are to be added to existing systems.
• User stories would be more suited for standalone applications, yet may also be helpful for singling out use cases success scenarios.

Depending on circumstances it may be easier to start with a success story (green lines) and its variants, or with use cases (red characters) with some activities already defined.

Requirements Taxonomy

Sorting requirements is arguably a critical undertaking as the outcome will set tasks and responsibilities along the whole development process. If a straightforward and stable classification is to be found as soon as possible, robust and unambiguous criteria are required:

The first criterion must help to draw a line between business processes and supporting systems:

1. Requirements dealing with symbolic contents (aka Functional Requirements). Given the plasticity of symbolic contents, the granularity of these requirements can be easily adjusted as to coincides with domains under the authority of clearly identified owners or stakeholders.
2. Requirements not dealing with symbolic contents (aka Non Functional Requirements). These requirements target systems features and behaviors and don’t necessarily coincide with the flows of symbolic contents. In that case stakeholders and responsibilities are to be associated with architecture levels: enterprise, functional, technical.

A second criterion is introduced to take into account that requirements are set within enterprise architectures combining business domains, organizational units, and other software systems. Crossing both criteria gives four categories: domain requirements (business), functional requirements (applications), technical requirements (how applications are to be implemented), and quality of service (how applications are to be operated).

Non Functional Requirements

Except for self-contained and standalone applications, requirements are supposed to be abutted on existing systems, and be supported by their resources and mechanisms. While some requirements will be supported by architectures as they are, others may require changes that may affect other existing of future applications. Hence the benefit of characterizing possible non functional requirements with regard to architectural footprint and responsibilities:

Architectural footprints are defined by the shared nature of the components supposed to meet the requirements :

• Non shared component with transient life-cycle (entry points).
• Shared component with transient life-cycle (applications).
• Shared component with persistent life-cycle (business entities).

Non functional requirements should also be classified with regard to authority and responsibilities:

• Enterprise level : business objects and processes; that’s where requirements about organization, regulations and standards will be introduced.
• Systems level: functionalities supporting business objects and processes; that’s where requirements about externally observable qualities are to be defined, e.g authorizations, confidentiality and ergonomics.
• Platforms level: components supporting systems functionalities; that’s for requirements targeting the qualities of artifacts, e.g scalability and maintainability.

It must be reminded that the aim of such classification is to organize actual requirements with regard to given organization and architecture, and not with regard to some theoretical framework.

Feasibility: Requirements vs Capabilities

Feasibility studies try to map system requirements to architecture capabilities; but requirements often mix concerns from different perspectives. It ensues that feasibility studies cannot take architectures boundaries for granted until requirements analysis is completed; and the decisions may even be affected by the way requirements are labelled and analyzed:

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

If all feasibility options (including the HW/SW divide) are to be properly considered, architectures capabilities must be understood as a trade-off between intrinsic parameters. Taking a leaf from the Zachman Framework, those core parameters can be figured out by a pentagon linking locations (Where), agents and roles (Who), functions (How), events and processes execution (When), and symbolic representations (What).

Feasibility can then be analyzed by mapping requirements against combined capabilities, e.g:

• Security (entry points) with regard to confidentiality (domain).
• Compliance (domain) with regard to flexibility (activities).
• Reliability (processes execution) with regard to interoperability (sites configurations).

Since the same core capabilities can be consistently defined across enterprise, systems, and platforms layers, requirements feasibility can be assessed without prejudging architecture decisions.

Requirements Analysis

Whatever their initial format, requirements must eventually be translated into models and programs, the latter being a special kind of the former. In between, and even if many projects don’t require staged development processes, explicit analysis and design will help to identify cross organizational or technical dependencies.

First of all, it must be reminded that the objective of analysis is not to bring requirements to some conceptual level but to map concrete needs rooted in the “here” and “now” of business environments to supporting systems’ existing or planned functionalities. Instead of a hierarchy of abstractions the modeling paradigm will put enterprise, systems, and platforms architectures on a peer-to-peer basis.

Set within that paradigm, the aim of requirements analysis is to build a modeling bridge between enterprise and functional architectures. Using core UML constructs, requirements analysis can be boiled down to a finite set of unambiguous options:

• Domain or Use Case ?
• Actual or Symbolic ?
• Power-type or Sub-type ?
• Object, Aspect, or Attribute ?
• Attribute or Relation ?
• Aggregate or Composite ?
• Inheritance or Delegation ?
• Static or Dynamic Rule ?
• …

It must be noted that those options are not just best practices but are principled guidelines supporting clear-cut decision-making at requirements level, with straightforward consequences at design level.

Rules Analysis

However tangled and poorly formulated, rules make the fabric of requirements, which makes their editing a significant part of requirements analysis. Moreover, given their ubiquity from connectors (references, flows, or transitions) to encapsulated methods, rules may have critical if shrouded consequences for functional or even technical (e.g rules engines) architectures. Hence the need for requirements analysis to clarify rules’ modus operandi and footprint.

Regarding modus operandi, rules can be grouped into three categories:

• Computation rules deal with the neutral processing of symbolic representations; they leave them unchanged and don’t affect agents’ expectations.
• Backward (aka pull) rules are constraints on the consistency of symbolic representations or on the execution of activities. Impact on system behavior, and derived architectural constraints, can be precisely demarcated beforehand.
• Forward (aka push) rules are conditions on when and how activities are to be performed. Possible impact and corresponding architectural constraints cannot be fully ascertained before the rule is executed.

The footprint of a rule is made of the categories of facts to be considered (aka domain), and categories of facts possibly affected (aka co-domain). A naive understanding would assume rules to target either actual or symbolic realms. But given that the objective of modeling is to decide how the former should be represented by the latter, all three configurations should be considered:

• Rules targeting actual contexts. They can be checked through sensors or executed by actuators. Since rules enforcement cannot be guaranteed on non symbolic artifacts, some rules will have to monitor infringements and proscribed configurations. Example: “Cars should be checked on return from each rental, and on transfer between branches.”
• Rules targeting symbolic representations. Their enforcement is supposedly under the full control of system components. Example: “A car with accumulated mileage greater than 5000 since its last service must be scheduled for service.”
• Rules defining how changes in actual contexts should impact symbolic representations: what is to be considered, where it should be observed, when it should be recorded, how it should be processed, who is to be authorized. Example: ” Customers’ requests at branches for cars of particular models should be consolidated every day.”

That classification should be applied as soon as possible because the outcome may have direct consequences with regard to architecture capabilities.

Requirements Threads

Assuming that projects don’t stand in a vacuum, the kind of organizational unit in charge will determine how requirements are managed:

• Application units, for requirements associated with business processes, users, and activities.
• Domain units, for requirements associated with the access to business objects shared by different business units.
• Support units, for non functional requirements.

As befit stakeholders, requirements weaving is to be anchored to identified elements of (respectively) processes, domains, or systems, with attributes and operations introduced iteratively on a need-to-know basis.

Users’ stories and use cases are the two basic approaches for application requirements, the former from a business process point of view, the latter focused on user interaction with systems seen as black-boxes.

Since business domains requirements target symbolic representations shared by different activities,  they are usually more complex than those dealing with applications. Ideally such requirements should lead to services.

Depending on development model, requirements threads may be weaved independently before committing any resource to development (phased), or entwined within iterations combining specifications and development (agile):

• Phased approaches deal with coarse requirements threads and long cycles. They best support the development of architectural features for which planned schedules and sequenced deliveries are critical (p).
• Agile approaches deal with fine requirements threads and short cycles. They best support the development of business features for which users value and adaptability are critical (a).

In both cases trade-offs will have to be set regarding scope vs granularity, visibility vs the length of cycles, schedules and budgets. But the mechanisms are different: with phased approaches product deliveries are driven by schedules set upfront along fixed sequences; with agile approaches product deliveries are driven by quality status with priorities and sequences reassessed at regular intervals.

Requirements Metrics

Being set between business processes and supporting systems, requirements are best positioned to assess ROI by comparing business value to development costs. As far as engineering is concerned, measurements of development costs must be based on the size and complexity of business and functional requirements, namely:

• Interactions with users, identified by primary roles and weighted by activities and flows (a).
• Access to business (aka persistent) objects, weighted by complexity and features (b).
• Control of execution, weighted by variants and couplings (c).
• Processing of objects, weighted by variants and features (d).
• Processing of actual (analog) events, weighted by features (e).
• Processing of physical objects, weighted by features (f).

Function points are the widely agreed outcome which combines intrinsic (business domain and logic) with functional (system contribution) size and complexity. The results have to be adjusted with regard to non functional requirements.

Requirements & Function Points

Despite their lack of across-the-board accuracy, Function Points remain the only objective basis of software metrics. Yet, as comprehensively explained by Alain Abran (Software Metrics & Software Metrology),  they are usually obtained from a confusing mix of inputs and measurements:

• Different kind of inputs: business contents, system functionalities, general systems characteristics.
• Different kind of measurements: objective tally, subjective guesses, and statistical regressions.

As it happens, much of those flaws can be mended by reorganizing the elements with regard to their basis:

1. The complexity of a business domain can be assessed independently of supporting systems functionalities. That would be measured by function points of requirements targeting identified artifacts by business domains and activities (respectively DFP and AFP).
2. For a given business process, the objective is to assess and compare alternative functionalities. That would be measured by function points for users’ transactions (UCFP).
3. Functional measurements may have to be adjusted with regard to quality of service or technical requirements. Those than can be circumscribed to specific domains (e.g privacy) or activities (e.g transaction rate) should be incorporated into primary function points (when translated into adjusted functionalities); otherwise they would be dealt with at system level.
4. Operational and quality of service requirements set at enterprise level are meant to be supported by technical architectures. As a consequence the corresponding adjustment factors should not be introduced until development effort is considered.

Given function points adjusted for non functional requirements, development effort will be assessed depending on organizational and technical contexts and resources.

Requirements Platform

Requirements are meant to define enterprise expectations with regard to IT support. While not much can be assumed about their format on the business side, requirements once analyzed are supposed to easily translate into normalized system functional specifications. That could be achieved by a requirements platform supporting two modeling capabilities.

The syntactic capability should be built from a subset of UML constructs with consolidated definitions that to be applied uniformly whatever the semantics:

• Objects or activities: persistent or transient representations identified on their own or as parts of a whole.
• Power-types describing variants of objects (classifications) and activities (extension points).
• Features (attributes or operation).
• Strong and weak structural connectors between instances (composition or aggregation) and types (inheritance)
• Functional connectors between physical objects (channels), symbolic objects (references), activities (flows), and execution states (transitions).

The semantic capability would use the syntactic one to build models along component and architecture dimensions, the former dealing with internal structures, the latter with requirements targeting units identified across enterprise architecture:

• Views: interfaces with agents, devices, and other systems.
• Business logic: processing of business objects within execution units (stateless control).
• Process control: synchronization between execution units (stateful control).
• Business domains: shared business objects (model).

Beyond possible naming discrepancies, the semantics of the associated modeling paradigm would make that platform fully compatible with modeling languages like BPMN or UML.

Further Reading

• How to Begin with Requirements
• Requirements Capture
• Requirements Taxonomy
• Requirements & Architecture Capabilities
• Requirements Analysis
• Requirements Threads
• Requirements & Value Chain
• Requirements Metrics Matter
• Use Cases
• Non Functional requirements
• Making the rules
• Requirements Platform
• From Requirements to Function Points

External Links

• i*
• Formality in software requirements, JEAN-MICHEL BRUEL, SOPHIE EBERSOLD, FLORIAN GALINIER, ALEXANDR NAUMCHEV, MANUEL MAZZARA, BERTRAND MEYER.