Method(ologie)s for Requirements Engineering

1 General-Purpose Software Development Method(ologie)s

In general terms, the aim of a software development methodology is to make it easier to develop good quality software. A software development organisation may opt to use a well-defined methodology in many development projects in order to minimise the kinds of risks involved in one-off 'seat-of-the-pants' developments. The methodology used may be a well-known standard methodology such as SSADM, or may be one developed by the organisation itself to meet its own specific needs.

A software development methodology takes a particular view of the software development process or 'lifecycle' and provides techniques, tools and working practices for use at various stages in the process. A software development methodology may be expected to offer:

• an overall philosophy and management framework
• a collection of techniques including notations and conventions about how to use them
• a collection of tools, some of which may be computer-based (eg CASE tools)
• a collection of organisational structures and working practices

Most general-purpose software development methodologies provide at least some support for requirements engineering activities, though many focus more on the design of the new system rather than discovering and analysing problems with an existing system and the requirements that arise from them. Methodologies targeted more specifically at the early stages of a development project often provide better support for requirements engineering.

2 Method(ologie)s for Requirements Engineering

There are a number of methodologies aimed specifically at providing support for the activities involved in requirements engineering. These can be loosely classified along the dimension of hard --- soft.

'Hard methods' tend to assume that requirements are explicit and quantifiable from the outset. Typically provide more guidance on requirements modelling than elicitation or validation. Very commonly used.

'Soft methods' have been developed as a reaction to the assumptions of hard methods. More effort is spent in working out what ends are desired, rather than what would be the means to a particular end. It is acknowledged that different views on what might be a desirable end are likely to exist at the beginning of a software development project, and the aim is to identify the different views and facilitate a reconciliation. Soft approaches typically focus more on elicitation and validation than formal modelling.

Methodologies for requirements engineering include:

Soft Systems Methodology (see below)	soft
ETHICS (Mumford 79)	|
Multiview (Avison 90)	|
ORDIT (see below)	|
CORE (see below)	|
Yourdon (see below)	|
JSD (Jackson 82)	hard

Soft Systems Methodology (SSM)

(D. Patching, Practical Soft Systems Analysis, Pitman Publishing, 1990 - see overview in chapter 4)

Soft systems methodology was originally developed by Peter Checkland. It provides a set of guidelines for examining an organisation in order to determine where improvements can most fruitfully be made. SSM adopts a systems perspective i.e. it attempts to consider an organisation (involving people, machines, policies etc) as a whole. It aims to involve system stakeholders in debate about what are desirable solutions, rather than impose a solution which the system developers believe to be the right one. It is best suited to use in situations where the problem to be solved by a new system is initially very vaguely defined.

The soft systems methodology involves 7 main activities. These need not be performed in the order described and may also be tackled in parallel.

Stages 1 & 2: the analyst begins at stage 1 where the problem situation is unstructured and the statement of the problem to be solved is vague and information needs to be collected from many different sources; in stage 2, this information is expressed in the form of a rich picture

Stages 3 & 4: one or more root definitions are defined; root definitions may be defined from a number of different viewpoints; they should contain the following components (which can be memorised using the CATWOE mnemonic):

Clients or customers of the proposed system

Actors who carry out the (human) activities within the system

Transformations - changes that take place within or because of the system

Weltanshaung (or Worldview) - how the system is perceived from a particular viewpoint, assumptions that are made about it etc

Owner of the system i.e. who the system is answerable to, or who could terminate it

Environment - the world that surrounds and may influence the system

Root definitions may be expressed as simple statements eg a root definition of a pub from a customer viewpoint might be:

C - the customers of the pub, casual and regular

A - the employees, visiting entertainers, customers

T - customer needs (for socialising etc) identified and satisfied

W - a pub is a place to socialise and enjoy a pleasant atmosphere

O - the publican

E - laws about licensing etc

Verbs in the root definitions are used as the basis for defining conceptual models, usually in diagrammatic form, which are then checked against a well-defined view of what a system model should be like (a 'formal systems model') to ensure that it is in some sense 'correct'.

Stage 5: the models are compared with what exists in real life eg do activities shown in the model exist in real life? Comparison should reveal areas where changes could be made.

Stage 6: possible changes are assessed, with actors in the system, for eg cultural feasibility, and desirability; an agreed list of changes is generated

Stage 7: action is taken to improve the situation!

CORE (COntrolled Requirements Expression)

