Documenting the Project Lifecycle

This document is a template for creating a Business Requirements Document (BRD); it includes instructions and examples for guidance. As you complete your BRD using the template, only include sections pertinent to your project.

Describe this project or product and its intended audiences, or provide a link or reference to the project charter.

Describe the purpose of this specification and its intended audience. Include a description of what is within the scope what is outside of the scope of these specifications.

Example:

In Scope

This document addresses requirements related to Phase 2 of Project A:

· Modification of Classification Processing to meet legislative mandate ABC

· Modification of Labor Relations Processing to meet legislative mandate ABC

Out of Scope

The following items in Phase 3 of Project A are out of scope:

· Modification of Classification Processing to meet legislative mandate XYZ

· Modification of Labor Relations Processing to meet legislative mandate XYZ

(Phase 3 will be considered in the development of the requirements for Phase 2, but the Phase 3 requirements will be documented separately.)

In this section, describe the general factors that affect the product and its requirements. This section should contain background information, not state specific requirements (provide the reasons why certain specific requirements are later specified).

How does this product relate to other products? Is it independent and self-contained? Does it interface with a variety of related systems? Describe these relationships or use a diagram to show the major components of the larger system, interconnections, and external interfaces.

Create general customer profiles for each type of user who will be using the product. Profiles should include:

· Type of user (e.g., student, faculty, staff, other)

· Experience of the user

· Technical expertise level of the user

· Other general characteristics of the user that may influence the product

List any assumptions that affect the requirements, for example, equipment availability, user expertise, etc. For example, a specific operating system is assumed to be available; if the operating system is not available, the Requirements Specification would then have to change accordingly.

Describe any items that will constrain the design options, including:

· Parallel operation with an old system

· Audit functions (audit trail, log files, etc.)

· Access, management, and security

· Criticality of the application

· System resource constraints (e.g., limits on disk space or other hardware limitations)

· Other design constraints (e.g., design or other standards, such as programming language or framework)

List dependencies that affect the requirements.

Examples:

· This new product will require a daily download of data from X.

· Module X needs to be completed before this module can be built.

Describe all system requirements in enough detail for designers to design a system satisfying the requirements, and for testers to verify that the system satisfies requirements.

In the example below, the requirement numbering has a scheme - BR_LR_0## (BR for Business Requirement, LR for Labor Relations). For small projects, simply BR-## would suffice. Keep in mind that if no prefix is used, the traceability matrix may be difficult to create (e.g., no differentiation between '02' as a business requirement vs. a test case).

The following table is an example format for requirements. Choose whatever format works best for your project.

Example:

In addition to functions required, describe the characteristics of each interface between the product and its users (e.g., required screen formats/organization, report layouts, menu structures, error and other messages, or function keys).

Specify static and dynamic numerical requirements placed on the system or on human interaction with the system:

· Static numerical requirements may include the number of terminals to be supported, the number of simultaneous users to be supported, and the amount and type of information to be handled.

· Dynamic numerical requirements may include the number of transactions and tasks and the amount of data to be processed within a certain time period for both normal and peak workload conditions.

All of these requirements should be stated in measurable form. For example, "95% of the transactions shall be processed in less than 1 second" rather than “an operator shall not have to wait for the transaction to complete”.

Include measurable capacity requirements (e.g., the number of simultaneous users to be supported, the maximum simultaneous user load, per-user memory requirements, expected application throughput).

Include specific and measurable requirements for:

· Hours of operation

· Level of availability required

· Coverage for geographic areas

· Impact of downtime on users and business operations

· Impact of scheduled and unscheduled maintenance on uptime and maintenance communications procedures

· Reliability (e.g., acceptable mean time between failures (MTBF), or the maximum permitted number of failures per hour)

Include explicit latency requirements, e.g., the maximum acceptable time (or average time) for a service request.

Include any requirements for product or service health monitoring, failure conditions, error detection, logging, and correction.

Specify attributes of the system that relate to ease of maintenance. These requirements may relate to modularity, complexity, or interface design. Requirements should not be placed here simply because they are thought to be good design practices.

Specify any normal and special operations required by the user, including:

· Periods of interactive operations and periods of unattended operations

· Data processing support functions

· Backup and recovery operations

· Safety considerations and requirements

· Disaster recovery and business resumption

Specify the use of other required products (e.g., a database or operating system), and interfaces with other systems (e.g., UWHires package interfaces with PubCookie and ODS, HEPPS system interfaces with Budget system). For each interface, define the interface in terms of message format and content. For well-documented interfaces, simply provide a reference to the documentation.

Outline each interface between the product and the hardware or network components of the system. This includes configuration characteristics (e.g., number of ports, instruction sets), what devices are to be supported, and protocols (e.g., signal handshake protocols).

