Mục Lục

CHƯƠNG I. TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM VÀ QUY TRÌNH .........................................5
1.1 5
1.2 Hãy nêu bản chất của yêu c u ph n m m .......................................................................................5
1.3 Nêu u ph n m m nhìn từ phía khách hàng .........................................................5
1.4 Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu c u ph n m m ..........6
1.5 ấ ủ ệ ấ .6
1.6 ủ ừ ........7
1.7 Mô tả Quy trình công nghệ học yêu c u ph n m m (Requirement Engineering Process)..............8
1.8 ủ ừ ủ
ấ ................................................................................................10
CHƯƠNG II. PHÁT HIỆN, TỔNG HỢP VÀ PHÂN TÍCH CÁC YÊU CẦU PHẦN MỀM ..............11
1.9 ệ ố ...........11
1.10 ệ ........................................................12
1.11 Trình bày các yêu c x nh nhiệm vụ và ph m vi của ph n m m ....................................13
1.12 Trình bày quy trình thực hiệ ( b ớ ), m và nh ng k thu x nh yêu
c u ph n m m Phỏng vấn (interview).......................................................................................................14
1.13 Trình bày quy trình thực hiệ ( b ớ ), m và nh ng k thu x nh yêu
c u ph n m m H i thảo ............................................................................................................................15
1.14 Trình bày quy trình thực hiệ ( b ớ ), m và nh ng k thu x nh yêu
c u ph n m m Brainstorming ...................................................................................................................16
1.15 Trình bày quy trình thực hiệ ( b ớ ), m và nh ng k thu x nh yêu
c u ph n m m Storyboarding ...................................................................................................................17
1.16 Trình bày quy trình thực hiệ ( b ớ ), m và nh ng k thu x nh yêu
c u ph n m m Áp dụng Usecase ..............................................................................................................17
1.17 Trình bày quy trình thực hiệ ( b ớ ), m và nh ng k thu x nh yêu
c u ph n m m Prototyping .......................................................................................................................19
1.18 ụ ủ
ả .........................................................................................................................................20
1.19 ( b ủ
ệ ) ụ ..................................................................................20
1.20 b b ớc (quy trình) Phân tích các yêu c u ph n m m ................................................20
1.21 Nêu các k thu t áp dụng trong Phân tích các yêu c u ph n m m ...............................................23
 1.22 b ỏ ệ
tiêu ch ấ , ự ệ .............................................................23
1.23 ủ ụ
trong BTL .................................................................................................................................................24
HƯƠ G ẶC T CÁC YÊU CẦU PHẦN MỀM .............................................................................25
1.24 Nêu các yêu c u củ c tả các yêu c u ph n m m .....................................................................25
1.25 Nêu khái niệm và thành ph n củ c tả yêu c u ph n m m ........................................................25
1.26 Nêu tên các bi u mẫu củ c tả yêu c u ph n m m (theo IEEE và CMU) .................................26
1.27 Trong cấu trúc củ c tả yêu c u ph n m m (SRS) System Requirement và Software
R c hi c tả v trí nào trong tài liệu SRS. ...............28
1.28 Nêu các k thu t vi c tả yêu c u ph n m m ...........................................................................28
1.29 ủ ừ ấ ệ .........................31
1.30 ủ ả ệ ố ả .......................................................33
1.31 ả ả
ả ệ .................................................33
1.32 ả ả
ả ệ ..............................40
1.33 ấ ệ ả ..............................41
1.34 ủ ừ x x ( ệ) ệ ả
..................................................................................................................................................42
1.35 ủ ụ
trong BTL .................................................................................................................................................43
1.36 ủ x ự ả ụ
trong BTL .................................................................................................................................................50
CHƯƠNG IV. DUYỆT VÀ KIỂM SOÁT CÁC YÊU CẦU PHẦN MỀM ...........................................52
1.37 Phân biệt các khái niệm Ki m th u ph n m m .......................................52
1.38 T i sao c n ki m th u ph n m m. Nêu tên m t số m th
yêu c u ph n m m thông dụng mà em bi t. ..............................................................................................53
1.39 x x x x
...............................................................................................................................54
1.40 ẫ ớ ...................................................54
1.41 ệ ....................55
1.42 ệ ệ ố ủ ệ
.......................................................................................................................................55
1.43 ủ ấ ệ .......................56
 1.44 ấ ệ ....................56
1.45 bả ủ ệ
ụ .....................................................................................................58
Kiểm toán: .....................................................................................................................................................58
Sử dụng đường cơ sở:...................................................................................................................................60
Thay đổi yêu cầu và các vấn đề về yêu cầu ngoại .........................................................................................61
b)Sử dụng các yếu tố bảo trì cho Thay đổi và các vấn đề .........................................................................62
1.46 Ki m th (testing) yêu c u ph n m m ..........................................................................................63
CHƯƠNG V. CÁC KỸ THUẬT NÂNG CAO CHẤT LƯỢNG YÊU CẦU PHẦN MỀM ..................64
1.47 õ t của yêu c u ph n m m. .........................................................64
1.48 ủ
õ ..........................................................................................................65
1.49 K thu t quả ý i yêu c u ph n m m ...............................................................................66
1.50 u ph n m m theo các thu c tính chấ ng ph n m m ................................67
1.51 õ u ph n m ảm bảo các yêu c u ph n m m ..............68
1.52 u ph n m m .................................................................68
1.53 ủ õ ..............................................69
1.54 ủ ả ý .................................71
C UH I N TẬP N H C IT PH N TÍCH CÁC YÊU CẦU PHẦN Ề

CHƯƠNG I. TỔNG QUAN VỀ YÊU CẦU PHẦN Ề VÀ QUY TRÌNH

1.1 C .
I EE.
ả :

 D (1993) : ủ ụ ( ,
) ủ ệ ố ả ệ ừ b
ệ ố
 J (1994) : b ủ ụ ự

 w (1997): Y ủ ụ ả
ả ả ả ả
ủ ệ ố ủ ệ ố

 (1) ệ ả ụ ả
ấ ụ ố ủ ọ
 (2) ệ ả ủ ệ ố
ệ ố ỏ , , ả bả
bắ b
 (3) bả ệ ệ ả ệ (1)
(2)

1.2 Hã bả ấ ủ
ả :
ả ấ ủ ẫ
ự ẫ ệ ý ệ x ấ ừ ừ
ụ
 x ấ ừ ụ ố ớ
ừ , .
 ả ừ ố ớ
ụ ấ , ụ

1.3 N ì ừ í à
ả :
ừ :
  ệ ả ủ ả
ụ ả ấ ả ụ (1)

1.4 Hã ó ố à ó ô ố ô ệ ọ

ả :
T ó ố:
 ỏ ủ ọ
 K ỉ ả ớ ụ , ả b
ấ ả ụ
 ấ õ ả:
ố , ả ớ
ụ ấ ả ấ
TBD( Tobe determined).  ấ ả D ả ả ớ
bắ x ự

T ó ô ố:
 ự ủ , ự

 ụ ự
ấ ả ự 
ắ ọ ả ỡ

1.5 N í ấ ủ .Q ệ
í ấ .
ả :
ấ ủ :
ố ớ ụ

 Hệ ả
 ẻ
 ả
 K ả ớ ệ ố

 K ả ệ chính xác
 Dễ ụ
 ố ớ
 ả ỡ
 Hệ ả
 ẻ
 ả

ệ ớ K ố ả ả bớ
bằ ấ

