Bài giảng Nhập môn công nghệ phần mềm - Phần III: Yêu cầu người dùng - Vũ Thị Hương Giang

 9/4/2011
 Nhập môn Phần III
 Công nghệ học Phần mềm Yêu cầu người dùng
 Introduction to Software Engineering User’s Requirements
 Chương 5: Phương pháp xác định yêu cầu
 Department of Software Engineering
 Faculty of Information Technology 5.1. Kỹ thuật xác định yêu cầu
 Hanoi University of Technology 5.2. Nội dung xác định yêu cầu
 TEL: 04-8682595 FAX: 04-8692906 
 Email: cnpm@it-hut.edu.vn 5.3. Các nguyên lý phân tích yêu cầu
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.1 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.2
 Kỹ thuật xác định yêu cầu phần mềm • Thông thường các yêu cầu phần mềm được phân
 5.1. loại theo 4 thành phần của phần mềm:
 SW Requirements Engineering – Các yêu cầu về phần mềm (Software)
• Yêu cầu phần mềm: là tất cả các yêu cầu về – Các yêu cầu về phần cứng (Hardware)
 phầm mềm do khách hàng - người sử dụng – Các yêu cầu về dữ liệu (Data)
 phần mềm - nêu ra, bao gồm: các chức năng – Các yêu cầu về con người (People, Users)
 của phần mềm, hiệu năng của phần mềm, các • Mục đích: mục đích của yêu cầu phần mềm là xác
 yêu cầu về thiết kế và giao diện, các yêu cầu định được phần mềm đáp ứng được các yêu cầu và
 mong muốn của khách hàng - người sử dụng phần
 đặc biệt khác mềm
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.3 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.4
 Tại sao cần phải đặt ra yêu cầu
 5.2. Nội dung xác định yêu cầu phần mềm
 phần mềm ? Contents of Requirements Engineering
• Khách hàng chỉ có những ý tưởng còn mơ hồ về phần
 mềm cần phải xây dựng để phục vụ công việc của họ, 
 chúng ta phải sẵn sàng, kiên trì theo đuổi để đi từ các ý • Phát hiện các yêu cầu phần mềm (Requirements elicitation)
 tưởng mơ hồ đó đến “Phần mềm có đầy đủ các tính năng • Phân tích các yêu cầu phần mềm và thương lượng với khách
 cần thiết” hàng (Requirements analysis and negotiation)
• Khách hàng rất hay thay đổi các đòi hỏi của mình, chúng • Mô tả các yêu cầu phần mềm (Requirements specification)
 ta nắm bắt được các thay đổi đó và sửa đổi các mô tả một • Mô hình hóa hệ thống (System modeling)
 cách hợp lý
 • Kiểm tra tính hợp lý các yêu cầu phần mềm (Requirements
 validation)
 • Quản trị các yêu cầu phần mềm (Requirements management)
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.5 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.6
 1
 9/4/2011
 Quy trình xác định yêu cầu phần mềm The Analysis Model
 Build a
 prototype
 Requirements Develop
 the problem elicitation specification Review
 Data Model
 Create Functional
 analysis Model
 models
 Behavioral
 Model
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.7 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.8
 5.2.1. Phát hiện yêu cầu phần mềm Phương pháp phát hiện yêu cầu phần mềm
 Requirements Elicitation Methodology
 (Requirements Elicitation) • Xác định các phương pháp sử dụng phát hiện các yêu cầu
 phần mềm: phỏng vấn, làm việc nhóm, các buổi họp, gặp gỡ
 đối tác, v.v.
 Các vấn đề của phát hiện yêu cầu phần mềm • 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, chi tiết nhất về hệ thống giúp chúng ta
 (Problems) xác định yêu cầu phần mềm
 • Phạm vi của phần mềm (Scope) • Xác định “môi trường kỹ thuật - technical environment”
 • Xác định các “ràng buộc lĩnh vực domain constraints”
 • Hiểu rõ phần mềm (Understanding) • Thu hút sự tham gia của nhiều chuyên gia, khách hàng để
 • Các thay đổi của hệ thống (Volatility) chúng ta có được các quan điểm xem xét phần mềm khác
 nhau từ phía khách hàng
 • Thiết kế các kịch bản sử dụng của phần mềm
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.9 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.10
 Sản phẩm (output) của 5.2.2. Phân tích các yêu cầu phần mềm và
 “phát hiện yêu cầu phần mềm” thương lượng với khách hàng
