The document discusses issues that can arise from using abstract terms in software requirements that are difficult to visualize. It notes that abstract terms like "furniture" are harder to imagine than specific terms like "kitchen table" as there is no shared understanding. When people think, they focus on a small percentage of details and forget most information, so abstract requirements provide nothing specific to focus on. It recommends removing abstractions from requirements and replacing them with more concrete language that is easier to visualize in order to avoid potential issues from differing interpretations of abstract terms.

1. DEAD BY USE CASE #2
DEADLY ERRORS IN THE SOFTWARE DESIGN

2. Non-Functional Use Case
WHAT IS WRONG WITH IT?
An app provides an optimal way to perform XYZ
…WHAT THE HECK IS “THE OPTIMAL WAY”?
DO YOU HAVE A CLEAR PICTURE OF IT?

3. We Cannot See The
Abstractions
WHEN WE USE THE SPECIFIC TERMS LIKE “KITCHEN TABLE”
WE CAN EASILY IMAGINE IT
!
WHEN WE USE AN ABSTRACT TERMS LIKE “FURNITURE” IT
IS DIFFICULT TO IMAGINE AND THERE IS NO COMMON
SHARED VISION
!
WHAT WE CANNOT IMAGINE, WE CANNOT THINK OF

4. Lesson From Cognitive
Science
HOW DO PEOPLE THINK?
Observe the situation -> Forget 99% of information -
> Focus attention on the rest 1%
… AND YOU DO NOT CONTROL WHAT PART YOU FORGET
!
YOU CANNOT THINK ABOUT YOUR “CLIENTS”, ONLY ABOUT A
SPECIFIC PERSON!

5. How To Fix?
REMOVE THE ABSTRACTIONS FROM THE REQUIREMENTS
An app provides an optimal way to perform XYZ
A User will prefer the App eight out of 10 times to
perform action XYZ
PUT THEM IN A WAY, THAT IS EASY TO IMAGINE

6. THANK YOU
ANDREY.VERBITSKY@GMAIL.COM