Bài giảng Thu nhận yêu cầu: Chương 3 - Trần Thị Kim Chi

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

Thêm vào BST

Báo xấu

67
lượt xem 3
download

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

Bài giảng "Thu nhận yêu cầu - Chương 3: Thu thập yêu cầu" cung cấp cho người học các kiến thức: Thu thập yêu cầu (Requirement elicitation) là gì, các kỹ thuật thu thập yêu cầu, chọn lựa kỹ thuật thu thập yêu cầu, quy tắc nghiệp vụ và chính sách, quản lý mối quan hệ khách hàng. 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 Thu nhận yêu cầu: Chương 3 - Trần Thị Kim Chi

Chapter 3: Thu thập yêu cầu Requirements Elicitation Or Requirement gathering BM HTTT Khoa CNTT - HUI 1
Nội dung Thu thập yêu cầu (Requirement elicitation) là gì? Các kỹ thuật thu thập yêu cầu Chọn lựa kỹ thuật thu thập yêu cầu Quy tắc nghiệp vụ và chính sách Quản lý mối quan hệ khách hàng BM HTTT Khoa CNTT - HUI 2
A major aspect of requirements engineering is the elicitation of requirements from the customer. It’s not just a simple matter of writing down what the customer says he wants !!!CNTT - HUI BM HTTT Khoa 3
Requirement elicitation Elicitation là quá trình xác định yêu cầu và làm giảm sự khác biệt giữa các nhóm có liên quan để rút ra các yêu cầu đáp ứng được nhu cầu của tổ chức hay dự án trong khi vẫn giữ được các ràng buộc. Có rất nhiều kỹ thuâṭ elicitation khác nhau BM HTTT Khoa CNTT - HUI 4
Phân biệt giữa elicitation và analysis Elicitation là sự tương tác với stakeholders để nắm bắt được nhu cầu của họ. Analysis là tinh chỉnh (refinement) nhu cầu của stakeholder thành các đặc tả sản phẩm chính thức. BM HTTT Khoa CNTT - HUI 5
Tầm quan trọng Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication- intensive aspect of software development. Elicitation chỉ có thể thành công thông qua mối quan hệ hợp tác giữa customer và đội development . BM HTTT Khoa CNTT - HUI 6
Mô hình song song của quy trình yêu cầu BM HTTT Khoa CNTT - HUI 7
Why is it difficult to elicit requirements? Customers and users often do not understand how software design and development works, and cannot specify their own software requirements in a way that works for developers. Software developers often do not understand the problems and needs of customers and users well enough to specify the requirements on their behalf. BM HTTT Khoa CNTT - HUI 8
Vấn đề về người dùng và khách hàng Người dùng không hiểu họ muốn gì Người dùng không tuân theo một bộ yêu cầu đã được tài liệu hóa Người dùng nhất định đòi hỏi các yêu cầu mới sau khi chi phí và kế hoạch phát triển đã được hoạch định xong. Mức độ giao tiếp với người dùng là thấp Người dùng thường không tham gia các đợt thẩm định hoặc không thể tham gia. Người dùng không hiểu kỹ thuật Người dùng không hiểu quy trình phát triển. BM HTTT Khoa CNTT - HUI 9
Các hoạt động của yêu cầu BM HTTT Khoa CNTT - HUI 10
Trước khi thu thập yêu cầu  Đã viết “vision and scope”  Vẽ lược đồ ngữ cảnh (context diagram)  Xác định stakeholder  Xác định người dùng và đại diện người dùng BM HTTT Khoa CNTT - HUI 11
Lược đồ ngữ cảnh  Phạm vi (scope) dùng để xác định đường biên (boundary) và các mối nối kết giữa hệ thống đang phát triển và mọi thứ khác bên ngoài.  Lược đồ ngữ cảnh được dùng để minh họa đường biên này. BM HTTT Khoa CNTT - HUI 12
Lược đồ ngữ cảnh  Là mức 0 (top level) của lược đồ dòng dữ liệu (data flow diagram) theo cách phân tích hướng cấu trúc  Được dùng rộng rãi cho bất kỳ phương pháp phát triển nào  Có thể nằm trong tài liệu vision, trong phục vụ đặc tả yêu cầu (SRS) BM HTTT Khoa CNTT - HUI 13
Lược đồ ngữ cảnh BM HTTT Khoa CNTT - HUI 14
Keeping Scope in Focus  Scope change isn’t a bad thing if it helps you steer the project toward satisfying evolving customer needs  Khi có ai đó kiến nghị 1 yêu cầu mới thì RA phải làm gì??  Cần xem xét yêu cầu mới có nằm trong scope hay không??  Nếu yêu cầu kiến nghị nằm trong scope thì có thể hợp nhất yêu cầu mới vào dự án nếu có độ ưu tiên cao so với yêu cầu hiện cócó thể phải trì hoãn hay hủy bỏ các yêu cầu hiện tại BM HTTT Khoa CNTT - HUI 15
Keeping Scope in Focus  Nếu yêu cầu kiến nghị nằm ngoài scope thì có thể có 1 trong các phương án sau: ◦ Nên đưa vào phiên bản sau hay trong dự án khác. ◦ Scope của dự án có thể thay đổi để đáp ứng yêu cầu mới  cần có phản hồi từ phía người dùng và cần cập nhật lại tài liệu vision and scope (nếu đã phê duyệt thì cần giám sát mọi thay đổi) ◦ Khi phạm vi dự án tăng, thường phải thỏa thuận lại ngân sách(budget), tài nguyên (resource), thời gian (schedule) BM HTTT Khoa CNTT - HUI 16
Xác định StakeHolder  Identify the different classes of users for your product  Identify source of user requeriments  Select and work with individual who represent each user class and other stakeholder groups  Agree on who the requirements decision makers are for you project  It’s not enough simply to ask a few customers what they want and then start coding. If the developers build exactly what customers initially request, they’ll probably have to build it again because customers often don’t know what they really need. BM HTTT Khoa CNTT - HUI 17
Xác định StakeHolder  Những tính chất mà người dùng đưa ra lúc đầu thường không đủ để trở thành chức năng của hệ thống.  Để có cái nhìn chính xác hơn nhu cầu người dùng, RA phải tập hợp các yêu cầu người dùng, phân tích và xác định chỉ nên xây dựng cái gì để người dùng làm tốt được công việc của họ. BM HTTT Khoa CNTT - HUI 18
Phân loại StakeHolder 1. Customers (người tài trợ dự án hay mua sản phẩm) 2. Users (người tương tác trực tiếp hay gián tiếp sản phẩm) 3. Requiremements analysts (người viết yêu cầu và làm việc với đội phát triển phần mềm) 4. Developers (người thiết kế, thực thi và bảo trì sản phẩm) 5. Testers (người kiểm tra xem sản phẩm có thực thi như mong muốn) BM HTTT Khoa CNTT - HUI 19
Phân loại StakeHolder 1. Documentation writers (người tạo ra sổ tay người dùng, hệ thống trợ giúp) 2. Project managers (người lập kế hoạch cho dự án, quản lý đội phát triển phần mềm) 3. Legal staff (người bảo đảm sản phẩm phù hợp với luật và quy chế) 4. Manaufacturing people (người phải xây dựng sản phẩm có chứa phần mềm) 5. Sales, marketing, field support, help desk, và những người khác sẽ làm việc với sản phẩm và khách hàng. BM HTTT Khoa CNTT - HUI 20