Доклад Юрия Гайдучка на Analyst Days-7. 13-14 октября 2017. Минск www.analystdays.com

1. Quality Attributes Analysis
Yuriy Gaiduchok, Oct 2017
REPLACE IMAGE
Quality Attributes Analysis
Yuriy Gaiduchok,
Oct 2017

2. Hello!
I’m Yuriy
Head of Business
Analysis @ Ciklum
Best BA 2017
by IT Awards Ukraine
14 years in IT: 12 in
Product Management
and Business Analysis

3. “This was not in specification”
“We never thought it would matter”
“No one ever told about it”
“It is too late to change
the architecture”
3

4. Assumptions
4
Explicit
Implicit

5. Structure
of Business
Solutions
Business
Rules
Business
Processes
Organizational
Structure
Business
Locations
Market
Events
Data
Sources
Applications
Technical
Infrastructure
Business Solution vs. Project Scope
5

6. Are they really non-functional?
6
IIBA
BABOK

7. 7
Quality Attributes & Non-Functional Requirements
A description of a property or characteristic
that a software system must exhibit
or a constraint that it must respect,
other than an observable system behavior.
Karl
Wiegers
IIBA
BABOK
Non-functional requirements augment the functional
requirements of a solution, identify constraints on
those requirements, or describe quality attributes a
solution must exhibit.

8. Quality Attributes Categories (Partial List)
8
Access Control
Accessibility
Accuracy
Adaptability
Adjustability
Affordability
Agility
Augmentability
Autonomy
Availability
Capacity
Cohesiveness
Compatibility
Completeness
Conciseness
Confidentiality
Configurability
Connectivity
Consistency
Controllability
Correctness
Coupling
Customizability
Decomposability
Dependability
Development Cost
Develop Time
Distributivity
Efficiency
Elasticity
Extensibility
Fault Tolerance
Feasibility
Flexibility
Independence
Integrity
Interoperability
Intuitiveness
Learnability
Maintainability
Maintenance
Time
Maturity
Measurability
Mobility
Modifiability
Modularity
Performance
Portability
Precision
Predictability
Productivity
Recoverability
Reliability
Replaceability
Replicability
Responsiveness
Retirement Cost
Reusability
Robustness
Safety
Scalability
Security
Sensitivity
Simplicity
Stability
Supportability
Survivability
Testability
Throughput
Trainability
Uniformity
Usability
Verifiability
Versatility

9. Quality Attributes Categories Selection
9
Ciklum
Primary
Availability
Compatibility & Portability
Performance & Efficiency
Scalability
Security & Audit
Testability (Automation)
Usability & Accessibility
Secondary
Customizability
Data Latency
Interoperability
Multitenancy
Reliability & Recoverability
Verifiability
Throughput

10. Incomplete list
No common ontology
Context-specific
Challenges

11. How can you determine which quality attribute
requirements are important before a system is built?

12. 12

13. 13
Who is responsible?

14. Approaches for Quality Attributes
14
Interviews Document Analysis
Observation Survey or Questionnaire
Acceptance and Evaluation Criteria Root Cause Analysis
Interface Analysis & Data Flow Diagrams Risk Analysis and Management
Quality Attribute Scenarios & Workshop Metrics and KPIs
Use Cases (Alternative and Exception Flows) Technical User Stories

15. 15
Technical User Stories
As DevOps, I want the system to use existing
clients database rather than create a new one,
so that we don't have to maintain additional
database.
As a user, I want the website to be available
99.9% of the time I try to access it, so that I
would not get frustrated and find another
website.
Who?
How?
Why?

16. 2000 Questions
16
Operation
How well is it safeguarded against unauthorized access? (Access Security)
How easy is it to learn and operate the system? (Usability)
Revision
How easy is it to modify to work in different environments? (Flexibility)
How easy is it to show it performs its functions? (Verifiability)
Transition
How easy is it to interface with another system? (Interoperability)
How easy is it to convert for use in another system? (Reusability)
Roxanne
Miller

17. Carnegie Mellon University
17
— facilitated method to generate and
prioritize quality attribute scenarios before the
software architecture is completed.
— focused on system-level concerns and
specifically the software role in the system.
— keenly dependent on the participation of
system stakeholders.
Quality
Attribute
Workshop

