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
|
1
00:00:00,270 --> 00:00:02,969
Gathering requirements is one of the most difficult tasks a software
2
00:00:02,969 --> 00:00:07,010
engineer faces. In industry, you may gather requirements from end users,
3
00:00:07,010 --> 00:00:09,580
external clients, or from co-workers in other areas of your own
4
00:00:09,580 --> 00:00:14,320
company. Occasionally, you may receive a well documented set of requirements.
5
00:00:14,320 --> 00:00:16,970
However, in most cases, you will need to glean the requirements
6
00:00:16,970 --> 00:00:20,230
from conversations with the prospective clients, and distill them down into
7
00:00:20,230 --> 00:00:23,150
something actionable on your own. Suppose a teacher came to you
8
00:00:23,150 --> 00:00:25,310
with a request for a piece of software their students could
9
00:00:25,310 --> 00:00:28,500
use to find out the average length of the sentences in
10
00:00:28,500 --> 00:00:31,390
their essays. What questions come into mind to help you figure
11
00:00:31,390 --> 00:00:34,620
out the full requirements for this project. Write down a list
12
00:00:34,620 --> 00:00:37,630
of at least ten questions that might help you determine them.
13
00:00:37,630 --> 00:00:40,240
Please take the time to do this before moving on. There's
14
00:00:40,240 --> 00:00:42,670
no penalty for looking ahead, but if you skip this exercise
15
00:00:42,670 --> 00:00:44,920
you'll cheat yourself out of the benefits of brainstorming and getting
16
00:00:44,920 --> 00:00:48,190
your mind around the project before being bombarded by more information.
|
