Bài giảng Công nghệ phần mềm - Chương 3: Yêu cầu phần mềm - Hoàng Thị Hà

Nội dung text: Bài giảng Công nghệ phần mềm - Chương 3: Yêu cầu phần mềm - Hoàng Thị Hà

1. Chương 3: Yêu cầu phần mềm (Requirements) GV: Hoàng Thị Hà Email: htha@vnua.edu.vn 05/10/2018 1
2. Nội dung chính 1. Yêu cầu phần mềm 2. Tiến trình kỹ nghệ yêu cầu – Nghiên cứu khả thi – Thu thập và phân tích yêu cầu • Các phương pháp phát hiện yêu cầu • Các kỹ thuật phân tích yêu cầu – Làm tài liệu yêu cầu – Thẩm định yêu cầu 3. Đặc tả yêu cầu phần mềm 2
3. 1. Yêu cầu phần mềm • Tiêu chí gì quan trọng nhất đối với chất lượng phần mềm? Phần mềm thỏa mãn được yêu cầu của người dùng • Yêu cầu phần mềm: Những gì người ta muốn có trong phần mềm được phát triển. 3
4. Ví dụ Travel Agency: Yêu cầu người dùng • Hãng du lịch TravelGood đến gặp bạn (người làm phần mềm) và đề nghị làm dự án phần mềm sau: – Mô tả bài toán / yêu cầu người dùng TravelGood muốn cung cấp cho khách hàng của họ một ứng dụng đặt vé và lập kế hoạch du lịch. Ứng dụng này cần cho phép khách lập kế hoạch về các chuyến bay và khách sạn. Đầu tiên, khách hàng có thể sắp xếp một chuyến đi, sau đó đặt vé và đặt phòng khách sạn cho chuyến đi đó. Người dùng có thể lập kế hoạch cho nhiều chuyến đi. Ngoài ra, phần mềm còn cho phép hủy các chuyến đã đặt. 4
5. Ví dụ Travel Agency: Yêu cầu hệ thống • Sau khi nhận làm phần mềm cho TravelGood đội phát triển chi tiết hóa thành các yêu cầu hệ thống: 1. Người dùng có thể lập kế hoạch một chuyến đi bằng cách chọn một trình tự các điểm đến, rồi lưu lại. (kèm theo sơ đồ mô tả kịch bản ca sử dụng) 2. Hệ thống cần là ứng dụng Web, chạy được tại tất cả các hệ điều hành và hầu hết các trình duyệt 3. Ứng dụng Web phải triển khai được tại các server tiêu chuẩn như GlassFish hoặc Tomcat 4. Hệ thống phải dễ sử dụng: đạt một test usability (kèm chi tiết cụ thể) 5. 5
6. Project: Hệ thống quản lý luận văn cao học • Học viên cao học ngành CNTT cần làm luận văn tốt nghiệp. Mỗi luận văn có 01 giáo viên hướng dẫn. Trong quá trình làm luận văn, học viên có những hoạt động sau mà giáo vụ Khoa cần quản lý: – Học viên đăng ký làm luận văn (đề cương và giáo viên hướng dẫn) – Báo cáo tiến độ theo đợt do Khoa tổ chức, học viên cần đăng ký và có giáo viên hướng dẫn đồng ý, khi báo cáo thì hội đồng có ghi lại nhận xét. – Bảo vệ luận văn theo đợt, do Khoa tổ chức, giáo viên hướng dẫn đồng ý. 6
7. Software requirements Hệ thống quản lý luận văn cao học • Học viên – Được cấp tài khoản sử dụng hệ thống – có thể đăng ký đề tài cùng với giáo viên hướng dẫn theo quy trình (các bước trong sơ đồ gắn kèm) – có thể tra cứu được tên và thông tin giáo viên – có thể xem danh sách đề tài đã được đăng ký • Giáo vụ – Xem danh sách học viên đã đăng ký đề tài – Tạo tài khoản cho học viên theo danh sách • 1 học viên tối đa 1 luận văn và 1 giáo viên hướng dẫn • 1 giáo viên được hướng dẫn nhiều học viên • Hệ thống có giao diện Web • HỌc viên chỉ có thể sửa thông tin của bản thân • Cho phép 1000 người sử dụng song song. • Chạy được trên IE, Chrome, Cốc Cốc, Firefox, Opera Mini, Safari. 7
8. Ví dụ khác Đặc tả yêu cầu người dùng 1. Phần mềm phải cung cấp một phương tiện để biểu diễn và truy nhập các file bên ngoài được tạo bằng các công cụ khác. Đặc tả yêu cầu hệ thống 1.1. Người dùng cần được cung cấp tiện ích để định nghĩa kiểu của các file ngoài. 1.2 Mỗi kiểu file ngoài có thể được biểu diễn dưới dạng một biểu tượng trên phần hiển thị của người dùng. 1.3 Mỗi kiểu file ngoài có thể có một công cụ có thể dùng cho loại file đó. 1.4 Cần cung cấp các tiện ích để người dùng có thể định nghĩa biểu tượng cho file ngoài. 1.5 Khi một người dùng chọn một biểu tượng đại diện cho một file ngoài, hiệu ứng của việc chọn đó là gọi công cụ tương ứng với kiểu của file đó để chạy nó. 88
9. Yêu cầu người dùng / Yêu cầu hệ thống • Yêu cầu người dùng - User requirements – Các phát biểu bằng ngôn ngữ tự nhiên cộng với các sơ đồ về các dịch vụ mà hệ thống cung cấp và các ràng buộc về vận hành. – Được viết cho khách hàng. • Yêu cầu hệ thống – System requirements – Một tài liệu có cấu trúc bao gồm các mô tả chi tiết về các chức năng và dịch vụ của hệ thống cùng với các ràng buộc về vận hành. – Định nghĩa cái gì cần được cài đặt • Có thể là một phần của một hợp đồng giữa khách hàng và người nhận thầu. 9
10. Ví dụ yêu cầu hệ thống Identifier Priority Requirement The system shall keep the door locked at all times, unless commanded otherwise by authorized user. When the REQ1 5 lock is disarmed, a countdown shall be initiated at the end of which the lock shall be automatically armed (if still disarmed). REQ2 2 The system shall lock the door when commanded by pressing a dedicated button. REQ3 5 The system shall, given a valid key code, unlock the door and activate other devices. The system should allow mistakes while entering the key code. However, to resist “dictionary attacks,” the number REQ4 4 of allowed failed attempts shall be small, say three, after which the system will block and the alarm bell shall be sounded. REQ5 2 The system shall maintain a history log of all attempted accesses for later review. REQ6 2 The system should allow adding new authorized persons at runtime or removing existing ones. The system shall allow configuring the preferences for device activation when the user provides a valid key code, REQ7 2 as well as when a burglary attempt is detected. The system should allow searching the history log by specifying one or more of these parameters: the time frame, REQ8 1 the actor role, the door location, or the event type (unlock, lock, power failure, etc.). This function shall be available over the Web by pointing a browser to a specified URL. The system should allow filing inquiries about “suspicious” accesses. This function shall be available over the REQ9 1 05/10/2018 Web. 10
11. Yêu cầu chức năng / phi chức năng • Yêu cầu chức năng – functional requirement: – Người dùng có thể lập kế hoạch một chuyến đi, đặt vé, đặt phòng, lưu một kế hoạch để sau này sẽ đặt vé đặt phòng • Yêu cầu phi chức năng – non-functional requirement: – Hệ thống cần là ứng dụng Web, chạy được tại tất cả các hệ điều hành và hầu hết các trình duyệt – Ứng dụng Web phải triển khai được tại các server tiêu chuẩn như GlassFish hoặc Tomcat – Hệ thống phải dễ sử dụng – phải đạt một test usability 11
12. – “Hệ thống cần là ứng dụng Web, chạy được tại tất cả các hệ điều hành và hầu hết các trình duyệt” • Không rõ ràng!!!! 12
13. Các loại yêu cầu phi chức năng Non-functional chi tiết tại requir ements GT Product Organisational External requir ements requir ements requir ements Efficiency Relia bility Portability Inter oper ability Ethical requir ements requir ements requir ements requir ements requir ements Usability Deli very Implementa tion Standar ds Leg islative requir ements requir ements requir ements requir ements requir ements Performance Space Pri vacy Safety requir ements requir ements requir ements requir ements13
14. Yêu cầu chức năng và phi chức năng • Yêu cầu chức năng – Phát biểu về các dịch vụ mà hệ thống cần cung cấp, • Hệ thống cần phản ứng như thế nào với các input cụ thể • Hệ thống cần ứng xử như thế nào trong các tình huống cụ thể. • Yêu cầu phi chức năng – Ràng buộc về các dịch vụ hay chức năng của hệ thống • Chẳng hạn ràng buộc về thời gian, về quy trình phát triển, về các chuẩn v.v 14
15. Đặc điểm của yêu cầu được diễn đạt tốt • Kiểm thử được – testability – Test được (thủ công hoặc tự động) • Đo được – Ví dụ về yêu cầu không đo được: • Hệ thống cần dễ sử dụng bởi các nhân viên và cần được tổ chức sao cho người dùng ít làm nhầm nhất – Đo được: • Nhân viên cần sử dụng được toàn bộ các chức năng của hệ thống sau 04 tiếng huấn luyện. Sau huấn luyện, số lỗi trung bình mà một người dùng có kinh nghiệm phạm phải trong mỗi giờ không vượt quá 02 lỗi 15
16. Các độ đo có thể sử dụng Đặc điểm Độ đo Tốc độ Số giao dịch được xử lý mỗi giây Thời gian đáp ứng mỗi sự kiện Tần xuất làm tươi màn hình Kích thước M Bytes Số lượng ROM chip Dễ sử dụng Thời gian huấn luyện Số trang tài liệu hướng dẫn sử dụng Độ tin cậy Reliability Khoảng thời gian trung bình giữa các sự cố Xác suất hệ thống không hoạt động tại một thời điểm Số lần xảy ra sự cố trong mỗi giờ Vững mạnh - Robustness Thời gian cần để hoạt động lại sau sự cố Phần trăm sự kiện gây sự cố Xác xuất hỏng dữ liệu do sự cố Khả chuyển - Portability Số lượng hệ thống đích 16
17. 2. Tiến trình kỹ nghệ yêu cầu Requirements Requirements Requirements Feasibility Study elicitation and specification validation analysis User and Feasibility Requirements System models system report document requirements 17
18. Kĩ nghệ yêu cầu Requirements System requirements specification Specification and modeling User requirements specification Business requirements System requirements specification elicitation User requirements Feasibility study elicitation Prototyping Requirements Reviews elicitation Requirements validation System requirements document 18
19. Nghiên cứu khả thi Feasibility studies • Một nghiên cứu ngắn, tập trung, nhằm kiểm tra xem – Hệ thống có đóng góp cho các mục tiêu của tổ chức hay không? – Hệ thống có thể được phát triển bằng công nghệ hiện hành và trong phạm vi ngân sách hay không? – Hệ thống có thể được tích hợp với các hệ thống khác đang được sử dụng hay không? 19
20. Thực hiện nghiên cứu khả thi • Dựa trên đánh giá thông tin (cái gì cần), thu thập thông tin và viết báo cáo. • Các câu hỏi dành cho nhân viên của tổ chức – Nếu hệ thống không được cài đặt thì sao? – Quy trình hiện hành có những vấn đề gì? – Hệ thống được đề xuất sẽ giúp được gì và như thế nào? – Thông tin có được chuyển đến/đi từ các hệ thống khác không? – Có cần công nghệ mới hay không? Cần kĩ năng gì? – Hệ thống mới cần hỗ trợ những tiện ích nào? 20
21. Thực hiện nghiên cứu khả thi • Nguồn thông tin có thể là: – Người quản lý các phòng ban nơi hệ thống sẽ được sử dụng – Kỹ sư phần mềm quen thuộc với loại hệ thống được đề xuất – Chuyên gia công nghệ – Người dùng cuối của hệ thống, v.v. • Thông thường, bạn nên thử và hoàn thành tính khả thi nghiên cứu trong hai hoặc ba tuần. • Khi thông tin có sẵn, sau đó bạn viết báo cáo nghiên cứu khả thi. Bạn nên đưa ra một khuyến nghị về việc có nên tiếp tục phát triển hệ thống hay không. Trong báo cáo, bạn có thể đề xuất các thay đổi đối với phạm vi, ngân sách và lịch biểu của hệ thống và đề xuất các yêu cầu cấp cao hơn nữa cho hệ thống. 21
22. Nội dung chính • Yêu cầu phần mềm là gì? • Tầm quan trọng của yêu cầu phần mềm trong quá trình phát triển phần mềm • Kĩ nghệ yêu cầu – Nghiên cứu khả thi – Thu thập và phân tích yêu cầu – Làm tài liệu yêu cầu – Thẩm định yêu cầu 22
23. Tiến trình thu thập và phân tích yêu cầu 23
24. Các hoạt động quy trình • Phát hiện – Tương tác với các stakeholder để tìm ra yêu cầu của họ. – Các yêu cầu về miền chuyên dụng cũng được phát hiện tại bước này. • Phân loại và tổ chức – Phân nhóm các yêu cầu có liên quan đến nhau và tổ chức chúng thành các cụm có quan hệ gắn kết với nhau. • Đặt thứ tự ưu tiên và giải quyết mâu thuẫn giữa các yêu cầu – Xếp thứ tự ưu tiên cho các yêu cầu và giải quyết các xung đột/mâu thuẫn giữa các yêu cầu. • Documentation – Viết tài liệu – Ghi lại các yêu cầu làm tài liệu đầu vào cho vòng xoắn tiếp theo. 24
25. Vòng xoắn ốc yêu cầu Phân loại và tổ chức Đánh giá độ ưu tiên và Classification and thương thảo organization Prioritization and negotiation Phát hiện mới Viết tài liệu Discovery Documentation 25
26. Phát hiện yêu cầu • Quy trình thu thập thông tin về hệ thống đề xuất và các hệ thống sẵn có, gạn lọc 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. 26
27. Thu thập yêu cầu từ đâu? • Làm việc với khách hàng để tìm hiểu thông tin về – Miền ứng dụng, – Các dịch vụ mà hệ thống cần cung cấp và – Các ràng buộc về vận hành hệ thống. • Những người có thể cần tham gia: khách hàng, người sử dụng, lập trình viên, chuyên gia kĩ thuật, – stakeholders. • Tài liệu về hoạt động doanh nghiệp • Đặc tả của các hệ thống tương tự. 27
28. Ví dụ: ATM stakeholder • Khách hàng của ngân hàng (người sử dụng dịch vụ) • Đại diện của các ngân hàng khác (ATM của ngân hàng này có thể dùng để giao dịch với ngân hàng khác) • Quản lý ngân hàng (dùng thông tin quản lý từ hệ thống ATM) • Nhân viên lại các chi nhánh ngân hàng (vận hành hệ thống) • Quản trị cơ sở dữ liệu (tích hợp hệ thống với CSDL của ngân hàng) • Quản lý an ninh • Phòng marketing (muốn dùng ATM để quảng cáo) • Kĩ sư bảo trì phần mềm và phần cứng • Những người điều phối hệ thống ngân hàng quốc gia (đảm bảo hệ thống tuân theo nguyên tắc chung) 28
29. Các kĩ thuật phát hiện yêu cầu • Lấy yêu cầu – Phỏng vấn, điều tra bằng bảng câu hỏi – Danh mục khái niệm (glossary) để hiểu miền ứng dụng – Ca sử dụng / user story – Quan sát – Nghiên cứu tài liệu – Joint Application Design – JAD – Làm bản mẫu • Đặc tả yêu cầu – Danh mục khái niệm – Use case / user story 29
30. Khó khăn khi phân tích yêu cầu • Stakeholder không biết họ thực sự muốn gì. • Stakeholder diễn đạt yêu cầu bằng các thuật ngữ của họ. • Các stakeholder khác nhau có thể có các yêu cầu xung đột. • Các nhân tố 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 ngay trong quá trình phân tích – Chẳng hạn khi môi trường doanh nghiệp thay đổi. 30
31. Nội dung chính • Yêu cầu phần mềm là gì? • Tầm quan trọng của yêu cầu phần mềm trong quá trình phát triển phần mềm • Kĩ nghệ yêu cầu – Nghiên cứu khả thi – Thu thập và phân tích yêu cầu • Use case – ca sử dụng – Làm tài liệu yêu cầu – Thẩm định yêu cầu 31
32. Scenario • Kịch bản (scenario) là các ví dụ đời thực về việc hệ thống có thể được sử dụng như thế nào. • Các kịch bản nên bao gồm – Một miêu tả về tình huống ban đầu – Một miêu tả về luồng sự kiện thông thường – Một miêu tả về những trục trặc gì có thể xảy ra – Thông tin về các hoạt động xảy ra đồng thời – Một miêu tả về trạng thái khi kịch bản kết thúc 32
33. Kịch bản LIBSYS (1) Initial Assumption: Người dùng đã đăng nhập hệ thống LIBSYS và đã tìm thấy tạp chí có đăng tài liệu cần tìm. Normal: •Người dùng chọn tài liệu cần copy. Hệ thống sẽ yêu cầu người dùng nhập thông tin thuê bao hoặc chọn cách trả phí dùng tài liệu. Có thể thanh toán bằng thẻ tín dụng hoặc dùng số tài khoản của một tổ chức. •Sau đó người dùng được yêu cầu điền một form bản quyền trong đó có chi tiết về giao dịch này, rồi submit form đó cho hệ thống LIBSYS. •Hệ thống kiểm tra form bản quyền, nếu OK, bản PDF của tài liệu sẽ được tải xuống máy tính của người dùng và người dùng được thông báo về việc này. Sau đó người dùng được chọn một máy in, và tài liệu sẽ được in tại đó. Nếu tài liệu đã được gắn cờ ‘print-only’ thì nó sẽ được xóa khỏi máy của người dùng ngay sau khi người dùng khẳng định rằng đã in xong. 33
34. Kịch bản LIBSYS (2) What can go wrong: •Người dùng có thể điền form sai. Khi đó hệ thống cần hiện lại form để người dùng sửa lại. Nếu form được submit sau đó vẫn sai thì hủy yêu cầu đọc tài liệu của người dùng. •Hệ thống có thể không chấp nhận giao dịch thanh toán tiền. Hủy yêu cầu đọc tài liệu của người dùng. •Việc download tài liệu có thể thất bại. Làm 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 tài liệu. Nếu bài báo không có gắn cờ ‘print-only’ thì giữ nó trong workspace của LIBSYS. Nếu không, xóa tài liệu và hoàn lại chi phí cho người dùng. Other activities: Song song download các tài liệu khác nhau. System state on completion: Người dùng đang ở trạng thái đăng nhập. Nếu tài liệu có gắn cờ 'print-only' thì nó đã bị xóa khỏi LIBSYS workspace. 34
35. Use case • Ca sử dụng (use-case) là một kĩ thuật kiểu kịch bản bằng ngôn ngữ UML – Chỉ rõ các actor trong một tương tác và – Mô tả chính tương tác đó. • Một bộ ca sử dụng có thể mô tả được tất cả các tương tác có thể đối với hệ thống. • Có thể dùng các sơ đồ tuần tự (sequence diagram) để bổ sung chi tiết cho các ca sử dụng – Minh họa chuỗi xử lý sự kiện. 35
36. use-case in tài liệu In tài liệu 36
37. LIBSYS use case 37
38. Article printing 38
39. Ca sử dụng – Use case • Use case: – Là một tập các kịch bản tương tác giữa một hoặc vài actor với hệ thống nhằm thực hiện một mục tiêu chung • Sơ đồ use case (đồ họa) – Sơ đồ mô tả tổng quan các ca sử dụng của một hệ thống và ai dùng chức năng nào • Mô tả chi tiết use case (văn bản) – Mô tả chi tiết tương tác giữa người dùng và hệ thống trong một tập các kịch bản 39
40. Ví dụ Use Case: Travel Agency use case list available flights Tên: list available flights Mô tả: người dùng xem danh sách các chuyến bay có thể đặt Actor: người dùng Kịch bản chính: 1. người dùng nhập thông tin về thành phố cần đến, ngày đi và ngày đến 2. hệ thống cung cấp một danh sách các chuyến bay phù hợp kèm theo giá vé và booking number Kịch bản phụ: 1a. Dữ liệu vào không đúng 2. Hệ thống báo lỗi và kết thúc, use case quay lại từ đầu 2.a. Không có chuyến bay nào phù hợp 3. Use case quay lại từ đầu Ghi chú: Dữ liệu vào là đúng nếu tên thành phố đúng, ngày đi và ngày đến là các ngày hợp lệ, ngày đi sớm hơn ngày đến, ngày đến muộn hơn thời điểm hiện tại ít nhất 2 ngày, và ngày đi không muộn hơn một năm kể từ hiện tại 40
41. Ví dụ Use Case: Travel Agency use case list available flights 1. người dùng nhập thông tin về thành phố cần đến, ngày đi và ngày đến 2. hệ thống cung cấp một danh sách các chuyến bay phù hợp kèm theo giá vé và booking number 1a. Dữ liệu vào không đúng 2. Hệ thống báo lỗi và kết thúc, use case quay lại từ đầu 2.a. Không có chuyến bay nào phù hợp 3. Use case quay lại từ đầu 1 1a 2 2a 3 41
42. Sơ đồ Use case 42
43. Các loại sơ đồ use case • Business use case – Một phần của tài liệu yêu cầu người dùng – Mô tả chức năng từ góc nhìn của người dùng • System use case – Một phần của tài liệu kĩ thuật của đội phát triển – Mang tính kĩ thuật và chi tiết hơn – Tập trung vào mô tả những gì cần cài đặt 43
44. Yêu cầu chức năng của TravelAgency: các business use case 44
45. Yêu cầu chức năng của TravelAgency: System use case, phần 1: manage trip 45
46. Yêu cầu chức năng của TravelAgency: System use case, phần 2: plan trip 46
47. Yêu cầu chức năng của TravelAgency: System use case, phần 3: manage flights 47
48. Yêu cầu chức năng của TravelAgency: System use case, phần 4: manage hotels 48
49. Mẫu tài liệu mô tả use case Mẫu dùng cho môn học này • Tên: tên của use case • Mô tả: Mô tả ngắn gọn của use case – mục tiêu của ca sử dụng • Actor: một hoặc vài actor – nhân tố tương tác với hệ thống • Tiền điều kiện: các điều kiện hệ thống cần thỏa mãn để use case có thể hoạt động • Kịch bản chính: Mô tả chuỗi tương tác chính giữa actor và hệ thống – Chú ý! Chỉ nên mô tả hệ thống từ góc nhìn của người sử dụng • Các kịch bản phụ: Có thể chứa các kịch bản thất bại • Ghi chú: Dùng cho tất cả những gì cần thiết nhưng lại không phù hợp với các thể loại trên 49
50. Travel Agency. Mô tả chi tiết use case: list available flights Tên: list available flights Mô tả: người dùng xem danh sách các chuyến bay có thể đặt Actor: người dùng Kịch bản chính: 1. người dùng nhập thông tin về thành phố cần đến, ngày đi và ngày đến 2. hệ thống cung cấp một danh sách các chuyến bay phù hợp kèm theo giá vé và booking number Kịch bản phụ: 1a. Dữ liệu vào không đúng 2. Hệ thống báo lỗi và kết thúc, use case quay lại từ đầu 2.a. Không có chuyến bay nào phù hợp 3. Use case quay lại từ đầu Ghi chú: Dữ liệu vào là đúng nếu tên thành phố đúng, ngày đi và ngày đến là các ngày hợp lệ, ngày đi sớm hơn ngày đến, ngày đến muộn hơn thời điểm hiện tại ít nhất 2 ngày, và ngày đi không muộn hơn một năm kể từ hiện tại 50
51. Kịch bản • Tương tác giữa một actor và hệ thống – Người dùng tác động vào hệ thống – Hệ thống phản ứng – Các hiệu ứng quan trọng đối với người dùng / người dùng thấy • Hoạt động bên trong của hệ thống không phải là một phần của tương tác 51
52. Travel Agency. Mô tả chi tiết use case: cancel trip Tên: cancel trip Mô tả: người dùng hủy một chuyến đi đã đặt Actor: người dùng Tiền điều kiện: • Chuyến đi đã được đặt chỗ • Ngày đầu tiên của thời gian đặt phòng khách sạn hoặc chuyến bay phải muộn hơn thời điểm hiện tại ít nhất 1 ngày. Kịch bản chính: 1. Người dùng chọn chuyến đi để hủy 2. Hệ thống thông báo chi phí của việc hủy chuyến đi 3. Chuyến đi được chọn sẽ bị hủy sau khi người dùng khẳng định việc hủy 52
53. Travel Agency. Mô tả chi tiết use case: plan trip Use case này chứa (include) các use case khác Tên: plan trip Mô tả: người dùng lập kế hoạch một chuyến đi bao gồm khách sạn và các chuyến bay Actor: người dùng Kịch bản chính: Lặp đi lặp lại hoạt động bất kì trong danh sách sau cho đến khi xong 1. list available flights (use case) 2. add flight to trip (use case) 3. list available hotels (use case) 4. add hotel to trip (use case) 5. list trip (use case) 6. delete hotel from trip (use case) 7. delete flight from tip (use case) 53
54. Travel Agency. Mô tả chi tiết use case: save trip Tên: save trip Mô tả: người dùng đặt tên cho chuyến đi hiện hành và lưu lại cho sử dụng sau này Actor: người dùng Tiền điều kiện: chuyến đi hiện hành không rỗng Kịch bản chính: 1. Người dùng nhập tên cho chuyến đi Các kịch bản phụ: 1: tên nhập không hợp lệ 2: thông báo cho người dùng và kết thúc use case 1: tên trùng với tên của một chuyến khác 2: hỏi người dùng xem có nên ghi đè lên chuyến đã ghi lần trước hay không 3a: nếu người dùng đồng ý, ghi đè lên chuyến cũ 3b: nếu người dùng không đồng ý, kết thúc use case 54
55. Use case và ranh giới hệ thống • Use case và actor được xác định tùy theo ranh giới hệ thống TRAVEL AGENCY FRONT END BACK END List Search flights for fights Người dùng • Biên hệ thống: TravelAgency • Biên hệ thống: Front End TRAVEL AGENCY FRONT END List flights List flights BACK END Người dùng Người dùng 55
56. Thẩm định yêu cầu • (Requirement validation) quan tâm đến việc chứng tỏ rằng các yêu cầu định nghĩa được hệ thống mà khách hàng thực sự muốn. • Chi phí của lỗi yêu cầu cao đến mức công đoạn thẩm định rất quan trọng – Việc sửa một lỗi yêu cầu sau khi đã bàn giao phần mềm có thể tốn kém gấp 100 lần chi phí cho việc sửa một lỗi cài đặt. 56
57. Các tiêu chí cho thẩm định • Hiệu lực – Validity – Hệ thống có cung cấp những chức năng phục vụ tốt nhất yêu cầu của khách hàng hay không? • Nhất quán – Consistency – Có những yêu cầu nào xung đột nhau không? • Đầy đủ – Completeness – Có đủ các chức năng mà khách hàng đòi hỏi hay không? • Thực tế – Realism – Có thể cài đặt các yêu cầu trong phạm vi công nghệ và ngân sách cho phép hay không? • Kiểm định được – Verifiability – Có cách kiểm tra các yêu cầu xem chúng đã được thỏa mãn chưa hay không? 57
58. Kĩ thuật thẩm định yêu cầu • Duyệt yêu cầu – Requirements reviews – Đọc và phân tích lại một cách có hệ thống (không dùng chương trình tự động). • Phiên bản thử nghiệm – Prototyping – Dùng một mô hình chạy được của hệ thống để kiểm tra các yêu cầu (Chương 17) • Tạo các ca kiểm thử (test case) – Viết các test dành cho các yêu cầu để kiểm tra khả năng kiểm thử được. 58
59. Quản lý yêu cầu Yêu cầu phần mềm luôn luôn thay đổi! • Môi trường doanh nghiệp và kĩ thuật thay đổi – Phần cứng mới giao diện mới. – Luật thay đổi, nhu cầu doanh nghiệp thay đổi thay đổi chức năng • Khách hàng, người sử dụng thay đổi – Thay đổi chức năng • Xung đột giữa các yêu cầu mới nảy sinh, và giữa yêu cầu mới với yêu cầu cũ 59
60. Quản lý yêu cầu • Để quản lý yêu cầu, cần xác định – Định danh yêu cầu: Mỗi yêu cầu có định danh riêng để tiện cho việc tham chiếu giữa các yêu cầu và lần vết – Quy trình quản lý thay đổi: các hoạt động đánh giá ảnh hưởng và chi phí của thay đổi – Chính sách lần vết: cách ghi lại và lưu trữ quan hệ giữa các yêu cầu và giữa mỗi yêu cầu với thiết kế tương ứng với nó – Công cụ hỗ trợ: hỗ trợ thực hiện các công việc trên một cách có hiệu quả. CASE tool, spreadsheet, cơ sở dữ liệu 60
61. Quản lý thay đổi Xác định vấn đề Phân tích vấn đề, Phân tích thay đổi & Thực hiện đặc tả thay đổi đánh giá chi phí thay đổi Yêu cầu đã chỉnh sửa 05/10/2018 61
62. Quản lý thay đổi yêu cầu • Nên áp dụng cho tất cả các thay đổi được đề xuất đối với bộ yêu cầu. • Các giai đoạn chính – Phân tích vấn đề: Thảo luận về vấn đề của các yêu cầu và đề xuất thay đổi; Bổ sung chi tiết; Chốt lại những điểm sẽ thay đổi. – Phân tích thay đổi và đánh giá chi phí. Đánh giá hiệu ứng của thay đổi đối với các yêu cầu khác; Ra quyết định có thực hiện thay đổi hay không. – Thực hiện thay đổi. Cập nhật tài liệu yêu cầu và các tài liệu khác để thực hiện thay đổi đã xét. 62
63. 3. Đặc tả yêu cầu phần mềm 63
64. Khái niệm • Đặ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ả. • Tài liệu đặc tả yêu cầu là một tài liệu mô tả hướng khách hàng và được viết bởi ngôn ngữ của khách hàng. Khi đó có thể dùng ngôn ngữ tự nhiên và các khái niệm trừu tượng. • Tài liệu đặc tả yêu cầu (đặc tả chức năng) là mô tả hướng người phát triển, là cơ sở của hợp đồng làm phần mềm. Nó không được phép mơ hồ, nếu không sẽ dẫn đến sự hiểu nhầm bởi khách hàng hoặc người phát triển. Với một yêu cầu mơ hồ thì người phát triển sẽ thực hiện nó một cách rẻ nhất còn khách hàng thì không muốn vậy., 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 64
65. Các phương pháp đặc tả • Có hai phương pháp đặc tả: – Đặc tả phi hình thức – Đặc tả hình thức 65
66. Các tính chất cơ bản của Tài liệu đặc tả phần mềm – Đúng – Không nhập nhằng – Hoàn chỉnh – Chứng minh được – Ổn định – Dễ hiểu (bởi NSD) – Ngắn gọn, xúc tích 66
67. Cấu trúc tài liệu đặc tả • Kết quả của bước phân tích là tạo ra bản đặc tả yêu cầu phần mềm (Software Requirement Specification – SRS). Đặc tả yêu cầu phải chỉ rõ được phạm vi của sản phẩm, các chức năng cần có, đối tượng người sử dụng và các ràng buộc khi vận hành sản phẩm. Có nhiều chuẩn khác nhau trong xây dựng tài liệu, dưới đây là một định dạng SRS thông dụng (theo chuẩn của IEEE 830-1984). Cấu trúc của tài liệu đặc tả như sau: 67
68. Cấu trúc tài liệu đặc tả (theo chuẩn của IEEE – chuẩn tài liệu đặc tả yêu cầu) 1. Lời nói đầu 2. Giới thiệu – Mục đích – Phạm vi – Định nghĩa – Tài liệu tham khảo 3. Mô tả chung – Tổng quan về sản phẩm – Chức năng sản phẩm – Đối tượng người dùng – Ràng buộc tổng thể – Giả thiết và sự lệ thuộc 4. Yêu cầu chi tiết – Yêu cầu chức năng – Yêu cầu phi chức năng – Yêu cầu giao diện ngoài – . Yêu cầu hiệu suất – Ràng buộc thiết kế – Thuộc tính – Yêu cầu khác 5. Phụ lục 6. Mục lục 68
69. CÂU HỎI VÀ BÀI TẬP CHƯƠNG 3 1. Yêu cầu phần mềm là gì? Có những loại yêu cầu phần mềm gì? Cho ví dụ minh họa đối với hệ thống phần mềm nhúng cho máy rút tiền tự động ATM của các ngân hàng. 2. Có những loại tài liệu yêu cầu phần mềm nào? Đối tượng chính của những loại tài liệu yêu cầu này là ai? 3. Trình bày các bước của tiến trình phát hiện và phân tích yêu cầu. Trình bày các kỹ thuật khác nhau để nhận biết và phân tích yêu cầu. 4. Cấu trúc cơ bản của tài liệu yêu cầu gồm những mục gì? 5. Đặc tả yêu cầu phần mềm là gì? Có những hình thức đặc tả nào? Khi nào cần áp dụng những hình thức đặc tả này? 6. Hãy thu thập và phân tích yêu cầu và viết tài liệu đặc tả yêu cầu của Phần mềm Quản lý vật tư Khoa CNTT- Học viện Nông nghiệp Việt Nam 69
70. Question? 70