3SL: Requirements management and model driven systems engineering from concept to creation.
Cradle®
Login:
Username:
Password:
 
Search:  
Visitor not logged in, You are: Home > Reference > Requirements > Performance Requirement
 

Performance Requirement

A Performance Requirement is the extent to which a mission or function must be executed, and is generally measured in terms of quantity, quality, coverage, timeliness or readiness. Performance requirements are initially defined through requirements analyses and trade studies using customer need, objective, and/or requirement statements. Performance requirements are defined for each identified customer (user and supplier) mission and for each primary function (and subfunction).


Speed

This requirement specifies the amount of time that is available to complete specified tasks. Speed requirements often refer to response times.

Some products must be able to perform certain functionality within a given time slot. Failure to do so may be disastrous. There is a wide variation in the importance of different types of speed requirements. In some systems speed will be extremely critical, such as a missile guidance system. In others split second speed is of no importance.


Safety

This is the perceived risk of possible damage to property, people and the environment. It is important to highlight and understand the potential damage that could occur when using a product within the anticipated operational environment.

Legal help should be sought to ensure that the developed product operates within legal safety guidelines and laws.


Precision

This requirement will quantify the desired accuracy of the results produced by the product. For example, a mathematics program must return highly accurate results.


Reliability and Availability

The realiability of the product must be quantified. This is usually expressed as the allowable time between failures, or the total allowable failure rate. It also quantifies the expected availability of the product.

Some products must not fail too often. The possibility of failure and the realistic levels of service must be explored. This requirement can be used to set client and user expectations about the system reliability.

For example, the product must be available for use 24 hours a day, 365 days a year or the product shall achieve 95% up-time.

There is a difference between a product that must be available for use and a product that must not fail at any time. There will be an added cost of reliability and availability, so building these features into a system must be justifiable.


Capacity

The volumes/numbers that a product must be able to deal with are specified in this requirement. Specifying these details ensures that a product is capable of processing the expected volumes.

For example, only one user can edit the database at any one time; no limit on the number of users who can view the same database.


Scalability

This requirement specifies the expected increases in size that the product must be able to handle. As businesses grow, software products must be able to handle increased volumes of users and/or data.

For example, The product shall be capable of processing the existing 5000 customers, and to deal with an expected growth of customers to 25,000 customers within 5 years.


[Copyright © 3SL 2008 | Last Updated: Thu Aug 28th, 2008 ]
Registered office: 2 Highfield Road, Barrow in Furness, Cumbria, LA14 5PA, Registered in England No. 2153654