Bài giảng môn Công nghệ phần mềm - Chương 4: Quy trình xác định các yêu cầu

Bài giảng Công nghệ phần mềm - Chương 4: Quy trình xác định các yêu cầu, cung cấp cho người học những kiến thức như: Phân tích yêu cầu; Thẩm định yêu cầu; Một số phương pháp mô hình hóa; Làm bản mẫu trong phân tích;...Mời các bạn cùng tham khảo!

Kh¸i niÖm, tÇm quan träng

Gi¸ ph¶i tr¶ cho sù t×m vµ söa lçi

Qu¸ tr×nh h×nh thµnh yªu cÇu

Phân tích yêu cầu: các công đoạn

„ Xác định khách hàng, cùng khách hàng phát hiện các yêu cầu

„ Xây dựng mô hình phân tích (hiểu bài toán)

Khó khăn của phân tích

cầu

„ người phát triển phải chi tiết hóa thành các

yêu cầu phần mềm có thể phát triển được

„ người phát triển cần tỉnh táo để xác định đúng các yêu cầu (cái gì là cốt yếu, bền vững)

Khó khăn trong phân tích(t)

• Các yêu cầu thường mang tính đặc thù

- khó hiểu, khó định nghĩa

- không có chuẩn biểu diễn

• Hệ thống đa người sử dụng

- yêu cầu đa dạng, mức ưu tiên khác nhau

- yêu cầu mâu thuẫn nhau

Mục tiêu và yêu cầu

• Mục tiêu: là cái hướng tới

• Yêu cầu: là cái cụ thể kiểm tra được

chọn bằng menu"

nhiệm vụ của người phân tích là

xác định các yêu cầu

C¸c lo¹i yªu cÇu

m« t¶ mét chøc n¨ng (dÞch vô) cô thÓ

mµ phÇn mÒm cÇn cung cÊp

• Yªu cÇu phi chøc n¨ng

c¸c rµng buéc vÒ chÊt l−îng, vÒ m«i tr−êng,

• Yªu cÇu chøc n¨ng

Cã thÓ ph©n lo¹i yªu cÇu phÇn mÒm thµnh:

Yªu cÇu phi chøc n¨ng

• Yªu cÇu ngo¹i lai

TiÕn tr×nh ph©n tÝch yªu cÇu

Nguyªn lý ph©n tÝch 1

M« h×nh hãa miÒn th«ng tin

Ph¶i hiÓu vµ biÓu diÔn ®−îc miÒn th«ng tin

Nguyên lý phân tích 2

Mô hình hóa chức năng

Bản chất của phần mềm là biến đổi thông tin

„ định danh các chức năng (biến đổi thông tin)

„ xác định cách thức dữ liệu (thông tin) di chuyển

trong hệ thống (luồng dữ liệu)

„ xác định các tác nhân tạo dữ liệu và tác nhân tiêu

thụ dữ liệu (tác nhân)

Nguyên lý phân tích 3

Mô hình hóa hành vi

Phần mềm (hệ thống) có trạng thái (hành vi)

„ xác định các trạng thái của hệ thống

„ ví dụ: giao diện đồ họa, phần mềm điều khiển,…

„ xác định các dữ kiện làm thay đổi hành vi hệ thống

„ ví dụ: bàn phím, chuột, các cổng thông tin

Nguyên lý phân tích 5

Tim hiểu vấn đề bản chất

Ph−¬ng ph¸p thu thËp yªu cÇu

• Pháng vÊn

• Quan s¸t

• §iÒu tra b»ng b¶ng hái

• Nghiªn cøu tµi liÖu

• Joint Application Design - JAD

Các mức trừu tượng của yêu cầu

Yêu cầu nên được biểu diễn ở nhiều mức trừu tượng khác nhau

Có nhiều đối tượng người đọc:

• người sử dụng

• nhà quản lý

• lập trình viên

C¸c møc trõu t−îng cña yªu cÇu

• tµi liÖu cã cÊu tróc

• m« t¶ chi tiÕt, chÝnh x¸c vÒ yªu cÇu

VÝ dô: chøc n¨ng kiÓm tra chÝnh t¶

§Þnh nghÜa: th«ng b¸o c¸c lçi chÝnh t¶ cña v¨n b¶n

Đòi hỏi đối với đặc tả yêu cầu

• Tính đầy đủ

• Tính không được mâu thuẫn lẫn nhau

- mọi yêu cầu của người dùng phải được mô tả

• Tính chính xác: yêu cầu không được mơ hồ

- người phát triển sẽ làm cái nhỏ nhất

- chi phí phát sinh do sửa đổi yêu cầu rất cao

Thẩm định yêu cầu

