-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathGathering Good Requirements for Developers
259 lines (231 loc) · 6.81 KB
/
Gathering Good Requirements for Developers
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
252
253
254
255
256
257
258
259
Gathering Good Requirements for Developers
Module 00: Requirements Gathering for Development
Introduction
Goals
Common general goals:
performance
scalibility
reiability
adaptability
cost-effectiveness
Correct system behaviors come from well-understood user requirements
Software requirements aim to create better understanding of the business
Audience
developer
who needs requirement himself
who support / work with BA to get requirements done
part-time BA with other duties, like project management
How does dev think about requirement process?
What is the group size?
What kind of project and how much details are needed?
Methodology
Waterfall Methodology:
essential to get started right
requirement skill are often lacking
requirement often seen as barrier to get start
Agile Methodology:
Requirements
some front work still required
seen as being done in cycle / iterative process
often take the form of use cases / user stories
considered very fluid
starting as business objective, refine through process
Requirement is both agile and waterfall
The objective at the begining of a project is to get:
Basic understanding
Scope
Sense of direction of project
List of things we will need
so that we are aligned with what user want
Make small course adjustment early on, then refine and iterate through SDLC
See from external that all of the work for requirements is done inside the process
Two end of spectrum
agile: fluid use cases
waterfall / waterfall-like: controlled and regid requirements
One vs. Many
Write individual requirement / tools and deliverables
Skills
Techniques
vs.
Put requirements into larger package for specifications
Tools
Deliverables
Managing relationships
Course Outline
The Big picture - where we are
A few good requirements
Requirements skills and techniques - do your own requirements
Requirements Activities - how to get requirements
When Requirements Get Together - how to get requirements into specifications
Getting Exhaustive - how to get the hard-to-get requirement details
Scope and Requirements Validation
Requirements Prioritization
Issues and Resolutions - what are the common issues?
Module 2: The Big Picture
Project Lifecycles
Software Development Roles
Requirements Tools - in terms of deliverables and techniques
Stakeholders - who is involved
Operating Environment - how people can share requirements
Time-Cost-Quality Triangle
Module 3: A Few Good Requirements
Why We Do Requirements
Defining Requirements
Requirement Types - from business objective to details
Exercise: Makeing an Omelet
A Good Requirement
A SMART Requirement - technique
Module 4: Requirements Skills and Techniques (soft skills)
Elicitation - how to get people to tell you
Facilitation - facilitate effective meetings
Evangelism - how to get people involved wanting to build the solution
Engagement - how to get people on board
People Integration - how to get people to work together
Mental Modeling - how to get people to understand the solution before it's built
Module 5: Requirements Activities
How to do ...
Meetings
1 on 1
interview
observation
Focus Groups
Attendance (who?)
Roles
Questionnaires (when are they not useful?)
Open / Close
Who to Survey
Writing
Text
Diagrams
Module 6: When Requirements Get Together (into document / specifications)
Goals
Agreement
Complete Enough - but we will never completely in alignment
Grouping
Unique ID - for reference later
Relationships
Requirements Forms
Document
Specification
Package
MECE
- mutually exclusive, collectively exhaustive
- none of the requirements should conflict
Inclusion by Reference - only include when necessary
Assumptions and Risks
Requirements Traceability
we want to get requirements traceable through design and testing
so that we can ensure quality
Module 7: Getting Exhaustive
Put together Components
Create Visuals to go with text requirement
Filling Gaps
Module 8: Scope and Requirements Validation
Scope
Product Vision Statement & Business Objectives
- measureable in Success Metrics
What are Acceptance Criteria for the project
To Know if the project is built successfully according to requirements
Diagrams
Validation (walk trhough items in requirement one by one)
Checklist
Pre and Post Conditions
Security
Imprecise Words - what else are we missing
Module 9: Requirements Prioritization
Techniques
Key Questions
Workarounds
Sanity Checks - does the project make sense
Module 10: Issues and Resolutions - challenges in developing requirements
Requirements Issues
Emotional Intelligence
Difficult People
Conflict Management
Whining
Pitfalls
Summary
Requirements is not straight forward, linear process
Process to deliverables - a package works for unique situation
Create requirements - one way or another
Module 02: The Big Picture
Introduction
How do software requirement fit in software development lifecycle?
Agenda
Project Lifecycles
- where is start and end
Software Development Roles
- who is involved in process
- what role they have to play in requirements
Requirements Tools
Conversation about Stakeholders
Operating Environment - what to do to get requirement
Time Cost Quality Triangle
Project Lifecycles
Software Development Roles
Requirement Tools
Stakeholders
Operating Environment
Time Cost Quality Triangle
Summary
Module 03: A Few Good Requirements
Introduction
Why We Do Requirements
Defining Requirements
Requirement Types
Exercise: Making an Omelet
A Good Requirement
A SMART Requirement
Summary
Module 04: Requirement Skills and Techniques
Introduction
Elicitation
Facilitation
Evangelism
Engagement
People Integration
Mental Modeling
Summary
Module 05: Requirement Activities
Introduction
Meetings
Questionnaires
Writing
Summary
Module 06: When Requirements Get Together
Introduction
Goals
Grouping
Requirements Forms
MECE
Inclusion by Reference
Assumptions and Risks
Requirements Traceability
Summary
Module 07: Getting Exhaustive
Introduction
Components
Visuals
Filling Gaps
Summary
Module 08: Scope and Requirements Validation
Introduction
Scope
Validation
Summary
Module 09: Requirements Prioritization
Introduction
Techniques
Key Questions
Workarounds
Sanity Checks
Summary
Module 10: Issues and Resolutions
Introduction
Requirements Issues
Emotional Intelligence
Difficult People
Conflict Management
Whining
Pitfalls
Summary