Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)

• 1. Tổng quan về yêu cầu phần mềm

• 2. Quy trình xác định yêu cầu phần mềm

• 3. Phương pháp và công cụ đặc tả yêu cầu

phần mềm

• 4. Nguyên lý phân tích yêu cầu sử dụng

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 1

Trang 1

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 2

Trang 2

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 3

Trang 3

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 4

Trang 4

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 5

Trang 5

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 6

Trang 6

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 7

Trang 7

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 8

Trang 8

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 9

Trang 9

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering) trang 10

Trang 10

Tải về để xem bản đầy đủ

pdf 12 trang xuanhieu 8400
Bạn đang xem 10 trang mẫu của tài liệu "Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

Tóm tắt nội dung tài liệu: Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)

Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering) - Chương 6: Kỹ nghệ yêu cầu phần mềm (Requirement Engineering)
 các yêu cầu phần mềm (Requirements 
 elicitation)
 – Các yêu cầu về phần mềm (Software)
 • Phân tích các yêu cầu phần mềm và thương lượng với
 – Các yêu cầu về phần cứng (Hardware) khách hàng (Requirements analysis and negotiation)
 – Các yêu cầu về dữ liệu (Data) • Đặc tả các yêu cầu phần mềm (Requirements 
 – Các yêu cầu về con người (People, Users) specification)
 • Mô hình hóa hệ thống (System modeling)
 • Theo cách đặc tả phần mềm • Kiểm tra tính hợp lý của các yêu cầu phần mềm
 – Các yêu cầu chức năng (Requirements validation)
 – Các yêu cầu ngoài chức năng • Quản trị các yêu cầu phần mềm (Requirements 
 management)
 – Các ràng buộc khác
 5 6
5 6
 Quy trình xác định yêu cầu PM (tiếp) Phát hiện yêu cầu phần mềm
 Xây dựng • Đánh giá tính khả thi về kỹ thuật và nghiệp vụ 
 một nguyên mẫu
 (prototype) của phần mềm định phát triển
 • Tìm kiếm các nhân sự (chuyên gia, người 
 sử dụng) có những hiểu biết sâu sắc nhất, 
 Xác định Phát triển chi tiết nhất về hệ thống giúp chúng ta xác 
 Vấn đề Xem
 yêu cầu đặc điểm kỹ thuật duyệt định yêu cầu phần mềm 
 • Xác định môi trường kỹ thuật trong đó sẽ 
 triển khai phần mềm
 Tạo ra
 mô hình • Xác định các ràng buộc về lĩnh vực ứng dụng 
 phân tích của phần mềm (giới hạn về chức năng/hiệu 
 năng phần mềm)
 Last Update8-07  Dept. of SE, 2002 SE-III.7 8
7 8
 Đầu ra của bước phát hiện yêu cầu 
 Phát hiện yêu cầu phần mềm
 phần mềm
 • Xác định các phương pháp sử dụng để phát hiện • Bảng kê (statement) các đòi hỏi và chức năng khả thi 
 các yêu cầu phần mềm: phỏng vấn, làm việc của phần mềm
 nhóm, các buổi họp, gặp gỡ đối tác, v.v. • Bảng kê phạm vi ứng dụng của phần mềm
 • Thu hút sự tham gia của nhiều chuyên gia, khách • Mô tả môi trường kỹ thuật của phần mềm
 hàng để chúng ta có được các quan điểm xem xét • Bảng kê tập hợp các kịch bản sử dụng của phần mềm
 phần mềm khác nhau từ phía khách hàng
 • Các nguyên mẫu xây dựng, phát triển hay sử dụng 
 • Xác định các yêu cầu còn nhập nhằng để làm mẫu trong phần mềm (nếu có)
 thử
 • Danh sách nhân sự tham gia vào quá trình phát hiện 
 • Thiết kế các kịch bản sử dụng của phần mềm để 
 các yêu cầu phần mềm - kể cả các nhân sự từ phía công 
 giúp khách hàng định rõ các yêu cầu chính. ty- khách hàng 
 9 10
9 10
 Phân tích các yêu cầu PM và Phân tích các yêu cầu phần mềm và 
 thương lượng với khách hàng thương lượng với khách hàng
 Phân tích
 Cần Nhất quán + Khả
 thiết ?
 hàng đầy đủ ? thi ?
 công
 ph ầ n
 khách
 Nhóm
 Nhóm ngh ệ m m ề
 Yêu cầu không cần Yêu cầu không đầy đủ, Yêu cầu không khả
 thiết yêu cầu mâu thuẫn thi
 Thương lượng
 Thảo luận Đặt thứ tự ưu Nhất trí
 về các tiên cho các yêu về các
 yêu cầu cầu yêu cầu
 11 12
