lecture duration: 180’

Instructor: Dao, Nguyen Thi Anh

International School - DTU
Email: nguyenthianhdao@duytan.edu.vn

1.1 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Contents

1. Functional vs. Non-functional

2. How do you express non-functional requirement?
3. Introduction of quality attribute types

1.2 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Functional vs. Non-Functional

 ƒ Functional requirements describe what the system should do.

 Non-functional requirements are global constraints on a
system such as development costs, operational costs,
performance, reliability, maintainability, portability, robustness
etc.

1.3 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Example Of Non-Functional
•
ƒ Interface requirements
• How will the new system interface with its environment?
• User interfaces and ‘user-friendliness’.
• Interfaces with other systems.
ƒ Performance requirements
• Time/space bounds.
• Workloads, response time, throughput and available storage
space, e.g., ‘the system must handle 1,000 transactions per
second’.

1.4 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attributes
•
ƒ Quality attributes are non-functional requirements used to
evaluate the performance of a system. These are sometimes named
"ilities" after the suffix many of the words share

1.5 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 What Do You Mean Quality?

Different people view quality differently:

ƒ Tester checks for errors:
• “Does it run without crashing?”
ƒ Quality Assurance reviews for defects:
• “Does it meet the specs?”
ƒ Architect checks engineering design:
• “Is my design reliable?”
ƒ Senior Manager asks marketing people:
• “How do you know that we have a quality product?”

1.6 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attributes

Important to Users Important to Developers

Availability Maintainability

Efficiency Portability

Flexibility Reusability

Integrity Testability

Reliability Performance

Interoperability

Security

1.7 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attributes

1.8 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Defining Quality Attributes

• Mƒ ost stakeholders only focus on functionality of the system but

may not know about quality attributes.
• ƒMost stakeholders do not know how to answer questions such as
“What are your reliability requirements?”
• ƒSoftware Engineers must make assumptions regarding which
quality attributes are important then verify with stakeholders.
• ƒThe process of making quality assumptions by involving
stakeholders to clarify is called Quality- Driven Requirements
Process.

1.9 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attributes

• Sƒ ystem requirements often focus on functionality and provide

only vague descriptions of the quality attribute requirements.
• ƒQuality attribute requirements are the means by which a system
is intended to meet its business goals. These requirements must
be recognized and considered as early as possible so that their
quality attributes are met.
• ƒTo do that, Software Engineers must understand the Quality
Driven Requirements Process.

1.10 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Driven Requirements

1.11 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attributes

 ƒQuality Attributes are derived from one of three sources:

• Quality goals for the system.
•Business goals for the system.
•Business goals for the people who will work on the system.
 ƒQuality attributes should not be as numerous as functional
requirements:
• Most systems average 4 - 7 quality attributes requirements.
• A maximum of 10 – 15 quality requirements is sufficient.

1.12 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Example
Scenario Number: Banking ATM system # 15
Scenario Description: When system detects a wrong password, it will not allow access and
prompts user to enter another password within 1 second.
Business Goals: Security.
Relevant Quality: Security.
Attributes: Security, performance.
Scenario Components: A wrong password is entered by user.
Stimulus: A wrong password is entered.
Stimulus Source: Bank user, external to the system.
Environment: The system is on, ready to accept password.
Artifact (If Known): Data key entry.
Response: The system stops access.
Measure: One second.
Questions: How many times can user enter password?
Issues: Could be intruder, hacker trying to enter system, not real user.

1.13 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attribute: Performance

ƒ Performance is the ability of a system to allocate resources to a

service request in a manner that will:
• Satisfy timing requirements.
• Provide various levels of service in the presence of competing
requests, varying demand and varying resource availability.
ƒ Performance is usually specified in terms of:
• Latency: Time it takes to respond to a request.
• Throughput: Number of events completed within observable
time.
• Capacity: Amount of work a system can perform and still
satisfy latency and throughput requirements (no degrade).

1.14 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attribute: Performance

1.15 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attribute: Security

ƒ Security can be defined as:

• Freedom from danger, safety.
• Protection of system data against destruction, unauthorized
modification.
ƒ Security has 3 basic types:
• Confidentiality: Protection from unauthorized disclosure.
• Integrity: Protection from unauthorized modification.
• Availability: Protection from denial of service to authorized users.

1.16 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attribute: Portability