1.6 N .P í ủ ừ
(note)
ả :
:
a) Phân lo i theo yêu c u chứ ă à ứ ă .
- Các yêu c u ch ả nh ng ch n m m sẽ thực
hiện. Ví dụ bản hay thu tín hiệu.
- Các yêu c u phi ch ràng bu c của
giải pháp thực hiện. Có th gọi yêu c u phi ch u
v tính ràng bu c và v chấ ng ph n m m.
b) Phân lo i các yêu c u ph n m m theo nguồn gốc từ m t hay nhi u
yêu c u ở cấ c các thu c tính nổi bật (emergent
property), ho ch u ả ởng của ph n m m bở ờ i diện
sử dụng (stake holder) ho c m t số nguồn khác:
- emergent property: Có m t số yêu c u ph n m m sẽ có
u không th x nh cho m t
thành ph ẻ, mà còn tùy thu p
các thành ph n trong hệ thống. Ví dụ u của m t trung tâm
gọ ện tho i (t ) ẽ phụ thu c vào sự k t h p của hệ thống
telephone, hệ thố u kiện khác. Các emergent
c biệt phụ thu c vào ki n trúc hệ thống.
c) Phân lo i theo các yêu c t ra cho sản ph m ho c là trên từng tiến
trình. Các yêu c u trên các quá trình phát tri n khác nhau sẽ có th
nh ng ràng bu c b i lựa chọn của nh i tài tr (contractor), ho c
là nh ng chu t ra.
d) Phân lo n m m: ng, các yêu c
n là nh ng yêu c u quan trọ c xây
dựng dựa trên m t số y u tố ự ủy nhiệ , mong muốn, ho c tính
có hay không bắt bu c.
 e) Phân theo ph m vi yêu c u ph n m m: Ph m vi yêu c u ph n m m
ự ả ng của yêu c u lên ph n m m và các
thành ph n của ph n m m.
f) Phân lo dễ biế ng/ tính ổ nh (volatility/ stability): M t
số yêu c u ph n m m sẽ i của ph n m m, và th m
chí ngay cả trong quá trình phát tri n của yêu c u ph n m m. Chúng ta có
th phân lo i các yêu c u bằng cách thông kê nh i mà yêu c u
có th phát sinh.

, ố x
ố , ự ệ ự ủ
bả ụ

ệ : Guide to the Software Engineering Body of Knowledges – 2004

ố 39 202 ý ụ ỉ
ễ , b bỏ ả

1.7 ô ả Q ì ô ệ ọ (R
Process)
ả :
ệ ọ 2 :
ả ý ỏ :
ệ , , ả

HÌNH 1-2 ấ ệ ọ

- ỏ :
ệ
 ả
K
- ả ý :” ả ớ
ủ ự ”( U 1995) ả ý b ớ
sau.
X ớ (R b )
D ệ ớ ủ
ả ý

ệ ẽ :

HÌNH 1-3. Biên phân chia giữa phát triển yêu cầu và quản lý yêu cầu.

ả :
ấ ừ ,
, , ỏ ớ , (
) K ả ủ bả
 Requrireme ệ ố ả
( ọ bả 1 0)
bả 10 ,b ụ ớ
bả , ,x ý
R
ớ : , , ả
ệ ố , ấ ả
bả 1 1
Bây bả 1 1 ấ ụ ự
ố ấ ừ

1.8 N ủ ừ . ở ủ
ế í ấ .
ả :

V ủ ừ
ụ
- N ời sử dụng:
 Cung cấp yêu cầu công việc(Business Requirement): th hiện các mục tiêu
yêu c u m c cao của t ch c hay khách hàng v khả , m vi ng
dụng và giới h n của ph n m m; cung cấp các thông tin v từng nhiệm vụ cụ
th mà họ sẽ làm việc với ph n m m
 Yêu cầu người sử dụng (user requirement): th hiện các nhiệm vụ cụ th mà
NSD c n phả , c với ph n m m.
 ng,thỏa th n vớ i phát tri n các yêu c u ph n m m.
- N ời phát tri n:
 Phát hiện các yêu c u
 Phân tích các yêu c u
 c tả các yêu c u
 Ki m th các yêu c u
ở ủ ế í ấ
:
- N ời sử dụng: có ả ng tới ấ
ệ ệ :
 ỏi quá cao ho c chẳ n quá trình phát tri n
ph n m t cod …
  ng yêu c ngh rất khó chấp nh
PTV
 Các yêu c u ph n m nh p nhằng
ủa các nhà phân tích: làm l i yêu c u ph n m ng
chi m khaỏng 40% quá trình xây dự 70, 80% c tính xây dựng
l i có th dẫ n các l i
 D ng yêu c u quá ngắn gọn mà không miêu tả k ỡ
chúng là gì
- N ời phát tri n:có ả ng tới ấ
ệ ệ :
 Phân tích c các vấ
 Hi u bi t v nhu c u s dụng
 Hi c hệ thống
 Hi u ph m vi quản tr
 Tinh chỉnh các tính hệ thống

CHƯƠNG II. PHÁT HIỆN, TỔNG HỢP VÀ PH N TÍCH CÁC YÊU CẦU PHẦN
Ề

1.9 N ệ à ồ ố
ả :
1. x nh yêu c u ph n m m
 K t phỏng vấn
 K t h i thảo
 K t BrainStorming
 K t storyBoarding
 K t thu t Use Case
 K t Protopyting
2. Ngu n gốc yêu c u ph n m m

ả ấ ủ ẫ
ự ẫ ệ ý ệ x ấ ừ
ừ ụ
 x ấ ừ ụ ố ớ
ừ ,
 ả ừ ố ớ
ụ ấ , ụ
 ự ẫ 1997
ừ ụ ,
bả ố ấ 2b
:
 ệ ả ủ ả
ụ ả ấ ả ụ (1)
 ệ ả ả ỏ ủ 1 ệ ố
1 ệ ố ằ 1 ,1
1 ả ủ ệ (2)
bả ệ ệ ả ệ (1) (2)

1.10 ậ ệ
ả :

6 ệ
 Phỏng vấn
 T ch c h i thảo
 Brainstorming và Idea Reduction
 Storyboarding
 Áp dụng các Use-case
 Prototyping

P ỏ ấ H ả Brainstorming Storyboarding Use case Prototyping

Đối tượng Khách hàng, b b ụ , K ,
tham gia ỏ liên quan quan khách hàng
ấ
Loại yêu ấ ả ấ ả ấ ả ấ ả ấ ả
cầu

Nội dung b b ý b Mô hình b ẫ ,

chuẩn bị ỏ ỏ ệ ọ ả , bả Use case bả b
ấ ả ả
ố
Đánh giá ự ự , ự , ự , ố G , ự ,
phương ả quá trình ệ , ả ẫ
pháp b ả ả case chính
công phu xác xác, là
 chính xác
ấ

1.11 T ì bà x ệ ụ à ủ
ả :
Trong phát , ố ấ ủ ự
ự ủ :

 ẵ ự
 ự ệ ự

 , ớ b ừ , ,
w , ả bả ấ
ủ , ả ệ ,
ỷ ệ ớ Hệ ả ủ ự
ẽb ả ự
b ả ự ớ, ẽ ả
ấ ủ ự
ằ ụ ,
ố ự
 , ẵ ủ
ố ,
ố ố
 Ch ng th b giới h n b i th i gian (cố ) ( ũ
cố nh), vì th ph m vi khả thi chính là hình ch nh t màu trắng.
 N u hiệ ỏi phải b c tính của hệ thống bằng với tài nguyên
trên th i gian sẵn có thì dự án có ph m vi khả thi.

ng trong công nghiệp, các dự u là dự t ph m vi.