(See also chapter 4 in I. Sommerville, Software Engineering, Addison-Wesley, 1992.)

CORE was developed by Systems Designers (now SD Scicon) and BAe in the late '70s, since when two major variants have emerged, both of which are still evolving.

A simplified view of the stages in the System Designers version is:

1. Problem definition - aim to identify customer authority and problem context and boundaries; aim to achieve consensus on what the problem is at this stage
2. Viewpoint structuring - identify all different viewpoints (or perspectives) on the system; viewpoints may relate to any entities with an interest in or relationship to the target system including humans (users, managers etc), hardware and software; all viewpoints identified in initial elicitation activities (such as brainstorming meetings) should be recorded, and then clustered together into eg data viewpoints, non-functional viewpoints, user viewpoints, function viewpoints and service viewpoints; viewpoints are structured into a hierarchy which can then be used to guide further elicitation.
3. Tabular collection - for each functional viewpoint, all inputs, outputs and major processes are identified in tables showing source viewpoint for inputs, processing (actions) carried out by the viewpoint of interest, and destination viewpoints for outputs; this begins to establish confidence in completeness and consistency once all data can be shown to have source and destination viewpoints, and to be used in particular actions.
4. Data structuring - data modelling techniques (eg using ER diagrams and data dictionaries) can be used to model input and output data more thoroughly.
5. Single viewpoint modelling - 'action diagrams' (eg using DFDs) can be used to define actions in the viewpoint tables more precisely.
6. Combined viewpoint modelling - model composition of viewpoints where necessary by showing relationships between different action diagrams
7. Constraints analysis - produce separate constraints specification (i.e. specification of non-functional requirements)

ORDIT: Organisational Requirements Definition for Information Technology

(See chapter 4 in M. Jirotka and J. Goguen (eds), Requirements Engineering: Social and Technical Issues, Academic press, 1994)

ORDIT stresses social-organisational issues. ORDIT aims to combine and reconcile the differing representations of a system and its operational, organisational and social environments.

ORDIT provides:

1. A process model - model of the process of eliciting and modelling requirements. According to ORDIT, finding requirements involves at least three roles - requirements owner, requirements elicitor and requirements modeller - and a number of separate tasks involving complex feedback loops
2. An enterprise modelling language - representing the structure of the organisation in order
   1. (a) to determine who the requirements owners are and what their positions and roles in the organisation are, and
   2. (b) to determine who is in the user community (and find out who else may be affected by the proposed system) and to find out their roles and responsibilities in the organisation
3. An information modelling language - to construct required data models and to record the non-functional requirements, such as security and privacy
4. A role reference model - to capture all the aspects of a role, such as functional and structural relationships, responsibilities, information access modes and rights
5. Supporting tools - the ORDIT methodology is supported by a number of modelling tools which combine the power of hypertext-like structures with easy-to-use graphical interfaces and logical and analytical power.

Yourdon Structured Method (Yourdon)

(E. Yourdon, Modern Structured Analysis, Prentice-Hall, 1989.)

Yourdon is typical of a number of methods developed in the 1980's. These methods all provide slightly different conceptual frameworks to support the activities of the developer. Most of the methods are based on the use of one or more graphical notations which are intended to allow a developer to describe succinctly what a software system should do. Notations used in Yourdon Structured Analysis include data flow diagrams, state transition diagrams, entity relationship diagrams and data dictionaries.

YSM includes two distinct modelling activities:

• essential modelling, the aim of which is to describe the essence of what the required system should do in the customer's terms and independent of any particular implementation technology
• implementation modelling, which aims to combine those aspects of the system specification which are dependent on a particular technology with the essential model. The implementation model is thus an elaboration of the essential model.

References

[1] D. Avison and A. Wood-Harper, Multiview: An Exploration in Information Systems Development, Blackwell Scientific, 1990.

[2] A.J.C.Blyth, J.Chudge, J.E.Dobson, M.R.Strens, The ORDIT Approach to Requirements Identification, Compsac '92, pp.356-361, 1992

[3] M. Jackson, Systems Development, Prentice-Hall, 1982.

[4] G.P.Mullery, CORE - A Method for Controlled Requirement Specification, in

Proceedings of the 4th International Conference on Software Engineering, Munich, Sept.1979

and in Thayer and Dorfman (see below)

[5] E. Mumford, designing Human Systems, Manchester Business School Publications, 1984.

[6] R. Thayer and M. Dorfman, System and software requirements engineering, IUEEE Computer Society Press,1990.