RequirementsFromStoriesToModels

Requirements : From Stories to Models

Summary

If programmes are seen as models of implementations, the main challenge of software engineering is to translate requirements into models. But while programmes are written with formal languages supporting some kind of verification and execution, nothing can be assumed about requirements apart from being stories told by whoever will need system support for whatever he has to do.

Along that reasoning, one may consider the capture and analysis of requirements under the light of two archetypal motifs of storytelling, the Tower of Babel and the Rashomon effect:

  • While users requirements are generally expressed with domain specific languages, supporting applications are designed by software engineers using a fundamentally different family of languages;
  • Business units may share a language yet differ with understandings; their requirements will initially reflect concrete and specific business contexts and concerns, before having to be consolidated into systems functionalities.

Hence the importance of managing requirements according to languages and narratives differences.

Business to System Analyst: your language or mine ?

Stories must be told before being written into models, and that distinction coincides with the one between spoken and written languages or, on a broader perspective, between direct (aka performed) and mediated (aka document-based) communication.

If the objective of requirements analysis is to transform stories into structured activities to be supported by systems, the inflexion point is their sequencing, i.e their slicing into meaningful segments.

Direct communication (by voice, signs or mime) is set by time and location and must convey contexts and concerns instantly; that’s what happens when requirements are first expressed by business analysts with regard to actual and specific goals.

Direct communication requires instant understanding

 

 

 

 

 

 

 

 

Direct communication requires instant understanding

Written languages and document-based communication introduce a mediation, enabling stories to be detached from their native here and now; that’s what happens with requirements when managed independently of their original source.

Kanji charaters can support document-based communication

 

 

 

 

 

 

 

 

Kanji charaters can support document-based communication between different spoken languages.

The mediation introduced by documented requirements can support two objectives:

  • Elicitation: while direct communication calls for instant understanding, through a common language or with the help of an interpreter, written communication makes room for translation and clarification. And when symbolic representations are introduced, as illustrated by Kanji characters, a single written language can be used as a bridge between different spoken ones. Such modeling capability would clearly enhance communication           between business and system analysts;
  • Analysis: since understanding doesn’t necessarily mean agreement, mediation is often necessary in order to conciliate, arbitrate or consolidate requirements; hence the benefits of working with written symbolic representations.

Depending on the languages used to tell the stories and the gamut of concerns behind them, the path from stories to models may be covered in a single step or it will have to mark the two steps of elicitation and analysis.

In any case, when stories are used to describe how business is to be supported by systems, they first have to be anchored to business roles and objectives.

Actors & Goals

Being rooted in actual contexts, direct communication entails identified agents, objects and phenomena. Using stories to express requirements should therefore begin by identifying actors and goals:

  • Every story is supposed to be told from a specific point of view set within the enterprise organisation, and expressed by a single actor, even if other participants may be involved;
  • While details of business objects and rules may have to be refined or even changed, stories must be identified by a single goal defined in relation to business objectives and situation. Once anchored to actors and events and bracketed between pre-and post-conditions, stories have to be fleshed out with detailed activities.

Scripts & Splits

If the objective of requirements analysis is to transform stories into structured activities to be supported by systems, the inflexion point is their sequencing, i.e their slicing into meaningful segments.

For that purpose the best approach is to use Aristotle’s three units rule for drama:

  • Unity of action: story units must have one main thread of action identified by a single goal. Subplots, if any, must return to the main plot after completion;
  • Unity of place: story units must be located into a single physical space where all activities can be carried out without depending on the outcome of activities performed elsewhere;
  • Unity of time: story units must be governed by a single clock under which all happenings can be set on a single time-scale.

Those rules can be used to segment stories and keep them small:

  • Action: splits are made to coincide with variants set by agents’ decisions or business rules;
  • Place: splits are made to coincide with variants in physical contexts as defined by communication constaints;
  • Time: splits are made to coincide with variants in execution constraints.

When stories refer to systems, those constraints should become more specific and coincide with interaction units triggered by a single event from a leading actor.

Flesh & Repeat

Business contexts, objectives and roles are meant to be uniquely and consistently defined at enterprise level, independently of supporting systems.

That’s not the case for the details and semantics which may differ across business units. That difficulty can be managed through iterative development adding specifics to stories providing they are kept within the casing invariants:

  • Each story is developed as a loop whose invariants are defined by its goal, pre-conditions, place and time-scale;
  • Development proceeds by iterations whose scope and semantics are circumscribed by the invariants: operations are relative to activities, features are relative to objects, events are    relative to time-scales.

A story is fully documented and the loop exited when no more details can be added without breaking the three-units rule or affecting its primary character (role and goal) or features semantics (attributes and operations).

Iterations: a story is fully fleshed out

 

 

 

 

 

 

 

 

Iterations: a story is fully fleshed out when nothing can be changed without affecting characters’ features or their semantics.

Documenting Stories

As far as requirements engineering is considered, stories are to be written down, either through text, model, or code:

  • Text-based documentation uses natural language, usually with hypertext extensions. When analysts are not familiar with modeling languages, it is the default option for elicitation and the delivery of comprehensive, unambiguous and consistent requirements;
  • Models use dedicated languages targeting domains (specific) or systems (generic). They are a necessary option when requirements from different sources are to be consolidated before being developed into code;
  • Code (aka executable models) use dedicated languages targeting execution environments.

It is the option of choice when requirements are self-contained (i.e not contingent to external dependencies) and expressed with formal languages supporting automated translation.

With regard to engineering, the aim of models is to manage the information contents of requirements along the development process.

Whatever their form (user stories, use cases, hypertext, etc), documented requirements must come out as a list of detached items with clearly defined dependencies. Depending on dependencies, requirements can be directly translated into design (or implementation) models or will have to be first consolidated into analysis models.

Engineering: From Analysis to Design

With regard to engineering, the aim of models is to manage the information contents of requirements along the development process. Apart from deployment ones, those contents can be of two breeds:

  • Analysis models are used to describe the different aspects of the problems under scrutiny as well as the part to be played by supporting systems;
  • Design models (including programmes) are used to describe the software artifacts meant to solve the problem, i.e. the surrogates to be used by supporting systems.

Analysis models deal with features of concern

 

 

 

 

 

 

 

 

 

Analysis models deal with features of concern, Design models deal with their surrogates.

In both cases models are to support communication of symbolic descriptions.

Models will be required for communication across organisational structures (business and systems, analysts as well as development tools) or intervals of time.

Sign up to our newsletter for free

 

 

 

 

As for model contents, one can take a leaf from Davis, Shrobe and Szolovits:

  • Surrogates: models must describe the symbolic counterparts of actual objects, events and relationships;
  • Ontological commitments: models must provide sets of statements about the categories of things that may exist in the domain under consideration;
  • Fragmentary theory of intelligent reasoning: models must define what artifacts can do or can be done with;
  • Medium for efficient computation: models must be understandable by computers;
  • Medium for human expression: models must provide for ergonomic interaction with users.

That approach brings together software engineering, knowledge management and story telling.





There are no comments

Add yours

This site uses Akismet to reduce spam. Learn how your comment data is processed.

x
freshmail.com powered your email marketing