11 12
 Phân tích các yêu cầu phần mềm và Phân tích các yêu cầu phần mềm và 
 thương lượng với khách hàng thương lượng với khách hàng
 • Phân loại các yêu cầu phần mềm và sắp xếp chúng theo • Thẩm định các rủi ro có thể xảy ra với từng yêu
 các nhóm liên quan
 cầu phần mềm
 • Khảo sát tỉ mỉ từng yêu cầu phần mềm trong mối quan
 hệ của nó với các yêu cầu phần mềm khác • Đánh giá thô (tương đối) về giá thành và thời gian
 • Thẩm định từng yêu cầu phần mềm theo các tính chất: thực hiện của từng yêu cầu phần mềm trong giá
 phù hợp, đầy đủ, rõ ràng, không trùng lặp
 thành sản phẩm phần mềm và thời gian thực
 • Phân cấp các yêu cầu phần mềm theo dựa trên nhu cầu
 và đòi hỏi khách hàng / người sử dụng hiện phần mềm
 • Thẩm định từng yêu cầu phần mềm để xác định: • Giải quyết tất cả các bất đồng về yêu cầu phần
 – Các yêu cầu PM có khả năng thực hiện được trong môi
 trường kỹ thuật hay không mềm với khách hàng / người sử dụng trên cơ sở
 – Có khả năng kiểm định các yêu cầu phần mềm hay không thảo luận và thương lượng các yêu cầu đề ra
 13 14
13 14
 Đặc tả yêu cầu phần mềm Ví dụ: Các yêu cầu về hồ sơ đặc tả
 • Đặc tả các yêu cầu phần mềm: xây dựng các tài liệu đặc tả, trong đó
 có thể sử dụng tới các công cụ như: mô hình hóa, mô hình toán học • Đặc tả hành vi bên ngoài của HT 
 hình thức (a formal mathematical model), tập hợp các kịch bản sử
 dụng, các nguyên mẫu hoặc bất kỳ một tổ hợp các công cụ nói trên • Đặc tả các ràng buộc về cài đặt 
 • Phương pháp đặc tả: 
 – Đặc tả phi hình thức (Informal specifications): viết bằng ngôn ngữ tự • Dễ thay đổi 
 nhiên
 – Đặc tả hình thức (Formal specifications): viết bằng tập các ký pháp có • Dùng như công cụ tham khảo cho bảo trì 
 các quy định về cú pháp (syntax) và ngữ nghĩa (sematic) rất chặt chẽ, 
 thí dụ ký pháp đồ họa dùng các lưu đồ. • Sự ghi chép cẩn thận về vòng đời của HT, 
 • Tiêu chí đánh giá chất lượng của hồ sơ đặc tả:
 – Tính rõ ràng, chính xác nghĩa là dự đoán các thay đổi
 – Tính phù hợp
 – Tính đầy đủ, hoàn thiện • Các đáp ứng với các sự cố không mong đợi
 15 16
15 16
 Các thành phần của hồ sơ đặc tả Đặc tả chức năng
 • Đặc tả vận hành hay đặc tả chức năng (Operational specifications): • Miêu tả các chức năng của hệ thống, phụ thuộc vào
 mô tả các hoạt động của hệ thống phần mềm sẽ xây dựng: kiểu phần mềm và mong đợi của người dùng
 – Các dịch vụ mà hệ thống phải cung cấp –
 – Hệ thống sẽ phản ứng với đầu vào cụ thể ra sao Tương tác giữa phần mềm và môi trường, độc lập với việc
 – Hành vi của hệ thống trong các tình huống đặc biệt. cài đặt
 • Đặc tả mô tả hay đặc tả phi chức năng (Descriptive – Ví dụ: Hệ thống đồng hồ phải hiển thị thời gian dựa trên vị
 specifications): đặc tả các đặc tính, đặc trưng của phần mềm: trí của nó
 – Các ràng buộc về các dịch vụ hay các chức năng hệ thống cung • Các công cụ đặc tả tiêu biểu:
 cấp như thời gian, ràng buộc về các quá trình phát triển, các 
 chuẩn, – Biểu đồ luồng dữ liệu (Data Flow Diagrams)
 • Ngoài ra còn có yêu cầu về lĩnh vực, bắt nguồn từ lĩnh vực – Máy trạng thái hữu hạn (Finite State Machines)
 của ứng dụng hệ thống và các đặc trưng của lĩnh vực này. – Mạng Petri (Petri nets),
 – Tuy nhiên không bắt buộc và có thể dùng ngôn ngữ tự
 nhiên.
 17 18
