Requirements Methodology Pack
January 2008 Version 0.3
Section 6.2
Functional Requirements - Template
Software Education Requirements Methodology Pack RMP_6.2_Functional_Requirements_-_Template_v0.3
Document Control
Version / Date / Author / Reviewers / Reason0.1 / 7 Dec. 07 / A Wever / Initial Draft
0.2 / Somebody? / Format, Style, Layout of document changed.
0.3 / 18 Jan 08 / A Wever / References and Hyperlinks updated.
Format, Style, Layout of document changed back to original format, style, layout consistent with remaining documents of Requirements Methodology pack.
0.3 / 8 Feb 2008 / Kate Wiltshire / Updated Copyright/Headers & Footers/Inserted SoftEd Logo
Acknowledgement
Portions of this template has been adapted from the VOLERE Requirements Specification template and Copyright © Atlantic Systems Guild.
Copyright
Copyright © 2008 Software Education Group. All rights reserved.
Approver Sign-Off
By providing my signature I acknowledge the accuracy of the content of this section/ document in the context of this project.Name & Title / Date Signed / Area of Responsibility
------/ ------
------
Table of Contents
Document Control 2
Approver Sign-Off 2
Introduction 4
Purpose 4
Document Conventions 4
Product Scope 4
Intended Audience 4
Acronyms and Abbreviations 4
Reference Documents 5
Overall Description 6
Product Perspective 6
Product Functions 6
User Classes and Characteristics 6
Operating Environment 6
Design and Implementation Constraints 6
User Documentation 6
Assumptions and Dependencies 7
The Scope of the Work 7
The current situation 7
The context of the work 7
The Scope of the Product 7
Product Boundary (Use Case diagram/ model) 7
Functional Requirements 8
System Feature 1 8
System Feature 2 (and so on) 9
Cutover/Conversion 9
Open Issues 9
User Documentation 9
Appendix A: Analysis Models 9
Appendix B: To Be Determined List 9
Introduction
Purpose
<Identify the product whose software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this Functional Requirements specification , particularly if this Functional Requirements specification describes only part of the system or a single subsystem.>
Document Conventions
<Describe any standards or typographical conventions that were followed when writing this Functional Requirements specification, such as fonts or highlighting that have special significance. For example, state whether priorities for higher-level requirements are assumed to be inherited by detailed requirements, or whether every requirement statement is to have its own priority.>
Product Scope
<Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If a separate Vision and Scope document is available, refer to it rather than duplicating its contents here.>
Intended Audience
<Describe the different types of reader that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers. Describe what the rest of this Functional Requirements specification contains and how it is organised. Suggest a sequence for reading the document, beginning with the overview sections and proceeding through the sections that are most pertinent to each reader type.>
Acronyms and Abbreviations
<Define all terms and acronyms used in this document.>
Term / DefinitionReference Documents
<This section defines all referencing documents such as:
- Related and or companion documents
- Prerequisite documents
- Documents which provide background and/or content for this document
- Linked documents for traceability such as Use Cases Documents or user interface style guides, standards, or Vision and Scope document>
Document Title6.3_Non-Functional_and_Supplementary_Requirements_-_Template.dot
Overall Description
Product Perspective
<Describe the context and origin of the product being specified in this Functional Requirements specification. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the Functional Requirements specification defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.>
Product Functions
<Summarize the major functions the product must perform or must let the user perform. Details will be provided within the detailed requirements section, so only a high level summary (such as a bullet list) is needed here. Organize the functions to make them understandable to any reader of the Functional Requirements specification.
User Classes and Characteristics
<Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the most important user classes for this product from those who are less important to satisfy.>
Operating Environment
<Describe briefly the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist. Detailed Environmental requirements constraining the product should be specified in the Non-Functional and Supplementary Requirements document.>
Design and Implementation Constraints
<Describe briefly any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software). Detailed Environmental requirements constraining the product should be specified in the Non-Functional and Supplementary Requirements document.>
User Documentation
<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards. Detailed Environmental requirements constraining the product should be specified in the Non-Functional and Supplementary Requirements document.>
Assumptions and Dependencies
<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the Functional Requirements specification. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the project brief (vision and scope document) or the project plan).>
The Scope of the Work
<The scope of the product and workflows may be described for the AS-IS or TO-BE system. Add relevant headers as necessary. Be aware that the Project Brief contains detailed scope information.>
The current situation
<This section describes existing business processes and the changes it may experience when adopting the new product. Business Use Cases or a Business Process Model may be used to describe the proposed Business Process Flow and Business Events to which the work responds (captured in a B5 model.>
The context of the work
<Add your context diagram in this section to illustrate the work to be investigated in order to build the product. Ensure that terms used within the context diagram are going to be consistent with terms used within the Entity Relationship Diagram or Data Dictionary.>
The Scope of the Product
Product Boundary (Use Case diagram/ model)
<Add your Use Case diagram to identify the boundary between the actors and the product. This can be derived from the Business Use Cases/ Business Process model by determining which parts of the process are to be automated, and not. Specify your use cases.>
Functional Requirements
<This template illustrates organising the functional requirements for the product by system features, the major services provided by the product. You may prefer to organize this section by use case, mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense for your product.
System Feature 1
<Don’t really say “System Feature 1.” State the feature name in just a few words, e.g. Monthly reporting.>
<Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available>
<Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind. The Requirements shell defined below is an excellent way of capturing the necessary requirement attributes. For each requirement, attributes identified in the table must be captured.>
RequirementsID / <Unique Requirements ID>
Background
Information / <A paragraph statement that explain the existence of this requirement. Any additional information which is considered valuable may be included as a reference to documents that illustrate and explain this requirement.>
Requirements
Statement / <A one sentence statement of the intention of this requirement.>
Verification / <A statement that determines whether a given solution fits the requirement or a measure of the requirement such that it is possible to test if a requirement has been implemented.>
Business
Priority / <A rating on the customer value if the requirements were/ were not implemented on time.>
Originator
(Name, Job Role, Date raised) / <The person who raised the requirement. e.g.
John Smith, Business Sponsor, 31/12/1967>
Use Case/ Event
Reference (s) / List of Use Cases/ Events that generated this requirement (Functional Requirements) or need this requirement (Non-Functional Requirements).
NB Requirements Shell adapted from Volere Atlantic Systems Guild.
System Feature 2 (and so on)
Cutover/Conversion
<Include details of any processes to change over from an existing system or process to the new application>
Open Issues
<Include any requirements related issues that have been raised but not yet resolved. Include details of current status, this section can be marked as "Not applicable" if an issues
User Documentation
<Plan/details of any user documentation that will be produced>
Appendix A: Analysis Models
<Optionally, include any pertinent analysis models, such as use cases, data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.>
Appendix B: To Be Determined List
<Collect a numbered list of the TBD (to be determined) references that remain in the Functional
Copyright © 2008 Software Education Group. All rights reserved. Page 2 of 9