Yuriy Gaiduchok: The Quest for Product Non-Functionality (UA) UA Online PMDay 2023 Autumn Website – www.pmday.org/online Youtube – https://www.youtube.com/startuplviv FB – https://www.facebook.com/pmdayconference

1. The Quest for
Product Non-
Functionality
Yuriy Gaiduchok
Sep 2023

2. Yuriy Gaiduchok
20 years in IT: General Management,
Business Transformation, Services Portfolio,
Business Analysis, Product Management
President
The Best BA 2017 by IT Awards Ukraine
VP Products and Services

3. • Understanding beyond functionality
• How to approach hidden areas
• Quality attributes (nonfunctionality) deep dive

4. Non-Functionality?
“We never thought it would
affect our success”
“It is too late to change
the architecture”
“This was not in specification”

5. 5

6. 6
40% of Fortune 500 to disappear in 10 years
Source: Huang Chenhong, president of Dell China via Yicai Global

7. 7

8. 8

9. Nonfunctionality
9
Amount of errors
Coverage of business needs
Estimates accuracy (time, cost)
Level of user satisfaction
Volume of rework

10. 10
Quality Attributes & Non-Functional Requirements
Karl
Wiegers
A characteristic that a software system must exhibit
or a constraint that it must respect,
other than an observable system behavior.
Non-functional requirements augment the
functional requirements or identify constraints
on those requirements
BABOK
by IIBA

11. Quality Attributes Categories
11
Access Control
Adaptability
Agility
Augmentability
Availability
Compatibility
Completeness
Conciseness
Configurability
Consistency
Controllability
Customizability
Dependability
Development Cost
Develop Time
Efficiency
Extensibility
Fault Tolerance
Flexibility
Independence
Integrity
Interoperability
Maintainability
Maintenance Time
Measurability
Mobility
Modifiability
Modularity
Portability
Productivity
Recoverability
Reliability
Replicability
Responsiveness
Reusability
Scalability
Security
Stability
Supportability
Testability
Uniformity
Usability
Verifiability

12. Quality Attributes Categories (still only some)
12
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

13. Incomplete lists
No common ontology
Context-specific
NF Challenges
13

14. 14

15. Uber
start
15

16. Software architecture and quality attributes
Functionality is orthogonal to the architecture
(can be achieved regardless of the architecture)
Nonfunctionality has more influence on the architecture!

17. Nonfunctionality Examples
1. Integrity: The digital bank solution subsystems shall perform all calculations with rounding
to 6 decimal places, before rounding to 2 decimals for presentation purposes
2. Scalability: The capacity of the emergency alert notification system must be able to be
increased from 5’000 messages per hour to 40’000 messages per hour within 24 hours.
3. Portability: All timestamps recorded in the database related directly to patients, employees,
working schedule, or services shall be in UTC time when recorded into permanent storage.
4. Interoperability: The system shall not use any images or icons that could be considered
offensive in the countries where it is operating or being marketed.
5. Reusability: The revenue recognition and attribution algorithms shall be reusable by future
dashboard versions or other future financial and managerial dashboards.
17

18. Interviews and Surveys (specific questions)
Technical User Stories
Quality Attribute Workshop & Scenarios
Use Cases (Alternative & Exception Flows)
Post-Mortem Simulation
Risk Analysis (NFR focus)
Interface Analysis
KPIs and Metrics Review
Approaches for
Non-Functionality
18

19. Questions for Interviews (Surveys)
Operation — How well does the system operate for daily use by the user?
How well is it safeguarded against unauthorized access? Access Security
How dependable is it during normal operating times? Availability
How fast, how many, and how well does it respond? Efficiency
How accurate and authentic is the data? Integrity
How immune is the system to failure? Reliability
How resilient is the system from failure? Survivability
How easy is it to learn and operate the system? Usability
Revision Transition
Roxanne
Miller
19

20. Questions for Interviews (Surveys)
Revision — How easy it is to correct errors and add functions?
How easy is it to modify to work in different environments? Flexibility
How easy is it to upkeep and repair? Maintainability
How easy is it to expand or upgrade its capabilities? Scalability
How easy is it to show it performs its functions? Verifiability
Transition — How easy it is to adapt to changes in the technical environment?
How easy is it to interface with another system? Interoperability
How easy is it to transport? Portability
How easy is it to convert for use in another system? Reusability
Roxanne
Miller
20