1.12 T ì bà ì ự ệ ( b ớ ), à ậ
x P ỏ ấ ( w)
ả :
ỏ bả ấ ủ ấ ả ấ ,
ụ ỏ:
- ụ ?
- Khách hàng là ai?
- ủ ọ có khác nhau không?
- ấ ả ấ ?
ủ ỏ ấ ự ệ ẫ :
-
- ấ
-
- ắ
- ấ ủ
- ả ủ ( )
-
- ự , ệ ả
-
-
-
ý ỏ ấ :
- b ớ ỏ ấ X ỏ ớ
ỏ ấ
- ớ ỏ ấ ả ủ b
ỏ ấ
- G ả ỏ ấ (K ố ắ ấ
thông tin trong lúc này).
- ả ẫ ỏ ấ ả bả ỏ
ắ
1.13 T ì bà ì ự ệ ( b ớ ), à ậ
x H ảo
ả
1. Quy trình thực hiện
- b H ả
o ả b
o ả bả b ẽ ự
o b ố
o K ấ (w - ): ớ ả
b ự ũ ệ ả ủ ả 2
w -up materials:
 ụ ự b bả
ả ủ ệ , ệ
, bả ỏ ấ ớ
,b x ớ , ừ ,b
ệ ố ệ , ỉ ả ý ớ, ệ
ớ…
 b ỏ ớ
- b f ( ẫ
ủ ọ ):
o b , ệ x ý ả ý
o ự ấ

 ừ o
 Ch ck x ựng sự ng lòng hay xây dựng
nhóm v ng chắc.
 c cả các thành viên trong nhóm và ngoài nhóm tôn
trọng.
 ủv ối m t với nh ng thách th c trong h i thảo.

- H ả
-
o ấ
o Brainstorming
o ự b ệ : H ả ,f
các ả ,f ệ ụ ủ

2. m
 - H i thảo yêu c u có lẽ là k thu t m nh mẽ nhấ g i ra các yêu c u
- Nó t p h p các bên liên quan l i với nhau trong th i gian ngắ p
tru
- Việc s dụng m u khi n bên ngoài có kinh nghiệm trong quản lý
yêu c u có th ảm bảo sự thành công của h i thảo.
- Brainstorming là ph n quan trọng nhất của m t h i thảo.
3. K thu t

- ọ ấ ủ ả b K
ự ả
b ự ừ ấ ả b

1.14 T ì bà ì ự ệ ( b ớ ), à ậ
x B
ả
2 :
- ý : ụ ý ố, ụ ớ b
,
- ý : ý , ọ ọ , , ,
, ỉ ý

K thu t này có nh ng l i ích chính sau:

 Khuy c mọi thành viên tham gia.

 Cho phép các thành viên tranh lu n với nhau v các ý ki xuất.
 u phối ho ý c h i thảo không b n.
 Diễn ra nhanh chóng.
 ải pháp khả thi cho vấ .
 Khuy ý , ,

nh:

 K c phép tranh cãi, phê bình gay gắt.

 Tự do sáng t , ng.
 ý ng càng tốt
 Nghiên c u t ng h p l ý ng hay.
1.15 T ì bà ì ự ệ ( b ớ ), à ậ
x b d
ả :
3 b :
 :G bả ả , ả , ả ệ
ệ ố õ ụ b
 ủ : ụ ấ ả
 : ệ ệ ố
ụ

ý:
 K b
 b ễ ỉ
 K ẽ ụ
ụ u này.
 ố ắ b ệ ớ , ớ

1.16 T ì bà ì ự ệ ( b ớ ), à ậ
x Á dụ U
ả :
 U U
ỉ ệ ớ ố U ả
b U -case.
U ả ớ ệ, b ( ),
ủ ệ ố U , ( )b
ệ ố ẽ ớ ọ ỏ ừ
ệ ố ( U ) U ố ệ
ả b U ủ U U ả ệ ,
ẽ ả ủ
X ự U -case:
- ớ ủ U - ệ ố (X
ủ ệ ố –H ): ệ ố ủ
U ớ ủ ệ ố ố ả
õ ớ ệ ủ ệ ố ả
b ũ ệ ễ ,b ả b ũ õ
ụ ả ự ố ấ ệ ố ụ ố ấ
ự ệ ủ ệ ố
ý ệ ố ả ớ ớ bả ủ ố ắ ố
bả ủ ệ ố ự ệ ,
ụ ệ ố ớ
ấ ệ ố
- Tìm ra các tác nhân(Actor) và các use-case
o ớ ệ ố ,
ụ ệ ố ệ ớ ệ ố ,ý ố
ằ ẽ ệ ệ ố ệ x ấ
ừ ệ ố , ớ ệ ố
ắ ọ , ự ệ U ,
ũ ệ ố ( ụ
ố ớ ệ ố ủ
b ớ ệ ố )
o U ệ ẹ
U U
ủ ệ ố ự ệ ả
, ớ ụ
b ệ ớ ũ
ự ệ ệ b b ệ ố
- ả U -case
- ố ệ U -case
- K
ụ:
1.17 T ì bà ì ự ệ ( b ớ ), à ậ
x P
ả :
x bằ ẫ
ẽ ự ả 1 ả b ả
bằ ệ ớ ệ ẽ ụ ự ớ ụ , ừ
ụ , õ , bệ “ ” ệ
ẫ ụ ẫ
ả ụ , ẫ ẽ ẫ
ớ ( )

ớ ụ x ẫ ự
ự ẻ ủ ệ ố , ằ ụ ỡ , ụ
ẽ ủ ệ ố
ớ ụ x ự ẫ : w w ,
z , f ( ố ụ ừ ọ ọ
R fw 13 )
x ự ẫ ụ , ớ
ả ả ủ ệ ố , ớ ự
ọ ụ ệ ẫ Dự ả bả ẫ
ớ ụ , ớ , ệ ụ bệ
“ ” ẫ ệ, b ớ ụ
ẫ ụ ẫ ừ ớ
1.18 N ó . ụ í ủ
ó . ế ả ó .
ả :
??????

1.19 N ô ì ó .T BTL (V
b ủ T ờ Vệ ) ó ã dụ à .
ả :
- D liệu và ki m soát lu ng (data and control Flows)
- Các mô hình tr ng thái (state models)
- Dò v t sự kiện (Event tracing)
- ớ i dùng (user interaction)
- ố ng (object models)
- Các mô hình d liệu (data models)

- Mô hình hóa use case

- Mô hình hóa nghiệp vụ

- Mô hình hóa d liệu

N ó ã dụ :
- Mô hình hóa use case
- Mô hình hóa nghiệp vụ
- Mô hình hóa d liệu

1.20 T ì bà b ớ ( ì )P í
ả :
- Phân lo i các yêu c u ph n m m:
C ứ ă ệ ệ ố , ủ ệ ố
ớ , ủ
C ứ ă : ụ , , ệ , ả …
C ớ ế ế: ụ ệ ố , ,…

- Mô hình hóa khái niệm:

ụ ủ ệ õ ấ , bắ ả
ệ ủ ự ả ố ệ ự ụ
.

ố : ệ , , ấ
ự ệ , , ố , ệ …

ố ốả ệ ự ọ
b :
- ả ấ ủ ấ , ố bệ
 - ủ ụ ọ
ệ
- Y ủ hàng
- K ả ủ ụ

- T ế ế ế ú à bố

- ớ ệ
ố , ọ ả ủ ệ ụ

- Phâ b ấ ọ D ,
ự ớ , ệ

- x ẽ ớ ệ ệ
ụ ý ệ

- 2000 ả

- à u

- “ ả x ”: b ấ ,
ả ,

- ọ ,
ả ý ớ b , ự
ự ỏ ệ ý ố ọ ố
1.21 N ậ dụ P í
ả :
1. ả( )
2.
3. (F )
4. (D )
5. (G )
6. ( (f w ))
7. ự ( ntity relationship models)
8. ớ ố (Obj -oriented analysis)
9. ấ ( )
10. ệ (D f w D )

1.22 T ì bà ậ à ỏ ậ .
ệ í ấ , ờ ự ệ .
ả :

