terça-feira, 15 de novembro de 2016

Requirements: Requirements Types (Functional, Non-Functional)

Requirement types are a useful categorization for your requirements catalog. There are several classifications and literature about the subject.
The following requirement types were identified according to European Space Agency (ESA) “Guide to the software requirements definition phase”.

FUNCTIONAL REQUIREMENTS

A function is a “defined objective or characteristic action of a system or component” and a functional
requirement “specifies a function that a system or system component must be able to perform”. Typically we will be describing functionality (features) with functional requirements at first. Then comes "the rest": Non-functional requirements.

NON-FUNCTIONAL REQUIREMENTS

  • Performance Requirements specify numerical values for measurable variables used to define a function (e.g. rate, frequency, capacity, speed and accuracy). Performance requirements may be included in the quantitative statement of each function, or included as separate requirements.
  • Interface Requirements specify hardware, software or database elements that the system, or system component, must interact or communicate with. Interface requirements should also be classified into “internal” and “external” interface requirements, depending upon whether or not the interface coincides with the system boundary.
  • Operational Requirements specify how the system will run (i.e. when it is to be operated) and how it will communicate with human operators (e.g. screen and keyboards etc.). Operational requirements may describe physical aspects of the user interface. Descriptions of the dialogue, screen layouts, command language styles are all types of operational requirements.
  • Resource Requirements specify the upper limits on physical resources such as processing power, main memory, disk space etc. They may describe any requirements that the development or operational environment place upon the software. A resource requirement should state the facts about the resources, and not constrain how they are deployed.
  • Verification Requirements constrain the design of the product. They may do this by requiring features that facilitate verification of system functions or by saying how the product is to be verified.
  • Documentation Requirements state project-specific requirements for documentation, in addition to those contained in Software Configuration Management Plan. The format and style of the Interface Control Documents may be described in the documentation requirements, for example. Documentation should be designed for the target readers (i.e. users and maintenance personnel).
  • Security Requirements specify the requirements for securing the system against threats to confidentiality, integrity and availability. They should describe the level and frequency of access allowed to authorised users of the software. If prevention against unauthorised use is required, the type of unauthorised user should be described. The level of physical protection of the computer facilities may be stated (e.g. backups are to be kept in a fire-proof safe off-site).
  • Portability Requirements specify how easy it should be to move the software from one environment to another. Possible computer and operating systems, other than those of the target system, should be stated.
  • Quality Requirements specify the attributes of the software that make it fit for its purpose. The major quality attributes of reliability, maintainability and safety should always be stated separately. Where appropriate, software quality attributes should be specified in measurable terms (i.e. with the use of metrics).
  • Reliability Requirements relate to the “the ability of a system or component to perform its required functions under stated conditions for a specified period of time”. The reliability metric, “Mean Time Between Failure” (MTBF), measures reliability according to this definition.
  • Maintainability Requirements relate to the “the ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment”. All aspects of maintainability should be covered in the specification of the maintainability requirements, and should be specified, where appropriate, in quantitative terms.
Source: Requirements Standard (INTERNAL) and ESA.