From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001
From: Nguyễn Gia Phong <mcsinyx@disroot.org>
Date: Sun, 24 May 2020 16:34:31 +0700
Subject: [usth/ICT2.7] Engineer software

---
 .../33 - SRS - lang_en_vs5.srt                     | 183 +++++++++++++++++++++
 1 file changed, 183 insertions(+)
 create mode 100644 usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt

(limited to 'usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt')

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
new file mode 100644
index 0000000..44076db
--- /dev/null
+++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt	
@@ -0,0 +1,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.
-- 
cgit 1.4.1