17 18
 Đặc tả phi chức năng và ràng buộc Tài liệu yêu cầu
 • Yêu cầu phi chức năng: Định nghĩa các khía cạnh sử dụng phần mềm, 
 không liên quan trực tiếp tới các hành vi chức năng: • Tài liệu về yêu cầu là các phát biểu chính thức 
 – Các tính chất của hệ thống như độ tin cậy, thời gian trả lời, dung lượng bộ
 nhớ,  về cái được yêu cầu bởi các nhà phát triển HT 
 • Thời gian trả lời phải nhỏ hơn 1 giây
 • Ràng buộc: do khách hàng hay môi trường thực thi phần mềm đặt ra • Nó bao gồm cả 2 phần: định nghĩa và đặc tả 
 – Các yêu cầu do tổ chức qui định như qui định chuẩn về quá trình tiến hành, 
 chuẩn tài liệu,  yêu cầu
 • Ngôn ngữ cài đặt phải là COBOL
 – Các yêu cầu từ bên ngoài • Nó không phải là tài liệu thiết kế. Tốt hơn có 
 • Phải giao tiếp với hệ thống điều phối được viết vào năm 1956.
 • Thường sử dụng các công cụ thể nó chỉ là 1 tập các cái mà HT phải làm hơn 
 – Biểu đồ thực thể liên kết (Entity-Relationship Diagrams)
 – Đặc tả Logic (Logic Specifications) là HT phải làm thế nào (PT chứ không phải là 
 – Đặc tả đại số (Algebraic Specifications) TK) 
 à Khó phát biểu chính xác, Rất khó kiểm tra
 19 20
19 20
 3. Phương pháp và công cụ đặc tả yêu
 Nội dung cần có của tài liệu yêu cầu
 cầu phần mềm
 Xác định các yêu cầu, đọc hiểu để kiểm tra
 Khách hàng hệ thống xem có đúng với nhu cầu hay không. Họ xác • Biểu đồ phân cấp chức năng - WBS (work 
 định các thay đổi về yêu cầu.
 break down structure)
 Sử dụng tài liệu về yêu cầu để lên kế hoạch
 Nhà quản lý đấu thầu cho hệ thống và lên kế hoạch cho • Biểu đồ luồng dữ liệu – DFD (data flow 
 quá trình phát triển hệ thống diagram)
 Sử dụng yêu cầu để hiểu về hệ thống sẽ phát
 Kỹ sư hệ thống •
 triển Máy trạng thái – FSM (Finite state machine)
 Sử dụng yêu cầu để phát triển các trường hợp • Sơ đồ thực thể liên kết – ERD (entity relation 
 Kỹ sư kiểm thử hệ thống
 kiểm thử cho hệ thống diagram)
 Sử dụng yêu cầu để hiểu về hệ thống và mối
 Kỹ sư bảo trì hệ thống
 liên hệ giữa các phấn khác nhau của hệ thống
 21 22
21 22
 Ví dụ: mô tả biểu thức toán học bằng
 Đặc tả chức năng với DFD
 DFD
 • Hệ thống (System): tập hợp các dữ liệu (data) được xử (a+b)*(c+a*d)-e*(a+b)
 lý bằng các chức năng tương ứng (functions)
 • Các ký pháp sử dụng:
 b c
 a d
 a
 Thể hiện các chức năng (functions)
 + * +
 Thể hiện luồng dữ liệu
 Kho dữ liệu *
 Vào ra dữ liệu và tương tác giữa
 hệ thống và người sử dụng
 23 24
