Ken Jackson

DOORS: A Tool to Manage Requirements

Systems engineers and managers need the right instruments to assist them with the requirements management process. A variety of tools currently exist. This chapter presents an overview of one of these tools – IBM Rational® DOORS® (Version 9.2). DOORS (Dynamic Object Oriented Requirements System) is a leading requirements management tool used by tens of thousands of engineers around the world. The tool was originally created by QSS Ltd, Oxford and is now developed and marketed by IBM.

Requirements Engineering in the Solution Domain

This chapter discusses requirements in the solution domain – the domain in which engineers use their ingenuity to solve problems. The primary characteristic that differentiates the solution domain from the problem domain is that, invariably requirements engineering in the solution domain starts with a given set of requirements. In the problem domain requirements engineering starts with a vague objective or wish list. The extent to which the input requirements for the solution domain are “well formed” depends upon the quality of the people within the customer organisation that developed them. In an ideal world, all the requirements would be clearly articulated, individual test able requirements.

A Generic Process for Requirements Engineering

This chapter introduces the concept of a process for the development of systems. It starts by examining the way in which systems are developed. This leads to the identification of a development pattern that can be used in many different contexts. This development pattern is expressed as a generic process and is explained in some detail. Subsequent chapters indicate how the generic process can be instantiated for specific purposes. The relationship between process models and information models is also explored and an information model for the generic process is developed.

Requirements Engineering in the Problem Domain

The problem domain is the domain in which a system is going to be used. Therefore it is important to look at requirements from an operational point of view. A system or any other product enables somebody or some equipment to do something. It is this enabling aspect that is at the heart of requirements engineering in the problem domain. Faced with the challenge of eliciting requirements from potential users one might therefore be tempted to ask a user the question:

System Modelling for Requirements Engineering

This chapter introduces system modelling as an important complement to requirements management. System modelling supports the analysis and design process by introducing a degree of formality into the way systems are defined. During system development it is often the case that pictures are used to help visualize some aspects of the development. Modelling provides a way of formalising these representations, through diagrams, by not only defining a standard syntax, but also providing a medium for understanding and communicating the ideas associated with system development.

Management Aspects of Requirements Engineering

The management of the requirements engineering process is similar to the management of any other endeavour. Before starting out it is necessary to understand what needs to be done. We need to know the sorts of activities that must be undertaken. We need to know whether there are any dependencies between the activities; for example, whether one activity can only commence when another one has been completed. We need to know what kinds of skills are required to perform the activities.

Combining a safety management process with a safety framework

A safety document management system, known as a Permit for Work (PFW) system is used commonly in the Power Industry to provide appropriate safety conditions for those working on the generating system. This paper investigates how a safety management process (+PFW) can be combined with a safety framework to enhance system effectiveness to ensure the requirements of users and suppliers can be met. While the paper makes some reference to the power industry, the concept is applicable to the management of systems in other domains.

Writing and Reviewing Requirements

Requirements engineering is a technical process. Writing requirements is therefore not like other kinds of writing. It is certainly not like writing a novel, or a book like this; it is not even like the kind of “technical writing” seen in instruction manuals and user guides.