Principles
Whereas it is based upon well known concepts and accepted standards, the Caminao approach entails a new modeling perspective which calls for change of habits, mostly at requirements level. The objective here is to experiment some Proof of Concept by contriving requirements on-line along the Caminao path.
For that purpose the proposed experiment makes use of four principles:
- Crowd-sourcing: except for Caminao stereotypes, understanding do not come from a special expertise or best-practices but is built on collective wisdom.
- Iterations: stakeholders and analysts are circling topics until they agree on clear and unambiguous pictures.
- Illustrations: requirements begin as expectations, as such they should be best captured through pictures before being analyzed through models.
- Assertions: requirements are meant to translate into commitments, hence, associated models should be settled by explicit constraints and expressions.
On that basis stakeholders will introduce their requirements as illustrations, analysts will try to translate them into models which, after being accepted by stakeholders, will subsequently be decorated by assertions.
Modus Operandi
- Requirements rings are managed through the G+ Caminao Rings page.
- In order to submit a project, candidate stakeholders must belong to the circle of fellows.
- Fellows stakeholders may submit projects by creating their own G+ pages and circles and identifying them with the Caminao G+. A new page is created for each project, to be matched with the fellow G+ circle.
- Fellow analysts propose models capturing all or parts of illustrated requirements.
- Stakeholders may accept, reject, or hold back their decision. Refusals can be commented but reservations can only be qualified with additional illustrations.
- Once approved models may subsequently be fleshed out with expressions, constraints and rules.
Models
Fellow analysts can propose two types of models:
- Horizontal models describe individual artifacts and their connections.
- Vertical models are anchored to single artifacts and focus on their partitions and inheritance relationships.
While it’s recommended to walk along basic UML conventions, models may include any kind of artifacts providing they are qualified by Caminao stereotypes for actual or symbolic objects and activities, roles, or events.
Stereotypes for containers use the same principle for organizational units (110) physical locations (121), physical executions (141), business domains (120), business activities (140).
The semantics of connectors (association, flow, transition, or channel) can remain implicit and defined by context. They may be stereotyped using standard set operators.
By convention, objects, events and roles are labelled with singular nouns, activities use infinitive verbs, and processes use present progressive ones. Containers are named with plurals.
Who’s in the Loops
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.
Mind Your Words
Language and meanings may be baffling bedfellows, as what is said is not necessarily what is meant. As a boost to requirements transparency, a simple gizmo may be used by players to speak their mind, for their interlocutor (talking bubble) or only for the audience (thinking bubble).
Price Your Words
Assuming clear understanding and good faith, customers and providers must agree on a price, and for that purpose they must align their respective expectations and commitments.
Expecting to take advantage of business opportunities at a given time, customers define system requirement along a black box perspective; in return, providers analyze those requirements along a white box perspective and make an estimate of cost and duration. Their respective expectations are consolidated and commitments made, customers regarding payment, provider regarding delivery.
As far as customers are concerned, success is measured by the return on investment (ROI), which depends on cost, quality, and timely delivery. Providers for their part will design the solution, develop the components, and integrate them into targeted environments. Narrowly defined, their success will be measured by costs. Those concerns may be played along a non-zero sum game:
- Customers assess the benefits (a) to be expected from the functionalities under consideration (b).
- Providers consider the solutions (a) and estimate their costs (b).
- Customers and providers agree on functionalities, costs and schedules (c).
Hence, while stakes are clearly conflicting on costs, there is room for collaboration on quality and timing, and that will bring benefits to both customers and providers.
Square the Rings
Even for standalone applications, it’s safe to assume that requirements will have to take into account external factors and constraints. Since those requirements will usually be managed by different organizational units, they must be sorted out upfront:
- Non functional constraints deal with performances and resources.
- Cross functional requirements deal with system functionalities shared by different business processes.
- Application specific requirements deal with system functionalities supporting a single business process.
Those rings are used to organize projects according the requirements architectural footprint and associated responsibilities.