Một thuật ngữ khác được sử dụng cho chủ đề này là “ conflict resolution” .
Điều quan tâm này giải quyết vẫn đề với các yêu cầu mà sự xung đột
xảy ra giữa hai yêu cầu của các bên liên quan cùng các tính năng không
tương thích , giữa các yêu cầu và nguồn lực hoặc giữa yêu cầu chức
năng và yêu cầu phi chức năng.
Trong tất cả các trường hợp , nó không thận trọng cho các kĩ sư phần mềm
làm các quyết định đơn phương và do đó nó cần thiết tham khảo từ các
bên liên quan để đạt được một sự đồng thuận trên sự thỏa hiệp thích
hợp.
Sử dụng Use Cases
 Để hỗ trợ các hoạt động thiết kế và mã hóa, các Use Case phát
triển trong các hoạt động suy luận hơn là xây dựng đầy đủ.
 Các Use Cases thích hợp nhất khi hệ thống giàu chức năng và
phải hỗ trợ các loại người dùng khác nhau.
  Các Use Case không có hiệu quả khi áp dụng đến hệ thống với
một vài hoặc không có giao diện người dùng tối thiểu, chủ yếu là
những yêu cầu phi chức năng và những hạn chế khi thiết kế.

thêm

1.23 C ứ ă ủ A í . ã
ử dụ ế à BTL
ả :
1. Xem xét cấ ú à à t của yêu c u ph n m m
S dụng c a s Hierachy. Khi lựa chọn 1 Requirement, ta sẽ x c các thông tin v :
Quan hệ phân cấp của Requirement: cho bi t nó là con của các Requirement
nào, cha của các Reqiurement nào, quan hệ thu c lo i nào (s h u hay k t t p)
…
Quan hệ v t của R : t b i các Element nào. N u
Requirement có các Requirement con, EA có th chi ti t việ t của từng
R

2. Phân tích sự phụ th c của yêu c u

S dụng ma tr n quan hệ (Relationship Matrix): thông qua c a s Relationship Matrix.
Cho bi t quan hệ gi ố ng trong 2 package

3. Quả ý ổi
S dụng c a s Audit View: ghi chép l ực hiện.
Kích ho t Audit View:
M c a s Audit View
Chọn Audit Settings
Enable Auditing

4. Lập báo cáo

S dụng menu Project | Documentation
 L b c tả ng : thông tin v Requirement và các
R ng. Có nhi nh d bản khác nhau
:R x F ,H ,…
Báo cáo quan hệ t
Báo cáo quan hệ phụ thu c
…

HƯƠ G Ặ Á YÊU ẦU HẦ Ề

1.24 N ủ ả
ả
 G
 ấ õ ả
 ố ả ệ ụ
 Không phụ thuộc vào các yêu cầu được tìm được ra hay xây dựng như thế
nào
 Trong đặc tả phải nêu được cả business requirement , phạm vi ứng dụng ,
giới hạn của ứng dụng.
 Trong đặc tả phải nêu được đầy đủ các user requirement, sử dụng mẫu
(template) của các trường hợp sử dụng của từng yêu cầu.
 Thỏa mãn các tiêu thức đánh giá một đặc tả: tính nhất quán, tính thân thiện,
tính dễ sử dụng.

1.25 N ệ à à ủ ả

ả :
Khái niệm:
Là hi u bi t hệ thống của khách hàng vào th m thi t k và phát tri n ph n
m ảm bảo v cả khách hàng và sự hi u bi t hệ thống,các nhu
c ớc khi ấ nh th m.
 - Không phụ thu c các yêu c u ph n m , c xây dựng
nào? Cuối cùng bao gi ch ũ ả c tả các yêu c u
này.
- 1 c tả: tính nhất quán, tính thân thiện và tính
dễ s dụng.
- c tả yêu c u ph n m m phả c cả yêu c i,
ph m vi ng dụng, giới h n của ng dụng.
- c tả phả ủ c các yêu c i s dụng, s dụng
các mẫu(template) củ ng h p s dụng của từng yêu c u

Thành phần :
 Ghi l i các nguyên tắc công việc.
K i s dụng miêu tả cho chúng ta m t ho ấy chỉ
c thực hiện trong nh u kiện nhấ nh, do nh ng tác nhân
nhấ nh..t 1 ắc công việc.
 c tả các yêu c u ph n m m theo mẫu.
c tả ch ệ thống, sự thỏa thu n v ch , c tả hệ
thống.(SRS)
 Gán nhãn các yêu c u ph n m m.
 ấu nh õ c tả.
 Mối liên quan gi c tả vào giao diệ i s dụng.

1.26 N b ẫ ủ ả ( I à C U)
ả :
G ệ
-
- ệ
- ả
- ấ
-H

IEEE:
 Giới thiệu
 Mụ ệu
  bả ớc.
 ố ng dự ki n và góp ý.
 Ph m vi sản ph m.
 Tài liệu tham khảo.
 Mô tả chung
 m sản ph m
 Ch ản ph m
 m user
 ng v n hành
 Thi t k và ràng bu c
 Giả nh và phụ thu c
 Yêu c u v giao diện ngoài
 Giao diệ i dùng
 Giao diện ph n c ng
 Giao diện ph n m m
 Giao diệ
 Tí ă ệ thống
 Hệ thố
 Mô tả
 Kích c u/ th tự ng.
 Yêu c u ch
 Yêu c u phi chứ ă .
 Yêu c u trình diễn
 Yêu c u an toàn
 Yêu c u bảo m t
 Yêu c u chấ ng các thành ph n ph n m m
 Nguyên tắc công việc
 Tài liệ i s dụng
 Các yêu c u khác
 Thu t ng
 Mô hình phân tích
 D nh d ng

CMU:
1.27 T ấ ú ủ ả ( R ) R à
Software R ế à à ảở í à
à ệ R .
ả :
.T ấ ú ả ( R ):
- R ( ệ ố ): ấ ệ ủ
ủ ệ ố ẽ : ấ
, ệ ố , b ,… ả ủ
ẽx ự x ớ ả ớ
ệ ố b ọ ả ả ý
- Software Requirement b :
ủ , ệ ủ ,
ệ , bệ
b. Trong tà ệ R R í ớ fw
Requirement:
- R ả ấ ố ớ ệ
ố ẽ
- fw R ủ ệ R ,b ả
ố ớ ừ ệ ố ả , ả
ủ ệ R

1.28 N ậ ế ả
Trả lời:
1. Giả ngôn ng
Gả ự ự ớ
ẽ, ấ ủ ễ ả
ễ ấ
 2. Máy tr ng thái h u h n

(F ) ấ b ố ụ
ệ ố , ắ , ệ ố , ệ ệ ố
F ả ự ụ ự b
ệ ố
3. Cây quy nh
ụ ệ x x ự ự ủ
th , ự ủ ẽ ẫ
ả ủ ả ệ x
ự ắ ớ ệ ệ “f – ”
nhau.
4. Bi ho ng
ớ ệ ụ U , ả ễ ả
ố ấ ự ụ ễ ắ bắ
ủ R

5. Mô hình thực th liên k t

 RD ấ 1 ấ ủ ệ , ẽ ụ
ớ ả
6. ớ ố ng

ố ấ ố x b
ố ự G ụ ễ

1.29 P í ủ ừ à ấ ú à ệ

ả :
ấ ệ : 11
- Introduction (Giới thiệu)
- Glossary (từ n thu t ng )
- U ( ng h p s dụng)
- Design Overview (thi t k t ng quan)
- Obj ( ố ng hệ thống)
- Object Descriptions (mô tả ố ng)
- Obj b ( ố ng h p tác)
- Data Design (thi t k d liệu)
- D ( ng)
- Non-functional Requirements (yêu c u phi ch )
- Supplementary Documentation (tài liệu b sung)
1. Introduction: cho ta bi t
- Mụ :
 Cung cấp m t mô tả v các thi t k của m t hệ thố ủ cho
