72 lines
1.7 KiB
Plaintext
72 lines
1.7 KiB
Plaintext
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.
|