GitHub

Mỗi loại yêu cầu cần quản lý các thuộc tính gì?

Yêu cầu đảo mô tả các ràng buộc về các hành vi được phép của hệ thống, Yêu cầu đảo mô tả những gì hệ thống sẽ không làm

Từ các yếu tố về chất lượng sản phẩm, môi trường vận hành sản phẩm

Yêu cầu chức năng phản ánh các chức năng cụ thể của phần mềm

3, gồm: Phát triến yêu cầu, đảm bảo chất lượng yêu cầu và quản lý yêu cầu

Quản lý yêu cầu tập trung vào việc kiểm soát sự thay đổi yêu cầu và các thông tin vê yêu câu, trong khi phân tích yêu câu tập trung vào việc xác định yêu câu.

Mọi yêu câu phần mềm đều được thu thập, phân tích và kiếm soát thay đối một cách rõ ràng và hiệu quả.

4 giai đoạn, gồm: Inception, Elaboration, Construction, và Transition

Các yếu tố về hiệu suất, bảo mật, khả năng mở rộng và độ tin cậy

Hỗ trợ quản lý yêu cầu với khả năng theo dõi dấu vết yêu cầu (requirements traceability)

Rational Requisite pro, vì nó được thiết kế chuyên biệt để quản lý yêu cầu và hồ trợ đầy đủ các tính năng về yêu cầu như phân tích, xác nhận và theo dõi dấu vết

Nhu cầu là một thứ gì phần mềm phải đáp ứng, mong muốn là một thứ gì phần mềm có thể đáp ứng hoặc không

Mỗi lặp của RUP phải trải qua tất cả các luồng công việc (workflows) trên các hàng.

Thuộc loại quy trình phát triển phần mềm lặp

Việc quán lý các yêu cầu thay đổi được triển khai như thế nào?, Dự án có sử dụng công cụ quản lý yêu cầu phần mềm không?

Những mô tả về tính năng và chức năng mà phần mềm phải đáp ứng

Các yêu cầu chức năng và phi chức năng, cũng như phạm vi tổng thế của dự án.

Các mốc thời gian (Milestones)

Các lần lặp ở hai giai đoạn đầu của RUP.

Lần lặp 1, lần lặp 2

Hệ thông không công khai những thông tin riêng tư của người dùng, Hệ thống không cho phép những người không có thẩm quyền truy cập vào chức năng quản trị., Hệ thống sẽ không sử dụng mầu đỏ trong giao diện người dùng khi yêu câu họ nhập thông

Làm tài liệu hướng dẫn triển khai cho nhóm phân tích viên nghiệp vụ (BAs).

Trả lời câu hỏi chính WHAT và các câu hỏi phụ gồm WHO, WHY và WHERE

Thu thập, phân tích xác định yêu cầu., Là cầu nối giữa hai bên gồm khách hàng & công ty phát triển phần mềm

Thu thập, phân tích xác định, phân loại, tinh chỉnh, và hình thành tập yêu cầu

Origin, Stakeholder's priority

13 quyết định

Giúp dễ dàng xác định tác động của các thay đối yêu cầu đến các yêu cầu khác và các phần liên quan khác của hệ thống.

4 loại, gồm: needs, features, use cases, và supplementary requirements

4 giai đoạn

Thu thập yêu cầu thông qua các cuộc họp Scrum hàng ngày và quản lý yêu cầu trong các sprint backlog, product backlog

Mục các loại tài liệu

Để kiểm soát và quản lý các thay đổi trong yêu cầu nhằm tránh rủi ro và giữ cho dự án phát triển theo đúng kế hoạch

Lập kế hoạch và yêu cầu có thể được cập nhật trong suốt vòng đời của dự án, với lần lặp được phân chia rõ ràng.

Là tài liệu hướng dần công việc cho các bên liên quan hiểu đúng và tuân thú một cách nhất quán

Để có thể kiểm thử và nghiệm thu một cách dễ dàng

Quản lý yêu cầu phần mềm

Tập trung vào các luồng (1), (2)

Quán lý mọi thông tin cần thiết của yêu cầu, theo dõi được các thay đối yêu cầu (nếu có) trong suốt thời gian sống của sản phẩm phần mềm.

Hệ thống phải dễ sử dụng và thân thiện

Quản lý yêu cầu thông qua các chu kỳ phát triển ngắn hạn (Iterative Phases), cho phép điều chính và thay đổi yêu cầu theo phán hồi từ khách hàng.

Where will the requirements be created?

Một issue, hoặc một pull request của dự án

Không cần sử dụng công cụ vì đây là phần mềm đơn giản.

Tại mỗi mốc thời gian chỉ định trong bản kế hoạch quản lý yêu cầu

Phát hiện và giải quyết sớm các vấn đề liên quan đến yêu cầu

Yêu cầu chức năng

Phân tích viên hệ thống

