diff options
Diffstat (limited to 'usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt')
| -rw-r--r-- | usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt | 183 |
1 files changed, 0 insertions, 183 deletions
diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt deleted file mode 100644 index 44076db..0000000 --- a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt +++ /dev/null @@ -1,183 +0,0 @@ -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. |