23 24
 Ví dụ đặc tả các chức năng của thư 
 Các hạn chế của DFD
 viện qua DFD
 Yêu cầu từ người mượn
 • Ý nghĩa của các ký pháp sử dụng được xác định
 Sách Tên sách, tác giả
 Tên người mượn
 Kho sách bởi các định danh lựa chọn của NSD
 Sách •
 Tên tác giả Ví dụ: DFD của chức năng tìm kiếm sách:
 Có If NSD nhập vào cả tên tác giả và tiêu đề sách Then 
 Danh sách tác giả sách Thông tin 
 về sách tìm kiếm sách tương ứng, không có thì thông báo lỗi
 Tên sách Tên sách;
 Danh sách tên sách Tên người mượn Elseif chỉ nhập tên tác giả Then
 Danh sách người mượn hiển thị danh sách các sách tương ứng với
 Danh sách chủ đề Tìm theo Liệt kê các tên sách tên tác giả đã nhập và yêu cầu NSD lựa chọn sách
 chủ đề liên quan đến chủ đề Elseif chỉ nhập tiêu đề sách Then
 Chủ đề
 . . .
 Chủ đề yêu cầu Đưa ra 
 Tên sách Endif
 25 26
25 26
 Các hạn chế của DFD Các hạn chế của DFD
 • Trong DFD không xác định rõ các • Chức năng D có thể cần cả A, B và
 C • DFD không xác định sự đồng bộ giữa các chức 
 hướng thực hiện (control aspects)
 • Chức năng D có thể chỉ cần một
 trong A, B và C để thực hiện năng / mô-đun
 A • Chức năng D có thể kết xuất kết –
 E quả cho một trong E và F A xử lý dữ liệu và B được hưởng (nhận) các kết 
 B D • Chức năng D có thể kết xuất kết quả được xử lý từ A
 F quả chung cho cả E và F
 C • Chức năng D có thể kết xuất kết – A và B là các chức năng không đồng bộ 
 quả riêng cho cả E và F (asynchronous activities) vì thế cần có buffer để 
 • Biểu đồ DFD này không chỉ rõ đầu ngăn chặn tình trang mất dữ liệu
 vào là gì để thực hiện chức năng
 D và đầu ra là gì sau khi thực hiện
 A B
 chức năng D.
 27 28
27 28
 Đặc tả trạng thái với FSM - Finite 
 Ví dụ: quản lý thư viện
 State Machines 
 • FSM chứa • Xét các giao dịch:
 – Tập hữu hạn các trạng thái Q – Mượn sách / Trả sách
 – Tập hữu hạn các đầu vào I – Thêm đầu sách / Loại bỏ đầu sách
 – Các chức năng chuyển tiếp – Liệt kê danh sách các đầu sách theo tên tác giả
 • δ : Q x I à Q hay theo chủ đề
 Báo động áp lực cao – Tìm kiếm sách theo các yêu cầu của người mượn
 – Tìm kiếm sách quá hạn trả, . . .
 Báo động nhiệt độ cao
 ON OFF
 Khởi động lại 29 30
29 30
 Đặc tả yêu cầu Đặc tả các đối tượng
 • Độc giả không được mượn quá một số lượng • Các đối tượng:
 sách nhất định, trong một thời gian nhất định – Tên sách
 • Một số sách không được mượn về – Mã quyển
 – Nhân viên phục vụ
 • Một số người không được mượn một số loại 
 – Người mượn
 sách nào đó, . . .
 • Cần có: 
 – tập hợp (danh sách) các tiêu đề sách
 – danh sách các tác giả cho từng quyển sách, 
 – danh sách các chủ đề liên quan của các quyển sách
 31 32
31 32
 Đặc tả dữ liệu với 
 FSM đặc tả trạng thái
 Mô hình thực thể liên kết -ERD
 • Ta có tập hợp các sách (mỗi đầu sách có thể có
 nhiều quyển sách trong thư viện). • Mô hình khái niệm cho phép đặc tả các yêu
 • Mỗi quyển sách có thể có 1 trong 5 trạng thái cầu logic của hệ thống, thường được sử dụng
 sau: trong các hệ thống dữ liệu lớn
 – (AV) Available: được phép mượn, • ER Model
 – (CO) - (BR): đã mượn (Check Out; Borrow), – Thực thể
 – (L): Last, CO AV BR – Quan hệ
 – (R): Remove – Thuộc tính
 • Biểu đồ thực thể
 L R
 Có thể có hạn chế về số sách được mượn cho 1 nhóm độc giả hoặc mọi độc giả, . . . 33 34
