Managing requirements is the heartbeat of systems engineering!

Independent of what school of Systems Engineering you adhere to, all of them will put requirements management at the heart of the systems engineering process. An effective and efficient development process requires a proper understanding of what needs to be done, and realistically a project has to take many requirements into account. These may be needs or wishes, parameters or constraints. All impose conditions on what needs to be developed, and how.

Paper chase

When I attended a systems engineering course by Robert Halligan in Bristol, UK, I was told that in aerospace design projects, large stacks of paper were produced to document all the requirements. Also, to manage these, a large fraction of the project’s system engineering team was assigned to manage the requirements, up to 5% of all the project engineering staff if I remember correctly. Despite the resulting large stacks of paper, I was told, the documented requirements could still not be considered to be complete.

"The requirements do not go away, so they need to be managed"

The lesson here is that there are many system requirements for a system development activity and some of them may even remain undiscovered. We need some means to manage them, and need to be aware that we’ll never be complete. So let’s stop at 20% of the effort to discover and document, but stay open to add and change later on.

Need to prioritize

Working on the predevelopment of an advanced semiconductor tool, in what was at the time a large project team, I discovered another thing. During reviews of the systems engineering documents, e.g. the requirements specification, a lot of time was always spent on discussing the specification of functional requirements such as accuracy and productivity. By the time the review meeting had been going on for two or three hours, with the clock on the wall having ticked past 6 pm and some people having already left for the weekend, we had made it to the paragraph on availability. Needless to say, this topic was not broadly discussed, not well understood by the team and (as a result) not well documented.

The lesson here is that when using documents for managing requirements, prioritization of requirements follows the template and people in the team get used to this prioritization – it becomes engrained in the organization. We need to think about ways to prevent an unintended bias.

Formalizing the process

Many methods and tools exist to manage requirements. In software engineering especially, tools have been developed not using documents but relational databases. Requirements are tied to and evolve with product releases, creating product roadmaps. Requirements are automatically linked to test cases to verify designs. The configuration of requirements is managed and can be baselined, and one can zoom in & out to work on requirements flow-down, etc. For some reason, available tools are not yet widely adopted at system level for high-end equipment development.

“We need some means to manage [system requirements], and need to be aware that we’ll never be complete.”

In discussing this with peers, I found out that formalized requirement management and deploying tooling is regarded by some as a threat to the creativity of their engineers. A formalized process is considered bureaucratic, given the large amounts of information processed. Remember, there are many requirements involved, and there will be more when system complexity increases. The requirements do not go away, so they need to be managed – ignoring them does not help.

Model based process

My personal opinion is that we do need a formalized process to manage requirements in system development projects. The process should preferably not be document based but model based. The model is electronically maintained, kept up-to-date with other models, can be zoomed in & out and focused on selected parts of a system, etc. System requirements make up one of, if not, the key system models that are created and will evolve during development. In so far as proper tooling is not available yet, we will have to create it. We can no longer afford to work with increasingly large stacks of documents that burden design teams twice: once to write and once more to read.