Requirements Engineering

Quality Attributes
THUC TNH CH T L

NG

Requirements & Functionality

Function is What a system does, Not
How well it does it.
Functional requirements must be specified
together with supplementary information
needed to determine their priority.
Requirements are, What the system must
do, NOT How the system does it, so do
not mix requirements with design.
A constraint is something that explicitly
and intentionally restricts the engineering
process, systems operation, or its lifecycle.
RED SUN Inc.

Scope & Boundaries

The scope of the requirements must be defined
and all specified requirements must be relevant to
the defined scope.
Only take on requirements that you should and
can address.
Any stated requirement that falls outside of the
scope needs to be validated and discussed with
stakeholders for including or deleting.
Note: Scope states the overall system
boundaries.
Constraints can help establish the system scope
(boundaries).
RED SUN Inc.

Constraints
A constraint is a requirement specification that
explicitly and intentionally restricts the
engineering process, systems operation, or its
lifecycle.
There are two types of constraints:
Binary Constraints are statements like Must
and Must not. These are called Demands
(must) and Vetoes (must not).
Scalar Constraints are specified using a scale of
measure, to limit some resources or capability
in some way.

The system must respond within 20 seconds after

logon.
RED SUN Inc.

Non-Functional Requirements
Developing systems that implement all functional
requirements is not enough. Every system must
also satisfy additional non-functional or quality
attributes such as security, performance,
scalability, maintainability and others.
Systems often fail to meet user needs (i.e. lack of
quality) when developers only focus on meeting
functional requirements without considering the
impact of others such as performance, usability.
Some functions may be changed or altered over
time but quality requirements always remain
stable.
Quality attributes are the key contributors in
prioritizing functional requirements.
RED SUN Inc.

Functional vs. Non-Functional

Functional requirements describe what the
system should do.
Things that can be captured in use cases or can
be analyzed by drawing interaction diagrams,
state charts, etc.
Functional requirements can be traced to
individual module(s) of a program.
Non-functional requirements are global
constraints on a system such as development
costs, operational costs, performance, reliability,
maintainability, portability, robustness etc.
Often known as the ilities.
Usually cannot be implemented in a single
module of a program.
RED SUN Inc.

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.

RED SUN Inc.

Beyond Functional Requirements

Quality attributes (Non-Functional requirements):
Difficult to define.
Usually not mentioned, but expected by
stakeholders, but different stakeholders have
different preferences.
Important for technical considerations (during
design and architectural decisions).
To be explored with all stakeholders during the
requirements development process not just
users.
To be measurable and verifiable.

RED SUN Inc.

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?

RED SUN Inc.

Measure Quality Attributes - 1

Think of an everyday object such as a chair.
How would you measure its quality?
Construction quality? (e.g., strength of the
joints,)
Aesthetic value? (e.g., Nice, elegance,)

tr th m m

Fit for purpose? (e.g., comfortable,)

All quality measures are relative there is no
absolute scale, we can sometimes say A is better
than B, but it is usually hard to say how much
better.

RED SUN Inc.

10

Measure Quality Attributes - 2

Measure quality attributes for BIM:
Construction quality? BIM is not manufactured.
Aesthetic value? BIM is invisible.
Fit for purpose? Need to understand the purpose.

BIM quality is all about fitness to purpose. Does it do what is needed?

- Does it do it in the way that its users need?
- Does it do it reliably enough? Fast enough?
- Does it do it safely enough? Securely enough?
- Is it affordable?
- Will it be ready when its users need it?
- Can it be changed as the needs change?

RED SUN Inc.

11

Some Quality Attributes - 1

