The SYSMOD Zigzag Pattern
Are your requirements really free of any solution? Requirements describe the What, the system architecture describes the How. Sounds easy, but…. Requirements are solution-free and they contain solution aspects at the same time. It depends on the level of abstraction.
Let’s assume that you have absolutely solution-free requirements (I argue that those requirements are not viable in practice). Now you derive a system architecture that satisfies the requirements and you get the typical what/how-pair. For example you have requirements about a transportation system for people and you derive a system architecture of a car. The solution car leads to new requirements that contain aspects of the solution. They are on another abstraction level and solution-free from the viewpoint of that level, but they contain solution aspects of the previous level. Again you derive a solution from the requirements, e.g. a hybrid engine. Again that solution leads to new requirements and so on. All in all the logical steps represent a zigzag pattern.
The SYSMOD-Zigzag-Pattern
Requirements in practice always contain some solution aspects. Unfortunately they are often implicit and are one of the causes why requirements are a sore spot of many projects.
I’ll write further posts to discuss consequences from the SYSMOD-Zigzag-Pattern.
6 Responses
My understanding of Systems Engineering (SE) principles is based on the understanding of the question “on what and when the requirements shall be imposed?”. The key to the right understanding of the SE principles in whole lies in the right answer to this topic. Typically this understanding is not properly established, what leads (unfortunately) to many misunderstandings in respect to the process of architecture development and the SE in whole, particularly escalating when the development of architecture alternatives matters.
Helpful in development of architectures is the rule to rigorously develop only one level of system architecture decomposition in one iteration of the SE process. This leads inevitably to the need to specify solution-free requirements for architecture elements defined in the just designed architecture level without the knowledge of the “how” these elements will be further decomposed. The “solution-freedom” of requirements is in fact only oriented in the direction of refinement of the architecture element in scope (downward the architecture) and bases on the architecture decisions made in higher levels of the architecture element (upward the architecture) the requirements are to be imposed on. Without these principles / practices it would be likely impossible to design any system, as we can’t doubt on everything at all steps of the SE process.
Example:
It seems to be obvious (and in fact it is), that putting requirements on a “car chassis” which has been decided to be an element of the architecture (at some level of it) of a “Terrestic Family Transportation System” won’t put in question other architecture elements at the same and at higher level of the architecture. Rather they will assume their existence at the same level of architecture. The requirements shall be solution-free for the architecture of the “car chassis” itself.
The Zigzac pattern describes / visualizes the proper understanding of this principle and helps to really understand what SE-process loop means.
Thanks, Mr. Weilkiens.
Hi,
Interestingly, in the KAOS/GORE methodology (Goal-Oriented), on all requirement derivations you can attach a solution/system. It means that indeed you have decompose your high-level requirement following a strategy in mind that it tied to a solution. It would be better to be explicitly written. I believe it could be mention on the strategy object of the GSN (Goal Structured Notation). Also it enable one to develop alternatives or exhibit existing system solutions and justification.
My conclusion is that strategy/refinement shall be first-citizen in requirement tools.
More over, in current situation, it also demonstrates that having the final result (model) is not enough to understand it. Thus I was wandering what would be the equivalent of Literate Programming in this context?
—
Loïc
Dear Mr. Malecki,
Thanks for the feedback and putting the zigzag pattern explicitly into the focus of SE.
Dear Loic,
you’ve mentioned interesting cross relations to other concepts like KAOS/GORE and literate programming. I’m not familiar with KAOS/GORE. Could you please explain it a little bit?
I couldn’t follow your argument about the coherence of literate programming and the zigzag. Please give me a hint.
/Tim
Hi,
Sure! Kaos/Gore is a goal-oriented methodology to engineer requirements. In this methodology a requirement is defined as a Goal assigned to one, and only one agent (aka system/subsystem/subpart). It is interesting because you start with vague objective (Goal) and refine them until to make them requirement (thus SMART and assigned to one agent). Have a look at the tutorial, it is pretty inspiring. Or better have a look at the book “Requirement engineering” from Axel Van Lamsweerde.
http://en.wikipedia.org/wiki/KAOS_%28software_development%29
One of their advice is to model the system as-is (if it exists) and the system to-be.
In the ZigZag context, it means that you start with solution free goals, refine them and if it is tied to a particular solution you “annotate” the refinement by it. It means that one requirement/goal could be refined several times with the meaning of alternatives. See page 18 of the tutorial about alternatives.
In Kaos/Gore diagram, refinement is just a link but in the GSN (Goal structuring notation) it is a plain box where you explain the strategy you have applied. I believe it would be similar to add a SysML rationale to a <> link.
http://safetyengineering.wordpress.com/2008/04/04/the-goal-structuring-notation-gsn/
Now about Literate programming. Literate programming was introduced by Donald Knuth as a way to write program following our logic flow.
http://en.wikipedia.org/wiki/Literate_programming
In the zigzag context, it means that you would exhibit or present the final model progressively just following the zigzag way, ie the way you have though it.
Thus the Zizag would be explicitly written, ready to be followed by a reviewer.
The conclusion is that in both cases, what was implicit become explicit an first class citizen in the model.
PS : I do not now yet a literate tool for system engineer. Maybe the Eclipse Mylin/Intent would become the first one?
I’m interested to get your perspective on how this would apply in a requirements based testing environment.
I work in safety critical, hard real-time embedded system design for the aerospace industry. We are mandated to perform requirements based testing by industry standards such as ARP-4754A and DO-178C. They make reference to architecture but to demonstrate compliance one just has to say they have created an architecture and have considered it when writing requirements. All of the emphasis is placed on requirements completely defining the system. As more industries (Automotive, medical etc) reach the same level of safety criticality I imagine they will start to create similar standards.
Dear Kim,
At which point do you assume a problem? The zigzag pattern either emphasize the requirements nor the architecture. It just describes the relationship between both across different levels.
If you don’t “translate” an architecture to requirements on the next level, the architecture itself is a kind of a set of requirements.
Tim