1. Types of Requirements  Functional Requirements  Descriptions of actions or processes that create or update information.  Outlines of reports or on-line queries. These can be user requested or automatically generated by the system at scheduled times, or when specified events occur.  Details of business data to be held and used within the system.  Non-functional Requirements  Required service levels  Volumes  Transition arrangements  Technical constraints  Usability  Required interfaces with other systems  Security and Access requirements  Project constraints, e.g. system delivery date, cost limits, company policies

2. Requirements Catalogue  A priority for the requirement, such as essential to the operation of the system or business (E), desirable as it will deliver significant business benefit (D) or nice to have (N), i.e. “luxury” features  Suggested solutions  The source of the requirement  The owner or user responsible for agreeing and signing off the requirement  Associated non-functional considerations  Benefits  Related project documents or products  Related functional requirements  Resolution

3. Requirements Catalogue

4. Requirements Summary

5. Identifying and Developing Requirements  Traditional Fact Finding:  Interviews.  Workshops.  Examination of Business Documentation.  Questionnaires.  Observation of Operations.  Brainstorming Sessions.  Project Sources:  Project input documents.  Previous or related studies.  Current system problem and change logs.  Business Activity Modelling.  Prototyping. General fact-finding are outside the scope of this module, but are documented well elsewhere, e.g. Yeates, Shields and Helmy (1994), Chaffey (1999).

6. Current Systems  While the emphasis of Requirements Definition must always be on the new system, the requirements most readily highlighted by users often relate to solving problems associated with the current system support, such as:  Restrictive operations.  Poor system quality.  Lack of system availability.  Inadequate or complex user interfaces.  Lack of capacity.

7. Developing Requirements - Tips  Where requirements are generated from current problems we must ensure that the future requirement is properly recorded. For example, if a current issue is that an enquiry takes 30 seconds, we need to record the required response time, rather than stating that 30 seconds is too long.  In areas where satisfactory support is already provided by an existing system we will still need to document requirements.  We must always attempt to explore the validity of a requirement with users before recording it formally in the catalogue. We should also attempt to identify duplicate requirements before documenting them.  Despite the danger of wasted effort, our policy should always be one of “if in doubt, record it”.  Our aim should be to capture a picture of requirements that is as accurate and complete as possible.  The precise number of catalogue entries generated is largely a matter of individual judgement and style (and an organisation’s internal standards).