18. QAW
18
Step 1. QAW Presentation and Introductions
Step 2. Business/Mission Presentation
Step 3. Architectural Plan Presentation
Step 4. Identification of Architectural Drivers
Step 5. Scenario Brainstorming
Step 6. Scenario Consolidation
Step 7: Scenario Prioritization
Step 8: Scenario Refinement
Quality
Attribute
Workshop
by Software engineering Institute of Carnegie Mellon University

19. QAW
19
Advantages
• Determine the right qualities before system is developed
— crucial for success and stakeholders' satisfaction.
Saves money and avoids future rework.
• Structured and efficient setting for communicating with
your stakeholders, supports analysis and testing.
• Generally leads to the identification of conflicting
assumptions about system requirements.
Disadvantages
• Gathering multiple stakeholders and conducting QAW
sessions requires appropriate planning and availability.
Quality
Attribute
Workshop

20. Scenarios (QAS)
20
Quality
Attribute
Scenario
— unambiguous and testable requirement for
one or more Solution Quality Attributes
such as Performance, Usability, Maintainability
and others.
by Software engineering Institute of Carnegie Mellon University

21. QAS (scenario) consists of 6 parts
21
1. Stimulus – A condition that affects the system.
2. Source of the stimulus – The entity that generated the stimulus.
3. Environment – The condition under which the stimulus occurred.
4. Artifact stimulated – The artifact stimulated by the stimulus.
5. Response – The activity that results because of the stimulus.
6. Response measure – The measure for system’s response evaluation.
by Software engineering Institute of Carnegie Mellon University

22. Quality Attribute Scenario (QAS) Example
22
External smoke detector2 sends an alarm event1 under peak load3.
The building management system4 receives the event and raises
an alarm5 within 0.5 seconds6
1) Stimulus 2) Source 3) Environment
4) Artifact 5) Response 6) Response Measure

23. QAS for One Modifiability Case
23
A product manager2 request the system accommodate
devices supporting the next version1 of the ECNET
standard3. The system4 can accommodate5 these
devices within 1 person month of effort6 with no
changes to the software architecture6.
1) Stimulus 2) Source 3) Environment
4) Artifact 5) Response 6) Response Measure

24. QAS for One Security Case
24
A unauthorized individual from an external site gains
access to the system and tries to modify consumer data.
The system detects the malicious behavior, maintains an
audit trail of the unauthorized individual’s actions, notifies
system administration, and shuts down the system within
15 seconds.

25. QAS for One Security Case
25
A unauthorized individual from an external site2 gains
access to the system1 during normal operation3 and tries to
modify consumer data1. The system4 detects the malicious
behavior5, maintains an audit trail5 of the unauthorized
individual’s actions, notifies system administration5, and
shuts down the system5 within 15 seconds6.
1) Stimulus 2) Source 3) Environment
4) Artifact 5) Response 6) Response Measure

26. QAS for One Availability Case
26
“An unanticipated external message is received by a process during
normal operation. The process informs the operator of the receipt
of the message and continues to operate with no downtime.”
Source:
External
to System
Stimulus:
Unanticipated
message
Environment:
Normal
Operation
Response:
Inform
Operator,
Continue
to Operate
Response
Measure:
No Downtime
Artifact:
Process

27. QAS for General Availability
27
Source:
Internal or
External:
people,
hardware,
software,
physical
Stimulus:
Fault:
omission,
crash,
incorrect
timing,
incorrect
response
Environment:
Normal operation,
startup, shutdown,
degraded
operation,
overloaded
Response:
Prevent
failure,
Detect
fault,
Disable
event
source.
Response
Measure:
Time or % system
must be available,
Time to detect
fault, Repair time
Artifact:
Processors,
comm.
channels,
storage

28. Ignore?
28
Revenue
Client satisfaction
Employee satisfaction
NPS
Reputation

29. 29
Functional
Attribute
Quality Attribute
(Non-Functional)

30. Tradeoffs
30

31. 31
Functional
Attribute
Quality Attribute
(Non-Functional)

32. 32
How Uber
Launched

33. 2017? Quality Market!
33

34. Questions?

35. Yuriy Gaiduchok
https://linkedin.com/in/uasdlc
Connect two worlds!