ABSTRACT
Systems engineering and architecting are very young sciences. The practice of each is more an art than a science. Many excellent books are available to help a practitioner increase the impact of the art or comprehend the science.1-8
This book aims to provide tools to do aspects of systems engineering and architecting better, faster, or cheaper. To accomplish systems engineering or architecting, one must do four things well:
1. Model system or architecture behavior 2. Make rational decisions 3. Establish natural language requirements 4. Improve systems engineering and architecting processes and products
The objective of this book is to provide formal requirements to do each of these four activities a variety of ways. Formal requirements are just explicit instructionsyou can think of them as a computer program if you like. Though at rst such a rigid structure may seem a hindrance, it actually provides two huge benets. First, explicit instructions can be executed, that is, produce a product. Many systems engineering and architecting activities cannot yet be described as formal requirements. For example, how do you explicitly tell someone to come up with the best concept that fullls customer requirements? The best you can do is give general guidance on how to identify candidate solutions and synthesize something new and innovative that will be appealing. The actual step-by-step process remains a mystery of the inner workings of an individual’s brain. Some people are extraordinarily good at concept formulation. The extraordinary good people may be able to explain how they found their innovation, but even when they can, their explanation is insufciently detailed for someone else to accomplish the same feat. On the other hand, you can explicitly tell someone how to nd a mathematical minimum or maximum; indeed, there are many ways to do so, and some are better suited for some problems than others. Should the search for the solution concept be translatable to a mathematical optimization problem, those explicit instructions can be quite helpful. Even if you cannot make such a translation, you can also instruct someone on the many ways to compare optional solutions to determine which is best. The second benet of formal requirements is that you can improve them and capture the improvements. If someone thinks they have a better way to do the job, they rewrite the formal requirements, execute them, and compare the results to how they were previously accomplished.
