Note: This post is based on a guest lecture I presented the systems engineering students at the University of Utah on April 17, 2023.

Some skills that I acquired during my career as a systems engineer served me well for a few years and then became obsolete. Other skills have served me well my entire career. Some skills are ephemeral; others are enduring.

To distinguish the enduring from the ephemeral requires an historical perspective. Looking back on my career, I can identify the skills that I acquired and determine which ones were ephemeral and which ones are enduring.

A History of Requirements Development

Good requirements enable good design. That is why the process of developing good requirements is so essential to the practice of system engineering. I have witnessed the evolution of the requirements development process over the course of my career. The history of this evolution provides many examples of both ephemeral and enduring skills.

To provide a framework for my reminiscences, I have modified the famous five maturity levels of the Capability Maturity Model¹.

Maturity Level 1: Oral Requirements

In the small startup companies that I worked for in the 1970’s and 1980’s, we developed requirements by talking about them. Three or four engineers would sit around a table in the lunchroom with the marketing director to discuss what our customers wanted. We would brainstorm designs for a product to meet their needs. These discussions would be long and sometimes contentious, but we would eventually come to a common understanding of what we wanted to do.

We never wrote down any requirements. Each engineer went off to design their part of the system based on their memory of the discussion. As we developed and integrated the system, we would encounter many issues. We would resolve each issue by having more discussions.

How well did this oral requirements development process work? Not very!

• We didn’t always remember what we agreed to do. With nothing written down, we couldn’t refer to a document to refresh our memory.
• Each engineer might remember something different. When it came time to integrate the product, the pieces often didn’t fit.
• We had only a vague idea of how long it would take to develop the system.
• Our testing was ad-hoc and haphazard. We never knew if we had tested the product adequately.
• Customers frequently complained that the product was missing important features. We spent a lot of time and money on rework to make them happy.

Maturity Level 2: Written Requirements

In 1991, I started working for a somewhat larger company with a development team of three dozen or so people. This company, realizing that oral requirements would be unworkable with such a large team, advanced to the next level of maturity. We wrote down the requirements that we had discussed and agreed upon. We used WordPerfect – the dominant text editing program at that time – to create documents listing the requirements.

Written requirements eliminated many of the problems encountered using oral requirements. Written requirements had additional advantages that made the product development process much more predictable and reliable:

• The program manager could develop a realistic schedule based on reasonable estimates for how long it might take to implement each requirement. (Even so, the program was still always behind schedule. Pondering this experience led me to the insights expressed in the post Parkinsons Law for Schedules).
• The testing department could test the product against written requirements. The testers could now give unambiguous and timely feedback after each iteration of testing. Developers could fix problems before the next testing iteration.

But after achieving Maturity Level 2, we encountered new problems:

• Most engineers were not particularly skilled at writing good requirements.
• Requirements documents were difficult to maintain. If a requirement had to be changed, it was tedious to the point of impossible to track down related requirements in other documents that also needed to be updated.

Maturity Level 3: Traceable Requirements

In 1993 I moved to a large medical devices company. When I arrived, the company was at Maturity Level 2, but the difficulty of maintaining requirements documents made us realize that we had to address the problems with Maturity Level 2. We needed to advance to Maturity Level 3.

To address the issue of poorly written requirements, my manager sent me to Seattle to take a class on writing good requirements. I learned a lot! I learned how to write requirements that are clear, concise, verifiable, consistent, well organized and that don’t unnecessarily impose a specific design on the product.

When I returned to Salt Lake, I taught my colleagues what I had learned. Of course, writing good requirements is a skill that takes practice to master. We would review our requirements aiming to improve our requirement writing skills as well as to correct any content errors in our requirements. Alas, many people have a higher opinion of their own writing skills (and a lower opinion of other people’s writing skills) than is warranted. Requirement review meetings got bogged down when people let loose their inner English major and indulged in critiquing style and word choice rather than content.