phép phát triển phần mềm.
 Cung cấp thông tin cần thiết cung cấp mô tả chi ti t cho các ph n
m m và hệ thố c xây dựng
- Ph m vi: cho bi t ph m vi của hệ thống
- Các từ vi t tắ , : ệu tr nên ngắn gọ , ọc
dễ ọc, dễ hi
- Sự tham khảo
- T : ọc có cái nhìn t ng quan v hệ thống c n xây dựng
2. Glossary:cung cấp các thu t ng s dụng n i b của tài
liệu
3. Use Cases: x c nh ng ai sẽ s dụng hệ thống, tác nhân kích
ho , i diện và quản tr hệ thống
4. Design Overview: t t ng quan v thi t k , cho nó vào m t ng
cảnh với các hệ thố b ọ i s dụng
tài liệ ớng cho bả thi t k và nhìn thấy m t bản tóm tắt
ớc khi ti p tục thi t k các chi ti t.
5. System Object Model : cho phép mô tả các hệ thống m t cách t ng th ,
cho thấy các nhóm khác nhau của các ph n vào các hệ thố ng
6. Object Descriptions: mô tả ố ng trong tài liệu
7. Object Collaborations: mô tả mối quan hệ ố ng
8. Data Design: thực th liên k t: cho bi t các liên k t gi a các ối
ng (1-1, 1-nhi u, nhi u-nhi u)
 9. Dynamic Model:
- trình tự: cho thấy m t ng quan v hình th c trình tự di chuy n từ
d liệu và mẫ có m t tài liệu
- chỉnh s a tài liệu: cho thấy m t ng quan v trìn tự di chuy n từ
m t tài liệu ba i cho m t tài liệu s i
10.Non-functional Requirements: cung cấp các yêu c u thực hiện (các yêu
c u phi ch )
11.Supplementary Documentation: có th là tài liệu tham khảm, có th là
công cụ c s dụ t o bi

1.30 ủ ả ệ ố ả
ả :
ý ủ ả ệ ố ả
ả ệ ố ả ệ ố :
ả x ự ấ ả
ệ ụ ả ụ

1.31 C ậ ă ả ứ ă ả .
P ã ó ả ứ ă à ệ
ứ ă
ả
ả

x ớ ả
ố ớ ự
1 ố b : ả, ,cây
, , ự - ệ, ớ ố ,
ấ

ọ ừ ả :

1. ã ả

2. .

3.C ế
 .B ồ

5. ô ì ự ệ

.P í ớ ố

7.P í ấ ú (B ồ ồ d ệ )

1. ã ả
ả , ủ
ự ớ ẽ, ấ ủ Mã
ảb ự ủ :

bắ b ớ ừ ấ ố ấ

40-50, ớ ừ ừ
ả x ự

ệ ấ F-ELSE-ENDIF
b ễ ớ DO- H ấ FOR-NEXT

Hình 28-1 ấ ụ ả ả ủ

2. .
ố , ệ ả ố ệ ủ 1 óm
ệ ố ả ớ , ẳ ệ ừ
 ụ ừ b b ,
ủ ả ự ệ
ụ (F )
niên.
Hình 28-2 ọ è

F ấ b ố ụ ệ ố , ẳ
ắ , ệ ố , ệ , ệ ố

3. C ế .
b x ớ ự ủ ố ,
ủ ố ẫ ả

Hình 28-3 ấ ụ ả ự ấ
HOLIS.
.B ồ .
 U , b ý: ả

5. ô ì ự - ệ
ả ấ ố
ệ ệ ệ ố , ệ bằ ự -
ệ ( RD) H 28-5 ấ RD
 RD x b ủ ệ ố cho
x ỏ ỉ
? ả :

RD ẽ ả ấ ả
ọ

. ô ì ớ ố .
ớ ự b ủ OO U , b ả ố
, ự ệ ủ ệ ố

Trong hình 28-6

7.B ồ ồ d ệ
Ví dụ ì 28-7.

ệ (DFD) ố RD
ễ ớ RD

1.32 C ậ ă ả ứ ă ả
.P ã ó ả ứ ă à ệ
ứ ă
ả :
Y b ả ỏ
ả ệ ố , ệ ự ệ
ủ ố , ẳ
 ẵ , ả , ả bả , ễ ụ
:
 Ràng bu c v hiệ : ẳng h n "hệ thống c n phục vụ liên tục từ 5 gi
n 9 gi tối.", "m t hàng c trong tối thi u 7

 Ràng bu c v quá trình phát tri n hệ thống: th i gian, tài nguyên, chất
ng. Ví dụ: khi nào hệ thống c n hoàn thành (th i gian); t ng chi phí cho
phát tri n hệ thống (tài nguyên); c n áp dụng các tiêu chu n nào cho quá
trình phát tri n hệ thố , ản lý dự án và
phát tri n hệ thống (chấ ng).

 õ (Eliciting requirements): ớ
ụ x ủ ọ
 X x (Analyzing requirements): x x
õ , ỉ , ,
ẫ , ả ấ
 ệ (Recording requirements):
, ẳ ệ ự ,
ố ụ (use case), ệ ụ (user story),
ả

õ ụ ố :

 ỏ ấ
 ọ tâm (focus group) ớ ọ b
(requirements workshops)

 ẫ (prototyping)
 ố ụ

1.33 N ấ à ệ ả
ả :
Tài ệ :
  Chỉ mô tả v ch , b c
 Không mô tả v t
 Phải dễ i (có cấu trúc)
 K x ủ chính xác ngay
 Phải qua nhi b ớc xét duyệt l i

ắ ỉ ệ ả:
(1) ố ắ ắ ọ ,
(2) ụ ễ ,
(3) ,
(4) ụ ừ ấ ả : ệ
ệ , ệ ố ệ ả,
ỉ õ ệ ,
ệ ả
(5) ụ ừ : ố ố ấ
ỉ õ ả
ấ ủ ả
 Tính rõ ràng, chính xác
 Tính phù h p
 ủ hoàn thiện

1.34 P í ủ ừ x x à ô ( d ệ) à
ệ ả
ả :
Các tác nhân tham gia vào quá trình xem xét và thông qua ( ệ) ệ ả
:
- i diện củ i s dụng (Product Champions): Thực hiện quá trình xác nh n các
yêu c (R ) vào tài liệ c tả và các yêu c u thực t của
hệ thống, họ sẽ phải trả l i câu hỏ “ mô tả nm m ?” Các
xác nh n g m có:
o Tính chính xác (Correct)
o Tính khả thi (feasible)
o Tính c n thi t (necessary)
o ( z ) ủa các yêu c u.
 - Các phân tích viên (Requirements Analysts): Thực hiện quá trình xác minh các yêu c u
(Requirements Verif ) vào tài liệ c tả và các yêu c i dùng, họ sẽ
phải trả l i cho câu hỏ “ xây dựng ph n m ?” x
minh g m:
o Tính ngắn gọn, súc tích (concise)
o Khả t (traceable)
o K ừa (non-redundant)
o T ch c tốt (organized)
o n (conformant to standards)
o Khả m ch ng (verifiable)
- Ngoài ra còn có các thành viên của công ty ph n m m tham gia vào qua trình thực hiện
phát tri n ph n m m: L p trình viên, các nhà ki m th …

1.35 C ứ ă ủ A ô ì ó . ã ử
dụ ế à BTL
ả :
Mô hình hóa use case
ệ
ệ ụ
Requirements Modeling
b ấ ự
, ụ R ừ bả R ủ b x
b ( ả R b ủ ệ
EA trong Toolbox)
ụ U õ U
, , ,
ụ ệ bấ ừ
ệ ụ ệ bả
ệ ớ ệ è (H 1) ố
õ bấ ũ (H 2)
“ b ” ụ f
 Hình 1

