Format: PDF / Kindle (mobi) / ePub
Using the latest research and driven by practical experience from industry, this book gives useful hints to practitioners on how to write and structure requirements. It will benefit those seeking to develop their knowledge of requirements engineering process.
read by those systems engineers (requirements engineers) in industry, who, being practitioners are keen to gain knowledge of using requirements engineering for system development. The book will also be of interest to final year undergraduate students in Computer Science, Software Engineering and Systems Engineering studying a course in Requirements Engineering and also to postgraduate research students in Computer Science or more generally in Engineering. xi xii Preface to the First Edition
each process. The purpose of an information model is to indicate what types of information exist and whether relationships can or should exist between the items of information. 34 2 A Generic Process for Requirements Engineering It is also useful to introduce state transition diagrams to indicate how the state of each type of information can be changed as time proceeds. Consequently these state transition diagrams can give a visual indication of when and how processes interact with each
exists between objects and thus can model complex behaviour. It is depicted by messages which flow between objects over time. Figure 3.30 shows a sample sequence diagram. The objects are represented by rectangles at the top of 3.3 Methods 73 putsLuggage Conveyor Passenger PassportID:Integer controls BaggageCheckInSystem LuggageID:Integer LuggageWeight:Real talks manages Clerk controls prints checkTicket() Printer WeightSystem printLabel() Weigh() Fig. 3.27 Elaborated class diagram
been assembled, the scope of the system can be finalised. This decision may have to be changed, once the cost of developing the system has been estimated. Such estimation can be made by people with experience of system development for the domain of the proposed system. Estimates based purely on scenarios are very coarse and consequently must have a high degree of uncertainty associated with them. Nevertheless making such an estimate can serve to give an initial idea of whether the proposed budget
draws out a number of facets of a requirement that are briefly discussed here, and in greater detail later: • Statement. That a requirement should be a statement is perhaps biased towards textual expression, whereas they can also be captured in tabular form, such as in Tom Gilb’s Planguage (Gilb 2005), in diagrammatic form in notations such as UML (OMG 2003), in formal notations, such as Z (Spivey 1989), VDM (Jones 1986), LOTOS (Bjorner 1987) and the B-Method (Abrial 1996), or in domain-specific