Bài giảng Công nghệ phần mềm ứng dụng - Bài 3: Phương pháp xác định yêu cầu - Thạc Bình Cường

• Sử dụng được các công cụ mô tả để mô hình
 hóa hệ thống.
• Xây dựng được các mô hình logic về yêu cầu
 phần mềm.
v1.0015112208 3
CÁC KIẾN THỨC CẦN CÓ
• Tin học đại cương;
• Ngôn ngữ lập trình;
• Phân tích thiết kế hệ thống thông tin.
v1.0015112208 4
HƯỚNG DẪN HỌC
• Dựa vào các dữ liệu thu thập được, sử dụng các
 kiến thức về đặc tả mô tả các yêu cầu phân loại
 các dữ liệu.
• Nắm các thành phần mô tả về yêu cầu.
• Rà soát các yêu cầu bằng cách chạy “miệng” các
 mô hình để khẳng định các yêu cầu đã được
 hiểu đúng.
v1.0015112208 5
CẤU TRÚC NỘI DUNG
 3.1 Kỹ thuật xác định yêu cầu phần mềm
 3.2 Nội dung xác định yêu cầu phần mềm
 3.3 Các nguyên lý phân tích yêu cầu sử dụng
v1.0015112208 6
3.1. KỸ THUẬT XÁC ĐỊNH YÊU CẦU PHẦN MỀM
Yêu cầu phần mềm:
• Tất cả các yêu cầu về phần mềm do khách hàng, người sử dụng phần mềm nêu ra
 bao gồm:
  Các chức năng của phần mềm;
  Hiệu năng của phần mềm;
  Các yêu cầu về thiết kế và giao diện;
  Các yêu cầu đặc biệt khác.
• Các yêu cầu phần mềm được phân loại theo 4 thành phần của phần mềm:
  Các yêu cầu về phần mềm (Software);
  Các yêu cầu về phần cứng (Hardware);
  Các yêu cầu về dữ liệu (Data);
  Các yêu cầu về con người (People, Users).
• Mục đích: Yêu cầu phần mềm là xác đị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 mềm?
v1.0015112208 7
3.1. KỸ THUẬT XÁC ĐỊNH YÊU CẦU PHẦN MỀM
• Kỹ thuật phỏng vấn;
• Sao chép từ phần mềm tương tự;
• Phiếu điều tra – bảng hỏi từ khách hàng;
• Thảo luận giữa các thành viên: Người đầu tư, nhóm phát triển, người dùng và ban
 Quản lý;
• Phân loại yêu cầu chức năng và phi chức năng.
v1.0015112208 8
3.2. NỘI DUNG XÁC ĐỊNH YÊU CẦU PHẦN MỀM
• Phát hiện các yêu cầu phần mềm (Requirements elicitation).
• 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 (Requirements
 analysis and negotiation).
• Mô tả các yêu cầu phần mềm (Requirements specification).
• Mô hình hóa hệ thống (System modeling).
• 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).
• Quy trình xác định yêu cầu phần mềm:
 Xây dựng mẫu
 Phát hiện Phát triển 
 Vấn đề yêu cầu đặc tả Rà soát
 Tạo mô hình 
 phân tích 
v1.0015112208 9
3.2.1. PHÁT HIỆN YÊU CẦU PHẦN MỀM
• Các vấn đề của phát hiện yêu cầu phần mềm (Problems)
  Phạm vi của phần mềm (Scope);
  Hiểu rõ phần mềm (Understanding);
  Các thay đổi của hệ thống (Volatility).
• Phương pháp áp dụng yêu cầu phần mềm:
  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
  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 xác định yêu cầu phần mềm.
  Xác định “môi trường kỹ thuật – technical environment”.
  Xác định các “ràng buộc miền lĩnh vực”.
  Thu hút sự tham gia của nhiều chuyên gia, khách hàng để 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.
v1.0015112208 10
3.2.1. PHÁT HIỆN YÊU CẦU PHẦN MỀM
• Sản phẩm (đầu ra) của phát hiện yêu cầu phần mềm:
  Bảng kê (statement) các đòi hỏi và chức năng khả thi của phần mềm.
  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.