Hình 2
x R
 Chu ‘ ’ ‘U b x’ m bảng custom
  ‘R ’ ừ bả
 EA cho phép b x nh vài thu c tính của yêu c u
o M ‘ D ’ ẽ hi n th
o ‘ x R b ’b ớ õ
 O k t thúc
 Nh ng thu c tính này có th s ch a l i sau này bằng cách double-click vào requirement
 M t requirement mớ c hi n th ‘ j w’

ủ ả x ố ớ
ố ự (x - b ớ)
C í
ủ x R
Double- R
ủ R , ff , , ụ: x 2b
ỉ ễ  OK y.
N í x R
K ụ x , ệ
ụ:
 T o nh ng thu c tính user-definable s dụng tagged values
 Viewing Requirement s dụng Elements list view ho c diagram view
 Thi t l p nh ng mối quan hệ gi a các yêu c , ệ với các thành ph n UML khác
, ,
 Nh ng quan hệ dò v t gi a nh ng yêu c u và nh ng thành ph n khác.
 T o m t cây yêu c u k thừa s dụng thành ph n child ho c packages.

T Add A b ủ R
x ự
ố bấ , , ễ
ệ ụ ‘ ’
- ff bả
ệ ớ
bệ, x ấ
ụ + f +6( ừ w| ) ụx 3
 Hình 3
Predefining Tagged Values Types for Requirements
,b ,
ự
ớ ụ U f ụx 4
ụ f ủ ự án.

Hình 4
 ấ ự -
x ự ọ | | w |[ ]
ụx 5

Hình 5
Element Numbering
ệ ấ ớ ệ ố
ớ ấ ấ b ố
111 bấ ụ
f ( ụ )
ụ ớ b

Hình 6
ự ọ
 Select m t package trong Project Browser
 Right-click và từ menu context select: Show Level Numbering

Hình 7
Từ Project View, các thành ph ố có th c sắp x p l ản bằng cách
kéo m t child element vào m t element khác. Nh ng elements con sẽ ốl
phù h p với elements cha.

Hình 8
Different Views of Requirements Using the Element List View
b i dùng không giống vớ U
EA h tr m t text-based view của nh ng yêu c u, trong khi vẫn duy trì cấu trúc phân cấp
trong Project View.
 :
 The Project View. Cái này có th gắn hi n th cây phân
cấp.
 w này có th thi t l p v ch text view
o i ch diagram view và Elements List View từ main menu,
sleect View| Element List.
 The Notes and Tagged Value windows có th thi t l p là default view
o xem the notes window select View| Notes
o xem the tagged values window select View| Tagged Values.

D ớ ụ ủ x -based mode

Hình 9
ớ ụ x -b ớ w w w w :
 Hình 10
ệ ố ‘ b ’ ‘
’ b ả

1.36 C ứ ă ủ A x dự ả . ã ử
dụ ế à BTL
ả :
 T o ra các yêu c u ph n m m bên ngoài (External Requirements)
+ T o trong bi ( Diagram )
 M Custom pages trong Enterprise Architect UML Toolbox. Chọn
Requirements
 C ố ng Requirement, thả vào trong bi
 Nh p tên và các thông tin khác cho Requirement. Save l i
+ T o trong gói ( Package)
 Nháy phải vào gói, chọn Insert | New Element ( ho c Ctrl + M )
 Trong h p tho i New Element, chọn Requirement
 Nh p tên và các thông tin khác cho Requirement. Save l i.
 T o ra các yêu c u ph n m m bên trong m t Element khác (Internal
Requirements)
Ta có th t o ra các yêu c u ph n m b 1 U ,
,… chỉ ra rằ ệm vụ t các yêu c
thực hiện việc này, ta thực hiệ :
 M h p tho i Properties của Element.
 Chọn Tab Require
 Nh p tên Requirement và các thu c tính của nó.
 Bấ R i
 N u muốn, bấ w t o ti p Internal Requirement khác cho Element,
ũ c thực hiện các thao tác quản lý khác ( sắp x p, s a, xóa )
 Bấ OK p tho i
 Chuy n yêu c u bên trong ra ngoài
 M h p tho i Properties của Element. Chọn Tab Require
 Chọn Requirement c n chuy n. Bấm Move External
 Trong h p tho i m ra, chọn package x R
 Quản lý các thu í bản của yêu c u:
Các thu bản của yêu c c quản lý trong EA:
 Tên
 Tr ng thái thực hiệ ( xuấ , , t, bắt bu , m
tra)
 khó

 Lo i yêu c u ( Ch g, hi n th , báo cáo, ki m th , …)
 Ghi chú
 Các thông tin khác
 Ghi chú các thông tin bổ sung
 S dụng thu c tính Note
 S dụ ố ng chú thích Note
 S dụng Tagged Values (lựa chọn, m c a s Tagged Values, t o ra các c p
Key – các thông tin b sung cho yêu c u )
 Xóa, sắp xếp các yêu c u
Thực hiện trong c a s Project Browser, thông qua các button trên toolbox ho c menu
ng cảnh.
 T o cấu trúc phân cấp cho yêu c u
Khi muốn chuy n 1 Requirement thành con của 1 Requirement khác, trong c a s
Project Browser, ta rê r i thả Requirement-con vào Requirement-cha.
 Với ch , xây dự c cấu trúc phân cấp cho Requirement: 1
requirement lớn có th bao g m nhi u Reqiurement nhỏ
 ố cho các Requirement:
Nháy phải vào package, chọn Show Level Numbering
 Kết xuấ à ă bản
 Lựa chọn Requirement c n k t xuất
 Vào menu, chọn Project | Documentation
 Lựa chọn lo i báo cáo phù h ( R x F ,H ,…)
 Trong h p tho i m ra, nh p các thông số c n thi t. Chú ý chọn Use
template là requirement template
…

CHƯƠNG IV. DUYỆT VÀ KIỂ ÁT CÁC YÊU CẦU PHẦN Ề

1.37 P bệ ệ K ử à
ả :
*K ( ): ệ
ằ x ủ ụ
ệ ự ệ :

 ụ ừ ọ
ủ ệ ố
 D ệ õ ệ ố ả
ủ ụ
:
• R
•U
•F ional Requirement
ụ ụ :
•D
•
• õ ụ

*
K ớ x x x
ớ ụ , ệ ự
ấ , ệ , ễ ụ ủ ệ ả
ụ ệ ự :
a. ố ớ ừ ố
a. ủ( )
b. Chính xác (Correct)
c. K ả thi ( feasible)
d. ( ))
e. X ọ (R f
and stability)
f. Rõ ràng.
g. ( f b )
b. ủ ệ ả ố
a. ủ
b. ( f b )
c. õ ( b )
d. ố ấ ( )
( ả ấ )

1.38 T ử .N ố
ử ô dụ à bế.
ả :
ệ b ệ
, ớ ắ ,
ệ ấ ủ ả R
ả ừ , ả
ệ ủ ọ
ố ụ :
- K
- K ắ
1.39 N x x .N à
à x x

ả :

 Quy trình xem xét:

o b ọ

o b

o b ọ ệ

o K

 ụ ụ , ẫ ụ

o Requirement Inspection Checklist

 ệ ( w):

o Các PTV –

o ệ ủ D( )

o ấ ả ủ ẽ
ự ệ : , …

1.40 P í dẫ ớ ổ

ng bên ngoài
 ỏi chúng ta phải giải quy t bài toán mới
 i ý ki n của họ
  i
 m t hệ thống mới t n t

ng bên trong
 Thất b i trong việc lấy yêu c u từ i dùng ( ấ ủ yêu c u từ
nhi i dùng)
 Thất b i trong việc t o m t quy trình thực hành giúp quản lý sự i yêu
c u ph n m m

1.41 N d ệ à

ả :
Vai trò:
ệ
ệ , ủ
ẫ ẫ bả b ừ ẽ
ố , ố ủ ẫ ,
ủ ẫ ừ ệ
bỏ b
ỏ ủ
ụ: bả ỏ ả
delete hay không?
ẫ ả b
ấ
ẫ ẽ ệ ả ự ụ
ố ệ ố
ệ ụ ẽ ấ

1.42 N ậ d ệ ô ì ệ ố ủ .C
d d ệ ô ì
ả :
ệ ố ố
ớ ố ụ ự
 ả ệ ả( ả)
ủ ệ ố :

 giải thích m i mô hình là phù h p

 N u có m t vài mô hình của hệ thố giải thích nh ng sự phù h p bên
trong và bên ngoài.
 giải thích rằng các mô hình có tính chính xác với các yêu c u thực của
nh b n hệ thố t việc rấ .

1.43 V ủ ử ấ ậ d ệ à

1.44 C ậ ử ấ ậ d ệ à

ả :
Các k thu t ki m th chấp nh n:
- Phát hiện l : c thực hiện và k t quả là th c n ki m tra. N u
k t quả , p tục thực hiệ b ng. M t ki m tra thất b i là triệu ch ng
của m t l i. Ki m th chấp nh n hiệu quả nhất n c dựa trên các tiêu chí
c l p với ch c th nghiệm và có th tính toán m ản
bi ớc k t quả.
- Ch i: Ki m th chấp nh x ỉ có
th nói rằ
- n l i: Ki m th chấp nh n t o ra rào cản không cho l i lan r ng.
- Che giấu l i: Ki m th chấp nh n che giấu m t giá tr xấu n u k t quả th l i ho c
thay th chính xác trong th ớc khi tuyên bố thất b i
- B ng l i: N u m ất b i trong ki m th chấp nh n có th
thay th bằng m ng h p dự phòng. N ng h p dự phòng thành công, có
th s dụ b ắ ng h b u
- S a l i:
- ------------------------------------------Ngu n--------------------------------------------------
----
- 4.3 Acceptance Test Techniques
- The fault detection mechanism used influences the remainder of the fault tolerance
activities (diagnosis, containment, masking, compensation, and recovery). The two
common mechanisms for fault detection are acceptance tests and comparison.
- 4.3.1 Fault Detection
-
- Acceptance tests are the more general fault detection mechanism in that they can be used
even if the system is composed of a single (non-redundant) processor. The program or
sub-program is executed and the result is subjected to a test. If the result passes the test,
execution continues normally. A failed acceptance test is a symptom of a fault. An
acceptance test is most effective if it is based on criteria that can be derived independently
of the function being tested and can be calculated more simply that the function being
tested (e.g., multiplication of a result by itself to verify the result of a square root
function).
- 4.3.2 Fault Diagnosis
-
- An acceptance test cannot generally be used to determine what has gone wrong. It can
only tell that something has gone wrong.
- 4.3.3 Fault Containment
-
- An acceptance test provides a barrier to the continued propagation of a fault. Further
execution of the program being tested is not allowed until some form of retry successfully
passes the acceptance test. If no alternatives pass the acceptance test, the subsystem fails,
preferably silently. The silent failure of faulty components allows the rest of the system to
continue in operation (where possible) without having to worry about erroneous output
from the faulty component [Schlichting 83].
- 4.3.4 Fault Masking
-
- An acceptance test successfully masks a bad value if a retry or alternate results in a new,
correct result within the time limit set for declaring failure.
- 4.3.5 Fault Compensation
-
- A program that fails an acceptance test can be replaced by an alternate, as described in the
next section. If the alternate passes the acceptance test, its result may be used to
compensate for the original result. Notice that the alternate program run during a retry
may be a very simple one that just outputs a "safe" value to compensate for the faulty
subsystem. A common approach in control systems is to "coast" the result by providing
the value calculated from the last known good cycle.
- 4.3.6 Fault Repair
-
- Acceptance tests are usually used in a construct known as a recovery block. A recovery
block provides backward fault recovery by rolling program execution back to the state
before the faulty function was executed. This repairs the faulty state and the result. When
a result fails an acceptance test, the program can be executed again before leaving the
recovery block. If the new result passes the acceptance test, it can be assumed that the
fault originally detected was transient. If the software is suspect, an alternative can be
executed in place of the original program fragment. If a single processor is used, the state
of the processor must be reset to the beginning of the function in question. A mechanism
called the recovery cache has been proposed to accomplish this [Anderson 76]. A
 recovery cache records the state of the processor at the entrance to each recovery block.
Although a recovery cache is best implemented in hardware, implementations to date have
been limited to experimental software. Where multiple processors are available, the retry
may take the form of starting the program on a backup processor and shutting down the
failed processor. Recovery blocks can be cascaded so that multiple alternatives can be
tried when an alternate result also fails the acceptance test.
- -------------------------------------------------------------------------------------------------------------
---
-

1.45 C ứ ă bả ủ A ờ d d ệ à
. ã ử dụ ế à BTL
ả :
õ b
toán, ả ý , ấ

Kiểm toán:

b EA. Nó
ủ ố, ,
ớ ớ ủ bệ

kích ho :
1. Từ menu chính b n chọn: View | Other Project Tools | Audit View,sẽ m ra:

2. B n chọn Audit Settings

 3. Nó sẽ m ra c a s Audit Settings :

4. Trong c a s Audit Settings b n thi t l p kích ho

hình vẽ trên.

ụ ớ y có Element List xem các tùy chọn thi t l p.c a s Output | Audit
History ấ ự ọ :
 x bằ bằ
ụ Audit View:

b ụ x ủ :
Projects and
Teams | Change Management | Tracking Changes | Auditing
Sử dụng đường cơ sở:
 , ấ ụ õ
y . Baseline Management
ủ ỳ
( , bả , x ự )
ớ ớ ệ ự ọ
b x ự bệ x
giúp:

Projects and Teams | Change Management | Tracking Changes | Package Baselines

Thay đổi yêu cầu và các vấn đề về yêu cầu ngoại

ủ b , ố ớ
x
ụ :

-Dùng Maintenance View , , ấ

ệ ụ ố
- ụ ố Issue " và " ớ

cái ụ ệ :
a.Sử dụng các Xem Bảo trì:
ụ ố ớ bấ ọ
gói. ấ danh sách cho:

ấ
ệ ụ
b ự b w w
ự ệ , ũ , ả,

Maintenance View ừ bằ ụ :
View | Other Element Tools | Maintenance or (Alt+4) . Hình ụ
ủ ệ :
 ệ ụ ả ý Y - ấ
-Y ố ớ bấ ỳ ố ệ

b)Sử dụng các yếu tố bảo trì cho Thay đổi và các vấn đề
ố bả ỡ ủ b ố ủ Issue và Change.
nh ng truy c p từ Toolbox | Maintenance ho c Toolbox | Custom
ả ố bằ ụ ố bấ ỳ
ố( ố ) ự ấ
:
- ố
b
-C ớ ố b
bằ ụ ố ệ
- ố ỉ ủ b

ọ ệ ụ ớ

D ớ ệ x Element List x ớ Relationship

ố ệ ự ọ :
1.46 K ử( )
ả :

K ệ ự ệ
ừ D, ủ ự … ắ ả
ự , ủ ũ

ệ ớ ủ
,ả ệ ố
, ừ
ý ấ , ỏ ả b
ụ ệ ố
Tại sao phải kiểm thử yêu cầu phần mềm:
- D ấ 2 ủ : ừ
ụ , ừ
- ụ ỏ ẳ

- D ấ ấ
trình viên
 - D ằ , ẽ ệ
õ
- ệ ừ ệ ố
ụ ừ ụ ố
- K ả
- ả õ

Tiêu chí kiểm thử yêu cầu phần mềm

- H ệ
- Chính xác
- K ả
-
- Rõ ràng
- K ,x

Quy trình kiểm thử yêu cầu phần mềm:

 Bussiness Requirement
 Use Case
 Functional Requirement
Các công cụ sử dụng:
 Dialog Map
 Test Case
 Ma õ ụ

CHƯƠNG V. CÁC KỸ THUẬT N NG CA CHẤT LƯỢNG YÊU CẦU PHẦN

Ề

1.47 N dõ ế ủ .

ả :
 2 õ :
o : ố ệ b ự
ụ: ố ệ
o K : ụ ố ệ ấ ớ Y
ố ệ ớ

 :(ừ – Pressman – p289)

x , bả õ bả
b ẽả ố ệ
ố ẽx ự ố bả õ :
 o Features traceability table: b ố ệ
ẽ ấ ả
o Source traceability table: X ủ ừ
o Dependency traceability table: b ố ệ ớ
o Subsystem traceability table: ệ ả

o Interface traceability table: b ố ệ ệ ủ

ệ ố ( ả ệ ệ ).

1.48 P í à ế .V ủ
ậ dõ ổ
ả :
Ma trận vết (theo dõi) yêu cầu phần mềm (Requirements Traceability Matrix - RTM)

Vai trò :
ụ ấ
ủ
ệ ố ( õ)
ệ ụ R ả ý ũ ệ
soát quy trình và quả ý ấ R ũ
ố ố ệ b ủ ự ả ố , ụ ả
x ấ
Thành ph :
 ệ ủ :
• ụ ( )
• (f )
• ( )
• ( )
• ( )

Các mối liên k t có th c phân chia:

• t-M t
• t-Nhi u
• u-Nhi u

Các d ng bi u diễn ma tr n:
• p bảng liên k t
• p ma tr n liên k t

1.49 K ậ ả ý ổ
ả :
 ?

- Nhân tố ngoài: Vấ i, D , ng thay

,…
- Nhân tố : ất b i trong việ ỏ ối
m trong suốt quá trình thu th p yêu c b u. Chúng ta
thất b i trong việc t o ra m t quá trình thích h tr giúp cho việc quản lý
i tron yêu c u ph n m m

ả ý :

1. Nh n th c rằng, sự i trong yêu c u ph n m m là không

th tránh khỏi và phải lên k hoach cho nó
2. V ch ra các yêu c .
3. Thi t l p m t kênh duy nhấ ki i.
4. S dụng m t hệ thống ki nắm bắt nh i
5. Quả ý i th b c.
Quản lý cấu hình yêu c u:
- ản các sự i trái phép và có khả ủy ho i tới
yêu c u
- các phiên bản tài liệu của yêu c u.
- T u kiện cho việc thu h i và/(ho c) xây dựng l i các phiên bản tài liệu
ớc.
- H tr quản lý, t ch c các chi bả cải ti n c p nh t hệ thống.
- n việc c p nh ng th i các tài liệu ho c các thông tin mẫu thuẫn
nhau.

1.50 í ấ
ả :
ủ ả x ấ ệ ủ ả
b
ụ ấ è ả
D: ệ ả, b , ả bả , ả …
b , , ố ố
ọ :
1. Khả bảo trì: có khả ực hiện nh ng ti n tri thỏa mãn yêu c u
của khách hàng.
 2. Khả y: bao g m hàng lo tin c , an toàn,
bảo m … n m m tin c y không th t o ra các thiệt h i v t chất hay kinh
t ng h ỏng.
3. h u hiệu: ph n m m không th phí ph m các ngu b
nhớ và các chu kỳ x lý.
4. Khả dụng: ph n m m nên có m t giao diệ ối dễ i
s dụ ủ các h ph n m m.
ấ
 Tính chính xác của yêu c u?
 Yêu c u có b l p l i hay không?
 Tính h p lý của yêu c u?

1.51 N dõ à ả bả

Trả lời:

1.52 N
ả :
*
K ớ x x x ớ
ụ , ệ ự ấ
, ệ , ễ ụ ủ ệ ả
ụ ệ ự :
c. ố ớ ừ ố
h. ủ( )
i. Chính xác (Correct)
j. K ả (f b )
k. ( ))
l. X ọ (R f
stability)
m. Rõ ràng.
n. Có t ( f b )
d. ủ ệ ả ố
e. ủ
f. ( f b )
 g. õ ( b )
h. ố ấ ( )
( ả ấ )
ả
ố ả

 Pseudocode (Giả ngôn ngữ)

 Finite state machines (máy trạng thái hữu hạn)
 Decision trees (Cây quyết định)
 Activity diagrams (flowcharts) (Biểu đồ hoạt động)
 Entity relationship models (Mô hình thực thể quan hệ)
 Object-oriented analysis (Phân tích hướng đối tượng)
 Structured analysis (Phân tích hướng cấu trúc)

ấ ng cho mô hình Use Case

ấ ng cho gói SRS
ất ng dự c tính chấ ng yêu c u ph n m m

1.53 C ứ ă ủ A ú dõ
ả :
õ
- ụ ấ
ủ ệ ố ụ õ
.
- ệ :
 ụ ( )
 (f )
 (design element)
 ( )
 ( )
- ố :
 –
  –
 –
- b ễ :
 bả

Quá trình lập ma trận:
- X ố ả
- ọ :
- ọ õ
- X
- X ụ ụ ự
- b ự
- K ự
ụ ệ (R x): R
x b ệ ố 2
1.54 C ứ ă ủ A ú ả ý ổ
ả :
a. Auditing
b
, , ớ
ớ ủ bệ ụ ệ
ủ
:
1. Từ menu chính chọn: View | Audit View, m
2. Chọn nút Audit Settings
3. c c a s Audit Settings:

4. Trong c a s Audit Settings check vào enable Auditing

ọ Ouput | Audit History ẽ

ọ
 ủ ủ ự b ố ụ w
b ệ ụ x ủ :
Help | Help Contents | Model Management | Auditing
b. Using Baselines
, ấ õ ụ ủ
ấ ố
ủ
( ụ , , bả x ự
ớ ệ ọ . ọ
b b x ự bệ,x :
Help | Help Contents | Model Management | Baselines, Diffirencing and Merges
c. Change Requests and Issues on External Requirements

ệ ự
ụ :
- S dụ w liệt kê nh i, khi m khuy t, vấ
và nhiệm vụ dựa theo m i nhân tố.
- S dụng nh ng nhân tố tự chọn của ki “ ” “ ” t với các
yêu c i

ụ ệ :
Using the Maintenance View
 w ụ ự bấ
ố ấ :
 Y u tố khi m khuy t
 Y u tố i
 Y u tố vấ
 Y u tố nhiệm vụ

b ự “b ”
, ũ , , ả
w ừ ụ : View |
Maintenance or (Alt+4)

ệ ụ ả ấ
bấ ố
Using Maintenance Elements for Changes and Issues
ố bả ủ ố :
ừ b x|
ố bả bằ ụ ố ớ bấ
ố ( ụ ) ấ
- Nh ng nhân tố trong gói ch a các yêu c u liên quan ho c
trong m t gói riêng biệt ch a m t t p nh ng sự i.
 - Chúng có th c liên k t tới nh ng nhân tố yêu c u trong bi thông
ng ho c s dụng ma tr n quan hệ.
- Nh ng nhân tố có th c tùy chỉ t ph n của m t h bao
g c tính m r ng.

ớ ọ ệ ụ ố ớ

D ớ ệ ớ
ệ ố ớ ấ ọ :
 N d bà ậ
1 ệ
2
3 X ự ệ ả
4 ệ
5 ấ