Requirements Capture

Objective

Requirements are not manna from heaven, they do not come to the world as models. So, where to begin ?  According to John,  “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. “

Frog meditating on representations capture (Sengai)

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

Confronted with lumps of words, assertions and rules, requirements capture may proceed with one of two basic options: organize requirements around already identified and structured objects or processes, or listen to user stories and organize requirements alongside. In both cases the objective is to spin words into identified threads (objects, processes, or stories) and weave them into a fabric with clear and non ambiguous motifs.

From Stories to Models

Requirements capture epitomizes the transition from spoken to written languages as its objective is to write down user expectations using modeling languages. Just like languages in general, such transitions can be achieved through either alphabetical of logographic writing systems, the former mapping sounds (phonemes) to signs (glyphs), the latter setting out from words and mapping them to symbols associated with archetypal meanings; and that is precisely what models are supposed to do.

As demonstrated by Kanji, logographic writing systems can support different spoken languages providing they share some cultural background. That is more or less what is at stake with requirements capture: tapping requirements from various specific domains and transform them into functional requirements describing how systems are expected to support business processes. System functionalities being a well circumscribed and homogeneous background, a modeling framework supporting requirements capture shouldn’t be out of reach.

Getting the right stories

If requirements are meant to express actual business concerns grounded in the here and now of operations, trying to apprehend them directly as “conceptual” models would negate the rationale supporting requirements capture. User stories and use cases help to prevent such misgivings by rooting requirements in concrete business backgrounds of shared references and meanings.

Yet, since the aim of requirements is to define how system functionalities will support business processes, it would help to get the stories and cases right upfront, in other words to organize them according patterns of functionalities. Taking a cue from the Gang of Four, three basic categories should be considered:

• Creational cases or stories deal with the structure and semantics of business objects whose integrity and consistency has to be persistently maintained independently of activities using them. They will govern objects life-cycle (create and delete operations) and identification mechanisms (fetch operations).
• Structural cases or stories deal with the structure and semantics of transient objects whose integrity and consistency has to be maintained while in use by activities. They will govern features (read and update operations) and target aspects and activities rooted (aka identified) through primary objects or processes.
• Behavioral cases or stories deal with the ways objects are processed.

Not by chance, those categories are consistent with the Object/Aspects perspective that distinguish between identities and objects life-cycle on one hand, features and facets on the other hand. They are also congruent with the persistent (non-transactional)/transient (transactional) distinction, and may also be mapped to CRUD matrices.

Since cases and stories will often combine two or three basic categories, they should be structured accordingly and reorganized as to coincide with the responsibilities on domains and projects defined by stakeholders.

User Stories vs Use Cases

Other than requirements templates, user stories and use cases are two of the preferred methods for capture requirements. Both put the focus on user experience and non formal descriptions, with use cases focusing at once on interactions between agents and systems, and user stories introducing them along the course of refinements. That make them complementary:

• Use cases should be the method of choice when new functionalities are to be added to existing systems.
• User stories would be more suited to standalone applications but may also be helpful to single out use cases success scenarii.

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

Combining user stories and use cases for requirement capture may also put the focus on system footprint, setting apart the activities to be supported by the system under consideration. On a broader perspective, that may help to position requirements along architecture layers: user stories arise from business processes  set within enterprise architecture, use cases are supported by functional architecture.

Spinning the Stories

Given that the aim of requirements is to define how systems will support processes execution and objects persistency, a sound policy should be to characterize those anchors meant to be targeted by requirements nouns and verbs. That may be achieved with basic parsing procedures:

• Nouns and verbs are set apart and associated to candidates archetypes for physical or symbolic object, physical or symbolic activity, corresponding container, event, or role.
• Among them business concerns should point to managed individuals, i.e those anchors whose instances must be consistently identified by business processes.

Finally business rules will be used to define features whose values are to be managed at instances level.