To address the issue of requirements maintenance, we acquired a requirements database tool (DOORS). We stored our requirements in the database. We could then link each requirement to its source requirements and to any derived requirements. We also stored our test protocols in the database and linked them to the requirements that they tested. This traceability provided us with very important advantages:

• When we had to modify a requirement, we could quickly trace to other requirements and test protocols that we also needed to update.
• We could easily compare each requirement with its corresponding test protocols to determine if the requirement was adequately tested.
• We could prove to ourselves and to the FDA – the government agency that regulates medical devices – that we tested all our requirements.

Unfortunately, the database tool could do nothing to solve the problem of poorly written requirements! We continued to rely on training and review to improve the quality of our written requirements.

Maturity Level 4: Model Based Requirements

In 2018, we started investigating Model Based Systems Engineering (MBSE). After all, mechanical, electrical and (to a lesser extent) software engineers have used modeling for decades. Why not us? We decided to focus on using models to describe some of the more technical parts of our system design. After slogging through a steep learning curve, we began to see some significant benefits:

• Unlike text-based requirements, models are unambiguous. Since it is possible to make good models of poor designs, we continued have design review meetings. Somewhat to our surprise, we found that reviewing models was significantly more productive than reviewing written requirements. We no longer spent time critiquing style and word choice. We spent our time focusing on content.
• Also somewhat to our surprise, our colleagues in other engineering disciplines, and even our engineering managers were quite comfortable reviewing our models.
• The modelling tool constrained us from making logical errors in our models.
• The simulation feature of our modeling tool allowed us to see if our model worked the way we intended.

We also encountered several significant difficulties:

• Learning the modeling language. We used the predominant modeling language SysML. It is very powerful and therefore very complex. People don’t just pick it up in a day or two. Some of the newer engineers had learned it at engineering school; the rest of us had to learn it on our own. If you have to learn it on your own, I highly recommend reading SysML Distilled by Lenny Delligatti.
• Picking a good modeling tool. At the beginning we made a big mistake. Our manager picked a modeling tool for us that he liked because it was free. Unfortunately, the tool had a difficult user interface, no documentation and produced really ugly diagrams that obscured the meaning of the model.
  The tool made modeling seem even more difficult than it really is. Finally, a new hire suggested that we use a tool he had used in his previous job. (Magic Draw; there are other tools that are also good). After evaluating a demo copy, we were able to show our manager that the tool would more than pay for itself in increased productivity. The new tool was intuitive and fun to use. People enjoyed using it and could focus on content.
• Deciding what to model. We quickly realized that we didn’t have the resources to model everything, so we had to pick aspects of the system where modeling would provide the most benefit.
• Developing our modeling skills. Modeling (like writing requirements) is one of those skills that isn’t really learned until it is practiced. We had experienced engineers mentor new engineers. We had frequent review meetings to go over models. These reviews caught problems and also served as an informal way to share best modeling practices.
• Coming up with a methodology appropriate for our organization and product. We devised a methodology where we modeled those parts of the system where a block definition diagram, an activity diagram, a sequence diagram or a state diagram communicated the design most clearly. We embedded these diagrams in a text document that presented an overview of the product design and provided context for the models. We placed requirements for those parts of the design that were not modeled into our requirements database.

Maturity Level 5: Requirements Nirvana!

We’re not there yet, but it would probably have the following capabilities.

• Modelling tools that support integration with modeling tools used by other engineering disciplines such as: UML based software modeling tools and the CAD systems used by mechanical and electrical engineers.
• Building parts of the system directly from the model. Circuit boards can be built using the CAD systems that design them. With the advent of Additive Manufacturing, mechanical engineers can design parts that are manufactured directly from their models. Software engineers are developing the capability to create production software directly from UML models. These capabilities could conceivably be integrated into the system model.
• Simulation of systems designs. This would make it much easier to develop and evaluate alternate designs.
• Testing products directly from the model. For example, an activity diagram could be fed to an automated testing system. Since both the product and the testing protocols would be developed from the same model, discrepancies between the product and the test protocols would be eliminated.

