Bài giảng Công nghệ phần mềm - Bài 2: Xác định Yêu cầu - Lê Nguyễn Tuấn Thành

Nội dung text: Bài giảng Công nghệ phần mềm - Bài 2: Xác định Yêu cầu - Lê Nguyễn Tuấn Thành

1. Công nghệ Phần mềm Xác định Yêu cầu Giảng viên: Lê Nguyễn Tu ấn Thành Email: thanhlnt@tlu.edu.vn Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT Tr ường Đại Học Thủy Lợi
2. Nội dung  Yêu cầu Phần mềm  Quy trình Kỹ thuật tạo Yêu cầu Bài giảng có sử dụng hình vẽ trong cuốn sách “Software Engineering, Ian Sommerville, 8th Edition, 2007” 2
3. 1. Yêu cầu Phần mềm (Software Requirements) 3
4. Mục tiêu  Giới thiệu khái niệm về Yêu cầu người dùng và Yêu cầu hệ thống  Miêu tả Yêu cầu chức năng và Yêu cầu phi chức năng  Giải thích cách những yêu cầu phần mềm được tổ chức trong một tài liệu yêu cầu 4
5. Những chủ đề được đề cập (Topics covered)  Yêu cầu người dùng và Yêu cầu hệ thống  Yêu cầu chức năng và Yêu cầu phi chức năng  Tài liệu yêu cầu phần mềm 5
6. Yêu cầu là gì? (Requirement?)  Yêu cầu có thể là:  phát biểu trừu tượng ở mức cao về một dịch vụ hoặc  một rằng buộc hệ thống đến một đặc tả chức năng toán học cụ thể 6
7. Phân biệt: Yêu cầu và Thiết kế (Requirements and Design)  Về nguyên tắc, yêu cầu nên phát biểu về CÁI (what) mà hệ thống nên làm, còn thiết kế nên miêu tả CÁCH (how) hệ thống làm điều đó  Trong thực tế, yêu cầu và thiết kế là không thể tách rời 7
8. Sự đầy đủ và nhất quán của yêu cầu (Requirements completeness & consistency)  Về nguyên tắc, những yêu cầu nên phải hoàn thiện và nhất quán  Hoàn thiện  Yêu cầu nên bao gồm miêu tả về tất cả các phương tiện, khía cạnh cần thiết  Nhất quán  Không nên có xung đột (conflicts) hoặc mâu thuẫn (contradictions) trong những yêu cầu  Trên thực tế, không thể tạo ra một tài liệu yêu cầu hoàn thiện và nhất quán 8
9. Case study: Hệ thống LIBSYS  Một hệ thống quản lý thư viện cung cấp một giao diện đơn cho một số lượng cơ sở dữ liệu bài báo trong những thư viện khác nhau,  Người dùng có thể tìm kiếm, tải về hoặc in những bài báo này cho mục đích học tập cá nhân 9
10. Phân loại Yêu cầu •Yêu cầu người dùng •Yêu cầu chức năng •Yêu cầu hệ thống •Yêu cầu phi chức năng 10
11. Yêu cầu Người dùng vs Hệ thống  Yêu cầu người dùng  Những phát biểu bằng ngôn ngữ tự nhiên cộng với sơ đồ (diagram) về những dịch vụ hệ thống sẽ cung cấp và những rằng buộc vận hành của nó.  Được viết cho/bởi khách hàng.  Yêu cầu hệ thống  Một tài liệu có cấu trúc đưa ra những mô tả chi tiết về chức năng hệ thống, dịch vụ và rằng buộc vận hành.  Được dự định là một cơ sở để thiết kế hệ thống  Có thể được định nghĩa hoặc minh hoạ sử dụng mô hình hệ thống (system models) 11
12. VD: Yêu cầu Người dùng và Hệ thống  Yêu cầu người dùng  Phần mềm phải cung cấp một cách thức để biểu diễn và truy cập những tệp bên ngoài được tạo bởi những công cụ khác  Đặc tả những yêu cầu hệ thống 1. Người dùng nên được cung cấp các phương tiện (facilities) để định nghĩa kiểu của những tệp tin ngoài (external files) 2. Mỗi kiểu tệp tin ngoài nên có một công cụ đi kèm có thể áp dụng cho kiểu tệp tin đó 3. Mỗi kiểu tệp tin ngoài nên được biểu diễn bằng một biểu tượng cụ thể (specific icon) trên màn hình của người dùng 4. Các phương tiện nên được cung cấp cho biểu tượng biểu diễn một kiểu tệp tin ngoài được định nghĩa bởi người dùng 5. Khi người dùng chọn một biểu tượng biểu diễn tệp tin ngoài, hiệu ứng của việc lựa chọn đó là sử dụng công cụ liên kết với kiểu tệp ngoài đó cho tệp tin được biểu diễn bởi công cụ lựa chọn 12
13. Insulin Pump / Phần mềm kiểm soát / SRS / 3.3.2 Chức năng Tính liều insulin: Mức đường an toàn Miêu tả Tính toán lượng insulin được cung cấp khi mức đường đo được hiện tại nằm trong vùng an toàn giữa 3 và 7 đơn vị. Đầu vào Lượng đường đọc được hiện tại (r2), hai lượng đường ở lần đọc trước (r0 và r1) Nguồn Lượng đường đọc từ cảm biến. Những lần đọc khác từ bộ nhớ. Đầu ra Compdose - liều lượng insulin được cung cấp Miêu tả Vòng điều khiển chính Hành động CompDose có giá trị 0 nếu mức đường ổn định hoặc giảm xuống hoặc nếu mức độ đang tăng lên nhưng tỷ lệ tăng đang giảm. Nếu mức độ đang tăng và tỷ lệ tăng lại đang tăng lên, thì CompDose được tính bằng cách chia sự khác biệt giữa mức đường hiện tại và mức trước đó cho 4 và làm tròn kết quả. Nếu kết quả, được làm tròn bằng 0, thì CompDose được đặt ở liều tối thiểu có thể được phân phối. Yêu cầu Hai lần đọc trước đó để có thể tính tỷ lệ thay đổi của mức đường. Điều kiện trước Túi insulin chứa ít nhất một liều đơn tối đa cho phép của insulin Điều kiện sau r0 được thay thế bởi r1 sau đó r1 được thay thế bằng r2 Ảnh hưởng phụ Không có 13
14. Đối tượng của những kiểu yêu cầu • Nhà quản lý phía khách hàng (Client managers) • ườ ố ủ ệ ố Yêu cầu người dùng Ng i dùng cu i c a h th ng (System end-users) • Kỹ sư phía khách hàng (Client engineers) (User requirements) • Nhà quản lý phía nhà thầu (Contractor managers) • Kỹ sư hệ thống (System architects) • Người dùng cuối của hệ thống (System end-users) Yêu cầu hệ thống • Kỹ sư phía khách hàng (Client engineers) (System requirements) • Kỹ sư hệ thống (System architects) • Lập trình viên phần mềm (Software developers) Đặc tả thiết kế phần mềm • Kỹ sư phía khách hàng (Client engineers) [có thể] • Kỹ sư hệ thống (System architects) (Software design • Lập trình viên phần mềm (Software developers) specification) 14
15. Yêu cầu Chức năng vs Phi chức năng (Functional and non-functional requirements)  Yêu cầu chức năng  Những tuyên bố (statements) về dịch vụ hệ thống nên cung cấp, cách hệ thống nên phản ứng với những đầu vào cụ thể và cách hệ thống nên hành xử trong những tình huống cụ thể  Yêu cầu phi chức năng  Những rằng buộc trên những dịch vụ hoặc chức năng được cung cấp bởi hệ thống như rằng buộc về thời gian, rằng buộc về tiến trình phát triển, về các chuẩn, 15
16. Yêu cầu chức năng (Functional requirements)  Mô tả chức năng hoặc dịch vụ hệ thống  Phụ thuộc vào kiểu phần mềm, mong muốn của người dùng và kiểu của hệ thống nơi mà phần mềm được sử dụng  Những yêu cầu chức năng người dùng có thể là những tuyên bố (statements) ở mức cao về điều mà hệ thống nên làm  Những yêu cầu chức năng hệ thống nên miêu tả chi tiết dịch vụ hệ thống 16
17. Ví dụ: Yêu cầu chức năng của LIBSYS  Người dùng có thể tìm kiếm tất cả các bộ cơ sở dữ liệu ban đầu hoặc chỉ chọn một tập con trong đó  Hệ thống sẽ cung cấp chế độ hiển thị thích hợp cho người dùng để đọc tài liệu trong kho tài liệu  Mỗi đơn hàng sẽ được cấp một định danh duy nhất (ORDER_ID) mà người dùng sẽ sử dụng để sao chép vào khu vực lưu trữ dài hạn của tài khoản đó 17
18. Yêu cầu phi chức năng (Non-functional requirements)  Định nghĩa những thuộc tính và rằng buộc, ví dụ: độ tin cậy, thời gian phản ứng, yêu cầu lưu trữ. Những rằng buộc là khả năng thiết bị vào/ra (I/O), những biểu diễn hệ thống,  Yêu cầu phi chức năng có thể quan trọng hơn yêu cầu chức năng. Nếu những yêu cầu này không được đáp ứng, hệ thống có thể sẽ vô dụng (useless) 18
19. Phân loại Yêu cầu phi chức năng (Non-functional classifications)  Yêu cầu sản phẩm (product requirements)  Những yêu cầu xác định rằng sản phẩm được phân phối phải hoạt động theo một cách cụ thể, ví dụ: tốc độ chạy (execution speed), độ tin cậy (reliability), v.v.  Yêu cầu tổ chức (organizational requirements)  Những yêu cầu là hệ quả của những chính sách (policies) và thủ tục (procedures) tổ chức, ví dụ: những tiêu chuẩn quy trình được sử dụng, phương pháp thiết kế, v.v.  Yêu cầu bên ngoài (external requirements)  Những yêu cầu phát sinh từ những yếu tố bên ngoài tác động lên hệ thống, ví dụ: yêu cầu về khả năng tương tác (interoperability) với các hệ thống khác, yêu cầu pháp lý (legislative), tính văn hóa, đạo đức, v.v. 19
20. Ví dụ: Yêu cầu phi chức năng  Yêu cầu sản phẩm (product requirement)  8.1 Giao diện người dùng cho LIBSYS sẽ được triển khai dưới dạng HTML đơn thuần mà không có frame hoặc Java applet  Yêu cầu tổ chức (organizational requirement)  9.3.2 Tiến trình phát triển hệ thống và những tài liệu chuyển giao (deliverable documents) phải phù hợp với tiến trình và sản phẩm được định nghĩa trong XYZCo-SP-STAN-95.  Yêu cầu bên ngoài (external requirement)  7.6.5 Hệ thống sẽ không tiết lộ bất kỳ thông tin về khách hàng ngoài tên và số tham chiếu của họ cho người vận hành hệ thống 20
21. Phân biệt: Yêu cầu và Mục tiêu  Yêu cầu là một cái gì đó có thể kiểm tra được  Mục tiêu là một đặc trưng khái quát hơn mà hệ thống phải thể hiện  Một ý định chung của người dùng, ví dụ tính dễ sử dụng, thân thiện với người dùng (nhưng đây không phải là một thuộc tính khách quan)  Mục tiêu hữu ích cho các nhà phát triển do chúng biểu đạt ý định của người dùng hệ thống 21
22. Ví dụ: Mục tiêu và Yêu cầu  Mục tiêu hệ thống  Hệ thống nên dễ sử dụng cho những người dùng kinh nghiệm và nên được tổ chức theo cách sao cho những lỗi người dùng được tối giản hóa  Yêu cầu phi chức năng có thể xác thực  Người dùng có kinh nghiệm có thể sử dụng tất cả chức năng hệ thống sau 2 giờ huấn luyện.  Sau thời gian huấn luyện này, số lượng trung bình lỗi được tạo ra bởi người dùng kinh nghiệm sẽ không quá 2 lỗi một ngày. 22
23. Những độ đo cho Yêu cầu (Requirements measures) Thuộc tính (property) Số đo (measure) Số giao dịch được xử lý / giây Tốc độ Số người dùng / thời gian đáp ứng sự kiện (speed) Thời gian làm tươi màn hình Kích thước Mbytes (size) Số lượng ROM chips Tính dễ sử dụng Thời gian huấn luyện (ease of use) Số lượng khung trợ giúp Thời gian trung bình mà hệ thống lỗi (failure) Độ tin cậy Xác suất của trạng thái không sẵn sàng (unavailability) (reliability) Tỷ lệ xuất hiện lỗi (failure occurrence) Tính sẵn sàng (availability) Thời gian khởi động sau khi có lỗi Độ vững mạnh Phần trăm sự kiện gây ra lỗi (robustness) Xác suất hư hỏng dữ liệu (data corruption) khi có lỗi Tính di động Phần trăm những phát biểu phụ thuộc mục tiêu (portability) Số lượng hệ thống mục tiêu (target systems) 23
24. Xung đột yêu cầu  Xung đột giữa những yêu cầu phi chức năng là phổ biến trong những hệ thống phức tạp  Ví dụ: Hệ thống tàu vũ trụ  Tối giản hóa trọng lượng, do đó số lượng vi xử lý (chip) trong hệ thống nên được tối giản hóa,  Tối giản hóa việc tiêu thụ điện năng (power consumption), những vi xử lý tiêu thụ điện năng thấp nên được sử dụng  Tuy nhiên, sử dụng vi xử lý điện năng thấp nghĩa là phải sử dụng số lượng nhiều hơn.  Đâu là yêu cầu quan trọng hơn? 24
25. Nhắc lại: Yêu cầu người dùng  Nên miêu tả những yêu cầu chức năng và phi chức năng theo cách mà chúng có thể được hiểu bởi người dùng hệ thống, những người không có kiến thức kỹ thuật chi tiết  Yêu cầu người dùng được định nghĩa sử dụng ngôn ngữ tự nhiên, các bảng và biểu đồ mà có thể được hiểu bởi tất cả người dùng 25
26. Hướng dẫn viết yêu cầu (Guidelines for writing requirements)  Tìm ra một định dạng chuẩn và sử dụng nó cho tất cả các yêu cầu.  Sử dụng ngôn ngữ một cách nhất quán. Sử dụng cho các yêu cầu bắt buộc, nên sử dụng cho các yêu cầu mong muốn.  Sử dụng văn bản được làm nổi bật để xác định những phần quan trọng của yêu cầu.  Tránh sử dụng thuật ngữ máy tính 26
27. Vấn đề của Đặc tả Ngôn ngữ tự nhiên (Problems with NL specification)  Sự mơ hồ (Ambiguity)  Người đọc và người viết yêu cầu phải phiên dịch những từ giống nhau theo cùng một cách.  Ngôn ngữ tự nhiên là không rõ ràng vì vậy điều này rất khó khăn.  Quá linh hoạt (Over-flexibility)  Những phát biểu tương tự có thể được nói bằng một số cách khác nhau trong đặc tả.  Thiếu tính mô-đun hóa  Cơ cấu ngôn ngữ tự nhiên không phù hợp để cấu trúc những yêu cầu hệ thống 27
28. Những thay thế cho Đặc tả bằng NNTN Ký hiệu Miêu tả (notation) (description) Ngôn ngữ tự Cách tiếp cận này phụ thuộc vào việc định nghĩa các hình thức hoặc nhiên được khuôn mẫu chuẩn để diễn tả đặc tả yêu cầu. cấu trúc Ngôn ngữ mô Cách tiếp cận này sử dụng một ngôn ngữ như một ngôn ngữ lập trình tả thiết kế nhưng với nhiều tính năng trừu tượng hơn để chỉ định các yêu cầu bằng cách định nghĩa một mô hình hoạt động của hệ thống. Cách tiếp cận này bây giờ không được sử dụng rộng rãi mặc dù nó có thể hữu ích cho các đặc tả giao diện. Ký hiệu đồ Một ngôn ngữ đồ họa, bổ sung bằng các chú thích văn bản, được sử hoạ dụng để định nghĩa các yêu cầu chức năng cho hệ thống. Một ví dụ ban đầu của một ngôn ngữ đồ họa như thế là SADT. Bây giờ, những mô tả use-case sử dụng và biểu đồ trình tự thường được sử dụng. Đặc tả toán Đây là những ký hiệu dựa trên các khái niệm toán học như các máy học hoặc tập hữu hạn trạng thái. Những đặc tả rõ ràng này làm giảm các tham số giữa khách hàng và nhà thầu về chức năng của hệ thống. Tuy nhiên, hầu hết khách hàng không hiểu những đặc tả hình thức và miễn cưỡng chấp nhận nó như một hợp đồng hệ thống. 28
29. Đặc tả ngôn ngữ được cấu trúc (Structured language specifications)  Sự tự do của người viết yêu cầu bị giới hạn bởi một khuôn mẫu được định nghĩa trước cho các yêu cầu.  Tất cả các yêu cầu được viết theo một cách chuẩn.  Thuật ngữ (terminology) sử dụng trong mô tả có thể bị hạn chế.  Ưu điểm là hầu hết các biểu cảm của ngôn ngữ tự nhiên được duy trì nhưng một mức độ đồng nhất bị bắt buộc trong đặc tả. 29
30. Đặc tả dựa trên biểu mẫu (Form-based specifications)  Sự định nghĩa của chức năng hoặc thực thể.  Sự mô tả về đầu vào và nguồn gốc của chúng.  Sự mô tả về đầu ra và nơi chúng đến.  Sự chỉ dẫn của các thực thể khác được yêu cầu.  Những điều kiện trước và sau (nếu thích hợp).  Những ảnh hưởng phụ (nếu có) của chức năng. 30
31. Đặc tả nút dựa trên biểu mẫu (Form-based node specification) Insulin Pump / Phần mềm kiểm soát / SRS / 3.3.2 Chức năng Tính liều insulin: Mức đường an toàn Miêu tả Tính toán lượng insulin được cung cấp khi mức đường đo được hiện tại nằm trong vùng an toàn giữa 3 và 7 đơn vị. Đầu vào Lượng đường đọc được hiện tại (r2), hai lượng đường ở lần đọc trước (r0 và r1) Nguồn Lượng đường đọc từ cảm biến. Những lần đọc khác từ bộ nhớ. Đầu ra Compdose - liều lượng insulin được cung cấp Miêu tả Vòng điều khiển chính Hành động CompDose có giá trị 0 nếu mức đường ổn định hoặc giảm xuống hoặc nếu mức độ đang tăng lên nhưng tỷ lệ tăng đang giảm. Nếu mức độ đang tăng và tỷ lệ tăng lại đang tăng lên, thì CompDose được tính bằng cách chia sự khác biệt giữa mức đường hiện tại và mức trước đó cho 4 và làm tròn kết quả. Nếu kết quả, được làm tròn bằng 0, thì CompDose được đặt ở liều tối thiểu có thể được phân phối. Yêu cầu Hai lần đọc trước đó để có thể tính tỷ lệ thay đổi của mức đường. Điều kiện trước Túi insulin chứa ít nhất một liều đơn tối đa cho phép của insulin Điều kiện sau r0 được thay thế bởi r1 sau đó r1 được thay thế bằng r2 Ảnh hưởng phụ Không có 31
32. Đặc tả dạng bảng (Tabular specification)  Được sử dụng để bổ sung cho ngôn ngữ tự nhiên.  Đặc biệt hữu ích khi phải định nghĩa một số các phương án thay thế có thể cho hành động 32
33. Ví dụ: Đặc tả dạng bảng Điều kiện Hành động Mức đường đang rơi CompDose = 0 xuống (r2 <r1) Mức đường ổn định (r2 CompDose = 0 = r1) Mức đường đang tăng CompDose = 0 và tốc độ tăng giảm ((r2-r1) <(r1-r0)) Mức đường đang tăng CompDose = round((r2-r1) / 4) và tốc độ tăng ổn định Nếu kết quả làm tròn = 0 thì hoặc tăng ((r2-r1) ≥ (r1- CompDose = MinimumDose r0)) 33
34. Mô hình đồ họa (Graphical models)  Được sử dụng để bổ sung cho ngôn ngữ tự nhiên.  Hữu ích nhất khi chúng ta cần hiển thị các trạng thái thay đổi hoặc mô tả một chuỗi hành động. 34
35. VD: Sơ đồ trình tự rút tiền ATM (Sequence diagram of ATM withdrawal) 35
36. Đặc tả giao diện (Interface specification)  Hầu hết hệ thống phải hoạt động với các hệ thống khác  Các giao diện hoạt động phải được xác định như là một phần của yêu cầu.  Ba loại giao diện có thể được định nghĩa:  Giao diện thủ tục (Procedural interfaces)  Cấu trúc dữ liệu được trao đổi (Exchanged data structures)  Biểu diễn dữ liệu (Data representations)  Những ký hiệu hình thức là một kỹ thuật hiệu quả cho đặc tả giao diện. 36
37. VD: Miêu tả giao diện 37
38. Tài liệu đặc tả Yêu cầu (Requirements document)  Tài liệu yêu cầu là tuyên bố chính thức về những gì được yêu cầu của các nhà phát triển hệ thống.  Nên bao gồm cả định nghĩa về các yêu cầu người dùng và đặc tả của yêu cầu hệ thống.  Nó KHÔNG PHẢI là một tài liệu thiết kế.  Càng nhiều càng tốt, nó nên thiết lập về CÁI hệ thống nên làm hơn là CÁCH hệ thống nên làm 38
39. Đối tượng của Tài liệu yêu cầu 39
40. Chuẩn Tài liệu Yêu cầu IEEE (IEEE requirements standard)  Định nghĩa một cấu trúc chung cho một tài liệu yêu cầu phải được khởi tạo cho mỗi hệ thống cụ thể.  Giới thiệu (introduction)  Miêu tả chung (general description)  Những đặc tả cụ thể (specific requirements)  Phụ lục (appendices)  Mục lục (index) 40
41. Cấu trúc Tài liệu Yêu cầu (Requirements document structure) 1. Lời nói đầu (Preface) 2. Giới thiệu (Introduction) 3. Bảng chú giải (Glossary) 4. Định nghĩa yêu cầu người dùng (User requirements definition) 5. Kiến trúc hệ thống (System architecture) 6. Đặc tả yêu cầu hệ thống (System requirements specification) 7. Mô hình hệ thống (System models) 8. Sự tiến hóa hệ thống (System evolution) 9. Phụ lục (Appendices) 10. Mục lục (Index) 41
42. Tóm tắt những điểm chính (1/2) (Key points)  Yêu cầu chỉ ra CÁI hệ thống nên làm và định nghĩa những rằng buộc về sự hoạt động và thực hiện của nó.  Các yêu cầu chức năng đưa ra các dịch vụ mà hệ thống cần cung cấp.  Các yêu cầu phi chức năng giới hạn hệ thống đang được phát triển hoặc quá trình phát triển. 42
43. Tóm tắt những điểm chính (2/2) (Key points)  Yêu cầu người dùng là những phát biểu ở mức cao về cái hệ thống nên làm.  Yêu cầu người dùng nên được viết bằng ngôn ngữ tự nhiên, những bảng biểu và sơ đồ.  Yêu cầu hệ thống nhằm mục đích truyền đạt các chức năng mà hệ thống cần cung cấp.  Một tài liệu yêu cầu phần mềm là một tuyên bố đồng thuận về các yêu cầu hệ thống.  Tiêu chuẩn IEEE là một điểm khởi đầu hữu ích để định nghĩa các tiêu chuẩn yêu cầu cụ thể chi tiết hơn. 43
44. 2. Quy trình Kỹ thuật tạo Yêu cầu (Requirements Engineering Processes) 44
45. Mục tiêu  Miêu tả các hoạt động kỹ thuật chủ yếu tạo yêu cầu và các mối quan hệ của chúng  Giới thiệu các kỹ thuật cho việc khai phá và phân tích yêu cầu  Mô tả việc xác nhận yêu cầu và vai trò của duyệt lại yêu cầu  Thảo luận về vai trò của quản lý yêu cầu trong việc hỗ trợ các quy trình kỹ thuật yêu cầu khác 45
46. Chủ đề được đề cập (Topics covered)  Nghiên cứu tính khả thi (Feasibility studies)  Khai phá và phân tích yêu cầu (Requirements elicitation and analysis)  Xác thực yêu cầu (Requirements validation)  Quản lý yêu cầu (Requirements management) 46
47. Quy trình kỹ thuật tạo yêu cầu (1/2) (Requirements engineering processes)  Các quy trình sử dụng cho việc tạo yêu cầu rất rộng lớn tùy thuộc vào lĩnh vực ứng dụng, những người liên quan và tổ chức phát triển các yêu cầu.  Tuy nhiên, có một số hoạt động chung cho tất cả quy trình  Khai phá yêu cầu (Requirements elicitation)  Phân tích yêu cầu (Requirements analysis)  Xác thực yêu cầu (Requirements validation)  Quản lý yêu cầu (Requirements management) 47
48. Quy trình kỹ thuật tạo yêu cầu (2/2) (Requirements engineering processes) 48
49. Kỹ thuật tạo yêu cầu (Requirements engineering) 49
50. 1. Nghiên cứu tính khả thi (Feasibility studies)  Một nghiên cứu khả thi quyết định xem hệ thống được đề xuất có đáng giá hay không  Đây là một nghiên cứu ngắn để tập trung kiểm tra:  Liệu hệ thống đóng góp vào các mục tiêu của công ty?  Liệu hệ thống có thể được kỹ nghệ hóa sử dụng công nghệ hiện tại và trong phạm vi ngân sách?  Liệu hệ thống có thể được tích hợp với các hệ thống khác đang được sử dụng? 50
51. Thực hiện nghiên cứu khả thi (Feasibility study implementation)  Dựa trên đánh giá thông tin (những gì được yêu cầu), thu thập thông tin và viết báo cáo  Đặt câu hỏi cho những người trong công ty  Điều gì xảy ra nếu hệ thống này không được thực thi?  Những vấn đề của quy trình hiện tại là gì?  Hệ thống được đề xuất sẽ giúp đỡ như thế nào?  Những vấn đề của tích hợp là gì?  Công nghệ mới có cần thiết không? Những kỹ năng nào?  Các phương tiện gì phải được hỗ trợ bởi hệ thống đề xuất? 51
52. 2. Khai phá và phân tích yêu cầu (Requirements elicitation and analysis)  Liên quan đến nhân viên kỹ thuật làm việc với khách hàng để tìm hiểu về các lĩnh vực ứng dụng, các dịch vụ mà hệ thống nên cung cấp và những rằng buộc hoạt động của hệ thống.  Có thể liên quan đến người dùng cuối, nhà quản lý, kỹ sư tham gia bảo trì, chuyên gia về lĩnh vực đó, tổ chức công đoàn, v.v. Đây là gọi các bên liên quan (stakeholders) 52
53. Khai phá yêu cầu (Requirements discovery)  Là quá trình thu thập thông tin về những hệ thống đề xuất và hiện có, sau đó đưa ra các yêu cầu người dùng và yêu cầu hệ thống từ các thông tin này.  Nguồn thông tin bao gồm tài liệu, các bên liên quan đến hệ thống và các đặc tả của các hệ thống tương tự. 53
54. Bên liên quan trong hệ thống ATM (ATM stakeholders)  Khách hàng ngân hàng (Bank customers)  Đại diện của các ngân hàng khác (Representatives of other banks)  Quản lý ngân hàng (Bank managers)  Nhân viên tính toán (Counter staff)  Quản trị viên cơ sở dữ liệu (Database administrators)  Quản lý an ninh (Security managers)  Bộ phận quảng cáo (Marketing department)  Kỹ sư bảo trì phần cứng và phần mềm (Hardware and software maintenance engineers)  Người điều hành ngân hàng (Banking regulators) 54
55. Khó khăn trong phân tích yêu cầu (Problems of requirements analysis)  Các bên liên quan không biết mình thực sự muốn gì  Các bên liên quan phát biểu yêu cầu theo thuật ngữ riêng của họ  Các bên liên quan khác nhau có thể có các yêu cầu xung đột.  Các yếu tố về tổ chức và chính trị có thể ảnh hưởng đến yêu cầu hệ thống.  Các yêu cầu thay đổi trong quá trình phân tích. Các bên liên quan mới có thể xuất hiện và môi trường kinh doanh thay đổi. 55
56. 2.1. Quan điểm (Viewpoints)  Quan điểm là một cách cấu trúc các yêu cầu để biểu diễn những khía cạnh khác nhau của các bên liên quan.  Các bên liên quan có thể được phân loại dựa trên các quan điểm khác nhau.  Sự phân tích đa góc độ này rất quan trọng khi không có cách nào chính xác để phân tích các yêu cầu hệ thống. 56
57. Các kiểu quan điểm (Types of viewpoint)  Quan điểm tương tác (Interactor viewpoints)  Con người hoặc các hệ thống khác tương tác trực tiếp với hệ thống.  Trong máy ATM, cơ sở dữ liệu khách hàng và tài khoản là những quan điểm tương tác.  Quan điểm gián tiếp (Indirect viewpoints)  Các bên liên quan tự họ không sử dụng hệ thống nhưng ảnh hưởng đến các yêu cầu.  Trong máy ATM, nhân viên quản lý và an ninh là những quan điểm gián tiếp.  Quan điểm miền (Domain viewpoints)  Đặc điểm và rằng buộc về miền ảnh hưởng đến những yêu cầu.  Trong máy ATM, một ví dụ là tiêu chuẩn cho truyền thông liên ngân hàng. 57
58. Nhận dạng quan điểm (Viewpoint identification)  Nhận dạng quan điểm sử dụng  Nhà cung cấp và người nhận của dịch vụ hệ thống;  Các hệ thống tương tác trực tiếp với hệ thống đang cần xác định;  Các quy định và tiêu chuẩn (regulations and standards);  Nguồn của các yêu cầu kinh doanh và phi chức năng;  Các kỹ sư phải phát triển và bảo trì hệ thống;  Quảng cáo và quan điểm kinh doanh khác. 58
59. Phân cấp quan điểm của LIBSYS (LIBSYS viewpoint hierarchy) 59
60. 2.2. Chất vấn (Interviewing)  Trong cuộc chất vấn chính thức hoặc không chính thức, nhóm tạo yêu cầu sẽ đặt câu hỏi cho các bên liên quan về hệ thống mà họ sử dụng và hệ thống sẽ được phát triển.  Có hai kiểu chất vấn  Chất vấn kín, khi mà một tập các câu hỏi định nghĩa trước sẽ được trả lời.  Chất vấn mở khi không có chương trình nghị sự được xác định trước và một loạt vấn đề được đề cập với các bên liên quan. 60
61. Thực hành Chất vấn (Interviews in practice)  Thông thường kết hợp giữa chất vấn đóng và chất vấn mở.  Chất vấn là tốt để có được sự hiểu biết tổng thể về những gì các bên liên quan làm và cách mà họ có thể tương tác với hệ thống. 61
62. Người chất vấn hiệu quả (Effective interviewers)  Người chất vấn nên có một đầu óc cởi mở, sẵn sàng lắng nghe các bên liên quan và không nên có những ý tưởng ban đầu về các yêu cầu.  Người chất vấn nên nhắc người được chất vấn bằng một câu hỏi hay một đề nghị và không nên chỉ đơn giản là mong đợi họ phản hồi một câu hỏi kiểu như 'Bạn muốn điều gì'. 62
63. 2.3. Kịch bản (Scenarios)  Kịch bản là những ví dụ thực tế trong cuộc sống về cách một hệ thống có thể được sử dụng.  Kịch bản nên bao gồm:  Một mô tả về tình trạng ban đầu;  Một mô tả về luồng bình thường của các sự kiện;  Một mô tả về điều gì có thể khiến sai sót xảy ra;  Thông tin về các hoạt động đồng thời khác;  Một mô tả về trạng thái khi kịch bản kết thúc. 63
64. Kịch bản của LIBSYS (1/2) (LIBSYS scenario) Giả định ban đầu: Người dùng đã đăng nhập vào hệ thống LIBSYS và đã tìm thấy tạp chí chứa bản sao của bài báo. Bình thường: Người dùng chọn bài báo để sao chép. Sau đó, anh/chị ấy sẽ được hệ thống nhắc để cung cấp thông tin đăng ký cho tạp chí hoặc chỉ ra cách họ sẽ trả tiền cho bài báo. Những phương thức thanh toán thay thế là bằng thẻ tín dụng hoặc bằng cách trích dẫn số tài khoản của tổ chức. Sau đó, người dùng sẽ được yêu cầu điền vào một mẫu bản quyền để lưu giữ chi tiết của giao dịch và sau đó họ gửi mẫu này vào hệ thống LIBSYS. Mẫu bản quyền được kiểm tra, và nếu OK, phiên bản PDF của bài báo sẽ được tải xuống khu vực làm việc LIBSYS trên máy tính của người dùng và người dùng được thông báo rằng bài báo đã có sẵn. Người dùng được yêu cầu chọn một máy in và một bản sao của bài báo sẽ được in ra. Nếu bài báo đã được gắn cờ 'chỉ in' thì nó sẽ bị xóa khỏi hệ thống của người dùng khi người dùng đã xác nhận rằng việc in đã hoàn tất. 64
65. Kịch bản của LIBSYS (2/2) (LIBSYS scenario) Điều có thể khiến sai sót xảy ra: Người dùng có thể không điền đúng trong mẫu bản quyền. Trong trường hợp này, mẫu đó phải được đưa lại cho người dùng để chỉnh sửa. Nếu mẫu đó được gửi lại mà vẫn không chính xác thì yêu cầu của người dùng về bài báo bị từ chối. Việc thanh toán có thể bị hệ thống từ chối. Yêu cầu của người dùng về bài báo bị từ chối. Bài báo có thể tải xuống không thành công. Hãy thử lại cho đến khi thành công hoặc khi người dùng chấm dứt phiên làm việc. Có thể không in được bài báo. Nếu bài báo không được gắn cờ 'chỉ in' thì nó sẽ được giữ trong không gian làm việc của LIBSYS. Nếu không, bài báo sẽ bị xóa và tài khoản của người dùng được cộng thêm chi phí của bài báo. Các hoạt động khác: Tải đồng thời các bài báo khác. Trạng thái hệ thống khi hoàn thành: Người dùng đăng nhập. Bài báo tải về đã bị xóa khỏi không gian làm việc của LIBSYS nếu nó đã được gán cờ là chỉ in (print-only) 65
66. Những trường hợp sử dụng (Use cases)  Use-case là một kỹ thuật dựa trên kịch bản trong UML giúp xác định các tác nhân trong một tương tác và mô tả chính tương tác đó.  Một tập hợp các use-case nên mô tả tất cả các tương tác có thể với hệ thống.  Sơ đồ trình tự (sequence diagram) có thể được sử dụng để thêm chi tiết cho use-case bằng cách hiển thị trình tự xử lý sự kiện trong hệ thống. 66
67. Use-case cho việc in bài báo (Article printing use-case) 67
68. Các use-case của LIBSYS (LIBSYS use cases) 68
69. Sơ đồ trình tự cho in bài báo (Sequence diagram for article printing) 69
70. 4. Xác thực yêu cầu (Requirements validation)  Liên quan đến việc chứng minh rằng các yêu cầu sẽ định nghĩa một hệ thống mà khách hàng thực sự muốn.  Chi phí của một lỗi yêu cầu là cao vì thế xác thực yêu cầu là rất quan trọng  Sửa một lỗi yêu cầu sau khi phát hành có thể mất chi phí lên đến 100 lần so với sửa một lỗi cài đặt. 70
71. Kiểm tra yêu cầu (Requirements checking)  Tính hiệu lực (validity).  Hệ thống có cung cấp các chức năng hỗ trợ tốt nhất nhu cầu của khách hàng không?  Tính nhất quán (consistency).  Có bất kỳ yêu cầu xung đột nào không?  Tính hoàn thiện (completeness).  Có phải tất cả các chức năng mà khách hàng yêu cầu đã được cài đặt?  Tính hiện thực (realism).  Các yêu cầu có thể được thực hiện với ngân sách và công nghệ sẵn có không?  Khả năng kiểm chứng (verifiability).  Các yêu cầu có thể được kiểm tra không? 71
72. Những kỹ thuật xác thực yêu cầu (Requirements validation techniques)  Đánh giá lại yêu cầu (Requirements reviews)  Phân tích thủ công có hệ thống của các yêu cầu  Tạo nguyên mẫu (Prototyping)  Sử dụng một mô hình có thể thực thi của hệ thống để kiểm tra các yêu cầu  Tạo các trường hợp thử nghiệm (Test-case generation)  Phát triển những bài kiểm tra cho các yêu cầu 72
73. Đánh giá lại yêu cầu (Requirements reviews)  Việc đánh giá lại thường xuyên nên được tổ chức trong lúc định nghĩa các yêu cầu đang được xây dựng  Cả nhân viên khách hàng và nhà thầu đều nên tham gia vào việc đánh giá lại  Việc đánh giá lại có thể chính thức (với những tài liệu đã hoàn thành) hoặc không chính thức. Viêc giao tiếp tốt giữa các nhà phát triển, khách hàng và người dùng có thể giải quyết các vấn đề ở giai đoạn đầu 73
74. Kiểm tra việc đánh giá lại (Review checks)  Khả năng kiểm chứng (Verifiability).  Liệu yêu cầu có thể kiểm thử được trong thực tế không?  Tính hiểu (Comprehensibility).  Liệu yêu cầu có được hiểu đúng không?  Khả năng truy vết (Traceability).  Liệu nguồn gốc của yêu cầu có được phát biểu rõ ràng?  Khả năng thích nghi (Adaptability).  Liệu yêu cầu có thể được thay đổi mà không ảnh hưởng lớn tới các yêu cầu khác không? 74
75. Quản lý yêu cầu (Requirements management)  Quản lý yêu cầu là quá trình quản lý sự thay đổi yêu cầu trong quá trình kỹ thuật tạo yêu cầu và phát triển hệ thống.  Yêu cầu khó tránh khỏi việc không đầy đủ và không nhất quán  Các yêu cầu mới xuất hiện trong quá trình khi nhu cầu kinh doanh thay đổi và sự hiểu biết tốt hơn về hệ thống được phát triển;  Các quan điểm khác nhau có những yêu cầu khác nhau và điều này thường mâu thuẫn (contradictory). 75
76. Thay đổi yêu cầu (Requirements change)  Mức độ ưu tiên của các yêu cầu từ các quan điểm khác nhau thay đổi trong quá trình phát triển.  Khách hàng hệ thống có thể xác định các yêu cầu từ quan điểm kinh doanh mà mâu thuẫn với những yêu cầu người dùng cuối.  Môi trường kinh doanh và kỹ thuật của hệ thống thay đổi trong quá trình phát triển. 76
77. Tiến hóa yêu cầu (Requirements evolution) 77
78. Yêu cầu ổn định và không ổn định (Enduring and volatile requirements)  Yêu cầu ổn định (Enduring requirements).  Yêu cầu ổn định bắt nguồn từ hoạt động cốt lõi của tổ chức khách hàng.  VD: Một bệnh viện sẽ luôn luôn có bác sĩ, y tá, v.v. Có thể được bắt nguồn từ các mô hình miền.  Yêu cầu không ổn định (Volatile requirements).  Yêu cầu thay đổi trong quá trình phát triển hoặc khi hệ thống đi vào sử dụng.  VD: Trong một bệnh viện, yêu cầu bắt nguồn từ chính sách chăm sóc sức khoẻ 78
79. Phân loại yêu cầu (Requirements classification) Kiểu yêu cầu Miêu tả Yêu cầu có thể Những yêu cầu thay đổi do sự thay đổi của môi trường mà thay đổi công ty đang hoạt động. Ví dụ, trong các hệ thống bệnh (Mutable viện, quỹ kinh phí chăm sóc bệnh nhân có thể thay đổi và requirements) do đó cần phải thu thập thông tin điều trị khác nhau. Yêu cầu khẩn cấp Những yêu cầu nổi lên khi sự hiểu biết của khách hàng về hệ (Emergent thống phát triển trong quá trình phát triển hệ thống. Quá trình requirements) thiết kế có thể bộc lộ các yêu cầu khẩn cấp mới. Yêu cầu hệ quả Những yêu cầu là kết quả từ sự giới thiệu của hệ thống (Consequential máy tính. Giới thiệu hệ thống máy tính có thể thay đổi quy requirements) trình của tổ chức và mở ra những cách làm việc mới để tạo ra các yêu cầu hệ thống mới Yêu cầu tương Những yêu cầu phụ thuộc vào các hệ thống hoặc quá trình thích kinh doanh cụ thể trong một công ty. Khi điều này thay đổi (Compatibility này, những yêu cầu tương thích trên hệ thống được ủy thác requirements) hoặc phân phối cũng có thể phải tiến hóa theo. 79
80. Lập kế hoạch quản lý yêu cầu (Requirements management planning)  Trong quá trình kỹ thuật tạo yêu cầu, bạn phải lên kế hoạch cho những việc sau:  Nhận dạng yêu cầu (Requirements identification)  Cách những yêu cầu được nhận dạng riêng biệt;  Quy trình quản lý thay đổi  Quá trình tiếp theo khi phân tích yêu cầu thay đổi;  Chính sách truy xuất nguồn gốc (Traceability policies)  Số lượng thông tin về các mối quan hệ yêu cầu được duy trì;  Công cụ hỗ trợ CASE  Công cụ hỗ trợ cần thiết để giúp quản lý sự thay đổi yêu cầu; 80
81. Khả năng truy vết (Traceability)  Khả năng truy vết liên quan đến các mối quan hệ giữa các yêu cầu, nguồn gốc của chúng và thiết kế hệ thống  Khả năng truy vết nguồn (Source traceability)  Liên kết những yêu cầu với các bên liên quan đã đề xuất các yêu cầu này;  Khả năng truy vết yêu cầu (Requirements traceability)  Liên kết giữa các yêu cầu phụ thuộc;  Khả năng truy vết thiết kế (Design traceability)  Liên kết những yêu cầu với thiết kế; 81
82. Ma trận truy vết (Traceability matrix) 82
83. Tóm tắt những điểm chính (1/2) (Key points)  Quy trình kỹ thuật tạo yêu cầu bao gồm: nghiên cứu khả thi, khai phá và phân tích yêu cầu, đặc tả yêu cầu và quản lý yêu cầu.  Khai phá và phân tích yêu cầu là quá trình lặp liên quan đến hiểu biết miền, thu thập yêu cầu, phân loại, cấu trúc, ưu tiên và xác thực.  Hệ thống có nhiều bên liên quan với các yêu cầu khác nhau. 83
84. Tóm tắt những điểm chính (2/2) (Key points)  Các yếu tố xã hội và tổ chức ảnh hưởng đến các yêu cầu hệ thống.  Xác thực yêu cầu liên quan đến việc kiểm tra: tính hợp lệ, tính nhất quán, tính đầy đủ, tính hiện thực và khả năng kiểm chứng.  Những thay đổi kinh doanh chắc chắn dẫn đến thay đổi yêu cầu.  Quản lý yêu cầu bao gồm lập kế hoạch và quản lý thay đổi. 84
85. Tài liệu Tham khảo  Giáo trình chính: Software Engineering, Ian Sommerville, 8th Edition, 2007  Tham khảo:  Object-Oriented Software Engineering Practical Software Development using UML and Java, Lloseng.com, Lethbridge/Laganièr, 2001  Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm, Phạm Thị Quỳnh 85