v1.0015112208 11
3.2.2. 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
• Phân tích yêu cầu và các thỏa thuận:
  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.
  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.
  Thẩm định từng yêu cầu phần mềm theo các tính chất: phù hợp, đầy đủ, rõ ràng,
 không trùng lặp.
  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.
  Thẩm định từng yêu cầu phần mềm để xác định chúng có khả năng thực hiện
 được trong môi trường kỹ thuật hay không? Có khả năng kiểm định các yêu cầu
 phần mềm hay không?
  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.
  Đánh giá thô (tương đối) về giá thành và thời gian thực hiện của từng yêu
 cầu phần mềm trong giá thành sản phẩm phần mềm và thời gian thực hiện
 phần mềm.
  Giải quyết tất cả các bất đồng về yêu cầu phần mềm với khách hàng/người sử
 dụng trên cơ sở thảo luận và thương lượng các yêu cầu đề ra.
v1.0015112208 12
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM
• Định nghĩa: Đặc tả các yêu cầu phần mềm là công việc 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 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.
• Chất lượng của hồ sơ đặc tả đánh giá qua các 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.
• Các thành phần của hồ sơ đặc tả:
  Đặc tả phi hình thức (Informal specifications) được viết bằng ngôn ngữ tự nhiên.
  Đặc tả hình thức (Formal specifications) được viết bằng tập các ký pháp có các
 quy định về cú pháp (syntax) và ý nghĩa (sematic) rấtchặtchẽ, thí dụ ký pháp đồ
 họa dùng các lưu đồ.
  Đặc tả vận hành chức năng (Operational specifications) mô tả các hoạt động của
 hệ thống phần mềm sẽ xây 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, Hành vi của hệ thống trong các
 tình huống đặc biệt.
v1.0015112208 13
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM
  Đặc tả chức năng:
 . Miêu tả các chức năng của hệ thống, phụ thuộc vào kiểu phần mềm và mong
 đợi của người dùng.
 . Thông thường khi đặc tả các chức năng của phần mềm người ta sử dụng các
 công cụ tiêu biểu: biểu đồ luồng dữ liệu DFD, máy trạng thái hữu hạn FSM,
 mạng Petri
 . Tuy nhiên không bắt buộc và có thể dùng ngôn ngữ tự nhiên.
  Đặc tả phi chức năng:
 . Định nghĩa các tính chất của hệ thống, các ràng buộc. Thí dụ như độ tin cậy,
 thời gian trả lời, dung lượng bộ nhớ
 . 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
 . Các yêu cầu từ bên ngoài.
 . Nhìn chung đặc tả phi chức năng rất khó phát biểu chính xác và rất khó
 kiểm tả.
  Đặc tả mô tả thường sử dụng các công cụ:
 . Biểu đồ thực thể liên kết;
 . Đặc tả Logic;
 . Đặc tả đại số.
v1.0015112208 14
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Tài liệu yêu cầu:
  Tài liệu về yêu cầu là các phát biểu chính thức về cái được yêu cầu bởi các nhà
 phát triển hệ thống.
  Nó bao gồm cả 2 phần: định nghĩa và đặc tả yêu cầu.
  Nó không phải là tài liệu thiết kế.
• Các yêu cầu về đặc tả tài liệu:
  Đặc tả hành vi bên ngoài của hệ thống.
  Đặc tả các ràng buộc về cài đặt.
  Dễ thay đổi.
  Dùng như công cụ tham khảo cho bảo trì.
  Sự ghi chép cẩn thận về vòng đời của hệ thống, nghĩa là dự đoán các thay đổi.
  Các đáp ứng với các sự cố không mong đợi.
  Nó chỉ là 1 tập các cái mà hệ thống phải làm hơn là hệ thống phải làm thế nào
 (phân tích chứ không phải là thiết kế).
v1.0015112208 15
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Chuẩn của IEEE về tài liệu:
  Giới thiệu;
  Miêu tả khái quát;
  Đặc tả yêu cầu;
  Phụ lục;
  Chỉ dẫn;
  Đó là cấu trúc chung cần cụ thể hóa cho các hệ thống cụ thể.
