At INCOSE 2007, I attended a panel discussion “Requirements Engineering for Software vs. Systems in General?”. The moderator was H. Kaindl and the panelists included R. Griego, M. Hause, C. Hood and M. Mannion. This content is all paraphrased or interpreted from things the panelists said.
So to start, a common response from the panelists was that there is no real difference between requirements for systems and software, at least not a significant one. In fact, one of the panelists responded to being invited to the panel by saying “there is no difference, so this panel won’t last long.”
In reality, when we look at requirements engineering for systems and software, the outputs are similar – requirements. The construction processes are similar. The management issues are similar. The tool support needs are similar. This may be an oversimplification, but in general I agree with the point.
One thought is that many software people tend to avoid the systems world, thinking of it as “messy”. But if you think about it, software really is just a component of systems. As one panelist said, it’s like the central nervous system. In looking at the different levels of requirements we can see the relationship between software and systems requirements is a bit more obvious.
- Customer requirements
- System requirements
- System design requirements
- Sub-system requirements
- Sub-system design requirements
- Implementation
One panelist took this a step further to look at the different types of requirements to deomonstrate more commonalities:
- Functions – effects achieved by some entity
- Behavior – state change over time, function could be an abstraction of behavior
- Constraints – restrictions or limitations
- Structure – arrangement or relationship of elements in a system, physical or logical
This last one, requirements that describe structure are not as common in software as systems, but the rest are all common in both. In addition, large complex systems have software, hardware and human actors. You can still write use cases to define the functional requirements for composite systems.
There are differences between systems people and software people, with the languages they speak and their cultures. So a real issue that comes out of this is that the communication really breaks down. This is not to say that communication does not breakdown within software projects of course! But it’s a different type of issue with large system projects. People skip from the customer requirements into sub-system requirements. They assume something is going into software or hardware and no one really owns the system level to know for sure that it’s all covered and the dependencies between components are known.
In the end, this is an easy thing to fix – ensure someone is accountable at the system-level for making this communication happen. And use tools to trace between requirements of the sub-systems, up to system-level business objectives.
So this may be simplifying it a bit, but it really seems like the tools and techniques we apply in the software world also apply to the systems world – perhaps at a different scope, with varying degrees of complexity.
