TABLE OF CONTENTS Very early in the drive to industrialize software development, Royce (1975) pointed out the following truths:
There are four kinds of problems that arise when one fails to do adequate requirements analysis: top-down design is impossible; testing is impossible; the user is frozen out; management is not in control. Although these problems are lumped under various headings to simplify discussion, they are actually all variations of one theme poor management. Good project management of software procurements is impossible without some form of explicit (validated) and governing requirements.
These truths still apply today, and a great deal of research has verified that devoting systematic effort to requirements engineering can greatly reduce the amount of rework needed later in the life of the software product and can improve various qualities of the software cost effectively.
Too often systems engineers forego sufficient requirements engineering activity either because they do not understand how to do requirements engineering properly or because there is a rush to start coding (in the case of a software product). Clearly, these eventualities are undesirable, and it is a goal of this book to help engineers understand the correct principles and practices of requirements engineering.
There are many ways to portray the discipline of requirements engineering depending on the viewpoint of the definer. For example, a bridge is a complex system, but has a relatively small number of patterns of design that can be used (for example, suspension, trussed, cable-stayed). Bridges also have specific conventions and...