• Cấu trúc tài liệu đặc tả:
  Giới thiệu;
  Từ điển;
  Định nghĩa về yêu cầu nội dung;
  Kiến trúc hệ thống;
  Đặc tả yêu cầu hệ thống;
  Mô hình hệ thống;
  Tiến hóa của hệ thống;
  Phụ lục;
  Chỉ dẫn.
v1.0015112208 16
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Biểu đồ luồng dữ liệu (DFD) (a+b)*(c+a*d)–e*(a+b)
  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 (functions). b c
 a d
  Các ký pháp sử dụng: a
 . Thể hiện các chức năng (functions).
 + * +
 . Thể hiện luồng dữ liệu.
 . Kho dữ liệu.
 . Vàoradữliệuvàtươngtácgiữahệ
 thống và người sử dụng. *
• Ví dụ mô tả biểu thức toán học bằng DFD:
v1.0015112208 17
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
 Ví dụ đặc tả các chức năng của thư viện qua DFD
 Yêu cầu từ người mượn
 Sách Tên sách, tác giả
 Kho sách Tên người mượn
 Sách
 Tên tác giả Có 
 sách Thông tin 
 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
v1.0015112208 18
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Các hạn chế của DFD:
  Ý nghĩa của các ký pháp sử dụng được xác định bởi các định danh lựa chọn
 của người sử dụng.
  Trong DFD không xác định rõ các hướng thực hiện (control aspects).
 A
 E
 B D
 F
 C
  Biểu đồ DFD này không chỉ rõ đầ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 chức năng D:
 . Chức năng D có thể cần cả A, B và C;
 . Chức năng D có thể chỉ cần một trong A, B và C để thực hiện;
 . Chức năng D có thể kết xuất kết quả cho một trong E và F;
 . Chức năng D có thể kết xuất kết quả chung cho 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.
v1.0015112208 19
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
 A B
• DFD không xác định sự đồng bộ giữa các chức năng/module:
  A xử lý dữ liệu và B được hưởng (nhận) các kết quả được xử lý từ A.
  A và B là các chức năng không đồng bộ (asynchronous activities) vì thế cần có
 buffer để ngăn chặn tình trạng mất dữ liệu.
• FSM chứa:
• Tập hữu hạn các trạng thái Q;
• Tập hữu hạn các đầu vào I;
• Các chức năng chuyển tiếp.
 High pressure alarm
 ON OFF
 Restart
v1.0015112208 20
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Đặc tả các yêu cầu phần mềm bằng FSM:
  Xem xét ví dụ về thư viện với các giao dịch như sau:
 . Mượn sách/trả sách;
 . Thêm đầu sách/loại bỏ đầu sách;
 . Liệt kê danh sách các đầu sách theo tên tác giả hay theo chủ đề;
 . 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ả.
  Các yêu cầu đặc biệt của thư viện:
 . Độc giả không được mượn quá một số lượng sách nhất định, trong một thời
 gian nhất định.
 . Một số sách không được mượn về.
 . Một số người không được mượn một số loại sách nào đó
v1.0015112208 21
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
Cc đối tượng:
 Tên sách
 Mã quyển CO AV BR
 Nhân viên phục vụ
 Người mượn
• 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 L R
 sách, danh sách các chủ đề liên quan của các
 quyển sách.
• 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 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.
• 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ả
v1.0015112208 22
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Mô hình đặc tả – Mô hình thực thể liên kết.
• 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 hệ thống dữ liệu lớn.
 ER Model:
  Thực thể;
  Quan hệ;
  Thuộc tính.
 Biểu đồ thực thể: Thực thể – tập hợp các thông tin liên quan cần được xử lý trong
 phần mềm.
 Thực thể có thể có mối quan hệ: – person owns car.
 Person Owns Car
v1.0015112208 23
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Thực thể có các thuộc tính
• Thuộc tính: Tính chất của một thực thể hoặc một đối tượng dữ liệu
  Đặt tên cho một 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 Automobile 
 Company
 Car Blue
 Ford
 ID
 Tập các thuộc tính của một đối tượng dữ liệu được xác định thông qua ngữ cảnh
 của bài toán.