1 Thỏa mãn được nhu cầu của người dùng

2 Yêu cầu không mâu thuẫn nhau

3 Yêu cầu phải đầy đủ (chức năng; ràng buộc)

4 Yêu cầu phải hiện thực

Nội dung cần thẩm định đặc tả yêu cầu:

Quan hÖ gi÷a ph©n tÝch vµ thiÕt kÕ

• Ph©n tÝch chØ nªn ®−a ra gi¶ sö tèi thiÓu

vÒ thiÕt kÕ hÖ thèng

• Yªu cÇu ph¶i kh«ng m©u thuÉn víi kü thuËt

m¸y tÝnh vµ tµi nguyªn hiÖn cã

Ví dụ: Biểu đồ phân rã chức năng

Biểu đồ luồng dữ liệu

Data Flow Diagram - DFD

DFD: Khái niệm

Tác nhân ngoài:

- đối t−ợng bên ngoài hệ thống

- phát sinh hoặc tiếp nhận thông tin

Luồng dữ liệu:

- luồng thông tin di chuyển trong hệ thống

DFD: Ký ph¸p

t¸c nh©n tiÕn tr×nhluång d÷ liÖukho d÷ liÖu

Cã nhiÒu c¸ch biÓu diÔn kh¸c nhau

DFD - C¸c b−íc x©y dùng

• Ph©n r· chøc n¨ng hÖ thèng

• LiÖt kª c¸c t¸c nh©n, c¸c kho¶n môc d÷ liÖu

• VÏ DFD cho c¸c møc

DFD – Mét sè nguyªn t¾c

• C¸c tiÕn tr×nh ph¶i cã luång vµo vµ luång ra

• Kh«ng cã luång d÷ liÖu trùc tiÕp gi÷a t¸c nh©nvíi t¸c nh©n hay kho d÷ liÖu

• Luång d÷ liÖu kh«ng quay l¹i n¬i xuÊt ph¸t

• B¾t ®Çu b»ng DFD møc 0, liÖt kª c¸c t¸c

nh©n ngoµi ë møc 0

DFD møc 1

Ph©n tÝch yªu cÇu

KiÓm tra giê tÇu

Ph¸t hµnh kh¸ch hµng

TÇm quan träng cña E-R

E-R: định nghĩa

Thực thể:

- là các đối tượng thế giới thực mà chúng ta

muốn xử lý

- có thể là đối tượng thực hoặc trừu tượng

Thuộc tính: đặc điểm của thực thể

Quan hệ:

- mối liên hệ giữa các thực thể

- là thông tin cần lưu trữ/xử lý

E-R: Ví dụ

sinh viên

địa chỉ

Lùc l−îng tham gia quan hÖ

object relationship object

E-R: Xác định thực thể và quan hệ

Thực thể:

- là các danh từ (trong câu mô tả yêu cầu)

- có các thuộc tính khóa (xác định duy nhất)

Quan hệ:

- hoạt động xẩy ra giữa các thực thể

- có nghĩa với hoạt động của hệ thống

- là động từ

Tõ ®iÓn d÷ liÖu

m« t¶ d÷ liÖu mµ hÖ thèng xö lý

miÒn gi¸ trÞ cña chóng (vd on/off)

c¸ch thøc xö lý d÷ liÖu

(CASE)

Kho¶n môc tõ ®iÓn d÷ liÖu

VÝ dô tõ ®iÓn d÷ liÖu

telephone number integrated office

phone system

Name:

Aliases:

Where/How used:

Description:

telephone number phone number, number read-phone-number (input) display-phone-number (output) analyze-long-distance-calls (input)

telephone no = [ local extension | outside no | 0 ] outside no = 9 + [ service code | domestic no ] service code = [ 211 | 411 | 611 | 911 ]

Build the requirements dictionary:

system output

2.3 Làm bản mẫu trong phân tích

Trong nhiều trường hợp, mô hình chạy thử là

phương pháp duy nhất để xác định yêu cầu

phần mềm lớn, phức tạp

bản mẫu (= trực quan)Các loại bản mẫu:

Các bước làm bản mẫu

Bước 1: Đánh giá yêu cầu và xác định

có nên làm bản mẫu không

Bước 2: Biểu diễn vắn tắt yêu cầu

yêu cầu chức năng/yêu cầu phi chức năng

Bước 3: Thiết kế nhanh

kiến trúc, cấu trúc dữ liệu

độ phức tạp, chủng loại, khách hàng

¦u ®iÓm

• Lo¹i bít hiÓu nhÇm

• Ph¸t hiÖn thiÕu hôt chøc n¨ng

