Requirements Modelling and Specification for Service Oriented Architecture

3.1. Conventional Approaches

Classic requirements engineering proceeded with the ultimate aim of producing a functional specification, which was often embodied in a number of giant-sized ring binders. The intention was that the customer would read, understand and correct the document, thus ensuring that the correct system was built. Such documents typically contained report layouts, screen mock-ups, Entity-Relationship (ER) and other technical diagrams and numbered lists of statements describing what the customer expected the system to do: the requirements. These were often written using a rather absurd vocabulary laid down originally by the US military, which insisted on the words that could be used as follows.

The word 'shall' (which in English implies duty) must be used for all statements of requirement. The word 'will' (in English this implies intention) must only be used to connote statements of fact. Goals can use the word 'should'. Michael Jackson (1995) pours scorn on this, challenging the reader to speak aloud and interpret the following two sentences. 'I shall drown, no one will save me. I will drown, no one shall save me'.

Whatever you think about this convention, enshrined as it is in an IEEE standard (Dorfman and Thayer, 1990), there are a number of points that the conventional approach sensibly insists upon. Most importantly, requirements should be numbered and cross-referenced to features and implementation status, and requirements should be concise descriptions ...