Non Functional Requirements

By : Divyansh Johri 090101064
A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.
Non-functional requirements define the overall qualities or attributes of the resulting system.
Non-functional requirements place restrictions on the product being developed, the development process, and specify external constraints that the product must meet.
Examples of NFR include safety, security, usability, reliability and performance requirements. Project management issues (costs, time, schedule) are often considered as non-functional requirements as well.
There is no a clear distinction between functional and nonfunctional requirements. Whether or not a requirement is expressed as a functional or a non-functional requirement may depend: - on the level of detail to be included in the requirements document - the comprehension of application domain and the desired system - experience of developers
Some properties of a system may be expressed either as a functional or non-functional property. Example. The system shall ensure that data is protected from unauthorized access. Conventionally a non-functional requirement (security) because it does not specify specific system functionality. Expressed as functional requirement: The system shall include a user authorization procedure where users must identify themselves using a login name and password. Only users who are authorized in this way may access the system data.
Non-functional requirements may result in new functional requirements statements.
The IEEE-Std 830 - 1993 lists 13 non-functional requirements to be included in a Software Requirements Document: Performance requirements Interface requirements Operational requirements Resource requirements Verification requirements Acceptance requirements Documentation requirements Security requirements Portability requirements
Quality requirements Reliability requirements Maintainability requirements Safety requirements
NFRs may be classified in terms of qualities that a software must exhibit. A more general classification distinguishes between product, process and external requirements
Non-functional requirements Product requirements Usability requirements Reliability requirements Safety requirements Efficiency requirements Performance requirements Capacity requirements
Process requirements Delivery requirements implementation requirements standards requirements
External requirements Legal constraints Economic constraints Interoperability requirements
Specify the desired characteristics that a system or subsystem must possess. Most NFRs are concerned with specifying constraints on the behaviour of the executing system.
Some product requirements can be formulated precisely, and thus easily quantified

Performance Capacity
Others are more difficult to quantify and, consequently, are often stated informally
Usability
Process requirements are constraints placed upon the development process of the system Process requirements include:
Requirements on development standards and methods which must be followed CASE tools which should be used The management reports which must be provided
May be placed on both the product and the process Derived from the environment in which the system is developed External requirements are based on:

application domain information organisational considerations the need for the system to work with other systems health and safety or data protection regulations or even basic natural laws such as the laws of physics
NFRs are difficult to express A number of important issues contribute to the problem of expressing non-functional requirements: Certain constraints are related to the design solution that is unknown at the requirements stage
Certain constraints, are highly subjective and can only be determined through complex empirical evaluations Non-functional requirements tend to be related to one or more functional requirements
Non-functional requirements tend to conflict and contradict

There are no universal rules and guidelines for determining when non-functional requirements are optimally met.
Stakeholders normally have a number of concerns Concerns are typically non-functional Examples include:

Critical business objectives Essential system characteristics (e.g. security) Safety, performance, functionality and maintainability
Vaguely defined user concerns may be related to NFRs
Users need
Users concern
Non-functional requirement
Function
Performance
Change
1. Ease of use 2. Unauthorised access 3. Likelihood of failure 1. Resource utilisation 2. Performance verification 3. Ease of interfacing 1. Ease of repair 2. Ease of change 3. Ease of transport ? 4. Ease of expanding or upgrading capacity or performance ?
1. Usability 2. Security 3. Reliability 1. Efficiency 2. Verifiability 3. Interoperability 1. Maintainability 2. Flexibility 3. Portability 4. Expandability

Non Functional Requirements

Uploaded by

Copyright:

Available Formats

Non Functional Requirements

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Non Functional Requirements

Uploaded by

Copyright:

Available Formats

By : Divyansh Johri 090101064

Non-functional requirements may result in new functional requirements statements.

Quality requirements Reliability requirements Maintainability requirements Safety requirements

Process requirements Delivery requirements implementation requirements standards requirements

External requirements Legal constraints Economic constraints Interoperability requirements

Non-functional requirements tend to conflict and contradict

Vaguely defined user concerns may be related to NFRs

You might also like