-
Notifications
You must be signed in to change notification settings - Fork 15
/
04-requirements.html
323 lines (279 loc) · 12.7 KB
/
04-requirements.html
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
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>CS 4970: 04-requirements slide set</title>
<meta name="description" content="A set of slides for UVa's Service Learning Practicum course">
<meta name="author" content="Aaron Bloomfield">
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
<link rel="stylesheet" href="../slides/reveal.js/css/reveal.css">
<link rel="stylesheet" href="../slides/reveal.js/css/theme/black.css" id="theme">
<link rel="stylesheet" href="../slides/css/slp.css">
<!-- Code syntax highlighting -->
<link rel="stylesheet" href="../slides/reveal.js/lib/css/zenburn.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? '../slides/reveal.js/css/print/pdf.css' : '../slides/reveal.js/css/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
<!--[if lt IE 9]>
<script src="../slides/reveal.js/lib/js/html5shiv.js"></script>
<![endif]-->
<script type="text/javascript" src="../slides/js/dhtmlwindow.js"></script>
<script type="text/javascript" src="../slides/js/canvas.js"></script>
<link rel="stylesheet" href="../slides/css/dhtmlwindow.css" type="text/css">
</head>
<body>
<div id="dhtmlwindowholder"><span style="display:none"></span></div>
<div class="reveal">
<!-- Any section element inside of this container is displayed as a slide -->
<div class="slides">
<section data-markdown><script type="text/template">
# CS 4970
### Capstone Practicum I
<center><small>[Aaron Bloomfield](http://www.cs.virginia.edu/~asb) / [[email protected]](mailto:[email protected]) / [@bloomfieldaaron](http://twitter.com/bloomfieldaaron)</small></center>
<center><small>Repository: [github.com/aaronbloomfield/slp](http://github.com/aaronbloomfield/slp) / [↑](index.html) / <a href="04-requirements.html?print-pdf"><img class="print" width="20" src="images/print-icon.png"></a></small></center>
## Requirements
</script></section>
<section data-markdown><script type="text/template">
# Contents
[Introduction](/#intro)
[Elicitation](#/elicitation)
[Conclusion](#/conclusion)
</script></section>
<section>
<section data-markdown id="intro"><script type="text/template">
# Introduction
</script></section>
<section data-markdown><script type="text/template">
## Scott Adams gets it right...
</script></section>
<section data-markdown><script type="text/template">
## The Process
- Whatever your cycle, whatever the format:
- Requirements
- Design
- Implementation
- Testing
- Maintenance
</script></section>
<section data-markdown><script type="text/template">
## "Mommy, where do requirements come from?"
- Up until now, where did your requirements come from?
- In class, from the professor
- In an internship, from your manager/tech lead
- In a personal project (like SGD), from yourself or your teammates
- Where else?
</script></section>
<section data-markdown><script type="text/template">
## "Mommy, where do requirements come from?"
- Are these really "requirements?"
- Think about it
- Did you have a "customer?"
- How were the "requirements" stated?
- Did the "requirements" change?
</script></section>
<section data-markdown><script type="text/template">
## "Real Requirements"
- Class Assignments?
- Usually (unfortunately) contrived examples that don't change
- We avoid this as much as possible in this course
- Internship Assignments?
- Often just "to do" items (but not always!)
- There are, of course, exceptions
- Personal Projects?
- Often you skip the requirements phase
</script></section>
<section data-markdown><script type="text/template">
## "Real Requirements"
- Real Requirements...
- Created by stakeholders
- Often messy
- Often change
- Often not specific
- Might be infeasible
</script></section>
<section data-markdown><script type="text/template">
## Who are the Stakeholders?
- Whoever is paying the developer
- The end user(s)
- The customer representative/proxy
- Marketing
- Business plans
- Market research
- Focus groups
- Others?
</script></section>
<section data-markdown><script type="text/template">
## So, what do they give you?
- In a requirements analysis, customers give you requirements that "all customers can unambiguously understand"
- Ugh. These things are impossible to program from
- Requirements need to be ***SPECIFIC*** and ***MEASUREABLE***
- If they aren't, how do you know you met the requirement?
</script></section>
<section data-markdown><script type="text/template">
## Functional requirements
- Specifies what a system should do things
- "system should send an e-mail when X happens"
- "system shall log when a failed login occurs"
- "system shall present the invoice upon completion of a sale"
- These are specific behaviors (functions), and are (relatively) easily to test
</script></section>
<section data-markdown><script type="text/template">
## Non-functional requirements
- Specify *how* a system should do things
- Cost: a system should be "cheap"
- Reliability: a system should have 99.999% uptime
- Documentation: the system shall have a "good" user manual
- Response time: the system shall respond in less than 1 second
- These are criteria to judge the system by, but opinions on some of these can vary...
</script></section>
</section>
<section>
<section data-markdown id="elicitation"><script type="text/template">
# Elicitation
</script></section>
<section data-markdown><script type="text/template">
## Requirements Elicitation
- Requirements elicitation: a systematic way of developing requirements through an iterative process of analyzing a problem, document the resulting observations, and checking the accuracy of the understanding gained
- Requirements analysis: studying user needs to get a definition of the system (all customers can unambiguously understand these)
- Requirements modeling: turning user requirements into actionable statements that all software engineers can unambiguously understand
</script></section>
<section data-markdown><script type="text/template">
## Techniques of Elicitation 1
- Interview - very common, usually structured, but could just be a conversation with stakeholders, must ensure the customer agrees with the outcome of interview
- Observation - watch people do their current daily jobs and see where problems arise
- Examining documents / artifacts - read everything you can about current policy and procedures
</script></section>
<section data-markdown><script type="text/template">
## Techniques of Elicitation 2
- JAD (joint application design) - very structured "board room" requirements gathering session
- Groupware - kind of a mix of asynchronous interview with a large digital whiteboard
- Questionnaires - an asynchronous interview with as many stakeholders as possible
</script></section>
<section data-markdown><script type="text/template">
## Techniques of Elicitation 3
- Prototypes - rapid prototyping is often a good way to determine if you're on the right track
- Focus groups - group interview sessions
- On-site customer - the customer is a member of the team and guides the whole process
</script></section>
<section data-markdown><script type="text/template">
## Which Technique to Use?
- Deciding on which techniques to use varies by:
- Team size
- Customer / user base size
- Available resources (money, time, etc.)
- Availability of customer
- Availability of user base
- Current technologies
</script></section>
<section data-markdown><script type="text/template">
## Obvious Question is Obvious
- Which techniques are we going to use and why?
- Interview
- Observation
- Examination (docs/materials)
- Joint app design
- Questionnaires
- Groupware
- Prototype
- Focus group
- On-site customer
</script></section>
<section data-markdown><script type="text/template">
## Problems of Requirement Elicitation 1
- Boundary of system is ill-defined
- Unnecessary design information provided
- Stakeholders have incomplete understanding of needs
- Stakeholders have poor understanding of computing capabilities (see next slide)
- Engineers have poor knowledge of domain
</script></section>
<section>
<h4>Tasks</h4>
<img class="stretch" src="http://imgs.xkcd.com/comics/tasks.png" title="In the 60s, Marvin Minsky assigned a couple of undergrads to spend the summer programming a computer to use a camera to identify objects in a scene. He figured they'd have the problem solved by the end of the summer. Half a century later, we're still working on it." alt="Tasks">
<p class="center"><a href="http://xkcd.com/1425/">xkcd # 1425</a></p>
</section>
<section data-markdown><script type="text/template">
## Problems of Requirement Elicitation 2
- Stakeholders and engineers speak different languages (literally and figuratively)
- "Obvious" information is omitted
- Different stakeholders have conflicting views
- Requirements are vague/untestable
- Requirements are volatile
</script></section>
</section>
<section>
<section data-markdown id="conclusion"><script type="text/template">
# Conclusion
</script></section>
<section data-markdown><script type="text/template">
## We've got requirements!
- ... now what?
- Requirements on their face are not actionable items
- User-level requirements live at the system level / acceptance test case level
- We need to break items down into their constituent parts to turn them into reasonable-sized to-do items
</script></section>
<section data-markdown><script type="text/template">
## Requirements Modeling
- Some common methods for modeling requirements:
- Use cases
- User stories
- System Requirements Specification (SRS)
- Basically, anything that makes a requirement ***SPECIFIC*** and ***MEASUREABLE***
</script></section>
<section data-markdown><script type="text/template">
## Specific and Measureable
- Many a project has gone awry because a feature was "done"... but according to who? According to what?
- Specific – there should be no debate as to what a requirement means
- If there is, break it up into smaller requirements until the debate goes away
- Measureable – very simply, how do you know it's "done?"
- Write a test case! Or several!
</script></section>
<section data-markdown><script type="text/template">
## Agile Requirements
- In general, agile methods use less formal means of modeling (user stories, basic use cases)
- The more complex the project (and/or the more regulations you have to meet) the more formal the requirements need to be
- ... Or ask Prof. Knight about formal methods
- and stand back
</script></section>
<section data-markdown><script type="text/template">
## What do we work on first?
- The XP Planning Game mentality applies to Scrum practices as well
- Give each story or use case an importance rating and a difficulty rating based on the Fib sequence (1-21 is usually sufficient)
- Choose however many highest-priority stories fit into the sprint time frame (you'll have to learn what your optimal time frame number is)
- At the end of each sprint, you should have something that's "working," but not "done"
</script></section>
<section data-markdown><script type="text/template">
## One More Thing...
- Operational Profiles
- These give a high-level percentage as to "how often a feature is used"
- For instance, 99% of all Word users use the Save feature, but only 5% use Mail Merge with Excel
- Prioritize your development and testing around the highest percentage cases/stories to get the most benefit
</script></section>
<section data-markdown><script type="text/template">
## Always Remember
- Once implemented, wrong requirements are very expensive to repair
- Once software is in the field, wrong requirements are extremely expensive to repair
- Customers think that requirements can be changed very easily
- You must make the costs clear
- Here, "cost" is time spent changing the requirement that could be spent on other things
</script></section>
</section>
</div>
</div>
<script src="../slides/reveal.js/lib/js/head.min.js"></script>
<script src="../slides/reveal.js/js/reveal.js"></script>
<script src="../slides/js/settings.js"></script>
</body>
</html>