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
|
1
00:00:00,120 --> 00:00:01,800
Before I conclude this lesson, I want to say
2
00:00:01,800 --> 00:00:06,150
a few additional things about the Software Requirement Specification document
3
00:00:06,150 --> 00:00:08,510
or the SRS. And I want to do that because this
4
00:00:08,510 --> 00:00:10,900
is a very important document and some of the projects
5
00:00:10,900 --> 00:00:13,160
actually require you to produce one. So why is
6
00:00:13,160 --> 00:00:16,760
the Requirement Specification such an important document? That's because a
7
00:00:16,760 --> 00:00:20,840
Software Requirement Specification document is an important fundamental way to
8
00:00:20,840 --> 00:00:25,310
communicate. Requirements to others. For example they represent a common
9
00:00:25,310 --> 00:00:29,490
ground between analysts and stakeholders. Note however, that different
10
00:00:29,490 --> 00:00:32,810
projects might require different software requirement specifications so you
11
00:00:32,810 --> 00:00:35,560
need to know your context. For example, the SRS
12
00:00:35,560 --> 00:00:38,140
document that you have to create for a small project
13
00:00:38,140 --> 00:00:40,690
performed by a few developers can in most cases.
14
00:00:40,690 --> 00:00:43,570
Be a concise and informal one. Conversely the software
15
00:00:43,570 --> 00:00:47,000
requirement specification for a multi-year project, involving a number
16
00:00:47,000 --> 00:00:50,480
of developers can be a fairly complex and extensive document.
17
00:00:50,480 --> 00:00:52,000
So again you have to be aware of your
18
00:00:52,000 --> 00:00:55,520
context and build your software requirement specification accordingly. In
19
00:00:55,520 --> 00:00:58,536
order to have a common format for the SRS
20
00:00:58,536 --> 00:01:01,380
document, IEEE defined a standard that divides the document in
21
00:01:01,380 --> 00:01:04,349
predefined sections. And in the context of this course,
22
00:01:04,349 --> 00:01:07,530
we will use a simplified version of the IEEE
23
00:01:07,530 --> 00:01:11,400
SRS format that includes three main sections. An introduction,
24
00:01:11,400 --> 00:01:15,540
which discusses the purpose, context, and objectives of the project.
25
00:01:15,540 --> 00:01:18,500
A user requirements definition, which contains the user
26
00:01:18,500 --> 00:01:22,690
requirements. And the system requirements specification, which includes both
27
00:01:22,690 --> 00:01:26,800
functional and non-functional requirements. And we provide more information
28
00:01:26,800 --> 00:01:29,430
about this format when we discuss the projects. So
29
00:01:29,430 --> 00:01:31,140
to conclude the lesson, I want to point
30
00:01:31,140 --> 00:01:33,670
out and in some cases recap a few important
31
00:01:33,670 --> 00:01:37,150
characteristics that requirements should have. First of all, requirements
32
00:01:37,150 --> 00:01:40,740
should be simple. Not compound. Each requirement should express
33
00:01:40,740 --> 00:01:43,710
one specific piece of functionality that the system
34
00:01:43,710 --> 00:01:47,000
should provide. Requirements should be testable. We mentioned
35
00:01:47,000 --> 00:01:48,660
this before, but I want to stress it
36
00:01:48,660 --> 00:01:51,820
because it is a very important point. Untestable requirements
37
00:01:51,820 --> 00:01:53,850
such as the system should be fast, are
38
00:01:53,850 --> 00:01:58,180
useless. Requirements should be organized. Related requirements should be
39
00:01:58,180 --> 00:02:01,220
grouped, more abstract requirements should contain more detailed
40
00:02:01,220 --> 00:02:05,400
requirements, and priorities should be clearly indicated when present.
41
00:02:05,400 --> 00:02:07,532
Finally, requirements should be numbered, so
42
00:02:07,532 --> 00:02:09,538
that they can be traced. For example,
43
00:02:09,538 --> 00:02:11,430
numbered requirements will allow you to trace
44
00:02:11,430 --> 00:02:14,510
them to design. Implementation and testing elements
45
00:02:14,510 --> 00:02:17,350
and items, which is something that you might have to do for one of
46
00:02:17,350 --> 00:02:20,680
the projects. And that we will discuss in more detail in a later class.
|