21. 21
Technical User Stories
As a returning customer, 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 look for another website (Availability)
As DevOps engineer, I want the system to use existing customers
database rather than create a new one, so that we don't have to
maintain additional databases (Maintainability)
Who?
How?
Why?
Hint: these are usually not for backlog directly

22. 22
Carnegie Mellon SEI Approach

23. QAW (Quality Attribute Workshop)
Advantages
Determine the right qualities before system is
developed. Saves money and avoids future rework.
Generally leads to the identification of conflicting
assumptions about system requirements.
Disadvantages
Gathering multiple stakeholders and conducting
QAW sessions requires appropriate availability.
23
Hint: for small projects may be used partially and still bring value

24. Quality
Attribute
Workshop
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
QAW Steps
by Software Engineering Institute of Carnegie Mellon University 24

25. Quality
Attribute
Workshop
Possible next steps after QAW:
• Refine requirements (all types)
• Create architecture, clarify drivers
• Validate requirements, evaluate architecture
QAW Steps
25

26. Scenarios
(QAS)
26

27. Scenarios (QAS)
Quality
Attribute
Scenario
— unambiguous and testable requirement for one or more
Solution Quality Attributes (such as Performance, Usability,
Maintainability and others).
Concrete scenarios play the same role in the specification of
quality attributes that use cases play in the specification of
functional requirements.
by Software engineering Institute of Carnegie Mellon University 27

28. QAS (scenario) consists of 6 parts
by Software engineering Institute of Carnegie Mellon University
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.
28

29. QAS for One
Security Case
29
— the measure of the system’s ability to resist
unauthorized attempts to use data or services
while providing access to legitimate users

30. QAS for One Security Case
30
An 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 and
notifies system administration5 within 15 seconds6.
Anything missing = unverified assumption!
1) Stimulus 2) Source 3) Environment
4) Artifact 5) Response 6) Response Measure

31. QAS for General Security
31
Artifact
System services
or components;
Data within
system
Source
Individual or
system: correctly
identified or not,
unknown identity,
who is: internal or
external, authorized
or not, with access
to: limited
resources, vast
resources
Stimulus
Tries to: display
data, change or
delete data,
access system
services, change
system services,
reduce
availability for
system services
Environment
Online or offline,
connected or
disconnected from
network,
firewalled or open,
operational fully
or partial or not
operational
Response
Authenticates user; hides
user identity; blocks or
allows access to data and
services; grants or
withdraws permissions;
records access/
modifications by identity;
stores data in unreadable
format; Recognizes an
unexplainable high
demand for services,
informs, and restricts
availability of services
Response Measure
Time/effort/resources for
security measures with
% of success; probability of
detecting attack; probability
of identifying responsible for
attack or access; % of services
still available under DoS
attack; restore data or services;
extent to which artifact is
damaged and legitimate
access denied

32. QAS example for One Availability Case
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.
32
Source:
External to
the system
Stimulus:
Unanticipated
message
Environment:
Normal
operation
Response:
Inform operator,
Continue to
operate
Response
Measure:
No downtime
Artifact:
Process

33. QAS example for One Performance Case
500 users initiate 1,000 total transactions per minute stochastically under normal
operations, and each transaction is processed with an average latency of two seconds
33
Source:
500 system
users
Stimulus:
Initiate 1000
transactions per
minute
stochastically
(randomly)
Environment:
Under normal
operation
Response:
Transactions are
processed
Response
Measure:
With average
latency of 2
seconds each
Artifact:
System

34. Ignore?
Lost Revenue
Reduced NPS
Employee satisfaction
34

35. Functionality Quality (Non-Functionality)
35

36. Tradeoffs
FR to QA (NFR)
&
NFR to NFR
36

37. 37
Functionality Non-Functionality
…and FR to NFR

38. 38
Summary
Balance functional and nonfunctional
areas development.
Workshops with scenarios help outperform
others and avoid fails even if done partially.
Start broad and refine. Match available time
and techniques complexity with your context
and stakeholders.

39. Quality
Market!

40. Which
one is
your
product
?

41. https://www.artofba.com/uk

42. Yuriy Gaiduchok
https://linkedin.com/in/uasdlc