-
Notifications
You must be signed in to change notification settings - Fork 16
/
requirements.theory.txt
251 lines (208 loc) · 17.3 KB
/
requirements.theory.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
REQUIREMENTS
/=+===============================+=\
/ : : \
)==: TRADEOFFS :==(
\ :_______________________________: /
\=+===============================+=/
OVER-ENGINEERING ==> #Spec|architecture|implementation that goes beyond actual requirements
#E.g. more complex, robust, quality, flexible, better UX, etc. that it should be
#"Rube-goldberg machine": when it is more complex than needed
EFFICIENCY VS EFFICACITY ==> #How much time to spend in requirements analysis or in architecture|design:
# - not enough: low efficacity, i.e. does not solve the right problems
# - too much: low efficiency ("analysis paralysis"), i.e. does not ship
#Depends on situation:
# - high-risk software (e.g. space shuttles) might need more efficacy
# - urgent software might need more efficiency
COST VS VALUE ==> #(UX + quality) (for users, i.e. value) vs maintainability (for developers, i.e cost)
UX VS QUALITY VS MAINTAINABILITY #Conflict between avoiding poor UX, bugs/unstability and system complexity:
==> # - improving UX or quality increases complexity
# - improving UX increasing unstability
USER-FRIENDLINESS VS FLEXIBILITY
==> #User-friendliness (simple|focused experience) vs flexibility (rich experience)
SIMPLER WORDING ==> #Less precise and easier wording for non-technical people:
# - "time" (maintainability)
# - "bugs" (quality)
# - "features" (flexibility)
# - UX
/=+===============================+=\
/ : : \
)==: LIST :==(
\ :_______________________________: /
\=+===============================+=/
TYPES ==> #Types:
# - functional (design): what software does
# - implementation needs:
# - quality: user-friendliness, robustness
# - quantity|number: flexibility
# - pertinence: respond precisely to the requirement
# - cohesion: with rest of system
# - non-functional, quality attributes (architecture): how software does it
# - experienced:
# - execution qualities: runtime, e.g. user-friendliness, robustness
# - evolution qualities: development-time, e.g. maintainability
# - can be:
# - product requirement, i.e. what to build, e.g. user-friendliness, flexbility, robustness, maintainability, manageability
# - process requirement, i.e. how to build, e.g. social impact, marketability
USER EXPERIENCE ==> #User-friendliness + flexibility
USER FRIENDLINESS ==> #Categories:
# - usability: can achieve goal efficiently, i.e. with no obstacles
# - ease of use
# - learnability
# - accessibility: how many different ways to use
# - internationalizability
# - design
# - performance: perceived performance
# - speed: latency vs throughput
# - efficiency: resource consumption
# - manageability: ease to manage by users. Anything but "using", i.e. any action not related to functionality, i.e. ease to:
# - discoverability: find|discover
# - deployability|installability: deploy|install
# - seamlessness|integratibility: install in existing platform
# - interoperability: install in different platforms
# - administrability
# - upgradability: upgrade
# - supportability|serviceability: technical support
# - interchangeability: uninstall, i.e. switching cost
FLEXIBILITY ==> #Behavior changes with different conditions, i.e. according to:
# - featureful: application state (i.e. lot of functional features)
# - interactivity: input
# - evolvability: after each interaction (e.g. AI)
# - configurability: expected context
# - adaptability: unexpected context
# - modifiability|customizability: user additions
QUALITY ==> #Preventing faulty execution:
# - stability|robustness:
# - testability
# - security: caused by malice
# - compatibility: caused by implementation changes
# - durability: caused by time
# - availability: total fault
# - reliability: frequent fault
# - vulnerability
# - recoverability: long-term damage (i.e. part cannot be fixed)
# - risk: fault impact (vertical)
# - fault tolerance: fault extent|scope (horizontal)
# - correctability: time|ease to fix
# - debuggability
# - monitoring:
# - auditability: how much is logged|visible
# - reporting: alerting for faults
MAINTAINABILITY ==> #Ease to manage by developers (i.e. complexity), i.e. ease to:
# - operability: keep on offering same features
# - transferability: operability for new developers
# - extensibility: offer new features
# - portability: support new environments
# - reusability
# - software rot
# - scalability: increase|decrease demand
SOCIAL IMPACT ==> #Categories:
# - privacy
# - environmental|human sustainability
# - transparency|accountability|inspectability|traceability
MARKETABILITY ==> #Categories:
# - certification
# - cost
# - legality
# - compliance
# - licensing
/=+===============================+=\
/ : : \
)==: DEFINITION :==(
\ :_______________________________: /
\=+===============================+=/
QUALITIES ==> #Should be INVEST:
# - Independent:
# - from other user stories
# - if some are tight together, put them as one user story
# - Negotiable:
# - can always be changed until start of coding
# - Valuable:
# - respond to stakeholders needs
# - imply all stakeholders, i.e. people: using, misusing (enemies), regulating
# - however must avoid "design by committee":
# - bad requirements due to try to please too many conflicting parties
# - e.g. feature creep, incoherent requirements, wrong directions for the whole due to office politics
# - Estimable:
# - put resources needed on it (time, price, material, etc.)
# - Small:
# - not more than a few person-days
# - when specifying, should cover the requirement, not less nor more
# - Testable:
# - tested by one or several "acceptance tests"
# - documented, traceable
#I.e.: valuable, granular (small, independent), easy to plan (can be estimated, tested, changed)
"WHAT TO DO", NOT "HOW TO DO" ==> # - "what to do" (requirements) should be specified by stakeholders, not developers
# - "how to do" (architecture, design) should be specified by developers, not stakeholders
HIGH-LEVEL FIRST ==> #In order:
# - high-level need:
# - guess actual need, i.e. why do you need to do this?
# - first formulated "need" is usually not the real need but a possible answer to it (formulated by stakeholders)
# - lower-level needs (summaries): to fulfill high-level need
# - proposals
/=+===============================+=\
/ : : \
)==: INCEPTION :==(
\ :_______________________________: /
\=+===============================+=/
INTERVIEWS ==> # - personal
# - in teams: JRD (Joint Requirements Development) sessions
/=+===============================+=\
/ : : \
)==: FORMALIZATION :==(
\ :_______________________________: /
\=+===============================+=/
TYPES ==> #From most generic to most explicit:
# - user story:
# - functionalities in natural language, i.e. "In order to BENEFIT as a ROLE, I want FUNCTION"
# - "epic story": group of user stories with same theme
# - acceptance test:
# - test of requirement in natural language, i.e. several scenarios: title, given/and (precondition), when (action), then (result)
# - used in ATDD (Acceptance test-driven development)
# - use case:
# - all interactions|actors in formal diagram or prose
/=+===============================+=\
/ : : \
)==: PROPOSALS :==(
\ :_______________________________: /
\=+===============================+=/
PROPOSALS ==> #Negotiable solution to set of requirements: prototype or specification
#Should only be from stakeholder perspective (including specification)
PROTOTYPE ==> #Proposal using fast implementation:
# - focus is on stakeholder feedback
# - can enter a review/enhance loop with stakeholder
#Completedness:
# - structure only:
# - partial ("sketch")
# - complete ("wireframe"/"blueprint")
# - visual design too ("mockup"):
# - low-fidelity
# - should provide visual hints of incomplete visual design, e.g. black&white
# - high-fidelity
# - interaction too (with|without visual design):
# - faked ("pretotype"), i.e. meant to be fast
# - close to real one ("prototype")
#Scope:
# - horizontal (the whole thing):
# - broader validation
# - vertical (a specific function):
# - more precise validation
# - should specify which requirements are addressed
#Evolution:
# - close-ended|throwaway|rapid:
# - not included in final product
# - importance is speed of creation
# - evolutionary|breadboard:
# - first step of final product
# - importance is possibility to build on it.
SPECIFICATION ==> #Proposal in details and in prose, but from stakeholder perspective
# - focus is on ease to implement: solution detailed enough to be used as a test of requirements
DESIGN PATTERNS ==> #Usual|recommeded way of solving architectural problems:
# - creational: initializing objects
# - structural: object structure like inheritance, composition, wrapper, etc.
# - behavioral: communication between objects
#"Gang of four" list (see it their respective docs):
# - creational: factory method, abstract factory, prototype, builder, object pool, singleton
# - structural: composite, wrapper, adapter, facade, bridge, proxy, flyweight, private class data
# - behavioral: chain of responsibility, command, interpreter, iterator, mediator, memento, null object, observer, state, strategy, template method, visitor