The book describes what we mean by requirements for systems, more specifically for information systems, and how you can specify them. Also available in Dutch.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.You have requirements for everything you use. A watch has to show the exact time. It must be possible to use it when diving, the wristband should not wear rapidly, et cetera. This does not only apply to things we have. This also applies to software we use. Software for making invoices must be able to deal with changes in VAT percentages that have to be applied. The software should not only be able to make an invoice that meets the legal demands, print it, et cetera, but should also, when making a credit invoice (an invoice that is meant as a reversal of a previous invoice), use the VAT percentage that was used in the original invoice, even when this percentage has changed in the meantime. When you don’t specify the correct requirements, you will get something different from what you expect. E.g. a watch that is difficult to read, software for making invoices that uses the new VAT percentage in credit invoices instead of the percentage in the original invoice.