Specify the logical characteristics of each interface between the product and the hardware or network components of the system. This includes configuration characteristics (e.g., number of ports, instruction sets), what devices are to be supported, and protocols (e.g., signal handshake protocols).

Specify the systems interface requirements.

Example:

Specify the factors that will protect the system from malicious or accidental access, modification, disclosure, destruction, or misuse.

Example:

· Encryption

· Activity logging, historical data sets

· Restrictions on intermodule communications

· Data integrity checks

Specify the Authorization and Authentication factors. Consider using standard tools such as PubCookie.

Specify the requirements for any information that is to be placed into a database, including:

· Types of information used by various functions

· Frequency of use

· Data access rules

· Data entities and relationships

· Integrity constraints

· Data retention

· Valid range, accuracy, and/or tolerance

· Units of measure

· Data formats

· Default or initial values

Specify the requirements derived from existing standards, policies, regulations, or laws (e.g., report format, data naming, accounting procedures, audit tracing). For example, this could specify the requirement for software to trace processing activity. Such traces are needed for some applications to meet minimum regulatory or financial standards. An audit trace requirement may, for example, state that all changes to a payroll database must be recorded in a trace file with before and after values.

If portability is a requirement, specify attributes of the system that relate to the ease of porting the system to other host machines and/or operating systems.

Example:

· Percentage of components with host-dependent code

· Percentage of code that is host dependent

· Use of a proven portable language

· Use of a particular compiler or language subset

· Use of a particular operating system

· The need for environment-independence (The product must operate the same regardless of operating systems, networks, development, or production environments.)

Provide a summary of the major functions that the product will perform. Organize the functions to be understandable to the customer or a first time reader. Include use cases and business scenarios, or provide a link to a separate document (or documents). A business scenario:

· Describes a significant business need

· Identifies, documents, and ranks the problem that is driving the scenario

· Describes the business and technical environment that will resolve the problem

· States the desired objectives

· Shows the “actors” and where they fit in the business model

· Is specific, measurable, and uses clear metrics for success

Identify any requirements that have been deleted after approval or that may be delayed until future versions of the system.

Example:

Include documentation of the approval or confirmation of the requirements.

Example:

· Sample input/output formats, descriptions of cost analysis studies, or results of user surveys

· Supporting or background information that can help the readers of the Requirements Specification

· A description of the problems to be solved by the system

· Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements

When appendixes are included, the Requirements Specification should explicitly state whether or not the appendixes are to be considered part of the requirements.

Define all terms, acronyms, and abbreviations used in this document.

List all documents and other materials referenced in this document.

The following trace matrix examples show one possible use of naming standards for deliverables (FunctionalArea-DocType-NN). The number has no other meaning than to keep the documents unique. For example, the Bargaining Unit Assignment Process Flow would be BUA-PF-01.

Example 1:

Example 2:

This section is for information only as an aid in preparing the Requirements section of the document.

Detailed requirements tend to be extensive. Give careful consideration to your organization scheme. Some examples of organization schemes are described below:

By System Mode

Some systems behave quite differently depending on the mode of operation. For example, a control system may have different sets of functions depending on its mode: training, normal, or emergency.

By User Class

Some systems provide different sets of functions to different classes of users. For example, an elevator control system presents different capabilities to passengers, maintenance workers, and fire fighters.

By Objects

Objects are real-world entities that have a counterpart within the system. For example, in a patient monitoring system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc. Associated with each object is a set of attributes (of that object) and functions (performed by that object). These functions are also called services, methods, or processes. Note that sets of objects may share attributes and services. These are grouped together as classes.

By Feature

A feature is an externally desired service by the system that may require a sequence of inputs to affect the desired result. For example, in a telephone system, features include local call, call forwarding, and conference call. Each feature is generally described in a sequence of stimulus-response pairs, and may include validity checks on inputs, exact sequencing of operations, responses to abnormal situations, including error handling and recovery, effects of parameters, and relationships of inputs to outputs, including input/output sequences and formulas for input to output.

By Stimulus

Some systems can be best organized by describing their functions in terms of stimuli. For example, the functions of an automatic aircraft landing system may be organized into sections for loss of power, wind shear, sudden change in roll, vertical velocity excessive, etc.

By Response

Some systems can be best organized by describing all the functions in support of the generation of a response. For example, the functions of a personnel system may be organized into sections corresponding to all functions associated with generating paychecks, all functions associated with generating a current list of employees, etc.

By Functional Hierarchy

When none of the above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by common inputs, common outputs, or common internal data access. Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data.

Additional Comments

Whenever a new Requirements Specification is contemplated, more than one of the organizational techniques given above may be appropriate. In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification.

There are many notations, methods, and automated support tools available to aid in the documentation of requirements. For the most part, their usefulness is a function of organization. For example, when organizing by mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; and when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful.

Copyright© 2018 by University of Phoenix. All rights reserved.

Copyright© 2018 by University of Phoenix. All rights reserved.