Tổng quan về phân tích và quản lý yêu cầu phần mềm

52 2.2K 23
Tổng quan về phân tích và quản lý yêu cầu phần mềm

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Tổng quan về phân tích và quản lý yêu cầu phần mềm

PHÂN TÍCH VÀ QUẢN LÝ CÁC YÊU CẦU PHẦN MỀM (Requirements Analysis and Management) Chuyên đề: Giảng viên: Phạm Thị Thương Bộ môn: CNPM Số điện thoại: 0912838646 Email: ptthuong@ictu.edu.vn Tổng quan về phân tích và quản lý yêu cầu phần mềm Chương 1 Mục tiêu  Làm quen với các khái niệm cơ bản  Tổng quan về tiến trình quản lý yêu cầu theo cách tiếp cận hướng đối tượng Nội dung Định nghĩa về yêu cầu và Stakeholder Các kiểu yêu cầu & mối quan hệ Dấu vết giữa các yêu cầu Các đặc trưng của một yêu cầu tốt Tổng quan về tiến trình phân tích và quản lý yêu cầu Thảo luận 1. Định nghĩa về yêu cầu & Stakeholder a. Định nghĩa yêu cầu ◦ điều kiện ràng buộc hệ thống hoặc ◦ năng lực hệ thống phải có. b. Định nghĩa Stakeholder  Người/nhóm người ◦ Bị tác động bởi kết quả của dự án phát triển hệ thống ◦ => Có thể xem Stakeholder là bất kỳ người nào đưa ra yêu cầu đối với hệ thống. 1. Định nghĩa về yêu cầu & Stakeholder  Các Stakeholder có thể là: ◦ Khách hàng; ◦ Người dùng cuối; ◦ Người phát triển; ◦ Nhà sản xuất; ◦ Nhà cung cấp tri thức cho hệ thống; ◦ Người bảo trì; ◦ Người quản lý; ◦ Những bộ phận cung cấp các luật và các quy tắc. 1. Định nghĩa về yêu cầu & Stakeholder  2 loại Stakeholder chính: ◦ Người dùng:  Những người sẽ sử dụng hệ thống ◦ Khách hàng:  Người yêu cầu phát triển hệ thống, có trách nhiệm phê chuẩn nó, và thường là người chi trả chi phí phát triển dự án. ⇒ Phân biệt giữa hai loại Stakeholder này là quan trọng. ⇒ Các yêu cầu giữa họ có thể xung đột. 1. Định nghĩa về yêu cầu & Stakeholder  Ví dụ: Xét p/m Online Travel Agency: 1. Định nghĩa về yêu cầu & Stakeholder Ví dụ: Xét p/m Online Travel Agency: ◦ Khách hàng: => Người chủ của Website ◦ Người dùng cuối: => Những người sử dụng Website qua internet. ◦ Người phát triển; => Người phân tích nghiệp vụ, các nhà thiết kế, người viết mã, những nhà quản lý dự án, người quản lý phát hành vé, những người thiết kế UC, các nhà thiết kế đồ họa. ◦ Nhà sản xuất: => không có ◦ Nhà cung cấp tri thức cho hệ thống: => Các chuyên gia miền, tác giả của các tài liệu được sử dụng để suy luận các yêu cầu, các chủ sở hữu Website cung cấp các link cho Website này). Xác định Stakeholder [...]... một chuỗi các hành động 2 Kim tự tháp các yêu cầu  Supplementary requirement (yêu cầu bổ sung): ◦ Yêu cầu khác (thường là yêu cầu phi chức năng, hoặc các yêu cầu chức năng không được thể hiện qua UC)  Test case (ca kiểm thử): ◦ ◦ Đặc tả về các đầu vào kiểm thử, các điều kiện thực thi, và các kết quả mong đợi => nhằm kiểm tra xem liệu các use case và các yêu cầu bổ sung đã được cài đặt một cách đúng... lập của yêu cầu thỏa mãn khi, để hiểu yêu cầu đó, ta sẽ không cần phải biết bất kỳ yêu cầu nào khác Ví dụ, xét các yêu cầu sau:  REQ1 The list of available flights shall include flight numbers, departure time, and arrival time for every leg of a flight  REQ2 It should be sorted by price => Từ “it” trong câu thứ 2 tham chiến đến yêu cầu trước đó Tuy nhiên, nếu thứ tự của yêu cầu thay đổi, yêu cầu này... thuật cung cấp mối quan hệ giữa hai mức độ yêu cầu Giúp xác định nguồn gốc của một yêu cầu bất kỳ Ánh xạ giữa các kiểu yêu cầu trong kim tự tháp: ◦ ◦ Quan hệ n-m:    Need -> feature Feature-> supplement Feature->Use case Quan hệ 1-n:    Use case -> scenario Scenario-> test case Supplement-> test case 4 Các đặc trưng của một yêu cầu tốt  [HUL05][LEF03][LUD05][YOU01]- Các yêu cầu tốt nên có những... được tách thành các yêu cầu nguyên tử 4 Các đặc trưng của một yêu cầu tốt g Necessary ◦ Một yêu cầu là không cần thiết khi:  Không Stakeholder nào cần yêu cầu Những yêu cầu được thêm vào bởi những nhà phát triển và những nhà thiết kế vì họ giả định rằng người dùng hoặc khách hàng muốn có nó    Ví dụ: Người phát triển nghĩ rằng người dùng thích đặc trưng hiển thị bản đồ các sân bay và anh ấy biết cách... 4 Các đặc trưng của một yêu cầu tốt d Correct ◦ ◦ Nếu một yêu cầu chứa các sự kiện, các sự kiện này phải đúng Ví dụ, xét yêu cầu sau: REQ1 Car rental prices shall show all applicable taxes (including 6% state tax) => Thuế phụ thuộc vào từng quốc gia, do đó con số 6% đã cung cấp là không đúng 4 Các đặc trưng của một yêu cầu tốt e Understandable ◦ Các yêu cầu phải đúng ngữ pháp và được viết một cách nhất... về thuế quốc gia 2 Kim tự tháp các yêu cầu 2 Kim tự tháp các yêu cầu ◦ Stakeholder need (nhu cầu Stakeholder): ◦ Feature (đặc trưng): ◦  Là yêu cầu được đề xuất bởi Stakeholder  Là dịch vụ được cung cấp bởi hệ thống, thường được hình thành bởi hoạt động phân tích nghiệp vụ;  Mục tiêu của đặc trưng là đáp ứng nhu cầu Stakeholder Use case (ca sử dụng):  Mô tả về hành vi của hệ thống bằng một chuỗi... thức cài đặt, đó không là lý do hợp lý để thêm yêu cầu này Xóa yêu cầu sẽ không ảnh hưởng đến hệ thống   Những yêu cầu có thể được xóa vì nó không cung cấp bất kỳ thông tin mới nào Ví dụ: REQ1 All requirements specified in the Vision document shall be implemented and tested 4 Các đặc trưng của một yêu cầu tốt h Implementation-free (Abstract)  ◦ không nên chứa thông tin cài đặt và thông tin thiết kế...1 Định nghĩa về yêu cầu & Stakeholder ◦ ◦ Nhà tiếp thị: => Không có Người bảo trì và hỗ trợ hệ thống: ⇒Công ty cung cấp Website hosting, • Người quản lý; => Lãnh đạo công ty du lịch, ◦ Giám đốc phòng Công nghệ thông tin của công ty thiết kế và phát triển Web Những bộ phận cung cấp các luật và các quy tắc =>Engine tìm kiếm: Các luật đối với nội dung website, các luật chính phủ, các luật về thuế quốc... đổi, yêu cầu này sẽ không thể hiểu 4 Các đặc trưng của một yêu cầu tốt h Atomic ◦ ◦ Yêu cầu nên chứa một phần tử đơn có thể theo dõi qua dấu vết Ví dụ:  REQ1 The system shall provide the opportunity to book the flight, purchase a ticket, reserve a hotel room, reserve a car, and provide information about attractions => Yêu cầu này kết hợp 5 yêu cầu nguyên thủy, điều này làm cho khả năng lưu vết rất khó... Kim tự tháp các yêu cầu   Càng ở mức dưới, mức độ trừu tượng của y/c càng thấp Ví dụ: ◦ ◦ ◦ Need: “dữ liệu nên được lưu trữ lâu dài” Feature: “hệ thống nên sử dụng cơ sở dữ liệu quan hệ” Specification: “Hệ thống nên sử dụng CSDL Oracle 9i” Từ một yêu cầu mức trên, có thể ánh xạ thành nhiều yêu cầu mức dưới ◦ Tài liệu vision: 12 trang, tài liệu chi tiết: 200 trang 3 Dấu vết các yêu cầu   Dấu vết

Ngày đăng: 07/02/2015, 17:17

Từ khóa liên quan

Mục lục

  • Slide 1

  • Slide 2

  • Mục tiêu

  • Nội dung

  • 1. Định nghĩa về yêu cầu & Stakeholder

  • 1. Định nghĩa về yêu cầu & Stakeholder

  • 1. Định nghĩa về yêu cầu & Stakeholder

  • 1. Định nghĩa về yêu cầu & Stakeholder

  • 1. Định nghĩa về yêu cầu & Stakeholder

  • Xác định Stakeholder

  • 1. Định nghĩa về yêu cầu & Stakeholder

  • 2. Kim tự tháp các yêu cầu

  • 2. Kim tự tháp các yêu cầu

  • 2. Kim tự tháp các yêu cầu

  • 2. Kim tự tháp các yêu cầu

  • 3. Dấu vết các yêu cầu

  • 4. Các đặc trưng của một yêu cầu tốt

  • 4 Các đặc trưng của một yêu cầu tốt

  • Slide 19

  • Slide 20

Tài liệu cùng người dùng

Tài liệu liên quan