• Ph¸t hiÖn c¸c ®iÓm yÕu:

• KiÓm tra tÝnh kh¶ thi/h÷u Ých

vd: so¹n th¶o kÐo theo kiÓm tra chÝnh t¶

- khã sö dông,

- thao t¸c kh«ng an toµn

- cã thÓ x©y dùng ®−îc kh«ng

Ưu điểm (t)

• Làm cơ sở cho đặc tả

• Huấn luyện người sử dụng

• Hỗ trợ kiểm thử (so sánh kết quả)

làm phần mềm giống như thế này, nhưng tốt hơn

Nhược điểm của bản mẫu

• Các yêu cầu phi chức năng thường không được thể hiện đầy đủ

• Làm tăng chi phí: cần phải ước lượng chính xácchi phí của bản mẫu

• Các yêu cầu thay đổi quá nhanh khiến bản mẫutrở nên vô nghĩa

• Người dùng không dùng bản mẫu theo cách

B¶n mÉu giao diÖn/ b¶n mÉu trùc quan

„ VB

„ Delphi, J Builder

„ FrontPage

cña nhiÒu nhãm, khã b¶o tr×

- có nhiều cách biểu diễn cho một khái niệm

khó phân hoạch, khó sửa đổi

§Æc t¶ h×nh thøc

<unsigned number> ::= <unsigned integer> | <unsigned real>

<unsigned integer> ::= <digit> {<digit>}

<unsigned real> ::= <unsigned integer> <digit> {<digit>} |

<unsigned integer> <digit> {<digit>} E <scale factor> |

<unsigned integer> E <scale factor>

<scale factor> ::= <unsigned integer> | <sign> <unsigned integer>

unsigned number

Đặc tả hình thức (t)

• Ưu điểm

tính chính xác (duy nhất) của định nghĩa

• Nh−ợc điểm

- khó hiểu, tốn thời gian mô tả

- không áp dụng đ−ợc với mọi bài toán

(các yêu cầu phi chức năng)

đúng đắn???

DFD, E-R, UML

võa dïng cho ph©n tÝch, võa h−íng tíi thiÕt kÕ

2.5 Tµi liÖu yªu cÇu

§Þnh d¹ng cña tµi liÖu yªu cÇu

Software Requirement Specification-SRS

định dạng của tài liệu yêu cầu (SRS)

1 Giới thiệu

1.1 Mục đích

1.2 Phạm vi

1.3 Định nghĩa (định nghĩa, từ viết tắt)

1.4 Tài liệu tham khảo

1.5 Mô tả cấu trúc tài liệu

2.5 Giả thiết và sự lệ thuộc

định dạng của tài liệu yêu cầu (SRS)

3 Yêu cầu chi tiết

3.1 Yêu cầu chức năng

3.1.1 Yêu cầu chức năng 13.1.1.1 Giới thiệu

3.1.1.2 Dữ liệu vào3.1.1.3 Xử lí

3.1.1.4 Kết quả

định dạng của tài liệu yêu cầu (SRS)

3 Yêu cầu chi tiết

…

3.2 Yêu cầu giao diện ngoài

3.2.1 Giao diện người dùng3.2.2 Giao diện phần cứng3.2.3 Giao diện phần mềm3.2.4 Giao diện truyền thông3.3 Yêu cầu hiệu suất

định dạng của tài liệu yêu cầu (SRS)

3 Yªu cÇu chi tiÕt

1 Ph©n tÝch yªu cÇu nghÜa lµ g×?

2 Môc tiªu cña ph©n tÝch yªu cÇu lµ g×?

3 C¸c c«ng ®o¹n cña tiÕn tr×nh ph©n tÝch yªu cÇu?

4 Nhøng khã kh¨n cña ph©n tÝch yªu cÇu?

5 Cã nh÷ng lo¹i yªu cÇu nµo?

6 Nªu nh÷ng yªu cÇu phi chøc n¨ng?

C©u hái «n tËp

8 Nêu các phương pháp thu thập thông tin về

yêu cầu?

9 Đặc tả yêu cầu cần có những tính chất gì?

10 Nội dung cần thẩm định yêu cầu là gì?

11.Các phương pháp mô hình hoá để phân tích

yêu cầu là những phương pháp nào?

Câu hỏi ôn tập

12.Phương pháp làm mẫu để xác định yêu cầu

có những ưu và nhược điểm gi ?

13.Những ngôn ngữ nào được dùng làm mẫu?

14 Có những loại phương pháp đặc tả nào?

Mô tả tóm tắt nội dung của nó?

15 Trình bày nội dung đặc tả yêu cầu theo chuẩn

IEEE 843-1984?

Câu hỏi ôn tập