Scope
The obvious starting point of system requirements is to stage objects into contexts and define what is expected from each of them. On one hand that should take into account the current situation of users, devices, and legacy systems, on the other hand that should provide a first sketch of entry points for the system under consideration.
Since big bang transitions are seldom an option, system models are meant to describe changing configurations with some component appearing simultaneously as yesterday implementations and today legacy. Standards like SysML (System Modelling) are explicitly designed to deal with such situations.
Archetypes for Context Elements
First of all, one needs to characterize context elements regarding how the are perceived and represented by the system under consideration:
- Taking architectural constraints as a guideline, the first archetype is a system with no context at all, ie no external objects are to be represented.
- Next, one finds systems which are meant to support the representation of passive objects. The system under consideration could perform its task by itself or will need to collaborate with other systems.
- Finally, some systems may have to represent active contexts.
From an architectural perspective, symbolic representations would have to be characterized by:
- Persistency: objects, roles, events, and process states can be recorded.
- Bind to context: only objects and processes are mapped to identified elements of context.
- Time dependency: only active objects, events and processes are mapped to time stamps.
- All representations except of events can be updated.
Context & Functional Requirements
On one hand interactions between systems and contexts are one of the first features to appear in requirements, on the other hand requirements are not meant to be fitted into strictly defined diagrams. That conundrum may be avoided using stereotyped building blocks for context components and associated coupling constraints.
Regarding behavior actual objects are to be characterized as:
- Passive physical objects.
- Documents are passive physical objects which can be fully translated into symbolic ones.
- Agents are active physical objects associated with organizational responsibilities.
- External Input/Output devices are active physical objects with business relevant continuous states.
- Information systems are active physical objects managing symbolic representations.
- Control systems are active physical objects controlling the execution states of physical devices.
Regarding coupling constraints:
- References between symbolic objects may be neutral regarding object states, or may entail synchronized updates.
- Flows between functional units may be neutral regarding execution (data), or may be associated with requests (control).
- Transitions between execution units may be neutral regarding their respective states (asynchronous) or may require synchronization.
- Communication channels between active objects may be neutral regarding objects connection (simplex), or may require synchronization.
It’s worth to remind that those constraints, being strictly functional, are meant to be defined by business analysts.
Architectures are first and foremost defined by the way components may communicate, and that can be described at physical functional and non functional level: the former describes what kind of communication is to be supported, the latter describes resources and mechanisms.
As far as system functional requirements are concerned, the objective is to factor out the relevant features of context objects independently of specific modeling tools to be introduced subsequently. Using SysML sample case representation patterns should focus on:
- Active (vehicle, control, users) and passive objects.
- Identified active roles (maintainer), active anonymous (driver) and passive and anonymous (passenger) ones.
- Actual (vehicle) and symbolic (control) systems.
- Individual (baggage) and non nondescript (road, weather, obstacle) passive objects.
- Connections: containment, symbolic references, functional flows, communication channels.
From Requirements to Functionalities
The way persistency and execution units are to be anchored to contexts bears significantly upon system architecture, and those constraints can and should be set as soon as possible.Hence, and before considering which features could be used as identifiers, identities must be rooted into external objects (persistency units) or events (execution units).
Regarding persistent identification mechanisms, the objective is to maintain the continuity and consistency of external objects states with their symbolic counterparts. Regarding transient identification mechanisms, the objective is to maintain the continuity and consistency of actual processes context with their symbolic counterparts.
- Mapping constraints between actual context and symbolic representations should be explicitly identified for roles and agents (staff vs users) on one hand, actual and symbolic objects (hybrids vs vehicles) on the other hand.
- Standard connectors should also be qualified regarding identification (reference to persistency units), or control (coupling of execution units) mechanisms.