Summary of Requirements Development Skills

Looking back on what has changed over the years, it is easy to categorize requirements development skills as ephemeral or enduring. Ephemeral skills include:

• WordPerfect (the word processing tool that was supplanted by Word)
• Microsoft Word (although Word has been around for 3 decades!)
• DOORS
• SysML
• MagicDraw

Enduring skills include:

• Interviewing users and other experts to understand user needs.
• Deriving a coherent set of requirements based on the user needs.
• Abstracting and synthesizing a good design based on the requirements.
• Presenting designs clearly to engineers, managers and users.
• Learning new ephemeral skills: tools, techniques and methodologies.

The Ephemeral

In general, ephemeral skills are the ability to use tools and methodologies that serve enduring needs. Ephemeral skills are essential for doing our work. They are the “how” of our practice of systems engineering.

The Enduring

The enduring skills, in contrast to the ephemeral skills, are much more difficult to acquire. They require not just the acquisition of knowledge but the cultivation of mindsets.

Mindsets

Enduring skills are based on several mindsets that are essential for the successful practice of Systems Engineering.

Systems Thinking

Systems engineers must be comfortable with seeing a system from many different points of view – the big picture and the details, what it looks like from the mechanical, electrical and software perspectives, what it looks like to the various people that use it. Systems thinking requires acceptance of complexity and comfort with conflicting points of view.

Curiosity

Systems engineers must be curious about the things and people we work with. Curiosity leads us to observe carefully and ask lots of questions. It encourages us to learn new tools and new methodologies.

Empathy

Systems engineers must have empathy for our users. We can’t assume that all users are like us. We have to understand them: What they need and want. Why they need and want the things they need and want. What their work environment is like. Who they work with. Who they work for. What motivates them.

Imagination

Systems engineers must be able to imagine a system that will meet user needs. We conceive of new uses for existing components. We can observe an existing system and imagine how to make it better.

Humility

An individual systems engineer can never know everything about a system. We must recognize our limitations. We must make use of other people’s knowledge. We must collaborate with many other people to be successful.

Flexibility

Systems engineers must be able to adapt when things don’t work out according to plan. We should never expect that anything will go completely according to plan. We will discover new user needs, new requirements. Testing will reveal design problems. A promising new technology can be applied to our product. There will always be new tools to learn, new methods to try, new products to develop, new companies to work for.

Integrity

Systems Engineers must develop relationships of trust with the people we work with. Trust is based on integrity. The stakeholders that we work with must feel confident that we understand and consider their wants and needs. When we make the inevitable design tradeoffs, everyone must have confidence that we are making decisions in good faith. We must always keep in mind that the systems we design are a public good. We must always resist efforts to persuade us to take shortcuts that compromise ethical or legal obligations.

Enduring Skills

Listening

Systems engineers listen to lots of people: users, experts, colleagues and managers to name a few. Effective systems engineers know how to learn from what we hear. Engineers with good listening skills have learned to:

• Listen to learn rather than to debate or answer. If you are thinking about your response while listening to the other person you are not fully paying attention to what they are saying.
• Use active listening techniques (sometimes called mindful listening)
• Ask follow-up questions about anything you don’t fully understand.
• Take into account the expertise and biases of your interlocutor.
• Listen to many different people.
• Cross check what you are told with other people.

Observation

Systems engineers need the ability to learn by observing. (This is an essential skill for scientists, too). You can’t learn everything worth knowing by talking to people or reading books and blogs! Get out into the environment and see for yourself.

Researching

Systems engineers often need to research topics that they need to learn more about. This calls for researching skills:

• Define what you want to find out.
• Decide how to find the information you need (interview an expert, read a book or two, read articles in technical journals, look up information on the internet, go out and look at an example, attend a class or conference)
• Keep current with developments in systems engineering and in areas relevant to the systems you are designing.

Analysis and Synthesis

Analysis is the ability to break down a system into parts and understand how the parts work. Part of analysis is being able to view a system from several perspectives.

