JRA4-MOD-2000-0002Software User Requirements Template
JRA4
<Software Package>
Software User Requirements Template
Author1 ()
Institute1
Author2
Institute2
Author3
Institue3
Author: vmmodelInstitute : / Signature :
Date :
Approved by :
Institute : / Signature :
Date :
Released by :
Institute : / Signature :
Date :
Change Record
REVISION / DATE / AUTHOR / SECTIONS/PAGES AFFECTEDREMARKS
Table of Contents
1Introduction
1.1Purpose
1.2Reference Documents
1.3Abbreviations and Acronyms
1.4Document Conventions
2General Description
2.1Software Perspective
2.2User Classes and Characteristics
2.3Operating Environment
2.4General Constraints, Assumptions, Dependencies, Guidelines
2.5Design and Implementation Constraints
2.6User Documentation
3Specific Requirements
3.1Capability Requirements
3.1.1[subsection]
3.1.2[ ... ]
3.2Constraint requirements
3.2.1[subsection]
3.2.2[ … ]
4User Interface Requirements
4.1GUI
4.2CLI
4.3API
4.4Diagnostics or ROM
5Operational Scenarios
IMPORTANT: This document is designed to provide guidelines for writing Software User Requirements. The author should add any new sections that are pertinent to the project.
1Introduction
The introduction of the User Requirements (UR) provides an overview of the entire UR. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the UR.
1.1Purpose
Specify the purpose of this UR. The scope of this document is to present the set of user requirements which have to be classified into two categories of Capability (functional) Requirements and Constraint Requirements.
Understanding the user’s real requirements, rather than their requirements as perceived by the software developer, is absolutely critical to the development of the successful software.
1.2Reference Documents
This subsection provides a complete list of all documents referenced elsewhere in the UR. Identify each document by title, report number if applicable, date, and publishing organization. This information may be provided by reference to an appendix or to another document.
[1]Document number, revision, date (optional), title, author.
or
[2]Book tit le, author, publisher, year
1.3Abbreviations and Acronyms
This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the UR. This information may be provided by reference to the project's Glossary.
TBDTo Be Defined
1.4Document Conventions
Describe any standards or typographical conventions that were followed when writing this UR, 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.
2General Description
2.1Software Perspective
Provides a brief overview, describe the context and origin of the software. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.
2.2User Classes and Characteristics
Identify the various user classes that you anticipate will use this software. 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 favoured user classes from those who are less important to satisfy.
List critical characteristics of the system's human interfaces based on the user's characteristics.
2.3Operating Environment
Describe 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.
2.4General Constraints, Assumptions, Dependencies, Guidelines
Include factors that impose constraints on the implementation of the software product. This can include hardware limitations or requirements, the amount of memory available, response times, policies, interfaces to other application software, networks, environmental limitations, compliance with relevant standards. This section can also provide guidance in situations when there may be more than one implementation strategy.
Examples: "The product will only work with certain operating systems or a particular network environment."
"The product must be Web-based."
"The product cannot require persistent data."
2.5Design and Implementation Constraints
Describe 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.
2.6User 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.
3Specific Requirements
List all specific requirements, with attributes.
User requirements fall into two categories: capabilities needed by users to solve a problem or achieve an objective; constraints placed by users on how the problem is to be solved or the objective achieved.
Each user requirement must include:
Description - a user requirement is clear if it has one, and only one, interpretation. Clarity implies lack of ambiguity. If a term used in a particular context has multiple meanings, the term should be qualified or replaced with a more specific term.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" have to be used in the requirement description and are to be interpreted as described in RFC 2119 (see
Priority - for incremental delivery, each user requirement shall include a measure of priority so that the developer can decide the production schedule.
Stability - some user requirements may be known to be stable over the expected life of the software; others may be more dependent on feedback from the specification or design phases, or may be subject to change during the software life cycle. Such unstable requirements should be flagged.
Verifiability - each user requirement shall be verifiable. This means that it must be possible to: check that the requirement has been incorporated in the design; prove that the software will implement the requirement; test that the software does implement the requirement.
3.1Capability Requirements
Capability requirements describe functions and operations needed by users. Quantitative statements that specify performance and accuracy attributes should form part of the specification of a capability.
3.1.1[subsection]
3.1.2[ ... ]
3.2Constraint requirements
Constraint requirements place restrictions on how software can be built and operated. For example, definitions of external communications, hardware and software interfaces may already exist, either because the software is a part of a larger system, or because the user requires that certain protocols, standards, computers, operating systems, library or kernel software be used.
Constraints that users may wish to place on the software include the quality attributes of adaptability, availability, portability and security. The user shall describe the consequences of losses of availability, or breaches of security, so that developers can fully appreciate the criticality of each function.
The user may choose to make additional standards applicable; such requirements are additional constraints on the development.
3.2.1[subsection]
3.2.2[ … ]
4User Interface Requirements
This section describes how the software interfaces with users for input or output.
4.1GUI
This section describes the graphical user interface, if present. This section should include a set of screen dumps or mock-ups to illustrate user interface features.
If the system is menu-driven, a description of all menus and their components should be provided.
4.2CLI
This section describes the command-line interface, if present. For each command, a description of all arguments and example values and invocations should be provided.
4.3API
This section describes the application programming interface, if present. For each public interface function, the name, arguments, return values, examples of invocation, and interactions with other functions should be provided.
4.4Diagnostics
This section describes how to obtain debugging information or other diagnostic data.
5Operational Scenarios
PURPOSE: This sectionidentifies the behavior of the SOFTWARE from a users perspective. It will detail the software responses to inputs provided by the user or actor. It will also identify the valid actors, pre-conditions, post-conditions, alternate paths, and constraints associated with each use case. This section should describe a set of scenarios that illustrate, from the user's perspective, what will be experienced when utilizing the software under various situations.
Scenarios can be defined as follows:
“In the broad sense, a scenario is simply a proposed specific use of the software. More specifically, a scenario is a description of one or more end-to-end transactions involving the required software and its environment. Scenarios can be documented in different ways, depending up on the level of detail needed. The simplest form is a use case, which consists merely of a short description with a number attached. More detailed forms are called scripts. These are usually represented as tables or diagrams and involved identifying an action and the agent of the action.”
Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because the describe the system's behavior only in specific situations; a specification, on the other hand, describes what the system should do in general.
Revision: 1.0Page 1/7