Scribd
Upload
1K views3 pages

FURPS

The document discusses non-functional requirements and how they are different from functional requirements. It explains that non-functional requirements place constraints on the system as a whole, such as usability, reliability, performance, and supportability. Specific non-functional requirements include the level of user expertise, interface standards, documentation, safety, security, availability, and response time.

Uploaded by

MNaveedsdk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
1K views3 pages

FURPS

The document discusses non-functional requirements and how they are different from functional requirements. It explains that non-functional requirements place constraints on the system as a whole, such as usability, reliability, performance, and supportability. Specific non-functional requirements include the level of user expertise, interface standards, documentation, safety, security, availability, and response time.

Uploaded by

MNaveedsdk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Identifying Non-Functional Requirements

Non-Functional Requirements
In addition to the functions a system must perform, there are often constraints the system must
satisfy.

Some constraints may apply to individual use cases.

For example, a constraint on opening an account at an online liquor store is that customers must
be at least 21 years old.

UML allows us to annotate elements by constraints. A constraint usually has the form:

{ condition }

The condition can be expressed informally or formally.

For example:

The FURPS+ Model


A system-wide constraint is called a non-functional requirement.

The FURPS model organizes all requirements into five categories:

F = Functional

U = Usability

R = Reliability
P = Performance

S = Supportability

The FURPS+ model adds a few more categories.

Non-Functional Requirements
Usability

Level of user expertise assumed.

User interface standards used.

Documentation provided.

Reliability

Safety and security requirements.

Availability, robustness, and reliability of the system.

Exception handling

Mean time between failures

Error tolerance

Data loss tolerance

Performance

number of concurrent users supported

response time

number of transactions per second

Supportability

How will system be extended?

Who maintains the system?

Implementation
Platform?

Interfaces

Interfaces to existing systems.

Protocols used.

Operation

Who manages the running system?

Packaging

Who installs the system?

How many installations are there?

Legal

Licensing?

Liability issues?

Licensing fees or liabilities incurred from using third-party components or algorithms?

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy