Bài giảng Phân tích yêu cầu phần mềm

TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM VÀ QUY TRÌNH .... PHÁT HIỆN, TỔNG HỢP VÀ PHÂN TÍCH CÁC YÊU CẦU PHẦN MỀM ..... DUYỆT VÀ KIỂM SOÁT CÁC YÊU CẦU PHẦN MỀM ..... CÁC KỸ THUẬT NÂNG CAO CHẤT LƯỢNG

M ục Lục

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

5 1.1

Hãy nêu bản chất của yêu c u ph n m m 5 1.2

Nêu u ph n m m nhìn từ phía khách hàng 5 1.3

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.4

ấ ủ ệ ấ 6 1.5

ủ ừ 7 1.6

Mô t ả Quy trình công nghệ học yêu c u ph n m m (Requirement Engineering Process) 8 1.7

ủ ừ ủ 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

ệ ố 11 1.9

ệ 12 1.10

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.11

Trình bày quy trình th ực hiệ ( b ớ ), m và nh ng k thu x nh yêu 1.12

c u ph n m m Phỏng vấn (interview) 14 Trình bày quy trình th ực hiệ ( b ớ ), m và nh ng k thu x nh yêu 1.13

c u ph n m m H i thảo 15 Trình bày quy trình th ực hiệ ( b ớ ), m và nh ng k thu x nh yêu 1.14

c u ph n m m Brainstorming 16 Trình bày quy trình th ực hiệ ( b ớ ), m và nh ng k thu x nh yêu 1.15

c u ph n m m Storyboarding 17 Trình bày quy trình th ực hiệ ( b ớ ), m và nh ng k thu x nh yêu 1.16

c u ph n m m Áp dụng Usecase 17 Trình bày quy trình th ực hiệ ( b ớ ), m và nh ng k thu x nh yêu 1.17

c u ph n m m Prototyping 19

ụ ủ 1.18

ả 20 ( b ủ 1.19

b ỏ ệ 1.22

tiêu ch ấ , ự ệ 23

ủ ụ 1.23

trong BTL 24 HƯƠ G ẶC T CÁC YÊU CẦU PHẦN MỀM 25

Nêu các yêu c u củ c tả các yêu c u ph n m m 25 1.24

Nêu khái ni ệm và thành ph n củ c tả yêu c u ph n m m 25 1.25

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.26

Trong c ấu trúc củ c tả yêu c u ph n m m (SRS) System Requirement và Software

1.27

R c hi c tả v trí nào trong tài liệu SRS 28 Nêu các k thu t vi c tả yêu c u ph n m m 28 1.28

ủ ừ ấ ệ 31 1.29

ủ ả ệ ố ả 33 1.30

ả ả 1.31

ả ệ 33

ả ả 1.32

ả ệ 40

ấ ệ ả 41 1.33

ủ ừ x x ( ệ ) ệ ả 1.34

42

ủ ụ 1.35

trong BTL 43

ủ x ự ả ụ 1.36

trong BTL 50

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

Phân bi ệt các khái niệm Ki m th u ph n m m 52 1.37

T i sao c n ki m th u ph n m m Nêu tên m t số m th 1.38

yêu c u ph n m m thông dụng mà em bi t 53

x x x x 1.39

54

ẫ ớ 54 1.40

ệ 55 1.41

ệ ệ ố ủ ệ 1.42

55

ủ ấ ệ 56 1.43

ấ ệ 56

1.44 bả ủ ệ

1.45 ụ 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

Ki m th (testing) yêu c u ph n m m 63

1.46 CHƯƠNG V CÁC KỸ THUẬT NÂNG CAO CHẤT LƯỢNG YÊU CẦU PHẦN MỀM 64

õ t của yêu c u ph n m m 64

1.47 ủ

1.48 õ 65

K thu t quả ý i yêu c u ph n m m 66

1.49 u ph n m m theo các thu c tính chấ ng ph n m m 67

1.50 õ u ph n m ảm bảo các yêu c u ph n m m 68

1.51 u ph n m m 68

1.52 ủ õ 69

1.53 ủ ả ý 71 1.54

ệ ố

 J (1994) : b ủ ụ ự

 w (1997): Y ủ ụ ả

ả ả ả ả

ủ ệ ố ủ ệ ố

N ì ừ í à

1.3

ả :

ừ :

bắ x ự

T ó ô ố :

 ự ủ , ự

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

ả

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)

 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ụ

- 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

ự ẫ 1997

ừ ụ ,

bả ố ấ 2 b :

b quan

ự ,

ả

ự , ố

ệ , ả

ả xác

G , case chính xác, là

ự ,

ẫ

chính xác

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

T ì bà ì ự ệ ( b ớ ), à ậ

1.12

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ả ỏ

ắ

 ừ o

 Ch c k 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

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

- ý : ý , ọ ọ , , , , ỉ ý

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

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

ụ:

ẫ ụ ẫ ừ ớ

- 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

T ì bà b ớ ( ì ) P í

1.20

ả :

- Phân lo i các yêu c u ph n m m:

- ọ ,

ả ý ớ b , ự

ự ỏ ệ ý ố ọ ố

7 ự ( ntity relationship models)

8 ớ ố (Obj -oriented analysis)

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

 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

C ứ ă ủ A í ã

1.23

ử 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

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

- 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

- Non-functional Requirements (yêu c u phi ch )

- Supplementary Documentation (tài liệu b sung)

- 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

ớ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

2

ố , ệ ả ố ệ ủ 1 óm

ệ ố ả ớ , ẳ ệ ừ

ụ ừ b b ,

ủ ả ự ệ

ụ (F ) niên

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