• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Requirements engineering for software versus systems

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.

3 Responses to Requirements engineering for software versus systems

  1. Rhonda U. Burgess July 16, 2010 at 4:06 pm #

    This is a great article, thanks for sharing.

  2. J. v. Roekel February 2, 2017 at 12:15 pm #

    Good article, but it misses one important point. At what point stops the system and starts the software?
    It is lapidary said, make a person responsible, but then the problems just start.
    Would you expect a system engineer to review software code? Or to inspect hex dumps for variable values? Guess not. Would you expect a software engineer to specify an external interface?
    What do you think? are algorithms to be defined by systems or by software engineers? Without having clarified such issues, you will loose efficiency since things are done twice (and mostly different), inducing frustration and resistence in the staff, or things will not be done because ‘this is the job of the other team’.
    The statement to assign someone to be accountable for system is not the end of the discussion. It is the beginning.

    However the conclusion is correct, yes it is a bit simplified.

  3. Joy February 13, 2017 at 12:41 pm #

    Thanks for your comment!

    So the short response to this is, “it depends”. 🙂 The answer is going to vary from organization to organization with regards to if and where they draw that line. At the end of the day, in many organizations that I’ve seen, the line between system and software isn’t that clear and actually doesn’t matter, so long as someone owns getting all the right details in place.

Leave a Reply

Your email address will not be published. Required fields are marked *