Some Thoughts on Requirements
(What exactly does a systems engineer do? Here’s one thing…)
There is one question that I get routinely, from both those inside and outside the engineering industry: “What exactly does a systems engineer do”? It’s not an easy question to answer, even after about a dozen years of having that somewhere in my job title. I imagine that if one asked five systems engineers that question, one would get five responses that would be just dissimilar enough to be considered different.
My response usually starts by describing how the field of systems engineering came about, using the aerospace industry as an example. For the first couple of decades of the 20th century, the designs for various flying machines had relatively clean interfaces. What I mean by this is that the connections — mechanical, electrical, or otherwise — between the various components that made up these machines were few and well-understood, to the point that one or two people — like a certain set of brothers hailing from Dayton, Ohio — could understand how the entire aircraft worked all by themselves.
However, over the next few decades, the aerospace industry advanced at a substantial rate. New technologies, such as the jet engine, made it difficult for a single person to understand. Interfaces became much more complex, and harder to visualize. A change to the design of the nose of an airplane, for example, could affect the flow of air into the engine, drastically changing its performance. And so, it became necessary to develop a new type of engineer — someone who could identify the components and their properties and how they interacted, and influence the system as a whole. Thus, the concept of systems engineering was born.
One of the terms most synonymous with systems engineering is the “V model.” I’m not referring to some new car that Tesla is coming out with; the “V model” offers a graphical interpretation of the key roles of a systems engineer, relative to a project’s life cycle. The V can be split up into two portions. The first half is called the “definition and decomposition” phase, in which the concept architecture is refined and segmented from a project-level down to its elements and subelements below that. The second half, called the “integration and test” phase, is where one confirms the project will meet the mission objectives, validating and verifying the system, starting at the various subelements and working back up to the project level.
Right now, the Psyche project is in the middle of what is known as “Phase B,” which is known as “Preliminary Design and Technology Completion.” (Phase B is described in more detail in a previous post from our PI here). This places us roughly in the center of the first half of the V. And, not coincidentally, right in that area we see a lot of references to “requirements.”
Requirements are the primary tool that a systems engineer has in defining interfaces and making sure things run smoothly. They play a key role in defining the necessary capabilities of the various elements that make up a project. This, in turn, ensures that the project as whole will complete its mission. When working on a project with subcontractors — as is the case with Psyche — requirement documents are an important element of any contract document between the various parties. As a result, the wording of requirements ends up being fairly formal, almost apropos to a courtroom, instead of an engineering workspace.
The process of developing requirements for the Psyche project dates back into the early proposal effort, almost three years ago. Back then, the various teams of engineers and scientists working on submitting proposals for the Discovery program — including Psyche — worked to tie their concepts to a set of themes and priority questions, located in what is known as the Planetary Science Decadal Survey. Produced every 10 to 15 years, the Decadal Survey represents a multi-year effort across several groups — scientists, engineers and technologists — to provide an overarching strategy for planetary exploration. This type of survey is not isolated; similar surveys are done for areas such as earth science and astrophysics as well. Among the major findings of this survey are a set of questions — in this case, ten — deemed to be a priority in planetary exploration.
And so, the Psyche science team created a set of “Science Objectives”; a set of tasks that, if answered, would be a major step towards answering those “Priority Questions.” Determining whether Psyche was the core of a differentiated planetesimal that was once resided in the main asteroid belt, for example, will go a long way towards answering the question of what the initial stages and conditions and processes of solar system formation.
In order to meet the Science Objectives, a set of requirements known as “Level 1s” were created. These requirements quantitatively defined the scientific measurements necessary to meet the objectives. For example, one of the ways to determine whether Psyche was a core is to see if there is a magnetic field. Therefore, a Level 1 requirement was created for the mission to map its magnetic field to a given accuracy. These requirements were refined throughout the length of the proposal process and even into Phase B. And as I’ve discovered over the years, when large groups of people meet to discuss a number, there is never unanimous agreement at first.
Once the Level 1s are refined to a sufficient fidelity, the process of requirements flowdown begins. The Level 1 requirements determine aspects of the mission, such as instrument selection, mission duration, and performance of the spacecraft bus. Requirements always beget more requirements, and they seem to multiply like rabbits. It is no coincidence that terms “parent” and “child” are used to describe the relationship between requirements that relate to each other. A project as complex as Psyche can have many thousands of requirements, spread across a large number of levels. It is not uncommon to have as many as seven or eight levels for a given spacecraft project. And more requirements are not necessarily a good thing; more requirements going down one side of the V means more time and money spent validating them when going up the other side.
A simplified example of the requirements flowdown process for Psyche is shown in the figure below. This example uses one of the Level 1s for the Psyche project, which is to characterize the morphology of the Psyche surface by mapping it to a certain horizontal and vertical resolution. For our example, this one requirement results in number of child requirements at lower levels. The project will have to specify the orbital parameters and duration, over which the data is obtained. The project will also need the means to store the data and transfer it to the ground — where, likewise, there will also need to be space for archival. Thus, these requirements flow down to subsidiary requirements, and so forth, all the way down to the component-level. And, as our PI mentioned in a previous post; it is always good to carry margin, rather than simply just meet a requirement, as one never knows what could come up during later phases.
After a draft requirement is written, one gets all the various stakeholders together to review them. Stakeholders include the system that is responsible for achieving the requirement, as well as well as those who are affected by it. At the reviews, the requirements get poked and prodded more than my kids’ teeth at a dentist’s appointment. Questions get asked. What are the “parent” requirement(s) that resulted in this? Can the requirement be verified through reasonable methods? What new “children” will need to be developed, or perhaps existing children that need to be modified? Eventually, these issues get resolved and consensus achieved, and the group of requirements formalized. From time to time, something is discovered and a requirement may need to be tweaked. This is another feat of logistics in obtaining consensus, and is probably a subject for another time.
In a later post, myself (or one of my colleagues) will discuss those other phases of the V, such as implementation, verification and validation. But in the meantime, feel free to ask any questions about requirements process, or perhaps share thoughts on your own experiences.
