Bài giảng Thiết kế hệ thống thông tin: Chương 3 - Trần Thị Kim Chi

Chia sẻ: Hấp Hấp | Ngày: | Loại File: PDF | Số trang:81

Thêm vào BST

Báo xấu

68
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Bài giảng "Thiết kế hệ thống thông tin - Chương 3: Thu thập theo yêu cầu" cung cấp cho người học các kiến thức: Mục đích thu thập yêu cầu, khó khăn khi thu thập yêu cầu người dùng, các bước thu thập yêu cầu, phân loại yêu cầu, các phương pháp thu thập yêu cầu. Mời các bạn cùng tham khảo.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Bài giảng Thiết kế hệ thống thông tin: Chương 3 - Trần Thị Kim Chi

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM KHOA CÔNG NGHỆ THÔNG TIN Chương III Trần Thị Kim Chi 1
NỘI DUNG 1. Mục đích thu thập yêu cầu 2. Khó khăn khi thu thập yêu cầu người dùng 3. Các bước thu thập yêu cầu 4. Phân loại yêu cầu 5. Các phương pháp thu thập yêu cầu Trần Thị Kim Chi 2
MỤC ĐÍCH THU THẬP YÊU CẦU What is requirement? • A statement of a service the system must do OR • A statement of a constraint the system must satisfy Requirements described the “what” of a system, not the “how” Trần Thị Kim Chi 3
MỤC ĐÍCH THU THẬP YÊU CẦU • Why do we need requirement definition? Trần Thị Kim Chi 4
MỤC ĐÍCH THU THẬP YÊU CẦU • Xây dựng và duy trì sự thỏa thuận với khách hàng và các stakeholder khác trên hệ thống đang xây dựng • Giúp các nhà phát triển hệ thống hiểu tốt rõ hơn các yêu cầu của hệ thống. • Xác định phạm vi hệ thống • Cung cấp cơ sở để lên kế hoạch cho các lần lặp tiếp theo. • Cung cấp cơ sở để ước tính chi phí và thời gian để phát triển hệ thống. • Xác định giao diện người dùng của hệ thống. Trần Thị Kim Chi 5
KHÓ KHĂN KHI THU THẬP YÊU CẦU NGƯỜI DÙNG • Nhiều khách hàng không biết họ thực sự cần gì • Không đánh giá được những gì đang xảy ra trong tổ chức của họ • Khó khăn khi trình bày các ý kiến của họ với nhà phát triển phần mềm • Thường không biết nhiều về công nghệ thông tin Trần Thị Kim Chi 6
MỘT VÀI THỰC TẾ • Khách hàng đang quản lý 1 chuỗi các cửa hàng bán lẻ không thu nhiều lợi nhuận và cần 1 SW về tài chính. • Khách hàng cần thay đổi nghiệp vụ bán hàng. • SW không thể cải thiện được tình trạng Trần Thị Kim Chi 7
CÁC BƯỚC CỦA THU THẬP YÊU CẦU Các bước thực hiện: • Bước 1: Thu thập thông tin bằng các phương pháp khác nhau • Bước 2: Củng cố, bổ sung và hoàn thiện kết quả khảo sát • Bước 3: Tổng hợp kết quả khảo sát • Bước 4: Hợp thức hoá kết quả khảo sát Kết quả: • Hiểu miền nghiệp vụ của hệ thống – Banking, automobile manufacturing, ... • Xây dựng mô hình nghiệp vụ của khách hàng • Xác định yêu cầu của khách hàng đối với hệ thống Trần Thị Kim Chi 8
PHÂN LOẠI YÊU CẦU Trần Thị Kim Chi 9
YÊU CẦU NGHIỆP VỤ (BUSINESS REQUIREMENTS) • Biễu diễn các mục tiêu của tổ chức hay khách hàng yêu cầu hệ thống phải có • Yêu cầu nghiệp vụ thường do người tài trợ cho dự án, khách mua phần mềm, người quản lý các người dùng, bộ phận tiếp thị (maketing)…cung cấp • Thường được ghi nhận trong phần đặc tả (vision) và phạm vi (scope) của tài liệu, đôi khi còn được gọi là tuyên bố dự án (project charter) hay tài liệu yêu cầu thị trường (market requirements document) Trần Thị Kim Chi 10
YÊU CẦU NGƯỜI DÙNG (USER REQUIREMENTS) • Mô tả mục tiêu (goal) hay tác vụ (task) của người dùng đối với hệ thống. • Các cách để biểu diễn yêu cầu người dùng: – Use cases, scenario – Bảng event-response. • Yêu cầu người dùng mô tả cái (what) mà người dùng có thể làm đối với hệ thống. • Ví dụ: use case "Make a Reservation" dùng trong các website của hàng không, thuê xe, hay khách sạn. Trần Thị Kim Chi 11
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS ) • Mô tả yêu cầu mức cao đối với 1 sản phẩm, nó chứa các hệ thống con (subsystem) nào. • Một hệ thống có thể là toàn bộ phần mềm hay bao gồm các hệ thống con của phần mềm cũng như phần cứng. • Con người cũng là 1 phần hệ thống, vì vậy các chức năng hệ thống cũng có thể chỉ định cả vai trò của con người • Gồm 2 loại: – Yêu cầu chức năng (Functional requirement) – Yêu cầu phi chức năng (Non-functional requirement) Trần Thị Kim Chi 12
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS ) Xác định chức năng của phần mềm mà các nhà phát triển phải xây dựng để giúp người dùng hoàn thành nhiệm vụ của họ, thỏa mãn được yêu cầu nghiệp vụ. Đôi khi còn được gọi là behavioral requirements. Ví dụ: “The system shall e-mail a reservation confrimation the user” Trần Thị Kim Chi 13
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS )  Yêu cầu chức năng (Functional requirements): Yêu cầu chức năng chỉ ra những gì hệ thống làm, chúng thường quan hệ các use-case hay những qui tắc nghiệp vụ (business rule) • Một số yêu cầu chức năng • Chức năng tính toán • Chức năng lưu trữ • Chức năng tìm kiếm • Chức năng kết xuất • Chức năng backup, restore • Chức năng đa người dùng • Chức năng đa phương tiện… Trần Thị Kim Chi 14
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS )  Yêu cầu phi chức năng (Non-functional requirements): Không tập trung vào các chức năng của hệ thống mà chỉ tập trung vào các ràng buộc của hệ thống. Những ràng buộc về tiêu chuẩn, thời gian, qui trình phát triển…, chủ yếu là những yêu cầu về chất lượng.  Sáu loại chính của yêu cầu phi chức năng: security, privacy, usability, reliability, availability, and performance.  Ràng buộc: phản ảnh những đặc trưng của miền ứng dụng. Chúng có thể là những yêu cầu chức năng hay yêu cầu phi chức năng. Trần Thị Kim Chi 15
YÊU CẦU HỆ THỐNG (SYSTEM REQUIREMENTS ) Một số yêu cầu phi chức năng • Độ tin cậy, thời gian đáp ứng, các yêu cầu về lưu trữ… • Các chuẩn được sử dụng, các công cụ CASE, ngôn ngữ lập trình… • Yêu cầu của người sử dụng: dễ sử dụng, thân thiện • Ràng buộc về ngân sách • Phù hợp với các chính sách của tổ chức sử dụng hệ thống • Yêu cầu tương thích giữa phần cứng và phần mềm • Các yêu cầu từ các tác nhân ngoài khác… Trần Thị Kim Chi 16
SO SÁNH YÊU CẦU CHỨC NĂNG VÀ PHI CHỨC NĂNG • Yêu cầu chức năng được xử lý ngay trong giai đoạn phân tìch hệ thống • Yêu cầu phi chức năng sẽ được xét đến khi chuyển qua giai đoạn thiết kế. Trần Thị Kim Chi 17
ĐẶC TRƯNG CỦA YÊU CẦU • Khả thi - Feasible • Có giá trị - Valid • Không nhập nhằng - Unambiguous • Dễ kiểm chứng - Verifiable • Dễ biến đổi - Modifiable • Toàn vẹn - Consistent • Đầy đủ - Complete • Lần vết được - Traceable Trần Thị Kim Chi 18
ĐẶC TRƯNG CỦA YÊU CẦU Yêu cầu Nhập nhằng Trần Thị Kim Chi 19
ĐẶC TRƯNG CỦA YÊU CẦU Yêu cầu Nhập nhằng Trần Thị Kim Chi 20