Giai đoạn đánh giá mẫu thử (Evaluate prototype)

Phản ánh chính xác kết quả khảo sát, Đầy đủ trong phạm vi cho trước, Phản ánh đúng mục tiêu xây dựng sản phẩm.

Từ một scenario ta có thể sinh ra nhiều test case

Mức độ dễ hiểu và rõ ràng của Use Case, đảm bảo rang các bên liên quan có thể dễ dàng hiểu và thực hiện nó.

Có thể là quan hệ 1-1, n-1, m-n

Thống nhất, Không dư thừa

Các vai trò, đại diện cho các nhóm đối tượng tương tác với hệ thống, như: người dùng, hệ thống con và hệ thống thuộc các tổ chức bên ngoài.

Requirements Hierarchy (Cấu trúc phân cấp yêu cầu)

Cấp giữa, dưới tang NEEDs va trên tầng Use cases trong mô hình kim tự tháp yêu cầu.

Một chuỗi các bước mà hệ thống và các actor tương tác với nhau để hoàn thành một mục tiêu cụ thể.

Khi một Use Case có thể bổ sung các hành động mới vào một Use Case khác chỉ trong một số tình huống nhất định, ví dụ như trong trường hợp ngoại lệ hoặc tùy chọn.

NEEDs là các yêu cầu có nguồn gốc từ Stakeholders, trong khi FEATs được hình thànhh từ NEEDs

Có thể thu thập được thông tin từ một lượng lớn người dùng trong thời gian ngắn.

Có thể đánh giá hành vi người dùng trong môi trường làm việc thực tế.

Là nhu cầu cầu, mong muốn, hoặc đòi hỏi của stakeholder về phần mềm cần

Thảo luận với các stakeholders khác để xác minh và đảm bảo tính cần thiết của yêu cầu này.

Scenario được sinh ra từ use case

Đánh giá yêu cầu, Đặc tả yêu cầu, Thu thập, phân tích yêu câu

Các tình huống mà người dùng tương tác với hệ thống

A Vì NEEDs xuất phát từ các stakeholder, cần quản lý để biết được nguồn gốc của mọi yêu cầu xuất phát từ ai (WHO)

Mô tả cách hệ thống sẽ xử lý các điều kiện ngoại lệ hoặc sự cố phát sinh trong quá trình thực thi.

11 tiêu chí với từng FEATs; 3 tiêu chí với tập FEATs

Không mập mờ (Unambiguous), Nguyên tử (Atomic)

Mô tả các tính năng và chức năng cốt lõi mà phần mềm sẽ cung cấp

Vì FEATs là yêu cầu có nhiều đặc thù hơn so với NEEDs, Vì FEATs là các yêu cầu chính thức về phần mềm, thường được đưa vào bán hợp đồng ký kết giữa khách hàng và công ty phần mềm

Mô tả các bước chi tiết của quy trình để đạt được mục tiêu của các Features đã xác định.

Tốn nhiều thời gian và công sức để tổ chức và thực hiện.

Sán phẩm này cạnh tranh với những sán phẩm nào và nó khác biệt ra sao?

(1) CRS có thể tìm kiếm giao dịch đặt trước mua vé máy bay theo tên khách hàng; (2) CRS có thể sửa thông tin giao dịch đặt trước mua vé.

Định nghĩa mục tiêu và tầm nhìn dài hạn của dự án phần mêm

Thiết lập kế hoạch quản lý yêu cầu

Phỏng vấn (Interviews)

Một tác nhân bên ngoài hoặc đối tượng tương tác với hệ thống phần mềm để đạt được một mục tiêu nhất định.

Phỏng vấn

Cung cấp hướng dẫn cho đội ngũ phát triển về các tính năng cần phải được phát triển

Sau khi phân tích xác định các tính năng (FEATs) của phần mềm cần xây dựng

FEATs là các yêu cầu người dùng, Ucs la các yêu cầu hệ thống

Use case được hình thành từ các tính năng là yêu cầu chức năng và các ràng buộc của chức năng

Must

Là quá trình chuyển dịch các yêu cầu từ tầng NEED xuống tầng FEAT trong mô hình kim tự tháp yêu cầu

Stakholder Request Documment

Các yêu cầu dạng thô, được đề xuất bởi stakeholders, có thể tiêm ẩn các vấn đề trong đó, ví dụ dài dòng, mập mờ, ...

2 mức; mức yêu cầu người dùng & mức yêu cầu hệ thống

Yêu cầu người dùng viết cho người dùng đọc, yêu cầu hệ thống viết cho developers, testers và desiger đọc và triển khai.

Phòng vấn có thể giúp hiểu rõ hơn về nhu cầu và cảm nhận của người dùng thông qua tương tác trực tiếp.

