Objective
Whatever the approach, software engineering starts with requirements; that’s where the divide between business and engineering realms is to be found, for concepts as well as concerns:
- Concepts: multiple understandings of business domains as opposed to the single semantics of software design.
- Concerns: business value and time-to-market as opposed to engineering constraints and development costs.
Hence the benefits to be found in an open-source environment for collaborative requirements capture in terms of scope, time, and price. Such an environment should aim at:
- Simplicity: few concepts with unambiguous semantics.
- Transparency: shared understanding of requirements on both sides of the business/system divide.
- Method neutrality: both agile and phased development models must be supported.
- Reuse: built-in traceability of development assets along application life-cycle.
- Interoperability: integration with business modeling and development tools.
Where to begin: From Business Processes to Symbolic Representations
Requirements define enterprise expectations with regard to IT support. Hence the importance of a clear distinction between the description of business context and processes on one hand, the symbolic objects to be managed by supporting systems on the other hand.
It’s worth to precise that those two descriptions should not be seen in terms of abstraction levels but as complementary descriptions at the basis of enterprise architecture.
How to begin: Basic Constructs
Raw inputs (initial requirements) can be introduced as plain or hyper text, possibly structured into lists or hierarchies using standard syntactic constructs. They are supposed to come with a dictionary of existing artifacts that will provide the context to be referenced.
The objective being to translate raw requirements into lean and unambiguous models, the proposed solution makes a distinction between syntactic constructs and semantics.
The syntactic constructs are a subset of UML with consolidated definitions to be applied uniformly:
- 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).
On that basis models can be introduced as flat networks of nodes and connectors before being detailed into structures.
Connectors (association, flow, transition, or channel) may also be structured using standard operators, opening the door to built-in consistency checks between nodes and connectors structures.
What does it means: Stereotyped Semantics
Assuming requirements can be consolidated into well-formed syntactic constructs, the objective is to add stereotyped semantics and map them to architecture capabilities:
- Who: agents (human or otherwise) and roles.
- What: symbolic representations of objects, events, roles, or activities.
- How: business logic.
- Where: organizational units and locations
- When: events and processes execution states.
Those basic stereotypes can be refined as to take into account functional contexts: nature of event, state, role, …
By convention, objects, events and roles should be labelled with singular nouns, activities with infinitive verbs, and processes with present progressive ones. Containers should be named using plurals.
Modeling Perspectives: Architecture vs Component
Models are to be organized along two perspectives: architecture and component. Architecture oriented requirements deals with the collaboration between components identified at architecture level:
- 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).
Component oriented requirements use structures and inheritance to define the features and behaviors of components independently of their use in architectures.
Either way, requirements can be fully documented with regard to their nature and context.
A requirements taxonomy must serve a clear purpose, in that case (a) identify the impact on users’ experience and, (b) help to decide who should take charge. Hence the distinction between four categories: business, functional, technical and Quality of service.
Moreover, requirements should always be set in the context of development assets.
For instance:
- A new scenario is added (functional requirement), to be implemented within an existing application (technical requirement).
- This scenario adds new rules to an existing process (business requirement); process control and business objects are not affected providing constraints on response time are satisfied (Quality of service).
Patterns
As compared to the maturity, acceptance and effectiveness of design patterns, advances of their analysis counterpart remain very limited, and for good reason: contrary to forward-looking design patterns, aiming at systems built with shared engineering concepts and concerns, the aim of backward looking analysis patterns is to describe specific domains and objectives, arguably a much more challenging task.
Yet, that intrinsic difficulty can be reduced by two distinctions, one between business and functional requirements, the other between component and architecture perspectives.
Business vs Functional patterns. The former looks at domains, organization, and processes, the latter looks at the role of supporting systems. While a consensus about business objectives and solutions can arguably appear as a mirage, systems interoperability is a legitimate and realistic objective, and so are associated patterns of functionalities.
Component vs Architecture. The former deals with the structure and features of functional units, the latter with their roles within systems architectures. That distinction between structures and behaviors is already well established, especially with design patterns. Moreover it coincides with the UML# distinction between syntactic constructs and stereotyped semantics.
Mapping requirements to patterns of functionalities will significantly improve traceability, quality, reuse, and model transformation.
Moreover, linking functional and design patterns will help to align design with requirements and will leverage the proven benefits of design patterns to the whole development process.
Who’s in the Loops
Given the objective of neutrality with regard to organization and methods, participants are defined by their role with regard to context and concerns:
- Enterprise and system architects provides dictionaries for their respective realms.
- Business and system analysts categorize, transform and edit requirements.
- Validation for organization and functionalities can be done by architects or quality specialists.
What’s in the Loops
Since nothing can be presumed with regard to formalism, stories appear as the least constraining assumption for initial requirements. Hence the importance of anchoring requirements to contexts and concerns:
- Contexts are set by dictionaries which must provide symbolic containers (aka packages) for identification mechanisms and features semantics. Dictionaries may also include references to existing artifacts.
- Concerns are expressed by nominal users and clearly defined objectives.
The proposed approach is built on the postulate that requirements must be rooted in actual business concerns before being transformed into abstractions. As a corollary, specialization and generalization should be limited to the component perspective and be introduced only for clear and specific modeling purposes.
The initial loop should focus on the identity of users and targeted objects. For instance, horses, carts, and customers.
Symbolic representations must be introduced for every identified element of business context meant to be managed individually: roles, actual or contractual objects, events or activities.
The activity is named and carts must be registered. A suggestion to register horses is rejected. Access for customers is deferred.
Partitions, parts, features (attributes or operations) and connections are added iteratively, with the comprehensiveness and consistency of identification constructs continuously and automatically checked.
As noted above, specialization and generalization should only be used within the component perspective: specialization to further partitions and power-types, generalization to consolidate new requirements with existing applications.
Running Cycles
Modeling sessions should be identified by an anchor (object, activity, role, or event) and a perspective (component or architecture); their outcome should provide a consistent and unambiguous specification of their scope, for instance:
- Use cases (architecture perspective) will start with triggering events and proceed with actors and activities, possibly with reference to business objects (a).
- Business application (component perspective) will start with alternative outcomes (e.g using activity diagrams) and proceed with methods, interfaces and sub-types (b).
- Business objects (component perspective) will start with structures and partitions and proceed with features, associations and sub-types (c).
Modeling sessions can be driven by scope or set in fixed envelopes. When driven by scope, cycles are repeated for all associated artifacts along the selected perspective until nothing can be added (using basic constructs) without introducing ambiguity.
Taking a leaf from agile book, sessions can also be run within time-boxes, with symbolic anchors under consideration managed in backlogs. Alternatively, envelopes could be defined by a fixed number of function points.
In any case, the objective would be the dynamic ranking of backlogs with regard to users’ value on one hand, architecture layers and functionalities assessment on the other hand.
Assessment, Pricing and Market Place
As noted above, requirements stand on the divide between two valuation contexts, business and engineering. All too often that distinction is ignored in the assumption (implicit or explicit) that the two valuations will be congruent. A more reasonable policy would be to acknowledge the difference and use negotiation to iron out the discrepancies.
As with any negotiation, and assuming clear understanding and good faith, success depend on non overlapping concerns, formally known as non-zero sum games.
All in all, business stakeholders and project managers have to agree on scope, time, and price.
From their business perspective, stakeholders will consider expected business value (as they assess it) and costs (a negotiated variable), the former being dependent on time to market, the latter being affected by architectural options. From their engineering perspective, project managers will consider resources and schedules.
Deciding at inception on scope, time, and price has proven to be a very hazardous policy:
- Given the inverse relationship between the level of details and the time-span on one hand, the reliability and stability of requirements on the other hand, there isn’t much to support informed decision-making upfront.
- With scope, time, and price fixed upfront, quality becomes the only adjustment variable and may easily turn into a collateral damage when set along mounting costs and scheduling constraints.
Combining agile principles and model driven development, the objective is to use itemized requirements in order to build models iteratively with respect to scope, time, and price. Taking advantage of dynamic ranking, business and engineering valuations can be reviewed between cycles according their non identical priorities, the objective being to reduce differences by updating valuations and rearranging backlogs.
What next ?
While these objectives may appear very ambitious, they are supported by a set of clear and consistent concepts and blueprints. Nonetheless, this is a work in progress that can only be achieved through the collaboration of many different actors, bringing both expertise and resources. To name a few:
- Service providers: to define and manage services to final users.
- Tools providers: to customize their tools.
- Integrators: to provide the on-line environment and host the service providers.
All could significantly contribute to- and benefit from- that project.
Oh, I must have forgotten to check “notify me” and only now was made aware of the comments here.
Here are some additional thoughts:
“Then, stakeholders are not supposed to translate requirements into models.”
Remy, I agree, going even further to say “stakeholders are not supposed to create requirements” — they are supposed to provide the information for a skilled BA to produce the requirements for them. But that does not mean stakeholders aren’t supposed to understand the language being used to document and organize requirements and translate them into models. That’s my concern here, that stakeholders will be alienated if they have to start to learn a whole new world of terminology just to understand what’s going on as you define a solution. (Example, “power types” is a term that most people involved in software projects will not be familiar with — and I’m not convinced they need to.)
Putcha, I’m flattered that you have such a high opinion of my skills.
I’m actually a trained engineer with a B.S. in electrical engineering, married to another engineer (now computer scientist), who agrees that software engineering is a field that hasn’t moved away entirely from an art form to a true engineering discipline (and who knows if it will ever do).
Sometime ago a consultant I highly admire recommended the book “Impact Mapping: Making a big impact with software products and projects” by Gojko Adzic. I think it is a great resource for all BAs interested in developing their analytical toolbox (it does reflect the way I practice business analysis). The book also contributes to the discussion happening here, serving as a useful example of how simple ideas, with not a lot of intricacies, can often make a larger impact than very elaborate constructs trying to cover everything.
For anyone interested in the book, you can start by checking the author’s website: http://www.impactmapping.org/index.php.
AA: I have been an admirer of Remy and Adriana. In principle “Text in most natural languages” is a master medium for expression but one cannot be sure of the “speed and precision” of what it conveys to a reader and it matches what the author intended.
BB: IIBA and IREB devote themselves to “Business & User Requirements” but they have not arrived at any breakthrough fundamental and useful principles (IIBA Core Concept Model has good aim. Let’s see how it evolves).
CC: I have not understood what Remy has brought out. It may be long and elaborate but it may still be simple and easy to use — I hope it is so.
DD: As Mary Shaw has pointed out, software engineering is critically dependent on “virtuoso performance” of what I call “the versatile software artists (of Adriana kind) who are not engineers”. Engineering has to ensure that the artifacts generated by a minimally trained artisan using well defined methods and tools are within specified tolerances on all key factors irrespective of the knowledge and skill of the artisan beyond the qualification criteria.
EE: Adriana can take credit for her achievements but NOT transfer it to her toolbox unless an average BA or RE or SE using the toolbox also achieves the same results.
FF: I would be keen to work with Remy for the success of CC. I hope Adriana would make some tools of her toolbox work in the hands of artisans and donate those tools to CC.
Cheers and best wishes,
Putcha
01OCT13
Adriana,
First, there are very few concepts, much less than any existing method, and all obtained by consolidation of well accepted ones.
Then, stakeholders are not supposed to translate requirements into models.
Third, while I’m sure you do perfectly well with your toolbox, I’m also sure that your personal expertise is a primary factor.
Remy,
In my opinion this model entirely violates the stated principle “Simplicity: few concepts with unambiguous semantics.”
I’m afraid this model is way too complicated for the average project stakeholder to learn and apply. I work in multiple concurrent software projects, and so far I haven’t seen a need to add more constructs than what we currently use: textual requirements augmented by appropriate models such as state diagrams, decision trees, etc.
Just thought I’d leave my feedback here as one additional input for what you are trying to achieve.