DOC NO 0158-0001-603-D-1
DRAFT
User Requirement Template
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 1 OF 9
DOC NO 0158-0001-603-D-1
DRAFT
DETAILS
Project Title: System/Subsystem Title: Document Issue Date: Client Reference: KC007 User Requirement Template 0 XXX, 0000 Order no
APPROVAL
Checked by Author Name J Zietsman Signature Date
Technical Approval
Project Manager
P Burger
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 2 OF 9
DOC NO 0158-0001-603-D-1
DRAFT
Table of Contents
DETAILS .............................................................................................................2 APPROVAL.........................................................................................................2 LIST OF FIGURES..............................................................................................4 LIST OF TABLES ...............................................................................................4 APPLICABLE DOCUMENTATION .....................................................................4 1. HEADING 1 SAMPLE..................................................................................... 1.1 1.2 HEADING 2 SAMPLE .....................................................................................
Heading 3 sample................................................................................................. 1.1.1
NEXT HEADING 2 SAMPLE ............................................................................
2. NEXT SECTION.............................................................................................. 3. INDEX ............................................................................................................. DISTRIBUTION LIST ............................................................................................ CONFIGURATION CONTROL ...........................................................................9 DOCUMENT HISTORY ..........................................................................................9 REVISION HISTORY .............................................................................................9 AUTHORISATION HISTORY ...................................................................................9 DEFINITION OF TERMS AND ACRONYMS......................................................9
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 3 OF 9
DOC NO 0158-0001-603-D-1
DRAFT
LIST OF FIGURES Number Enter your figures here LIST OF TABLES Number Page Page
Enter your list of tables here. It may be a good idea to put all figures and tables at the back of the document as appendices, so as to make the reading of your document easier.
APPLICABLE DOCUMENTATION
Insert the complete list of all documents referenced in your document here. These include, but are not limited to, terms of reference, minutes of meetings, contracts, specifications, test reports, trade off study reports, international or other standards etc., as applicable. In the body of your document, reference shall be made to the specific paragraph in the referenced document. DO NOT QUOTE A COMPLETE DOCUMENT AS REFERENCE.
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 4 OF 9
DOC NO 0158-0001-603-D-1
DRAFT
1. USER REQUIREMENTS STATEMENT SCOPE
1.1 Purpose The User Requirements Statement (URS) is a document that describes a shortfall or a technological opportunity of a prospective customer. It presents the primary decision factors that should be considered at proposal evaluation. 1.2 Description
• •
The URS shall justify the need for action to resolve a shortfall for a customer. The URS shall be derived from rigorous requirements analysis (i.e., continuous analysis of current and forecasted capabilities in relation to projected demand for services or solutions) . The URS shall contain sufficient quantitative information to establish and justify the need. The URS shall be “need-oriented” and shall not seek to justify a specific solution or acquisition program. The URS shall be updated when there is significant change to the user requirements. It shall be revalidated and approved at subsequent decision points.
• • •
NOTE 1: The User requirements Statement is a summary document that describes the operational problem and presents major decision factors. The customer shall agree to this statement. NOTE 2: Detailed quantitative and analytical information should be included as attachments.
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 5 OF 9
DOC NO 0158-0001-603-D-1
DRAFT
2. APPLICABLE DOCUMENTS.
The following documents of the exact issue shown form a part of this specification to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this specification, the contents of this specification shall be considered a superseding requirement. Insert the complete list of all documents referenced in your document here. These include, but is not limited to, terms of reference, minutes of meetings, contracts, specifications, test reports, trade off study reports, international or other standards etc., as applicable. In the body of your document reference shall be made to the specific paragraph in the referenced document. DO NOT QUOTE A COMPLETE DOCUMENT AS REFERENCE. Copies of specifications, standards, drawings, and publications required by suppliers in connection with specified procurement functions should be obtained from the contracting agency or as directed by the contracting officer.
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 6 OF 9
DOC NO 0158-0001-603-D-1
DRAFT
3. USER REQUIREMENT STATEMENT FOR THE
3.1 Background to the user’s requirements
3.2 Requirements Area. The URS should describe the role or task requirements.
• • •
Define typical task profiles for primary and secondary task requirements. Elaborate tasks, as needed using scenarios. Specify figures of merit for each task.
Describe the requirements in terms of functions to be performed or services to be provided. Never describe the requirements in terms of a system or solution. Describe the environment in which the requirements are to operate (physical, operational, organisational, etc.). Describe the support policy intended to sustain the requirement throughout it’s lifetime. Investigate alternative support models. Include the following issues: 1. Diagnostic requirements. 2. Support and test equipment policy. 3. Maintenance and repair logistics. 4. Personnel support policy (Number, skills, know-how, etc.) 5. Training and related equipment. 6. Provisioning for spares, repair parts and supplies. 7. Required facilities policy. 8. Packaging, handling, storage and transport policy. 9. Configuration management. 10. Interfaces to existing co-functioning systems. Cite reference(s) where possible to add credibility to the existence of the need. 3.2.1 Current Capability. Describe quantitatively the capability of current systems, facilities, equipment, or other assets currently in use to meet the user requirements. 3.2.2 Shortfall. Describe and quantify the shortfall, as derived from operational and performance analyses. Describe the technological opportunity in terms of:
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 7 OF 9
DOC NO 0158-0001-603-D-1
DRAFT
• • •
Improved productivity. Operational effectiveness. Efficiency.
Provide validated growth projections based on operational analysis, if possible. Summarise the limitations of facilities, equipment, or services currently in use. Provide specific operational and performance analyses, quantitative projections, supporting data, or other analyses as attachments. 3.2.3 Impact. Describe the impact on the users ability to perform if the problem is not resolved. Categories of impact include safety, capacity, operations, maintenance, cost, and other factors as appropriate. 3.2.4 Time frame. Identify when the problem will seriously affect the users ability to perform if no action is taken. Establish when action must be taken to avoid the adverse impact. 3.2.5 Criticality. Define the priority of this problem relative to other needs of the customer. Characterise the criticality of this problem. 3.2.6 Resource estimate and constraints. Provide a rough estimate of the resources that will be needed to resolve the problem or achieve the technological solution. Address the following constraints: 1. Budget and cash flow. 2. Initial operational date. 3. The number of items to be produced. 4. Phase out of existing system.
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 8 OF 9
DOC NO 0158-0001-603-D-1
DRAFT
CONFIGURATION CONTROL DOCUMENT HISTORY Version 1 Date 6/5/1997 Status Draft Editor S.P Filename Document8
REVISION HISTORY Version 0 1 2 2-C D-1 Date 6/5/1997 6/6/1997 6/27/1997 8/14/1997 09/04/1998 Changes New template created Changes made to the footer and the layout of the standards section Version changed to 2 for approval Front page corrected Re-issued with new layout
AUTHORISATION HISTORY Version 2 D-1 Date 6/30/1997 09/04/1998 Status Approved Approved Reference Meeting on 6/30/1997 ref. 0158-9999-952-A-1 Meeting on 03/04/1998
DEFINITION OF TERMS AND ACRONYMS
ISSUE DATE: 3 AUGUST, 1998
DRAFT
PAGE 9 OF 9