Tim Wiseley and Kent de Jong
Requirements engineering, what is it? What happens? Over the past several years, we’ve noticed that normally rational engineers just expect the requirements to be written magically, yielding the specification for their product. In this paper we discuss lessons applied to convert the needs, wants, wishes, and design domain knowledge into sets of clear, singular, verifiable requirements. We sort these lessons into three categories: Ownership, modeling, and a requirements focus. And we provide some practical magic that you can apply to projects and programs to develop a clean, consistent requirements set.
For over twenty years, we have been developing requirements in one form or another for our customers. Starting about fifteen years ago, we started hearing the term, “requirement engineering,” associated with this work. Almost ten years ago, the words “system engineering” crept into our lexicon in a way different from which we had used it before.
More recently, we observed a peculiar phenomenon among our engineers. When we observed how engineers were generating requirements we saw design documents from earlier projects copied with minor updates that were used to represent components of new systems. We also saw customers’ wants, wishes, and needs captured as requirements. And we saw plans, procedures, and processes represented as requirements.
In this paper we discuss the lessons we learned and applied with hard work and engineering knowledge to convert the needs, wants, wishes, and design domain knowledge into sets of clear, singular, verifiable requirements. We also established a common language regarding requirements engineering.
We worked on many projects over the course of our careers at the Laboratories. Each of us brings different backgrounds to a project ranging from security systems to satellites to weapons systems. In addition, we used mechanical, software development, electrical, project management, and Lean System Engineering skills to identify customer needs and to develop sets of requirements for those customers.
It is never easy to take the expressed wants and desires of a customer and successfully turn them into clear, easily understood, comprehensive requirements that managers, engineers, designers and customers can easily recognize and agree upon. We need to clearly define roles and effectively communicate the requirements development process as it evolves. We must also effectively use visual communication through modeling to avoid the ambiguity and nuances that can arise from textual and verbal communications. Further , we need to keep a focus on writing clear and consistent requirements and never stop asking the what, why and how questions. Such clarity leads to greater success in meeting the needs of customers.
It is a challenge to sort through the ideas and language and translate the often confusing wants and needs of a stakeholder into a universal language that can be understood and used by every participant on a project. In taking ownership of the process, utilizing models and focusing on writing solid requirements the we can take lesser metals of ambiguity and turn them into gold.