This book is made up of a number of chapters that should provide a good overview of every aspect of the approach to context-based requirements engineering (ACRE) described in this book. Part one is mainly concerned with the generic concepts of modelling and the notation that are used in the book. Part two is aimed at introducing the basic approach that forms ACRE. Part three of the book is aimed at realising the ACRE approach.

This chapter introduces the concept of modelling, discusses why modelling is so important in the context of the 'three evils' of engineering, establishes (some what appropriately in a book on requirements modelling) the basic requirements for modelling and concludes with a brief introduction to the systems engineering modelling language (SysML) that is used as the modelling language throughout the rest of the book. This chapter has introduced, appropriately for a book on model-based requirements engineering, the concept of modelling. We define a model as a simplification of reality created in order to help us understand the system under consideration because as human beings we cannot comprehend complexity. A model, whether mathematical, physical, textual or visual, allows us to address the so-called three evils, giving us techniques to identify complexity, increase our understanding and communicate in an unambiguous manner.

This chapter looks at the two aspects of modelling that are necessary in SysML the structural and behavioural aspects of a system. Block definition diagrams are used to discuss structural diagrams, and behavioural modelling is discussed by considering how the various diagrams relate to system hierarchy and engineering activity. A key consideration when modelling is consistency, leading to a good correct, concise and consistent model, which leads directly to confidence in the system. Confidence means that the system is understood and can be communicated to other people. Remember: SysML + consistency = model SysML consistency = pictures. The nine SysML diagrams are briefly introduced, with the five diagrams that are used by ACRE covered in more detail. For each diagram, its notation is introduced along with examples of its usage. These examples are taken from the world of escapology, namely the so-called coffin stunt, which is chosen since it ties in with the example system used in the case study.

This chapter discusses the key concepts associated with the world of model-based requirements engineering. The concepts and terminology introduced here are used throughout the rest of the book and form the basis of the context-based approach to model-based requirements engineering. To capture and describe the concepts and terminology, an 'ontology' is introduced. An ontology, in the context of this book, provides a visualisation of all the key concepts, the terminology used to describe them and the inter-relationships between said concepts. The ontology, however, is much more than just a data dictionary and plays a pivotal role in the definition and use of any rigorous framework. The use of ontologies for defining frameworks for architectures, such as enterprise architectures, process architectures, system architectures and so on, is one that is well established and used extensively throughout industry. For examples of the use of ontologies, see References 1-3. Whenever any framework is defined in terms of a set of views, an ontology is essential. It is the ontology that enforces the consistency and rigour demanded by such frameworks. The ontology that is introduced here covers all of the concepts pertinent to model-based requirements engineering and then, in the next chapter, a number of views are defined based on this ontology. Each view will focus on, and expand upon, a subset of the ontology and instantiate, or realise, specific concepts in the context of a real system or project. The use of the ontology for specifying views is shown explicitly in the next chapter, where the framework is introduced and described in some detail.

This chapter introduced the approach to context-based requirements engineering (ACRE) framework that comprises a number of views. The views are based on realisations of ontology. The chapter also discussed how the framework may be used to implement the ACRE philosophy on real projects and to discuss the 'people, process and tools' aspects of MBSE.

This chapter discusses the application of model-based requirements engineering by looking at a case study. Iteration is a necessary part of modelling and as such all of the models that follow have been developed in an iterative manner. Iteration is one of the fundamental principles of modelling; a model is never 'right first time'. Confidence in a model is gained by ensuring consistency between the diagrams forming the views; to achieve this, partly completed diagrams may need to be updated based on information gained from populating other views within the framework.

In order to realise any aspect of the model-based systems engineering (MBSE), it is essential to have people, processes and tools in place. This chapter looks at the pragmatic issues involved when trying to realise the context-based requirements engineering approach in any organisation or business. This chapter also suggests a course structure for teaching at university level. This chapter, along with supporting CASE tools and models, can be used as a tool kit for someone to create a requirements modelling course based on the contents of this book.

This appendix provides a summary of the systems engineering modelling language (SysML) notation used throughout this book. Although the SysML contains nine types of diagram, only five are used in this book. For each of these five SysML diagram types, three diagrams are given: A simplified meta-model diagram for that diagram type. The notation used on that diagram type. An example of that diagram type.

This appendix gives a summary of some of the advanced notations that can be used with SysML sequence diagrams that allow the following to be shown: Parallel behaviour; References to other sequence diagrams; Alternative steps; Loops. The notation to allow these constructs are known as combined fragments. For full details, see Reference 1. Examples of the notation for each of these combined fragments showing how they are used are given in the following sections.

This appendix gives a very brief overview of each of the seven views together with a model of UCAM processes. The seven views are: (1) Requirements View; (2) Stakeholder View; (3)Process Structure View; (4) Process Content View; (5)Process Behaviour View; (6) Information View; and (7) Process Instance View.