Actual iterative, Planned iterative

Chi tiết về các yêu cầu kỹ thuật của phần mềm

Dùng để sinh ra các test case sử dụng kỹ thuật sinh test case dựa trên kịch bản của use cases

Phát triển FEATS, Đảm bảo chất lượng FEATs, Quản lý FEATs

Tạo ra một tầm nhìn chung cho toàn bộ đội ngũ dự án về mục tiêu và phương hướng phát triển

Scenario phải là một đường đi từ điểm đầu đến điểm kết thúc trong biểu đồ hoạt động biểu diễn Use Case

Để đăng ký học phần sinh viên, trước hết sinh viên phải đăng nhập thành công, khi đăng ký học phần sinh viên có thể xem lịch học

Có thể dẫn đến quá nhiều ý tưởng không thực tế hoặc khó triển khai.

Giúp dễ dàng gom nhóm các yêu cầu và xác định yêu cần đầy đủ hơn

Kết hợp (Combination) - Các NEEDs dự thừa hoặc phủ lên nhau được kết hợp thành một FEAT., Phân tách (Split) - Các NEEDs chưa atomic, tách ra thành các FEATs atomic

Traceability Matrix (Ma trận dấu vết)

Khi một use case cần phải luôn bao gồm các hành động của một use case khác trong quá trình thực thi của nó, bất kể tình huống cụ thể nào.

Xác định các stakeholder của dự án phần mềm

Có thể xung đột (UnConsistent), Có thể trùng lặp (Duplicate)

Cả hai đều mô tả chi tiết các bước thực hien và hành động trong hệ thống, nhưng Scenario thường chỉ mô tả một tình huống cụ thể, còn Use Case mô tả các tình huống có thể xảy ra.

Giai đoạn thu thập, phân tích yêu cầu

Đánh giá scenarios, Phân tích xác định các scenarios, Quản lý scenarios

NEEDs là nguồn gốc của FEATs trong mô hình kim tự tháp yêu cầu

Xác định vị thế của phần mềm trên thị trường, phân khúc khách hàng và những khác biệt của phần mềm so với các sản phẩm khác đang có trên thị trường

Project Vision Document

(x)

Cả NEEDs và FEATs đều thuộc loại yêu cầu người dùng (user requirements)

Khảo sát điều tra

Thời gian thường ngắn hơn so phỏng vấn., Khuyến khích sự sáng tạo và tư duy mở trong việc đưa ra ý tưởng.

Status

Phiên làm việc tập trung

Tài liệu "Software Project Vision"

Mô tả các actor, các use case của hệ thống, và các mối quan hệ giữa chúng.

Bản đặc tả use case (use case specification)

Xác định đâu là Features phản ánh các chức năng của phần mềm, sau đó phân chia chức năng thành các bước hành động cụ thể.

(1) CRS có thể tìm kiếm giao dịch đặt trước thuê phòng khách sạn theo các tiêu chí: tên cuối, tên đầu của khách hàng, thành phố đến, ngày đến; (2) CRS có thế xóa giao dịch đặt trước thuê phòng

Mã nguồn dự án

Vì chúng là các yêu cầu có nguồn gốc trực tiếp từ các stakeholders

Khi Scenario mô tả đầy đủ chuỗi hành động trên đường đi từ điểm đầu đến điểm kết thúc của biểu đồ hoạt động biểu diễn use case tương ứng.

Priority

Các Scenarios giúp đội ngũ kiểm thử hiểu rõ các tình huống thực tế về hành vi của hệ thống, từ đó xây dựng các ca kiểm thử phù hợp.

Đánh giá yêu cầu

Xác định những điều kiện cần thiết phải được thỏa mãn trước khi một use case có thể được thực hiện.

Actors là những người hoặc hệ thống tương tác trực tiếp với hệ thống trong các use case, trong khi Stakeholders là những người có quan tâm hoặc ảnh hưởng đến kết quả của hệ thống, nhưng không nhất thiết phải tương tác trực tiếp.

4 FEATs: (1) Độc giá có thể tìm kiếm sách; (2) Độc giả có thể hiện thị sách theo chú đề; (3) Độc giá có thể mượn sách; (4) Độc giá có thể trá sách

Là tính năng sản phẩm được phân tích và hình thành từ một hoặc nhiều NEEDS

Xác định mối quan hệ giữa các yêu cầu và Use Cases, giúp theo dõi các thay đổi và kiểm soát được sự thống nhất giữa các yêu cầu

Khả thi (Feasible)

Tạo ra một tâm nhìn chung cho toàn bộ đội ngũ dự án về mục tiêu và phương hướng phát triển.

(1) -> (3) -> (2) -> (4) -> (5) -> (6) -> (7)

Yêu cầu 1), 4) và 5)