v1.0015112208 24
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Quan hệ – chỉ ra mối liên quan giữa các đối tượng dữ liệu
 1N
 Bookstore Orders Books
  Cardinality: chỉ ra định lượng của mối quan hệ
 1:1 one–to–one 1:N one–to–many M:N many–to–many
  Modality: 0 – có thể có, có thể không có quan hệ
 1 – bắt buộc có quan hệ
 1NIs 
 Customer provided Repair Action
 with
v1.0015112208 25
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
Các yêu cầu của một đặc tả tốt:
• Dễ hiểu với người dùng.
• Có ít điều nhập nhằng.
• Có ít quy ước khi mô tả, có thể tạo đơn giản.
• Với phong cách từ trên xuống (topdown).
• Dễ triển khai cho những pha sau của vòng đời: thiết kế hệ thống và thiết kế chương
 trình và giao diện dễ làm, đảm bảo tính nhất quán,
v1.0015112208 26
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
Ví dụ ERD mô tả thư viện
 Area
 N
 Deals 
 with Belongs to Copy
 1
 NN
 Title State
 Was 
 Written Text Holds held 
 by by
 1M
 Author
 Borrower
 Limit
 ER diagram for a library
v1.0015112208 27
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
• Quan hệ – chỉ ra mối liên quan giữa các đối tượng dữ liệu
 1N
 Bookstore Orders Books
  Cardinality: chỉ ra định lượng của mối quan hệ
 1:1 one–to–one 1:N one–to–many M:N many–to–many
  Modality: 0 – có thể có, có thể không có quan hệ
 1 – bắt buộc có quan hệ
 1NIs 
 Customer provided Repair Action
 with
v1.0015112208 28
3.2.3. ĐẶC TẢ YÊU CẦU PHẦN MỀM (tiếp theo)
Các yêu cầu của một đặc tả tốt:
• Dễ hiểu với người dùng.
• Có ít điều nhập nhằng.
• Có ít quy ước khi mô tả, có thể tạo đơn giản.
• Với phong cách từ trên xuống (topdown).
• Dễ triển khai cho những pha sau của vòng đời: thiết kế hệ thống và thiết kế chương
 trình và giao diện dễ làm, đảm bảo tính nhất quán,
v1.0015112208 29
3.3. CÁC NGUYÊN LÝ PHÂN TÍCH YÊU CẦU SỬ DỤNG 
• Nguyên lý I. Mô hình hóa dữ liệu:
  Xác định các đối tượng dữ liệu;
  Xác định các đặc tính của các đối tượng dữ liệu;
  Thiết lập các mối quan hệ giữa các đối tượng dữ liệu.
• Nguyên lý II. Mô hình hóa các chức năng:
  Xác định các chức năng chuyển đổi đối tượng dữ liệu;
  Chỉ ra luồng dữ liệu đi qua hệ thống như thế nào;
  Biểu diễn bộ phận sản sinh dữ liệu và bộ phận tiêu thụ, sử dụng dữ liệu.
• Nguyên lý III. Mô hình hóa hành vi:
  Chỉ ra các trạng thái (states) khác nhau của hệ thống;
  Đặc tả các hiện tượng (events) làm hệ thống thay đổi trạng thái.
• Nguyên lý IV: Phân hoạch các mô hình:
  Tinh lọc từng mô hình để biểu diễn các mức trừu tượng thấp hơn;
  Lọc đối tượng dữ liệu;
  Tạo ra phân cấp chức năng;
  Biểu diễn hành vi ở các mức chi tiết khác nhau.
• Nguyên lý V. Bản chất (Essence): 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.
v1.0015112208 30
TÓM LƯỢC CUỐI BÀI
 Trong bài này chúng ta đã tìm hiểu những nội dung sau:
 • Kỹ thuật xác định yêu cầu phần mềm;
 • Nội dung xác định yêu cầu phần mềm;
 • Các nguyên lý phân tích yêu cầu sử dụng.
v1.0015112208 31