In this interview, we talk to Michael Ryan, author of the book Requirements Practice in Conceptual Design: A Practical Guide, Second Edition. We discuss the motivation behind writing the book, the target audience, the most useful aspects of the book, the challenges of writing the book, and advice for other engineers who are considering writing a book.
1. Could you summarize the main content of your book? What are the key topics addressed?
Requirements Practice in Conceptual Design: A Practical Guide, Second Edition is a practical guide to how formal system requirements are actually developed during the earliest and most influential phase of the system life cycle. The central premise of the book is simple but critical: poor requirements cannot be rescued by good design or good engineering. If the logical foundation is flawed, the project will struggle regardless of technical excellence later. The book therefore focuses on requirements practice the disciplined, step-by-step conduct of requirements engineering during conceptual design. While international standards such as ISO/IEC/IEEE 15288 and IEEE 1220 describe what must be done, they deliberately do not prescribe how to do it. The INCOSE Needs and Requirements Manual (NRM) goes a long way to filling that gap by translating those standards into actionable approaches. However, the scope of the NRM is necessarily very broad, addressing all aspects of needs and requirements and, crucially, verification and validation across the entire life cycle. This book is in harmony with those three seminal texts but drills down to focus on what is arguably the most important activity of all the development of needs and requirements during conceptual design. Readers will also find the book valuable because it complements its sibling Artech House title Applied Systems Engineering, Second Edition , which addresses systems engineering across the entire life cycle. Using the same framework and terminology, Requirements Practice in Conceptual Design: A Practical Guide, Second Edition concentrates specifically on the first and most influential major phase of that life cycle conceptual design.
Consequently, at the core of the text is the Conceptual Design Methodology (CDM). CDM defines a structured process for moving systematically from business needs and requirements (BNR), through stakeholder needs and requirements (SNR), to the formal system requirements specification (SyRS), as part of the functional baseline at the end of conceptual design.
In short, the book addresses three key topics:
- Why requirements matter — from business, project management, and systems engineering perspectives.
- How to conduct requirements engineering rigorously in conceptual design — through a structured, repeatable, proven methodology.
- How to produce integrated, feasible, traceable, and verifiable requirements artifacts that form a sound contractual and technical foundation.
2. What is the primary purpose of your book? How do you envision it helping readers in their work or studies?
The primary purpose of the book is to provide a practical, disciplined methodology for conducting requirements engineering during Conceptual Design. Its focus is not merely on explaining what requirements are, nor on describing standards at a high level, but on showing—step by step—how to develop a complete, coherent, and defensible set of formal system requirements.
In practice, many organizations understand that requirements are important, yet struggle with how to produce them rigorously. This book bridges that gap. It provides readers with a structured process for moving from business intent to stakeholder needs, and from stakeholder needs to system-level requirements that are feasible, traceable, verifiable, and contract-ready.
For practitioners, the book provides a repeatable framework that reduces ambiguity, strengthens scope control, and improves the probability of project success—particularly in fixed-price or high-accountability environments. For students, it provides intellectual structure: it connects systems engineering theory, project management, and business analysis into a coherent methodology that can be applied immediately in real-world settings.
Ultimately, the book helps readers begin projects correctly. And in complex systems, beginning correctly is often the single most important determinant of eventual success.
3. What sets your book apart from other works in the same field? Are there any innovative concepts, methodologies, or insights that make it stand out?
What sets the book apart is its focus on how to do requirements engineering at the system level—not simply how to write individual requirement statements, and not merely how to comply with standards.
Many standards and textbooks describe processes at a high level. They define required activities, life-cycle models, and governance structures. Others focus narrowly on elicitation techniques or requirement syntax. Very few provide a fully integrated, end-to-end methodology for conducting logical system design in conceptual design.
The book’s principal innovation is the Conceptual Design Methodology (CDM), which provides that missing middle layer. CDM defines structured processes, artifacts, baselines, and reviews that guide the practitioner from business needs and requirements, through stakeholder needs and requirements, to a formal system requirements specification. It integrates stakeholder analysis, constraint identification, scoping, feasibility assessment, traceability, and validation into one coherent flow.
Another distinguishing feature is its strong emphasis on the logical architecture—the disciplined separation of the what from the how. By maintaining that distinction rigorously, the methodology prevents premature solution bias and enables better trade-offs between functionality, cost, and risk.
Finally, the book integrates business management, project management, and systems engineering perspectives. It treats requirements not as isolated technical artifacts, but as the formal interface between organizational intent and engineering execution. That systems-level integration is what makes it distinctive.
4. Who is the intended readership of this book? Are there specific industries, professionals, or fields of study that would benefit most from this content?
The intended readership includes both practitioners and students. From a professional standpoint, the book is particularly relevant to:
- Systems engineers
- Requirements engineers
- Business analysts
- Project managers
- Chief engineers and technical leads
- Acquisition and contract professionals
It is especially valuable in industries that develop or procure complex engineered systems such as defense, aerospace, infrastructure, transportation, advanced manufacturing, medical systems, energy, and large-scale IT-enabled capability programs.
The methodology is particularly suited to environments where accountability is high, projects are complex, and contracts are formal such as government acquisition, regulated industries, and major capital programs.
From an academic perspective, the book is designed for undergraduate and postgraduate programs in systems engineering, engineering management, project management, and business analysis. It provides a structured framework that connects theory to practice and can serve as a primary or supplementary text in courses focused on requirements engineering or conceptual design.
In short, the book is for anyone responsible for defining the scope of a complex system and who understands that clarity at the beginning determines success at the end.
5. What are the most important lessons or insights you want readers to take away from this book?
The most important lesson is that requirements are not paperwork—they are the foundation of project success. If that foundation is weak, no amount of engineering excellence can compensate for it later.
A second key insight is the disciplined separation of the logical and physical descriptions of a system. Conceptual Design must focus on the what and the why before moving to the how. When organizations blur that distinction, they prematurely lock into technical solutions and often solve the wrong problem very efficiently.
Another critical takeaway is that requirements engineering is fundamentally about integration. It integrates stakeholder perspectives, business intent, cost realism, and technical feasibility into a coherent and defensible set of requirements. That integration requires structure, negotiation, trade-offs, and traceability not just good writing.
6. Does your book include any original research, cases studies or data? If so, could you highlight some of the most significant findings?
Although the book is not primarily a research monograph, it is a structured methodology grounded in professional practice and informed by established standards. Its originality lies in the integration and formalization of a coherent methodology that has been proven and fine-tuned in application to a wide range of requirements development endeavors.
The text includes multiple unifying case studies that are developed throughout the chapters to illustrate how CDM is applied in practice. These include examples such as a medical facility, a domestic security system, a communications system, and an aircraft replacement scenario. These examples are not isolated illustrations; they are woven through the methodology to demonstrate how business needs are progressively transformed into formal system requirements.
One of the most significant practical insights demonstrated through these examples is how early constraint identification, structured stakeholder engagement, and disciplined traceability dramatically reduce scope ambiguity. The cases also show how trade-offs between functionality, cost, and feasibility can be made transparently at the logical level before expensive design commitments are made.
The originality, therefore, lies in the structured “how”—the articulation of a complete, end-to-end method that practitioners can adopt and tailor within their own organizational frameworks.
7. Does your book address any new or emerging trends in the field? How does it prepare readers for future developments?
While the methodology is grounded in enduring systems engineering principles, it is deliberately structured to be adaptable to modern and emerging development environments.
One emerging trend is the increasing complexity and interconnectedness of systems—particularly systems-of-systems and capability-based acquisition. The book addresses this directly by emphasizing hierarchical system descriptions, stakeholder integration, and logical architecture discipline, all of which are essential in large, distributed, or multi-organizational programs.
Another important trend is the rise of iterative and incremental development models. Although the book is written within a structured life-cycle framework, the methodology can be applied at the level of increments, builds, spirals, or sprints. In that sense, it is compatible with both traditional and agile delivery models—provided the logical discipline is preserved.
Finally, as digital engineering, model-based systems engineering (MBSE), and advanced requirements tools become more prevalent, the need for sound logical foundations becomes even more critical. Tools cannot compensate for poor conceptual thinking. The methodology presented in the book provides the intellectual structure that underpins effective use of such tools.
In short, the book prepares readers not by focusing on transient tools or trends, but by equipping them with disciplined thinking that remains valid regardless of technological evolution.
8. What personal experiences, if any, have shaped your perspective or approach to the topics discussed in your book?
My perspective has been shaped primarily by long experience in complex system acquisition and engineering environments, where the consequences of poorly defined requirements are both expensive and difficult to recover from.
Over the last 35 years, I have facilitated requirements development activities for more than 50 major projects. I have observed projects where technical teams performed superbly, yet the project still failed because the scope was ambiguous or unstable. I have also seen comparatively modest technical efforts succeed because the requirements were clear, validated, and controlled from the outset.
Those experiences reinforced the conviction that conceptual design is the decisive phase of the system life cycle. It is during that phase that purpose is clarified, boundaries are defined, and expectations are formalized. Once a contract is signed or development begins, correcting deficiencies in that foundation becomes exponentially more difficult.
This book is, in many respects, a response to those observations. It attempts to capture the disciplined practices that distinguish successful programs from troubled ones, and to present them in a structured, teachable, and repeatable form.
Learn more about the book on our websites: ARTECH HOUSE USA : Requirements Practice in Conceptual Design: A Practical Guide, Second Edition
ARTECH HOUSE U.K.: Requirements Practice in Conceptual Design: A Practical Guide, Second Edition
More Project Management content here: Project Management
