FURPS+ Model

https://ik.imagekit.io/beyondpmf/frameworks/furps-model.png
The FURPS+ Model primarily addresses friction related to software implementation and delivery. By categorizing system requirements, it aims to improve the quality of the software, and potentially enhance the customer experience.

The FURPS+ Model, developed by Robert Grady at Hewlett-Packard, is a comprehensive classification system for software quality attributes. It stands for Functionality, Usability, Reliability, Performance, and Supportability, with the '+' signifying additional considerations like design constraints, implementation requirements, interface requirements, and physical requirements. This framework helps in setting clear expectations and benchmarks for software development projects, ensuring all critical aspects of system performance and maintenance are addressed.

Steps / Detailed Description

Identify and categorize the system requirements into the main FURPS categories. | Further break down the requirements into the '+' categories as applicable. | Prioritize and manage these requirements throughout the development process. | Use the categorized requirements to guide design and testing phases. | Continuously update and refine requirements based on feedback and project evolution.

Best Practices

Regularly review and update the requirements as the project evolves | Ensure all stakeholders understand the categories and their importance | Integrate FURPS+ into the entire lifecycle of the software development process

Pros

Provides a comprehensive overview of system requirements | Facilitates clear communication among stakeholders | Helps in prioritizing development and testing efforts

Cons

Can be overly complex for smaller projects | May require extensive documentation | Could be rigid in dynamic development environments

When to Use

In large-scale software development projects | When a clear, structured approach to requirements is needed

When Not to Use

In small or rapid development projects where flexibility is key | When project requirements are not well-defined or are expected to change frequently

Related Frameworks

Scope

Scope not defined

Maturity Level

Maturity level not specified

Time to Implement

2–4 Weeks
3–6 Months
1–2 Weeks
3–6 Months
1–2 Months
3–6 Months
1–2 Weeks
Less Than 1 Day
1–2 Weeks
Longer Than 6 Months
1–2 Weeks
Longer Than 6 Months
1–2 Weeks
3–6 Months
1–2 Weeks
1–2 Weeks
1–2 Weeks
1–2 Weeks
1–2 Days
1–2 Weeks
1–2 Weeks
1–2 Weeks
1–2 Weeks
1–2 Weeks
1–2 Weeks
3–6 Months
1–2 Weeks
1–2 Weeks
1–2 Weeks
3–6 Months
1–2 Weeks
1–2 Weeks
2–4 Weeks
1–2 Weeks
1–2 Days
1–2 Weeks
Longer Than 6 Months
Longer Than 6 Months
3–6 Months
Longer Than 6 Months
Longer Than 6 Months
Longer Than 6 Months
1–2 Weeks
Longer Than 6 Months
3–6 Months
Less Than 1 Day
3–6 Months
1–2 Months
3–6 Months
Longer Than 6 Months
3–6 Months
Less Than 1 Day
1–2 Weeks
3–6 Months
3–6 Months
1–2 Weeks
3–6 Months
1–2 Weeks
1–2 Weeks
1–2 Days
1–2 Weeks
1–2 Months
Longer Than 6 Months
1–2 Weeks
Longer Than 6 Months
1–2 Weeks
3–6 Months
1–2 Weeks
Less Than 1 Day
1–2 Weeks
3–6 Months
1–2 Weeks
3–6 Months
1–2 Weeks
1–2 Weeks
Longer Than 6 Months
Less Than 1 Day
3–6 Months
Longer Than 6 Months
1–2 Months
1–2 Weeks
Longer Than 6 Months
1–2 Weeks
3–6 Months
1–2 Weeks
1–2 Weeks
3–6 Months
Less Than 1 Day
1–2 Weeks
1–2 Weeks
3–6 Months
3–6 Months
Less Than 1 Day
1–2 Weeks
Longer Than 6 Months
1–2 Months
1–2 Weeks
1–2 Weeks
1–2 Weeks
Longer Than 6 Months

Copyright Information

Autor:
Hewlett-Packard
1987
Publication:
Hewlett-Packard