ƒ Definition:
The degree to which software running on one platform can
easily be converted to run on another.
ƒ Considerations:
• Portability is hard to quantify.
• It is hard to predict all other platforms the software will be
required to run.
• Portability is strongly affected by design choices such as choice
of languages, operating systems and tools that are universally
available and standardized.
• Portability requirements should be given priority for systems
that may have to run on different platforms in the near future.
1.17 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attribute: Modifiability
ƒ Definition:
Modifiability is about the cost of making changes.
ƒ Considerations:
• What may be changed: Function, Hardware, System,
Software.
• Who will make the change: Developer, System, User.
• When will the change be made: During development or
maintenance.
• Changes can be classified according to:
Probability – How likely it will occur.
Frequency – How often it will occur.
Dependence – How does it impact others.
1.18 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attribute: Reliability

ƒ The ability of the system to behave consistently in a user-

acceptable manner when operating within the environment for
which it was intended. Reliability can be defined in terms of a
percentage (99.999%).
ƒ Different meanings for different applications:
• Telephone network: the entire network can fail no more than,
on average, 1hr per year, but failures of individual switches
can occur much more frequently.
• Patient monitoring system: the system may fail for up to
1hr/year, but in those cases doctors/nurses should be alerted of
the failure. More frequent failure of individual components is
not acceptable.
ƒ
1.19 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attribute: Reliability

ƒ ƒ Example of reliability requirements: ‘No more than X bugs

per 10KLOC may be detected during integration and testing;
no more than Y bugs per 10KLOC may remain in the system
after delivery.

1.20 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attribute: Usability

ƒ Many systems are only technically successful (meet all

functional requirements) but fall short of their expected
benefits because the users find them:
• Difficult to understand and use
• Inconsistent
• Needing excessive training & retraining
• Error-prone
• Discouraging to explore

1.21 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Measure Usability

ƒ Five areas from which to measure usability:

1) Time to learn
2) Speed of performance
3) Error rate
4) Retention over time
5) Subjective satisfaction
ƒ These criteria to some degree can be measured by observing
people using software or by designing experiments.

1.22 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Costs of Un-Usability

ƒ The typical user interface cost is about 45% of the total

application effort.
ƒ Lack of systematic approach to interface design:
• Causes false starts
• Extends development schedules
• Causes rework - Cost of non-quality
• Increases complexity of code
• Lowers customer satisfaction

1.23 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Using Trends To Quantify Attributes
ƒ Past history and future trends can help define words like
‘improve’ and ‘reduce’ in requirement specification.
ƒ For example:
• Past data: 30,000 Hours
• Industry Trend: 50,000 Hours
• Goal for our system can be set between 30,000 and 50,000 Hours

1.24 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Attribute Trade-Off

ƒ Certain attributes may have conflicting consequences,

Software Engineers must conduct “attribute trade-off” to
balance product characteristics.
ƒ Software Engineers and stakeholders must decide which
attributes are more important than others.
ƒ Examples:
• You can not expect systems to operate on multiple platforms
(Portability) and also have usability.
• Complex system (Robust) may not be fast (efficient) due to
more data checking and validating.
• It is difficult to completely test the integrity of very high
security systems.
1.25 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Quality Attributes Trade-Off

1.26 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Attributes Vs. Design Criteria

ƒ Quality Attributes:
• These are customer-related concerns such as efficiency,
integrity, reliability, correctness, security, usability, etc.
ƒ Design Criteria
• These are development-oriented concerns such as anomaly,
completeness, consistency, traceability, visibility.
ƒ Quality Attributes and Design Criteria are related:
• Each attribute depends on a number of associated criteria:
ƒ Correctness depends on completeness, consistency,
traceability.
ƒ Verifiability depends on modularity, self-descriptiveness and
simplicity.
1.27 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Translating To Technical Spec.
Quality Attributes Types Likely Technical Information

Integrity, Robustness, Usability, Functional Requirements

Interoperability, Safety

Availability, Efficiency, Flexibility, System Architecture

Performance, Reliability

Interoperability, Usability Design Constraints

Flexibility, Maintainability, Portability Design Guideline

Reliability, Reusability Portability

Portability Implementation Constraints

1.28 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Class Discussion

ƒ 1. Identify five quality attributes that you think are important

to the software tool that you use today.
ƒ 2. Create five questions about each attribute to articulate your
expectation.
ƒ 3. Use the quality driven requirements template to explore the
quality attribute of a computer game that you like.

1.29 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 References

• Hull, E., Jackson, K., & Dick, J. (2014). Requirements

Engineering. Newtownabbey, UK: Springer.
Reference Materials:
• Axel van Lamsweerde. (2009). Requirements Engineering.
Wiley. pp. 187-217
• Nguyen, Tam T. T. (2014). Requirements Engineering.
Danang, Vietnam: Duy Tan University, for internal use.
pp. 112-123
Please watch the video at the link below:
https://www.youtube.com/watch?v=j4WITZFLkUM&t=21s
1.30 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen
 Questions & Answers

1.31 © by
© by CMU
CMU Dao
Dao Nguyen
Nguyen