- You have requirements for everything you use. When you don't specify the correct requirements, you will not get what you expect: software that does not fully apply the fiscal rules for calculating VAT or a watch that is difficult to read. This book is primarily intended to help with specifying requirements for information systems, but by using examples of other systems as well, the theory is easier to understand, and makes it possible to use the book for these other systems. The reader learns to formulate requirements for (information) systems. Furthermore the reader learns to distinguish between functional requirements, non functional requirements and restrictions. Once a system is developed, you must be able to test the requirements. The book shows how you can make additions to requirements to make testing possible. For a system sometimes a huge amount of requirements is specified. The book shows how you can keep a clear overview by clustering the requirements. The book discusses the difference between requirements and goals (of the organization that wants to have the system) the system has to contribute to, and also the difference between requirements and solutions. Furthermore the book deals with requirements management, the application of requirements, and how the art factor can make a system more attractive than other systems that are based on exactly the same set of requirements. In the second edition six chapters have been added. In these chapters the IREB approach has been introduced, the influence of architecture on specifying requirements has been stressed, TOGAF as a method for setting up your own architecture has been explained, NORA as an example of a reference architecture has been given, 'user stories' and 'use cases' have been explored as alternatives for specifying functional requirements for information systems. The book contains an extended exercise, together with an also extended set of answers. With this the reader can practice the theory of the book.