Rational RequisitePro

Tối đa 4 tuần

Statement of work

Requirements Engineering

Là mô hình tố chức các yêu cầu theo nhiều cấp độ, từ yêu cầu cao nhất (các yêu cầu doanh nghiệp) xuống các yêu cầu chi tiết hơn (các yêu cầu chức năng và phi chức năng) , Là một cách tiếp cận cụ thể áp dụng cho quy trình kỹ nghệ yêu cầu

Các mô tả, tiêu chí chấp nhận, và trạng thái của yêu cầu

Đảm bảo sự nhất quán và tính liên kết giữa các yêu cầu ở các tầng khác nhau trong suốt quá trình phát triển.

GitHub hỗ trợ theo dõi yêu cầu qua các issues, trong khi Rational RequisitePro cung cấp một hệ thống chuyên biệt để quản lý yêu cầu với các tính năng theo dõi dấu vết yêu cầu.

Thông qua việc tạo và theo dõi các issues để ghi nhận yêu cầu và các thay đổi cần thiết

Các yêu cầu phần mềm có thể được thu thập trong các lần lặp tương ứng với các giai đoạn của RUP.

Đều là cách tiếp cận lặp, tức phân tích và quản lý yêu cầu được thực hiện lặp lại nhiều lần., Scrum không yêu cầu một kế hoạch chi tiết cho yêu cầu, trong khi RUP yêu cầu lập kế hoach chi tiet ngay từ đầu.

Là các yêu cầu được phân tích hình thành từ các needs

"Tôi quá bận! ... thật lãng phí thời gian với các yêu cầu.", "Tôi không bận! ... nhưng việc quản lý yêu cầu là không cần thiết"

Ngụ ý về tầm quan trọng của các yêu cầu phần mềm và những khó khăn trong việc xác định chúng

Rational RequisitePro, Rational DOORS

Ghi nhận kiểm soát các thay đổi yêu cầu để duy trì tính nhất quán

Quy trinh hợp nhất Rational (RUP)

Phải quay lại làm lại từ đầu, hoặc trì hoãn yêu cầu thay đổi đến tận giai đoạn bảo trì phần mềm.

Để tự động hóa và tăng tính linh hoạt trong quản lý yêu cầu

Để giúp phân tích viên nghiệp vụ xác định được họ sẽ cần phải xây dựng những tài liệu đặc tả yêu cầu nào để ký hợp đồng với khách hàng.

Có, là quyết định số 3

Yêu cầu được thu thập ở giai đoạn đầu của dự án và các yêu cầu sẽ không thay đổi sau khi kết thúc giai đoạn.

Các yêu cầu được quản lý trong product backlog và sprint backlog

Thu thập yêu cầu

Yêu cầu có thể bị hiểu sai, dẫn đến việc phát triển phần mềm không đáp ứng nhu cầu thưc tế

Là yêu cầu đến từ stakeholder

Yêu cầu người dùng viết cho người dùng đọc dễ hiểu và hiệu chỉnh, yêu cầu hệ thống viết cho phát triển viên, lập trình viên và kiểm thử viên đọc để triển khai hệ thống, Yêu cầu hệ thống thường đặc tả chi tiết hơn so với yêu cầu người dùng

Tôi có thực sự cần tất cả những thứ này?

Các tổ chức, trách nhiệm và bảng thông tin liên lạc

Các vai trò trong team Aglie gồm: chủ sở hữu sản phẩm, lãnh đạo team, các phát triển viên và kiểm thử viên

Hệ thống sẽ được phát triển sử dụng các công cụ nguồn mở và sẽ chạy trên hệ điều hành Linux, Hệ thống sẽ được phát triển sử dụng nên tảng Microsoft .Net

Bản kế hoạch quản lý yêu cầu (RMP), tài liệu tầm nhìn dự án (Project Vision), tài liệu yêu cầu bổ sung (Suplementary Requirements document), bảng chú giải (Glossary), và tài liệu đặc tả use case (Use case specification).

Chủ sở hữu sản phẩm (product owner)

Yêu cầu phần mềm chỉ phát biểu "What", không phát biểu "HOW"

Phần quản lý các thay đổi yêu cầu

Product Owner

Tối thiểu 2 tuần.

Stakeholder's requests, product features, use cases

Các yêu cầu không đầy đủ và tồn tại các vấn đề trong đặc tả, Thiếu giải pháp cho việc quản lý các yêu cầu thay đổi, Thiếu sự tham gia của người dùng

Yêu cầu miền là yêu cầu chứa các thuật ngữ chuyên ngành của miền ứng dụng, Yêu câu miền có thế là yêu cầu chức năng hoặc yêu câu phi chức năng

Các bước để quán lý và kiểm soát các thay đổi đối với yêu cầu sau khi chúng đã được phê duyệt.

Thuộc loại quy trinh phát triển phần mềm linh hoạt Agile