Availability: Is it available when and where I
need to use it?
Efficiency: How many/few system resources
does it consume?
Flexibility: How easy is it to add new
capabilities?
Installability: How easy is it to correctly install
the product.
Integrity: Does it protect against unauthorized
TON VN (S LIN T C V TRAO
I THNG TIN GI A CC
access, data loss? TNH
PH N M M (VD TRONG BUILDING DESIGN SUITE)
Interoperability: How easily does it
interconnect with other systems?
Maintainability: How easy is it to correct
defects or make changes?

RED SUN Inc.

12

Some Quality Attributes -2

Portability: Can it be made to work on other
platforms? TNH C NG, CH Y TRN NH NG PLATFORM KHC NHAU
Reliability: How long does it run before
experiencing a failure?
Reusability: How easily can we use components
in other systems?
Robustness: How well d oes it respond to
unanticipated conditions?
Safety: How well does it protect against injury or
damage?
Testability: Can I verify that it was implemented
correctly?
Usability: How easy is it for people to learn or to
use?

RED SUN Inc.

13

Quality Attributes
Important to Users

Important to Developers

Availability

Maintainability

Efficiency

Portability

Flexibility

Reusability

Integrity

Testability

Reliability

Performance
Scalability

Interoperability
Security

Modifiability

RED SUN Inc.

14

Defining Quality Attributes

Most 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?
BIM 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 QualityDriven Requirements Process.
RED SUN Inc.

15

Quality Attributes
System 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, BIM Engineers must understand the
Quality Driven Requirements Process.

RED SUN Inc.

16

Quality Driven Requirements

Stakeholders reviews

Requirements

Requirements
Engineers experience

Quality Driven
Requirements
Process

Validated
Requirements

Quality Attributes

During requirements analysis, it is possible to be able to predict

how well the BIM will fit its purpose and derive quality
requirements from this.
RED SUN Inc.

17

Quality Driven Requirements Process

Quality Driven Requirements is a method for eliciting and
documenting quality attributes requirements early in the
requirements development process, by providing a forum for
stakeholders to come to consensus about these quality
attributes.
If there are a large number of diverse, geographically
scattered stakeholder groups, multiple sessions can be
conducted at various stakeholder locations, after which their
results can be consolidated.
A Quality Driven Requirements session is where a group of
stakeholders gather after the user requirements are
complete to identify quality assumptions about system
requirements.
In addition to clarifying quality attribute requirements, the
session provides increased stakeholder communication, an
informed basis for requirements decisions, and support for
further analysis throughout the development process.
RED SUN Inc.

18

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.
RED SUN Inc.

19

Quality Driven Session

Each stakeholder selects a scenario in the system
requirements and ensures that each scenario is
well formed with stimulus, environment, and
response.
Stakeholders review the scenarios and begin to
add quality attributes to each function to create a
more complete well-formed scenario.
Example:
The system shall produce reports for users.
The system shall produce reports for users within five
minutes after receiving request from user.

Note: The initial requirement remains the same,

but the scenario further explores the performance
aspect of this requirement.
RED SUN Inc.

20

Quality Driven Worksheet

Scenario Number:
Scenario Description:
Business Goals:
Relevant Quality:
Attributes:
Scenario Components:
Stimulus:
Stimulus Source:
Environment:
Artifact (If Known):
Response:
Measure:
Questions:
Issues:

RED SUN Inc.

21

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.

RED SUN Inc.

22

Quality Specific Scenarios

Just like use cases are used to determine the behavior of a
system (functionality), a quality driven scenario is used to
determine the quality attributes of a system.
Review specific scenarios by asking questions for each
function on:
1) Performance
2) Scalability
3) Security
4) Usability
5) Reliability
For example: A threat scenario in a case of security,
response time scenarios in a case of performance, and error
handling scenarios in a case of reliability.
RED SUN Inc.

23

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).

RED SUN Inc.

24

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.
RED SUN Inc.

25

Quality Attribute: Portability

Definition:
The degree to which BIM 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 BIM 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.

RED SUN Inc.

26

Quality Attribute: Modifiability

Definition:
Modifiability is about the cost of making changes.
Considerations:
What may be changed: Function, Hardware, System,
BIM.
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.

RED SUN Inc.

27

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 t o
1hr/year, but in those cases doctors/nurse s should be
alerted of the failure. More frequent failure of individual
components is not acceptable.

Example of reliability requirements: No more

than X bugs per 10KLOC may be detected dur ing
integration and testing; no more than Y bugs per
10KLOC may remain in the system after delivery.
RED SUN Inc.

28

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
RED SUN Inc.

29

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
BIM or by designing experiments.

RED SUN Inc.

30

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 Model
Lowers customer satisfaction
RED SUN Inc.

31

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

RED SUN Inc.

32

Attribute Trade-Off
Certain attributes may have conflicting
consequences, BIM Engineers must conduct
attribute trade-off to balance product
characteristics.
BIM 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.
RED SUN Inc.

33

Quality Attributes Trade-Off

RED SUN Inc.

34

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

traceability.

Verifiability

simplicity.

depends on completeness, consistency,

depends on modularity, self-descriptiveness and

RED SUN Inc.

35

Translating To Technical Spec.

Likely Technical Information

Quality Attributes Types

Integrity, Robustness, Usability,
Interoperability, Safety

Functional Requirements

Availability, Efficiency, Flexibility,

Performance, Reliability

System Architecture

Interoperability, Usability

Design Constraints

Flexibility, Maintainability,
Portability Reliability,
Reusability Portability

Design Guideline

Portability

Implementation Constraints

RED SUN Inc.

36

Class Discussion
Identify five quality attributes that you
think are important to the BIM tool
that you use today.
Create five questions about each attribute
to articulate your expectation.
Use the quality driven requirements
template to explore the quality attribute of
a computer game that you like.

RED SUN Inc.

37

Questions & Answers

RED SUN Inc.

38