Requirements

Ton de Rooij • Boek • paperback

• Samenvatting
  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.
  
  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.
• Productinformatie
  Binding : Paperback
  Distributievorm : Boek (print, druk)
  Formaat : 168mm x 240mm
  Aantal pagina's : 166
  Uitgeverij : Educom
  ISBN : 9789082888034
  Datum publicatie : 12-2019
  
• Inhoudsopgave
  • Chapter 1 describes what requirements are, what a system is, and why we use the term ‘requirement’ instead of ‘need’ or ‘demand’. • Chapter 2 discusses why we specify a set of requirements. With a large number of examples we show what goes wrong when you fail to specify requirements before making a system. Furthermore, we point out why we not only specify requirements for information systems that still have to be developed, but also for the acquisition of already developed standard software. • Chapter 3 shows that writing down requirements is no mega science. In addition chapter 3 shows that requirements are not only specified by using text. A drawing, a photo or a diagram often are not only clearer and more compact, but sometimes the only way. A lot of requirements cannot be made clear with only using text. • Chapter 4 discusses comprehensively the entire process of specifying requirements. All subjects are covered. Each of the chapters 5 - 15 covers in detail one of the subjects described in chapter 4. • Chapter 5 is about why you, before specifying the requirements in detail, need to describe the context of the system and the problem to be solved by the system. • Chapter 6 shows that you can start with an overall requirement that you subsequently divide into sub requirements. • Chapter 7 is about the difference between goals of the organization and requirements for a system. A system has to contribute to goals, but a goal of the organization is not a system requirement. However, it is important to write down the goals a system has to contribute to. • Chapter 8 discusses the difference between solution and requirement. For meeting requirements often more solutions are possible. A reason for making a distinction. • Chapter 9 helps the reader with recognizing whether a requirement is a ‘functional’ requirement or a ‘non functional’ requirement. Furthermore we discuss what ‘restrictions’ are: limitations that are valid for the system as a whole. • Chapter 10 discusses ‘test additions’ to requirements. A test addition is an integral part of a requirement, meant to show how you can see that the requirement is met. Testers need them when testing the system. Not all requirements need test additions. For many, if not for most, it is clear how they are met. • Chapter 11 describes how you get a good overview of the sometimes enormous amount of requirements. Ways of clustering the requirements are shown. For example, by parts of the system, or in the case of an information system, by parts of the business process which the information system is going to support. • Chapter 12 shows what requirements management is, why it is important, and how it should be done. • Chapter 13 discusses making requirements SMART. All automation experts know this acronym. We discuss the importance of this acronym when specifying, using and managing requirements. • Chapter 14 is about the application of requirements. Among other things we show the value of having a complete set of requirements when acquiring standard software. • Chapter 15 discusses the ‘art factor’. Systems that have something special are generally successful. In this chapter we show how you can deliberately incorporate the ‘art factor’ when using requirements. • Chapter 16 enables the reader to apply the theory of the chapters 1 - 15. The chapter describes a case and gives a number of exercises. • Chapter 17 gives answers to the exercises of chapter 16. Alternatively the answers can be used as an example of how you can work out requirements. • Chapter 18 discusses the IREB standard for requirements management. The reader will find an explanation of what IREB entails and how it has to be applied. • Chapter 19 describes the influence architecture has on specifying requirements. This shows the importance of having a well worked out architecture. • Chapter 20 gives an example of a method to set up an architecture: TOGAF. • Chapter 21 gives an example of a very extended reference architecture that can be used by an organization in case there is not yet a worked out architecture available. The example is NORA. • Chapter 22 describes a way of working out functional requirements: the use of ‘user stories’. • Chapter 23 describes a way to work out functional requirements that is more extended than ‘user stories’: the use of ‘use cases’.
• Reviews (0 uit 0 reviews)
  Wil je meer weten over hoe reviews worden verzameld? Lees onze uitleg hier.