• Bảng kê (statement) các đòi hỏi và chức năng khả thi của phần Software
 Engineering Customer
 mềm Group Group
• Bảng kê phạm vi ứng dụng của phần mềm
• Mô tả môi trường kỹ thuật của phần mềm
• Bảng kê tập hợp các kịch bản sử dụng của phần mềm
• Các nguyên mẫu xây dựng, phát triển hay sử dụng trong phần
 mềm (nếu có)
• Danh sách nhân sự tham gia vào quá trình phát hiện các yêu cầu
 phần mềm - kể cả các nhân sự từ phía công ty- khách hàng
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.11 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.12
 2
 9/4/2011
 Requirements Analysis and Negotiation Requirements Analysis and Negotiation
 • Phân loại các yêu cầu phần mềm và sắp
 xếp chúng theo các nhóm liên quan • Phân cấp các yêu cầu phần mềm theo dựa trên nhu
 • Khảo sát tỉ mỉ từng yêu cầu phần mềm cầu và đòi hỏi khách hàng / người sử dụng
 trong mối quan hệ của nó với các yêu cầu • Thẩm định từng yêu cầu phầm mềm để xác định
 phần mềm khác chúng có khả năng thực hiện được trong môi
 • Thẩm định từng yêu cầu phần mềm theo trường kỹ thuật hay không, có khả năng kiểm định
 các tính chất: phù hợp, đầy đủ, rõ ràng, các yêu cầu phần mềm hay không
 không trùng lặp • Thẩm định các rủi ro có thể xảy ra với từng yêu
 cầu phần mềm
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.13 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.14
 Requirements Analysis and Negotiation
 5.2.3. Đặc tả yêu cầu phần mềm