33 34
 Thực thể Thuộc tính
 • Tính chất của một thực thể hoặc một đối
 • Thực thể : tập hợp các thông tin liên quan cần
 tượng dữ liệu
 được xử lý trong phần mềm
 – đặt tên cho 1 mẫu (instance) của đối tượng dữ liệu
 • Thực thể có thể có mối quan hệ: – mô tả mẫu (instance)
 – người sở hữu ôtô – tạo liên kết (reference) đến các mẫu khác
 Người sở hữu Ôtô Ford Automobile 
 Company
 Car Blue
 Ford
 ID
 • Thực thể có các thuộc tính Tập các thuộc tính của 1 đối tượng dữ liệu được xác định thông
 qua ngữ cảnh của bài toán.
 35 36
35 36
 Quan hệ Ví dụ: ERD mô tả thư viện
 Area
 • Chỉ ra mối liên quan gữa các đối tượng dữ liệu
 N
 1 N Deals 
 Bookstore Orders Books
 with Belongs to Copy
 1
 Ø Cardinality : chỉ ra định lượng của mối quan hệ N N
 Title
 1:1 one-to-one 1:N one-to-many M:N many-to-many state
 Ø Modality : 0 – có thể có, có thể không có quan hệ Was 
 Text holds held 
 Written by
 1 – bắt buộc có quan hệ by
 1 M
 1 Is N Author
 Customer provided Repair Action Borrower
 with limit
 37 38
37 38
 So sánh Thế nào là một đặc tả tốt? 
 DFD FSM ERD
 • Dễ hiểu với người dùng
 Đơn giản, dễ hiểu. Có thể phức tạp với số Đơn giản, dễ hiểu
 lượng trạng thái lớn • Có ít điều nhập nhằng
 Mô tả trạng thái của thực •
 Mô tả luồng dữ liệu thể Mô tả trừu tượng cơ sở Có ít quy ước khi mô tả, có thể tạo đơn giản
 dữ liệu
 Xác định rõ hướng thực • Với phong cách từ trên xuống (topdown)
 Không xác định rõ hướng hiện Không xác định rõ hướng
 thực hiện thực hiện • Dễ triển khai cho những pha sau của vòng đời: 
 Thể hiện tốt tính song 
 Không thể hiện tính tuần song và tuần tự Không thể hiện tính tuần thiết kế hệ thống và thiết kế chương trình và 
 tự hay song song của tiến tự hay song song giao diện dễ làm, đảm bảo tính nhất quán, . . .
 trình
 39 40
39 40
 2.1
 D Customer 1 
 Order
 Thế nào là một đặc tả tốt? Customer Verify Master
 Customer
 Need to 
 establish
 Valid
 Khách hàng mới
 2.2
 D Inventory 2 
 Order Update
 Đặt hàng Mặt hàng Customer Verify Master
 Hệ thống Item
 Hoá đơn Phiếu hàng Kho hàng Notify
 Khách hàng đặt hàng 2.4
 Thông báo Update
 chuyển hàng Valid Avail Commit
 2.3
 Item
 D Shipping 4 
 Check Taxes
 Available
 Tax
 2.5
 Back Ord D Inventory 2 
 Master
 Order Create 
 D Back 3 Order Pending Order
 Order
 41 42
41 42
 4. Nguyên lý phân tích yêu cầu sử 
 Mô hình hóa các chức năng
 dụng
 Mô hình hóa dữ liệu • Xác định các chức năng chuyển đổi đối tượng
 • Xác định các đối tượng dữ liệu dữ liệu
 • Xác định các đặc tính của các đối tượng dữ • Chỉ ra luồng dữ liệu đi qua hệ thống như thế
 liệu nào
 • Thiết lập các mối quan hệ giữa các đối tượng • Biểu diễn bộ phận sản sinh dữ liệu và bộ phận
 dữ liệu tiêu thụ dữ liệu
 43 44
43 44
 Mô hình hóa hành vi Phân mảnh các mô hình
 • Chỉ ra các trạng thái (states) khác nhau của hệ • Tinh lọc từng mô hình để biểu diễn các mức
 thống trừu tượng thấp hơn
 • Đặc tả các hiện tượng (events) làm hệ thống • Lọc đối tượng dữ liệu
 thay đổi trạng thái • Tạo ra phân cấp chức năng
 • Biểu diễn hành vi (behavior) ở các mức chi tiết
 khác nhau
 45 46
45 46
 Bản chất của việc phân tích
 • Hãy bắt đầu bằng cách tập trung vào bản chất
 của vấn đề chứ không xem xét những chi tiết
 cài đặt
 47
47

File đính kèm:

  • pdfbai_giang_nhap_mon_cong_nghe_phan_mem_introduction_to_softwa.pdf