Requirements Threads

Objectives

Projects are supposed to be rooted in requirements, but how are requirements to be captured ?  As the Good Book says “In the beginning was the word …”, but Gabriel García Márquez counters that at the beginning “The world was so recent that many things lacked names, and in order to indicate them it was necessary to point. ”

Obviously system requirements are not manna from heaven, in other words they do not come to the world as models. As they happen, neither words nor objects can be taken for granted: names may not be adequately fixed to denoted objects, and pointed objects may still waiting to be named. Hence, requirements at their very beginning are just a flux of assertions, conditions and consequences, and the aim of requirements analysis is to spin the threads and weave them into a fabric with clear and non ambiguous motifs, without making any prior assumption of what that may be. Fortunately, that can be achieved with the spinning-jenny of requirements capture, namely hypertext editors.

Assuming language barriers have been removed by requirements capture, requirements management faces three major stumbling blocks:

• Transparency and traceability: all along the development process one should be able to justify both the tasks and the options.
• Accountability: every deliverable should be traced back to a stakeholder (who asked for that) and a customer (who will accept it).
• Relevance: no requirement should be taken into account before an accurate assessment of its bearing on the development process, namely why and when is this  item to be used.

For that purpose, the fabric of requirements should be weaved into identifiable motifs made of a finite set of threads.

Who’s In The Loop

Four types of players may appear in requirements loops:

• Stakeholders (one by project) set the context and objectives with pictures, photos or drawings. Textual descriptions are not allowed. Stakeholders accept or reject artifacts.
• Users and business analysts add to the stakeholder requirements using the same media (no texts); they also may qualify model artifacts with formal expressions, constraints or rules.
• System analysts suggest artifacts.
• Architects (one by project) accept or reject qualifications on artifacts.

Single vs Multiple Motifs

Even for standalone applications, it’s safe to assume that requirements will have to take into account factors and constraints not directly under the responsibility of the project. As a consequence motifs may overlap,  either at business or functional level, which means that some threads will have to be managed in collaboration with outsiders.

• First one should identify functional requirements that can be fully defined and accepted by the unit in charge. Depending on the unit, they may be specific or meant to be (re)used, but even if their outcome is shared, those requirements can be managed under a single responsibility.
• That is not the case when a project has to deal with a mix of functional and business requirements. If the latter is to be (re)used by different business processes corresponding requirements will have to be consolidated.
• Finally, one may have to consider non functional requirements dealing with performances, resources or any constraints involving support units.

It must be reminded that requirements are seldom neatly expressed along architectural concerns for enterprise (business requirements), systems (functional requirements) and implementations (non functional requirements). The challenge is therefore to identify the different threads and allocate responsibilities accordingly.

Guiding Threads

Assuming that requirements don’t stand in a vacuum, their inception can be sourced to one of three basic kind of organizational unit.

• Operational units, for requirements associated with business processes, users, and activities.
• Domains units, for requirements associated with the persistency of business objects shared by different activities.
• Support units, for requirements set at corporate level and/or shared by different business units (non functional requirements).

Given the organizational unit in charge, requirements weaving is to be driven by the identification of anchors, with attributes and operations introduced iteratively on a need-to-know basis.

Use Case Threads

Use Cases provide a straightforward approach to requirements due to their simple formalism and their focus on user interaction with systems seen as black-boxes. Once business objective and expected outcome defined, requirements should be organized as follows:

1. Identify primary and secondary players (agents, systems, or devices) and their roles. Define contexts: entry points (a), event features (b), and I/O data flows (c).
2. Identify functional units from constraints on communication channels (a), events (b), or persistency units (c). Define respective conditions on state of symbolic objects, agents authorizations, and events features.
3. Consolidate descriptions of activities with operations and variants for active objects (a), data (c) and control (b) flows .
4. Complete functional units with execution constraints: states of physical (a) and symbolic (c) objects, control table and transitions (b).

While inner threads for attributes and operations are run independently of the main one, a secondary thread may simultaneously deal with requirements coming to light with specific use cases yet subject to a broader perspective (aka non functional requirements):

• Standards for user interfaces or devices connections.
• Supporting communication architecture.
• Access to persistent objects, for instance confidentiality.
• Management of business rules.
• Operational requirements: frequency, volumes, security, etc.

