The System Requirements Document Introduction Here we give the template for a highly formal System Requirements Document,

based on [IEEE, 1993b,ESA, 1984,Mazza et al., 1996] that would be compatible with the formal waterfall process; we then emphasise the utility of the section headings as checklist items for less formal applications. paragraphContents of the SRD (i) Title Page: Name and address of organisation. Title of Document: System Requirements Definition for... Version number - if there are going to different versions. Date. Reference number. Author/responsible (optional). (ii) Abstract. (optional). (iii) Change control log. (iv) Distribution log. (v) Contents list. List of sections. List of Figures. List of Tables. List of Appendices. 1. Introduction. - Introduce purpose of document. - Scope of document. - Structure of document. 2. Applicable and Reference Documents. - List of documents -- like a bibliography. 3. General Description. 3.1 Perspective.

- brief sketch of business area; of users; finally zooming in to system required. - should attempt to give programmers etc. a feeling for the problem, outside formal specification. 3.2 Related projects. - e.g. software to replace an out of date package, or one that never worked. - a parallel project (say) being conducted by another S/W house. 3.3 Function and Purpose. Thumbnail sketch of of what the system must do, not do, and the purpose it will be used for. 3.4 System Environment. - what the system must interface with, - special considerations leading to reliability (say) or safety requirements. - relationship to other systems. 3.5 General constraints. - e.g. software must run on a particular computer, use a particular compiler, etc. - e.g. system must be available by December 31 1998. - e.g. wages system must be able to perform a particular function between 9am and 11am on Thursday mornings. 4. Specific Requirements. 4.1 Functional Requirements. The requirements that we normally think of -- what the system must do. - list of tasks or processes, - processes (maybe) specified by: - inputs - outputs - detailed specification of processing - in structured systems analysis the functional requirements are specified by:

- the hierarchy of Data Flow Diagrams - the Data Dictionary - specification of lowest level DFD processes using Structured English, or pseudo-code and other methods. - emphasis on: UNAMBIGUOUS, QUANTITATIVE, TESTABLE requirements. 4.2 Performance Requirements. - specifies the speed at which the system must operate, - e.g. payroll must complete in 1 hour -- for 1000 employees or less. - Sections 4.1 and 4.2 might need to be lumped together where there were many separate processes in the functional requirements -- each with its own performance requirement. 4.3 Interface Requirements. - what the system must connect to. - e.g. a software payroll system which must interface with the current personnel information system. - a personal computer system which must connect to the existing corporate network. 4.4 Operational Requirements. Requirements arising out of how, where the system will be used. E.g. - qualification of users/operators, - use in a hostile environment. 4.5 Resource Requirements. - for a software system specifies: - the hardware to be used, - hardware limitations e.g. amount of memory. - compiler to be used. 4.6 Verification Requirements. - specifies tests to be done during development, test data, test documentation to be delivered. 4.7 Acceptance Testing. - specifies the tests that will be used as the basis for user acceptance of the system.

4.8 Documentation Requirements. - documentation to be delivered during development. - docn. that will be part of system e.g. User Manuals, Maintenance Manuals, etc. 4.9 Quality Requirements. - may specify production and adherence to a Quality Assurance Plan, - may require supplier to have achieved a Q.A. standard, e.g. BS 5750 - change control requirements; configuration management. 4.10 Safety Requirements. - safety of data files in a Data Processing application. cf Data Protection Act. - safety of equipment and people in a real time control application, cf. Year 2000 problem. cf. Product liability. 4.11 Reliability Requirements. Can be formally specified by Mean Time Between Failures (MTBF), and Mean Time To Repair (MTTR). But difficult for software, still a research area. 4.12 Maintainability Requirements. Specifies attributes of the system that affect the ability to - trace and repair defects - make modifications. e.g. for software: - modularity, - use of object-oriented programming, - built-in self test, - quality of documentation, - readability of source code. 4.13 Schedule Requirements. The above information can be found at: http://www.cs.qub.ac.uk/~J.Campbell/myweb/misd/node3.html#SECTION0034000000000 0000000