Parsing nondescript requirements for anchors will set apart a distinctive backbone of clear and straight threads on one hand, a remainder of rough and tousled features and rules on the other hand.

Fleshing the Stories out

Archetypes are like clichés, they may support a story but cannot make it. So it goes with requirements whose meaning is to be found into the intricacy of features and business rules.

However tangled and poorly formulated, rules provide the substance of requirements as they express the primary constraints, needs and purposes. That jumble can usually be reshaped in different ways depending on perspective (business or functional requirements),  timing constraints (synchronous or asynchronous) or architectural contexts; as a corollary, the way rules are expressed will have a significant impact on the functional architecture of the system under consideration.

If transparency and traceability of functional arbitrages are to be supported, the configuration of rules has to be rationalized from requirements inception. Just like figures of speech help oral storytelling, rules archetypes may help to sort out syntax from semantics, the former tied to rules themselves, the latter derived from their targets. For instance, constraints on occurrences (#), collections (*) or partitions (2) should be expressed uniformly whatever their target: objects, activities, roles, or events.

As a consequence, and to all intents and purposes, rules analysis should not only govern requirements capture, it should also shadow iterations of requirements analysis, each cycle circumscribed by the consolidation of anchors:

• Single responsibility for rule implementation: project, architecture or services, users.
• Category: whether a rule is about life-cycle, structure, or behavior.
• Scope: whether enforcement is transient of persistent.
• Coupling: rules triggered by, or bringing change to, contexts must be set apart.
• Control: whether enforcement has to be monitored in real-time.
• Power-types and extension points: all variants should be explicitly associated to a classification or a branching rule.
• Subsidiarity: rules ought to be handled at the lowest level possible: system, domain, collection, component, feature.

Pricing the Stories

One of the primary objectives of requirements is to put a price on the system under consideration and to assess its return on investment (ROI). If that is straightforward for hardware and off-the-shelf components, things are not so easy for software developments whose metrics are often either pragmatic but specific, or  inclusive but unreliable.

Putting aside approaches based on programs size, both irrelevant for requirements assessment and discredited as development metrics, requirements can be assessed using story or function points:

• Story points conduct pragmatic assessments of self-contained stories. They are mostly used locally by project teams to estimate their tasks and effort.
• Functional metrics are more inclusive as based on principled assessment of archetypal system functionalities. Yet they are mostly confined to large organizations and their effectiveness and reliability highly depends on expertise.

Whereas both approaches start with user expectations regarding system support, their rationale is different: function points (FPs) apply to use cases and take into account the functionalities supported by the system; story points (SPs) apply to user stories and their scope is by definition circumscribed. That difference may be critical when categories are considered: points for behavioral, structural and creational stories should be weighted differently.

Yet, when requirements capture is supported both by stories and use cases, story and functions points can be combined to obtain functional size measurements:

• Story points are used to assess business contents (aka application domain) based on master data (aka persistent) entities, activities, and their respective power-types.
• Use case points target the part played by the system, based on roles and coupling constraints defined by active objects, events, and controlling processes.

Non adjusted function points can then be computed by weighting use case function points with the application domain function points corresponding to use case footprint.

Further Reading

• Thread
• How to Begin with Requirements
• Requirements Rounds up
• Requirements Taxonomy
• Requirements & Architecture Capabilities
• Requirements Analysis
• Requirements Threads
• Requirements Metrics Matter
• Use Cases
• Non Functional requirements
• Making the rules
• Requirements Platform
• From Requirements to Function Points
• How to Mind a Tree Story
• From Stories to Models
• Agile Business Analysis: From Wonders to Logic
• Spaces, Paths, Paces (Part 1)
• Spaces, Paths, Paces (Part 2)
• Business Stories: Stakeholders’ Plots & Users’ Narratives

External Links

• John Sowa, “Signs and Reality”
• Karl Wiegers Describes 10 Requirements Traps to Avoid
• Reinventing Agile: From Value to Solutions