Synthesis is the ability to put parts together into a working whole. One aspect of synthesis is identifying components that can be re-used in a new system.

Analysis and synthesis are complementary skills. Systems engineers use these skills together to build a system architecture. There are many ways to analyze a system – some are more useful than others. And there are many ways to put a system together. Once again, some are more useful than others.

These are very difficult skills to master. Practice, practice, practice!

Good Judgement

Systems Engineers make decisions all the time. We decide on the boundaries of the systems we design. We specify which groups of stakeholders should be interviewed when gathering system requirements. We select design tools and methodologies. We choose which design is best.

We should use good judgement when making these decisions. We must decide which factors are more important, which are less important and which to ignore. We must decide when to make a decision: decisions can never be perfect, but they should always be timely.

Communication

Systems engineers communicate with other people constantly: with customers, users, other engineers, managers. Effective systems engineers communicate clearly and effectively. There are many ways to communicate:

• Written text
• Charts
• Graphs
• Plots
• Photographs
• Models
• Oral presentations (with or without Power Point)
• Elevator speeches

Know your audience. Pick the ways that will communicate most effectively with them. A presentation to upper management might require an effective graphic combined with a 3 minute oral summary, whereas a presentation on the same topic to a group of engineers might be most effectively presented as a set of models.

Collaboration (Meetings)

INCOSE Wasatch Chapter president Elgan Iorwerth is fond of saying that “systems engineering is a team sport”. How true! Systems engineers can accomplish nothing without collaborating with colleagues, either one-on-one or in meetings with groups of people.

Systems engineers do much of our collaboration work in design meetings and review meetings, but we receive little training in leading meetings or participating in meetings. Running a productive meeting is a skill that can be taught and honed.

Running a good design meeting is similar to hosting a good dinner party:

• Invite the right people
• Don’t invite the wrong people
• Put together a good menu/agenda
• Make sure everyone has a chance to speak
• Draw out shy people
• Gently curb domineering people
• Follow the conversation carefully. Be able to summarize it at any point.
• Recognize when the conversation is stuck and nudge it back on track.
• Make sure topics/issues are discussed adequately.
• Everyone gets to speak for themselves; no one gets to speak for others.
• Maintain detachment. Your job as a host/leader is to make sure that the group has a good time/does good work. It’s not about you.

As people become more skilled in leading meetings, everyone also becomes more skilled in participating in meetings. A culture of respect and trust develops, supporting better design and easier conflict resolution.

For more thoughts on leading meetings, see the post Leading a Design Meeting.

Conflict Resolution

Conflict is an intrinsic part of the development process. Stakeholders will always have some conflicting needs and wants. Here are some suggestions for resolving these conflicts:

• Since conflicts often are resolved in meetings, put a lot of effort into developing your team’s meeting skills. See above.
• Listen carefully and respectfully to all sides in a conflict. People will usually accept not getting everything they want if they have been listened to and their concerns have been acknowledged and taken into account.
• Develop an objective method for evaluating the relative importance of requirements. Make sure the method isn’t rigged to favor a predetermined outcome.
• Distinguish between wants and needs. Needs must be met but wants can be negotiated.

Conclusion

Note that many of the enduring skills are people skills: listening, communicating, collaborating, resolving conflicts. Other enduring skills are more intellectual in nature: synthesis, analysis, good judgement. And some enduring skills are learning skills: listening, observation, researching. Enduring skills serve us well, not only in our careers but also in our personal lives. We never fully master enduring skills, but we cultivate them by study and practice.

On the other hand, ephemeral skills are generally technical skills. Systems engineers learn new ephemeral skills (and forget old ones!) as technology changes. Systems engineers view the ephemeral skills as tools used to design and implement systems.

Footnotes

1. The Capability Maturity Model was developed by the Department of Defense in the 1980’s to evaluate the capability of its software subcontractors to perform software development projects. The CMM was very much in vogue for a couple of decades. It even spawned a parody model – the Capability Immaturity Model.