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ờ, ...

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.

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

Phỏng vấn (Interviews)

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

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.

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ế.

Phỏng vấn

(x)

Must

(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

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.

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

Stakholder Request Documment

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

Khảo sát điều tra

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

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.

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

(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é.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mã nguồn dự á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?

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

Tài liệu "Software Project Vision"

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

Status

Actual iterative, Planned iterative

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

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

Khả thi (Feasible)

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

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

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

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

Project Vision Document

Priority

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

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

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.

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)

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

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

Đánh giá 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ể.

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.

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.

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

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

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ể.

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.

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

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

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

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.

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

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

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

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.

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.

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.

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

Scenario được sinh ra từ use case

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

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ó.

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.

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

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.

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.

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.

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

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.

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

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.

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