• Đánh giá thô (tương đối) về giá thành và thời • Đặc tả các yêu cầu phần mềm là công việc xây
 gian thực hiện của từng yêu cầu phần mềm trong 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ô
 giá thành sản phẩm phần mềm và thời gian thực hình toán học hình thức (a formal
 hiện phần mềm 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
• Giải quyết tất cả các bất đồng về yêu cầu phần các công cụ nói trên
 mềm với khách hàng / người sử dụng trên cơ sở • Chất lượng của hồ sơ đặc tả đánh giá qua các
 thảo luận và thương lượng các yêu cầu đề ra tiêu thức
 – Tính rõ ràng, chính xác
 – Tính phù hợp
 – Tính đầy đủ, hoàn thiện
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.15 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.16
 Requirements Specification Requirements Specification
• Các thành phần của hồ sơ đặc tả
 – Đặc tả phi hình thức (Informal specifications) được viết • Đặc tả chức năng Operational
 bằng ngôn ngữ tự nhiên (
 – Đặc tả hình thức (Formal specifications) được viết bằng tập Specifications): thông thường khi đặc tả các
 các ký pháp có các quy định về cú pháp (syntax) và ý nghĩa chức năng của phần mềm người ta sử dụng
 (sematic) rất chặt chẽ
 – Đặc tả vận hành chức năng (Operational specifications) mô các công cụ tiêu biểu sau
 tả các hoạt động của hệ thống phần mềm sẽ xây dựng
 – Biểu đồ luồng dữ liệu (Data Flow Diagrams)
 – Đặc tả mô tả (Descriptive specifications) – đặc tả các đặc
 tính đặc trưng của phần mềm – Máy trạng thái hữu hạn (Finite State Machines
 – Mạng Petri (Petri nets)
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.17 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.18
 3
 9/4/2011
 Requirements Specification Biểu đồ luồng dữ liệu (DFD)
 • Hệ thống (System): tập hợp các dữ liệu (data) 
 được xử lý bằng các chức năng tương ứng
 • Đặc tả mô tả (Descriptive (functions)
 Specifications) • Các ký pháp sử dụng:
 – Biểu đồ thực thể liên kết (Entity- Thể hiện các chức năng (functions)
 Relationship Diagrams) Thể hiện luồng dữ liệu
 – Đặc tả Logic (Logic Specifications) Kho dữ liệu
 Vào ra dữ liệu và tương tác giữa
 – Đặc tả đại số (Algebraic Specifications)
 hệ thống và người sử dụng
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.19 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.20
 Ví dụ đặc tả các chức năng của thư viện qua DFD
 Ví dụ mô tả biểu thức toán học bằng DFD
 Yªu cÇu tõ ng•êi m•în
 (a+b)*(c+a*d) Tªn s¸ch, t¸c gi¶
 S¸ch Tªn ng•êi m•în
 Kho s¸ch
 b c
 Tªn t¸c gi¶ Cã S¸ch
 a d Th«ng tin 
 a s¸ch
 Danh s¸ch t¸c gi¶ vÒ s¸ch
 + * +
 Tªn s¸ch Tªn s¸ch;
 Danh s¸ch tªn s¸ch Tªn ng•êi m•în
 Danh s¸ch ng•êi m•în
 Danh s¸ch chñ ®Ò T×m theo LiÖt kª c¸c tªn s¸ch 
 * chñ ®Ò
 liªn quan ®Õn chñ ®Ò
 Chñ ®Ò
 Chñ ®Ò yªu cÇu §•a ra 
 Tªn s¸ch
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.21 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.22
 Các hạn chế của DFD • Trong DFD không xác định rõ các hướng
 • ý nghĩa của các ký pháp sử dụng được xác thực hiện (control aspects)
 định bởi các định danh lựa chọn của NSD A
 E
 Ví dụ của chức năng tìm kiếm:
 B D
 If NSD nhập vào cả tên tác giả và tiêu đề sách Then F
 tìm kiếm sách tương ứng, không có thì thông báo lỗi C
 Elseif chỉ nhập tên tác giả Then
 hiển thị danh sách các sách tương ứng với Biểu đồ DFD này không chỉ rõ đầu vào là gì
 tên tác giả đã nhập và yêu cầu NSD lựa chọn sách để thực hiện chức năng D và đầu ra là gì
 Elseif chỉ nhập tiêu đề sách Then
 . . . sau khi thựchiện chức năng D.
 Endif
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.23 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.24
 4
 9/4/2011
 A
 E
 B D A B
 F
 C
 • DFD không xác định sự đồng bộ giữa các chức
 – Chức năng D có thể cần cả A, B và C năng / mô-đun
 – Chức năng D có thể chỉ cần một trong A, B và C – A xử lý dữ liệu và B được hưởng (nhận) các
 để thực hiện kết quả được xử lý từ A
 – Chức năng D có thể kết xuất kết quả cho một – A và B là các chức năng không đồng bộ
 trong E và F (asynchronous activities) vì thế cần có buffer
 – Chức năng D có thể kết xuất kết quả chung cho để ngăn chặn tình trang mất dữ liệu
 cả E và F
 – Chức năng D có thể kết xuất kết quả riêng cho
 cả E và F
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.25 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.26
 Finite State Machines (FSM) Đặc tả các yêu cầu phần mềm
 FSM chứa bằng FSM
 • Tập hữu hạn các trạng thái Q • Xem xét ví dụ về thư viện với các giao
 • Tập hữu hạn các đầu vào I dịch như sau:
 • Các chức năng chuyển tiếp – Mượn sách / Trả sách
 – Thêm đầu sách / Loại bỏ đầu sách
  : Q I Q – Liệt kê danh sách các đầu sách theo tên tác
 High pressure alarm giả hay theo chủ đề
 – Tìm kiếm sách theo các yêu cầu của người
 High temp. alarm
 ON OFF mượn
 – Tìm kiếm sách quá hạn trả, . . .
 Restart
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.27 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.28
 Đặc tả . . . Các đối tượng –
 Tên sách
• Các yêu cầu đặc biệt của thư viện: Mã quyển
 Nhân viên phục vụ
 – Độc giả không được mượn quá một số lượng Người mượn
 sách nhất định, trong một thời gian nhất định • Chúng ta 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
 – Một số sách không được mượn về chủ đề liên quan của các quyển sách
 – Một số người không được mượn một số loại • 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ỗi quyển sách có thể có 1 
 sách nào đó, . . . trong 5 trạng thái sau:
 • (AV ) - Available được phép mượn, (CO) - (BR) - đã
 mượn (Check Out; Borrow), (L): Last, (R): Remove
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.29 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.30
 5
 9/4/2011
 Mô hình đặc tả : 
 Mô hình thực thể liên kết
 • FSM đặc tả các trạng thái
 • Mô hình khái niệm cho phép đặc tả các yêu cầu
 logic của hệ thống, thường được sử dụng trong các
 CO AV BR
 hệ thống dữ liệu lớn
 ER Model
 L R – Thực thể
 – Quan hệ
 – Thuộc tính
 ii. Có thể có hạn chế về số sách được mượn cho Biểu đồ thực thể
 1 nhóm độc giả hoặc mọi độc giả, . . .
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.31 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.32
 • Thực thể – tập hợp các thông tin liên quan cần • Thực thể có các thuộc tính
 được xử lý trong phần mềm • Thuộc tính: Tính chất của một thực thể hoặc một
 Thực thể có thể có mối quan hệ: – person owns car đối tượng dữ liệu
 – đặt tên cho 1 mẫu (instance) của đối tượng dữ liệu
 – mô tả mẫu (instance)
 – tạo liên kết (reference) đến các mẫu khác
 Ford
 Person Owns Car Automobile 
 Company
 Car Blue
 Ford
 ID
 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
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.33 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.34
 • Quan hệ – chỉ ra mối liên quan gữa các đối tượng Ví dụ ERD mô tả thư viện
 dữ liệu Area
 1 N N
 Bookstore Orders Books Deals 
 with Belongs to Copy
 1
  Cardinality : chỉ ra định lượng của mối quan hệ N N
 1:1 one-to-one 1:N one-to-many M:N many-to-many Title state
 Was 
  Modality : 0 – có thể có, có thể không có quan hệ Written Text holds held 
 by
 1 – bắt buộc có quan hệ by
 1 M
 Is 
 1 N Author
 Customer provided Repair Action Borrower
 with limit
 ER diagram for a library
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.35 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.36
 6
 9/4/2011
 Các yêu cầu của một đặc tả tốt 5.3. Các nguyên lý phân tích
 yêu cầu sử dụng
 • Đẽ hiểu với người dùng
 • Có ít điều nhập nhằng • Nguyên lý I. Mô hình hóa dữ liệu
 • Có ít quy ước khi mô tả, có thể tạo đơn giản – Xác định các đối tượng dữ liệu
 • Với phong cách từ trên xuống (topdown) – Xác định các đặc tính của các đối
 • Dễ triển khai cho những pha sau của vòng đời: thiết tượng dữ liệu
 kế hệ thống và thiết kế chương trình và giao diện dễ – Thiết lập các mối quan hệ giữa các
 làm, đảm bảo tính nhất quán, . . . đối tượng dữ liệu
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.37 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.38
 Các nguyên lý phân tích Các nguyên lý phân tích yêu
 yêu cầu sử dụng cầu sử dụng
 • Nguyên lý II. Mô hình hóa các chức năng • Nguyên lý III. Mô hình hóa hành vi
 – Xác định các chức năng chuyển đổi đối – Chỉ ra các trạng thái (states) khác nhau
 tượng dữ liệu của hệ thống
 – Chỉ ra luồng dữ liệu đi qua hệ thống như – Đặc tả các hiện tượng events làm hệ
 thế nào ( ) 
 thống thay đổi trạng thái
 – Biểu diễn bộ phận sản sinh dữ liệu và bộ
 phận tiêu thụ dữ liệu
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.39 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.40
 Các nguyên lý phân tích yêu
 Các nguyên lý phân tích yêu
 cầu sử dụng
 cầu sử dụng
 • Nguyên lý V. Bản chất (Essence)
 • Nguyên lý IV. Partition the Models Hãy bắt đầu bằng cách tập trung vào bản
 Tinh lọc từng mô hình để biểu diễn các chất của vấn đề chứ không xem xét những
 mức trừu tượng thấp hơn chi tiết cài đặt (begin by focusing on the
 • Lọc đối tượng dữ liệu essence of the problem without regard to
 • Tạo ra phân cấp chức năng implementation details)
 • Biểu diễn hành vi (behavior) ở các mức
 chi tiết khác nhau New Tool: Unified Modeling Language (UML)!
HUT, Falt. of IT  Dept. of SE, 2002 SE-III.41 HUT, Falt. of IT  Dept. of SE, 2002 SE-III.42
 7