What Are Quality Attributes?
Users have expectations - often unstated - about how well a product will work: how fast it responds, how rarely it fails, how easy it is to learn, and yes, even how loud it is.
Quality attributes (also called quality factors, quality requirements, quality of service requirements, or the " - ilities") are user and developer expectations about how well the system performs its tasks. They constitute a major portion of nonfunctional requirements.
Quality attributes are NOT synonymous with nonfunctional requirements - they are a subset. NFRs include three categories:
Performance, security, usability, etc.
Connections to other systems, HW, users
Restrictions on design/implementation choices
Why Quality Attributes Matter
Quality attributes separate a product that merely works from one that delights its users. Excellent products reflect an optimum balance of competing characteristics.
It's far more costly to re-architect a completed system to achieve quality goals than to design for them at the outset. Like security patches - they cost far more retroactively.
Quality attributes serve as the origin of many functional requirements and architectural decisions. They drive how the system must be built.
If you don't explore quality expectations during elicitation, you're just lucky if the product satisfies them. Disappointed users and frustrated developers are the typical outcome.
Q: Collecting quality requirements is considered problematic. Discuss what problems we may face as RE when collecting and specifying such requirements. (2P)
- Requirements engineers often lack domain expertise to evaluate quality expectations precisely.
- Stakeholders may have unstated, implicit expectations (like noise levels) they don't think to mention.
- Quality attributes are harder to specify - "the system shall be secure" is unverifiable without measurable criteria.
- Conflicting quality requirements are common (e.g., more security can mean less performance).
- Stakeholder unavailability and resistance to change can hinder gathering accurate quality needs.
- Many quality attributes are only revealed after the system is operational (e.g., reliability as a lagging indicator).
Classification: External vs. Internal Quality
Quality attributes are classified into external (visible to users) and internal (visible to developers & maintenance staff).
External Quality Attributes (important to users)
Availability
Extent to which system services are available when and where needed.
Installability
How easy it is to install, uninstall, and reinstall the application.
Integrity
Extent to which system protects against data inaccuracy and loss.
Interoperability
How easily system can exchange data with other systems or components.
Performance
How quickly and predictably the system responds to user inputs or events.
Reliability
How long the system runs before experiencing a failure.
Robustness
How well the system responds to unexpected operating conditions.
Safety
How well the system protects against injury or property damage.
Security
How well the system protects against unauthorized access to data/functions.
Usability
How easy it is for people to learn, remember, and use the system.
Internal Quality Attributes (important to developers)
Efficiency
How efficiently the system uses computer resources (ES-specific).
Modifiability
How easy to maintain, change, enhance, and restructure the system.
Portability
How easily system can work in other operating environments.
Reusability
To what extent components can be used in other systems.
Scalability
How easily system can grow to handle more users, data, and transactions.
Verifiability
How readily developers and testers can confirm correct implementation.
External = "AIRP-RSSUn" (what users feel); Internal = "EMPRSVV" (what devs build)
- External: Availability, Installability, Reliability, Performance, Robustness, Safety, Security, Usability, iNteroperability + Integrity
- Internal: Efficiency, Modifiability, Portability, Reusability, Scalability, Verifiability
- Think of it as: External = what you FEEL when using the app; Internal = what engineers WORRY about when building it.
How to Explore Quality Attributes - 5 Steps
Review all possible quality attributes to avoid overlooking any important dimension. Don't skip attributes just because they seem obvious.
Work with a cross-section of stakeholders to identify which attributes matter most for the specific project. Example: an airport kiosk needs usability (infrequent users) and security (payment handling).
Use pairwise ranking: "If I could have only one of these attributes, which would I take?" Build a comparison matrix. This helps resolve conflicts - if security (score 7) outranks performance (score 4), bias conflict resolution toward security.
Ask targeted questions. Users won't know how to answer "What are your reliability requirements?" but can answer "What would constitute an unacceptable failure?" Guide them through domain-specific scenarios.
"The system shall be user-friendly" is useless. Use the SMART mnemonic: Specific, Measurable, Attainable, Relevant, Time-sensitive.
Every quality requirement must be…
Why is "user-friendly" a bad NFR? Why is "24×7 availability" bad?
- "User-friendly" is subjective and unmeasurable - violates the M in SMART.
- "Available 24×7" is rarely realistic or necessary and is not measurable without defining what "available" means.
- Always ask: Can a tester verify this requirement objectively? If not, it needs rewriting.
Defining Each Quality Attribute
Availability
Definition: A measure of the planned uptime during which system services are available and fully operational.
When specifying, define: what "available" means (degraded mode?), scheduled maintenance windows, user notifications, and dependencies between functions.
AVL-2: Downtime excluded from availability calculation consists of maintenance scheduled Sunday 6 PM through Monday 3 AM Pacific Time.
Don't specify 100% availability!
- A "five 9s" requirement (99.999%) - only 5 min 15 sec downtime/year - contributed to ~25% of one system's total costs.
- It virtually doubled hardware costs due to redundancy requirements.
- High availability = complex failover architecture = expensive!
Integrity
Definition: Preventing information loss and preserving the correctness of data. Has no tolerance for error - data is either protected or it is not. Security is sometimes considered a subset of integrity.
INT-2: The system shall protect against unauthorized addition, deletion, or modification of data.
INT-3: The Chemical Tracking System shall confirm that imported chemical structures represent valid chemical structures.
INT-4: The system shall confirm daily that application executables have not been modified by unauthorized code.
Performance
Definition: Responsiveness of the system to user inputs and events. Closely related to the internal quality attribute of efficiency.
Performance dimensions: Response time, throughput, data capacity, dynamic capacity, predictability (real-time), latency, behavior under degraded/overloaded conditions.
PER-2: Webpages shall fully download in an average of 3 seconds or less over a 30 Mbps internet connection.
PER-3: At least 98% of the time, the trading system shall update the transaction status display within 1 second of each trade completion.
Reliability
Definition: The probability of software executing without failure for a specific period. A lagging indicator - you can't tell if you've achieved it until the system has run for a while.
Sources of reliability problems: improper inputs, software code errors, unavailable components, hardware failures.
REL-2: The mean time between failures of the card reader component shall be at least 90 days.
Reliability vs. Availability
- Reliability = probability of NOT failing over time (MTBF)
- Availability = percentage of time the system IS up (considers repair time too: MTBF / (MTBF + MTTR))
- A system can be highly available but not reliable (it fails often but restarts quickly!)
Robustness
Definition: The degree to which a system continues to function properly when confronted with invalid inputs, defects in connected components, external attacks, or unexpected operating conditions. Robust software recovers gracefully without adversely affecting the user experience.
Dimensions: Fault tolerance (are errors caught?), Survivability (can it handle physical stress?), Recoverability (can it resume after failure?)
Note: This might lead a developer to implement autosave - but you should NOT specify the mechanism in the requirement. Leave technical decisions to developers.
Safety
Definition: Preventing a system from doing injury to people or damage to property. Primarily relevant when hardware devices are controlled by software (medical devices, vehicles, industrial equipment).
SAF-2: The therapeutic radiation machine shall allow irradiation only if the proper filter is in place.
Security
Definition: Blocking unauthorized access to system functions or data. A major concern for internet software. Like integrity, has no tolerance for error. Many security requirements originate from business rules.
SEC-2: The system shall log all attempts to access secure data by users with insufficient privilege levels.
SEC-3: The resident antimalware software shall quarantine any incoming Internet traffic with known or suspected virus signatures.
SEC-4: Only users with Auditor access privileges shall be able to view customer transaction histories. [originated from a business rule]
Usability
Definition: All factors constituting "user-friendliness." Measures effort required to prepare input, operate the system, and interpret outputs. Encompasses: ease of learning, memorability, error avoidance/handling/recovery, efficiency, accessibility, and ergonomics.
Key goal: Balance usability optimally for the whole spectrum of users, not just a single community.
USE-2: All File menu functions shall have Ctrl+key shortcuts; shortcuts that appear in Microsoft Word shall use Word's default keys.
USE-3: 95% of chemists who have never used the system before shall place a chemical request correctly with no more than 15 minutes of orientation.
Modifiability (Internal)
Definition: How easily the software designs and code can be understood, changed, and extended. Encompasses maintainability and flexibility.
MOD-2: Function calls shall not be nested more than two levels deep.
Portability (Internal)
Definition: The effort needed to migrate software from one operating environment to another. Goals should identify which portions must be portable and describe target environments.
POR-2: The user shall be able to port browser bookmarks to and from Firefox, Internet Explorer, Opera, Chrome, and Safari.
Scalability (Internal)
Definition: Ability to grow and accommodate more users, data, servers, geographic locations, transactions, network traffic, and searches without compromising performance or correctness. Has both hardware and software implications.
SCA-2: The website shall handle a page-view growth rate of 30% per quarter for at least two years without user-perceptible performance degradation.
Q: List two functional requirements and two non-functional requirements for the Riyadh Seasons ticketing system.
Functional Requirements:
- The Riyadh Season customer shall be able to self-check in at the terminal using his/her ticket.
- Upon self-check-in, the system shall issue the customer a bracelet with an electronic chip.
Non-Functional Requirements:
- The Riyadh Seasons online payment service shall be secure. (Security)
- The customer's bracelet payment transaction shall be completed in under 3 seconds. (Performance)
Quality Attribute Trade-offs
In an ideal world, every system would maximize all quality attributes. In reality, there are trade-offs and conflicts. Prioritization tells you how to resolve them.
| If you increase → | Effect on Performance | Effect on Security | Effect on Usability | Effect on Reliability |
|---|---|---|---|---|
| Security | − (slower auth) | - | − (more friction) | + (fewer breaches) |
| Portability | − (abstraction layers) | - | - | + (tested on more platforms) |
| Reliability | − (redundancy overhead) | + | + | - |
| Modifiability | − (abstraction) | - | - | + |
| Performance | - | − (fewer security layers) | + (faster = better UX) | − |
How prioritization resolves conflicts
- If Security (score 7) outranks Performance (score 4) in your prioritization matrix, bias any security vs. performance conflict toward security.
- The airport kiosk example: security is more important than performance because the kiosk handles payments and is used infrequently by strangers.
- Don't just know the trade-offs - know why one attribute might be more important in a specific domain context.
Constraints
A constraint places restrictions on the design or implementation choices available to the developer. They can be imposed by external stakeholders, interacting systems, existing agreements, management decisions, or technical decisions.
Sources of Constraints
CON-2: Only open source software under the GNU GPL may be used. [implementation constraint]
CON-3: The application must use Microsoft .NET framework 4.5. [architecture constraint]
CON-4: ATMs contain only $20 bills. [physical constraint]
CON-5: Online payments may only be made through PayPal. [design constraint]
CON-6: All textual data shall be stored as XML files. [data constraint]
Unintentional Constraints
- Users often present "requirements" that are actually solution ideas that embed a design constraint.
- The BA must detect when a requirement includes a solution idea and distinguish the underlying need from the constraint.
- Example: "The search results shall appear in a dropdown list" - is this a requirement or a design constraint? The BA should ask why a dropdown is needed and write the requirement about the search behavior, listing the dropdown as a constraint if truly required.
- Some say quality attributes ARE constraints - but it's more precise to say certain quality requirements are the origin of design/implementation constraints.
Past Exam Questions
Q: Based on the Volere shell, how can the information provided help prioritize a specific requirement? Which prioritization technique does the Volere shell adopt? (Quiz 2)
Part A - How the shell helps prioritize:
- The Volere shell includes fields like Priority, Benefit, Customer Satisfaction, and Customer Dissatisfaction ratings - these directly inform priority decisions.
- It also links to the Business Goal the requirement supports, helping assess strategic value.
- The Fit Criterion ensures the requirement is measurable and verifiable, which is a prerequisite for fair prioritization.
Part B - Technique:
- The Volere shell is closely aligned with the Value/Cost/Risk-based prioritization technique and shares characteristics with MoSCoW (Must/Should/Could/Won't).
- The satisfaction and dissatisfaction ratings resemble the Kano model approach used in prioritization based on customer value.
Q: Distinguish between Reliability and Robustness. Provide one example requirement for each.
Reliability: The probability of the software executing without failure for a specific period. It's a lagging indicator.
Example: "No more than 5 experimental runs out of 1,000 can be lost because of software failures."
Robustness: The degree to which a system continues to function when confronted with invalid inputs, hardware defects, attacks, or unexpected conditions. It's about graceful recovery.
Example: "If the text editor fails before the user saves, it shall recover the file contents from at most one minute prior to the failure."
Key Difference: Reliability is about not failing; Robustness is about handling failure gracefully.
Q: Which of the following is a NON-functional requirement?
A) The system shall allow customers to purchase tickets.
B) The system shall process payments within 2 seconds.
C) The system shall display available events.
D) The user shall be able to register an account.
Answer: B - The system shall process payments within 2 seconds.
This is a Performance quality attribute - it specifies how well (how fast) the system performs a function, not what the function is. Options A, C, and D describe what the system should do (functional requirements).
Q: Explain why saying "the system shall be available 24×7" is not a well-written nonfunctional requirement. How would you improve it?
- Problem 1: It's-not-measurable- - -"available" is undefined. Does degraded mode count as available?
- Problem 2: It's rarely realistic or necessary - maintenance windows are typically required.
- Problem 3: It could be prohibitively expensive (as shown in the "five 9s" example - 25% of total system cost).
- Improved version: "The system shall be at least 99.5% available on weekdays between 6:00 AM and midnight Riyadh Time. Scheduled maintenance may occur between 2:00 AM and 5:00 AM Sunday Pacific Time."
- This version is: Specific (time windows), Measurable (99.5%), Attainable, Relevant, and Time-sensitive.
Q: Security is sometimes considered a subset of Integrity. (True/False - explain)
Answer: TRUE
Some security requirements are intended to prevent unauthorized users from accessing or modifying data - which is the same goal as integrity (protecting data correctness and preventing loss). Therefore, security can be viewed as a subset of integrity from a data-protection perspective. Both have zero tolerance for error.
Tips & Tricks to Understand and Memorize
Remember the 10 External Quality Attributes: "AIRP-RS-SU-II"
- Availability - Installability - Reliability - Performance
- Robustness - Safety - Security - Usability
- Integrity - Interoperability
- Think: "A reliable app is safe and secure and usable."
The "Heating System" test - always ask what's unstated
- Before finalizing requirements, ask: "What would make a stakeholder upset that we forgot to specify?"
- The heating system met all stated requirements but failed an unstated one (noise). The BA's job is to surface the unstated.
- Quality attributes are the most commonly forgotten category - build a checklist.
Easily confused pairs - know the difference
- Reliability vs. Availability: Reliability = probability of not failing. Availability = % time the system is up (accounts for repair time). A system can be reliable (rarely fails) but unavailable (takes forever to restart).
- Safety vs. Security: Safety = protect people/property from the system itself. Security = protect the system from unauthorized people.
- Integrity vs. Security: Integrity = data correctness and protection from loss. Security ⊂ Integrity (preventing unauthorized access is a form of protecting data).
- Robustness vs. Reliability: Reliability = won't fail. Robustness = handles failure gracefully. A non-robust system crashes ungracefully; a non-reliable one crashes frequently.
- Portability vs. Scalability: Portability = running on different platforms. Scalability = handling more load on the same/expanded platform.
Template for writing verifiable quality requirements
- Structure: [Condition] the [system component] shall [measurable behavior] [within X time/percentage/count].
- Always include: who is affected, what condition triggers it, how much/how fast/how often.
- Ask: "Can I write a test for this?" If no test is imaginable, the requirement is unverifiable and needs rewriting.
- Use "shall" for mandatory requirements, "should" for optional ones.
- Avoid: user-friendly, fast, reliable, secure (without measurement), "as much as possible", "where applicable".
High-priority topics to review
- Be able to classify a given requirement as functional, NFR-quality attribute, NFR-constraint, or NFR-external interface.
- Be able to rewrite a bad NFR into a SMART one (this is a common exam task).
- Know 2-3 example requirements for each quality attribute (availability, performance, security, reliability, usability).
- Know the 5-step method for exploring quality attributes.
- Understand trade-offs: why security conflicts with performance, why portability conflicts with performance.
- Know that reliability is a lagging indicator - this is a specific fact professors like to test.
- Constraints: identify when a user's "requirement" is actually a design constraint in disguise.
Nonfunctional Requirements = Quality Attributes + External Interfaces + Constraints