How do we derive a system?
First of all, I define a system as having requirements, architecture and behavior.
These are present at every level of the system hierarchy.
And, every system has hierarchy.
Requirements, obviously are what the system has to accomplish. Requirements are Use Cases.
An aside on requirements;
Upon X, the system shall do Y, within Z.
I believe this simple little construct helps requirement crafting more than any multi-day academic training session on requirement writing and specification development.
The “within z” picks up, at least to some extent, non-functional requirements.
Architecture includes the HW and SW elements that have functionality. They perform definable functions. Not to split hairs or get religious about terms but they are actors in the scenarios. I call them actors. Actors have interfaces and behavior. At every level, except maybe L0, the system has external and internal interfaces between its actors. Interfaces internal to the actors of the level are not discussed at that level.
Behavior is how the system performs the function. Sometimes the specific sequence of actions and timing is significant. Sometimes it’s not so important. When it is, we tend to document the behavior. Otherwise we tend to ignore it and just capture the architecture and requirements. This is a trap. They are all related and should be considered together.
Behavior and requirements are the same thing, depending on the perspective. Behavior internal to an actor of the level are not discussed at that level. The elaboration of a Use Case as a scenario of behavior derives lower level (internal) architecture and the necessary functions of the actors. These “necessary functions” are derived Use Cases allocated to the actor. “necessary function” == Use Case == Requirement.
Do we allocate requirements to external actors? Technically no, but actually, yes. We may need to allocate “wills” (rather than shalls) to identify contractually binding expectations of behavior of the external actor.
Design Derivation (Synthesis or Decomposition)
These all; requirements, architecture, and behavior, decompose. Their decomposition is not linear top down flow and is very much a “chicken or egg” situation.
I have used “Analysis Packages” to execute this design and requirement derivation process. We triage and assign various Use Cases to engineers for elaboration. Each analysis package elaborates a Use Case and must begin with Source or Driving requirements which define the objective to be achieved (the Use Case).
Each “Analysis Package” also starts with a notional architecture of decomposed HW and SW elements and interfaces between them and external elements. These architectural elements are all Actors in the Use Case elaboration exercise. The notional architecture is necessary to provide a starting point for analysis but may change as a result of analysis (Chicken – Egg).
The achievement of functionality requires that we identify interactions between actors, hence we define the existence (and maybe the specifics) of the interfaces (an architectural element). We also identify/allocate functionality to specific actors, thus creating requirements for those actors which are children of the Use Case source requirement. The Elaborated Use Case is a behavior that often must follow a specific sequence to be successfully achieved.
Documentation
So how do we document this? Basically I think we need two things; a requirements document and a design document. I have thought for quite awhile that the Operations Concept Document, following the IEEE/AIAA format of OCDs is the almost perfect design document. The IS&GSs ABD document was also pretty good. The goal is to capture the hierarchies of architecture; Actors and Interfaces and the behavior necessary to achieve the function. Since Functions/Use Cases/Requirements are derived from the analysis that arrived at the architecture and behavior the requirements spec aligns with the design document.
Now the bugaboo.
Is the design document a design driving document or a design capture document? The answer, I think, may well be, Yes. J