Domains Threads

Since they are meant to specify symbolic representations shared by different activities, requirements targeting business domains are usually more complex than those dealing with use cases. Once business concerns and the semantics of targeted objects and activities defined, requirements should be organized as follows:

1. Identify physical objects for which some information will have to be managed: passive objects, agents, information and control systems.
2. Identify events that will have to be recorded: external (from roles), control flows (from activities), transitions (from process execution).
3. Consolidate symbolic descriptions of physical objects and events records with the descriptions of notional (non physical) objects based upon their use by agents (value objects or views), activities (references) and processes control (state variables).
4. Complete with attributes and partitions for roles (authorizations), activities (integrity constraints), and processes (triggered updates).

Aspects are set by the crisscrossing between domains and use cases; as such they may be used as a transition between requirements and system analysis.

Non Functional Threads

Requirements that cannot be confined to specific needs and permeate a wider range of system functionalities are usually regrouped as non functional requirements. Some will be specified directly and managed by projects set independently, others will first appear in association with specific requirements and their threads will have to be set apart.

Spinning the Threads

Obviously system requirements don’t spring up as models, and even anchors cannot be taken for granted: names may not be adequately fixed to objects, and objects may still waiting to be properly named. More often, requirements at their very beginning will be made of few identified anchors floating in a flux of assertions, conditions and consequences, and the aim of requirements analysis is to weave them into a fabric with clear and non ambiguous motifs without making any prior assumption of what that may be.

However tangled and poorly formulated, constraints and rules provide the rough material to be spun into requirements threads.

• Requirements are made of textual assertions, conditions, classifications, and rules.
• Depending on responsibilities or physical context, requirements can be allocated to symbolic (organizational units) or actual (locations) containers.
• Textual requirements must then be associated to stereotyped anchors which may have been suggested or have to be newly identified.
• As is well known, spinning is not an exact science and rules can be formulated differently depending on context and concern. Hence the necessity to iterate requirements analysis until business and functional threads coincide.

Primary and Secondary Threads

Physical or symbolic, objects and activities are set by concerns. Some may be local to enterprises, some defined by common business activities, and some set along a broader social perspective. While the continuity of business objects and processes has to be supported by consistent and comprehensive identities, that’s not the case for roles and features whose elements and semantics may differ with concerns change with business opportunities.

The first step is therefore to identify the organizational units responsible for domains, objects identities and semantics:

• Domains in charge of identities will govern objects life-cycle (create and delete operations) and identification mechanisms (fetch operations). That would target objects, agents, events and processes identified independently of systems.
• Domains in charge of semantics will define objects features (read and update operations). That would target aspects and activities rooted (aka identified) through primary objects or processes.

Along the same reasoning it may be useful (but not necessary) to assign specific responsibilities to specific project participants:

• Stakeholders and project managers set the perimeters of domains and processes.
• Business analysts identify the primary threads and help users to identify and detail the secondary ones.
• System analysts validate corresponding artifacts taking into account existing functionalities.
• Architects validate functional architectures taking into account existing systems.

Say What You Mean, Mean What You Say

Language and meanings may be baffling bedfellows, as what is said is not necessarily what is meant. Moreover, as even candid storytellers can make stories, iterations and simple communication rules should be used to clarify meanings and eliminate possible Rashomon effects.

Trade-offs

By nature requirements start with tohu-bohu and wind up in harmony. Depending on methods, that can be done fully upfront before committing any resource to development, or entwined within iterations combining specifications and development:

• 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;  yet mechanisms will be very 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.

In order to get the best of each approach requirements threads should therefore distinguish between architectural and business threads.

From Requirements Footprint to Project Blueprint

Organizing requirements along primary and secondary threads will bring benefits for the whole engineering process.

• The distinction between objects identity and aspects brings requirements and models under a common object-oriented roof.
• That provides built-in transparency and traceability all along development flows.
• Artifacts being associated to primary and secondary threads, models can be sequenced and development flows optimized according built-in constraints.
• Since primary and secondary threads are mapped to organizational responsibilities,  work units can be directly associated to artifacts and planned according implicit responsibilities.
• Requirements patterns provide the rationale for development profiles and strategies.

That will be especially useful to distinguish between projects that can be developed on their own and those that will affect shared execution or persistency units.