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
|
1
00:00:00,130 --> 00:00:01,880
Now that we know what the requirements are and
2
00:00:01,880 --> 00:00:05,520
their main types, let's discuss where requirements come from and
3
00:00:05,520 --> 00:00:08,610
there are many possible sources for requirements so I'm
4
00:00:08,610 --> 00:00:10,610
going to list here the main ones. The first one are
5
00:00:10,610 --> 00:00:14,440
clearly stakeholders, anybody who is effected by the system
6
00:00:14,440 --> 00:00:18,830
and its functionality. Customers, users, and so on. The second
7
00:00:18,830 --> 00:00:22,610
typical social requirement is the application domain. For example,
8
00:00:22,610 --> 00:00:25,380
the fact that my software is running within a bank,
9
00:00:25,380 --> 00:00:27,930
or within a school. Why is the application domain a
10
00:00:27,930 --> 00:00:31,410
social requirement? Well, because there are constraints that are characteristics
11
00:00:31,410 --> 00:00:34,140
of the application domain that will affect the functionality of
12
00:00:34,140 --> 00:00:37,130
the system. For a simple example, just think about regulations.
13
00:00:37,130 --> 00:00:40,400
So banking regulations and school regulations in these cases. Those
14
00:00:40,400 --> 00:00:43,120
are things that might affect the functionality of my system
15
00:00:43,120 --> 00:00:45,570
and, therefore, that may become part of my requirements. And,
16
00:00:45,570 --> 00:00:50,120
finally, documentation can be an additional source of requirements. For example,
17
00:00:50,120 --> 00:00:54,110
notes, papers, manuals, books. So everything that refers to
18
00:00:54,110 --> 00:00:56,610
the functionality of the system that we're going to build.
|
