Yêu cầu (Requirements) là một phần thiết yếu trong phát triển phần mềm, yêu cầu giúp cho quản lý dự án (PM), team và khách hàng thống nhất về định hướng xây dựng sản phẩm.
Trong khi thu thập các yêu cầu, một người PM phải có các kĩ năng và công cụ cần thiết khi làm việc với khách hàng, với team để thể hiện các yêu cầu một cách rõ ràng, minh bạch, bài học này sẽ đề cập đến các vấn đề đó.
Yêu cầu là gì?
Có rất nhiều định nghĩa khác nhau về yêu cầu nhưng ta có thể sử dụng một định nghĩa đơn giản là: một mô tả cụ thể về nhu cầu của khách hàng có thể dùng để tạo ra sản phẩm.
Các yêu cầu được xác định rõ ràng sẽ khiến cho nhu cầu của khách hàng được hiểu và thực hiện tốt hơn, giúp phát hiện vấn đề sớm hơn để tránh trường hợp vấn đề trở lên thổi phồng và tốn kém để giải quyết.
Ở trong bài học trước ta có thứ tự chia công việc: Process>>Phases>>Activities>>Task.
Có 5 hoạt động (activities) quan trọng về yêu cầu các PM cần chú ý:
- Khơi gợi yêu cầu: Xác định các yêu cầu mà khách “muốn có” trong sản phẩm và “cần thiết” trong một sản phẩm, những yêu cầu “cần thiết ” sẽ là chức năng cốt lõi của phần mềm đó và cần được ưu tiên.PM nên tham gia chủ động để xác định được nhu cầu chính xác hơn thay vì chỉ bị động ghi lại những nhu cầu mà khách hàng đề xuất.
- Thể hiện yêu cầu: Thể hiện yêu cầu theo dạng có tổ chức như Use case, user stories…
- Ưu tiên yêu cầu: Ưu tiên làm trước các yêu cầu theo thứ tự: phải có > nên có > có thể có ( must>should>could).
- Phân tích yêu cầu: Thường xuyên đánh giá danh sách yêu cầu để đảm bảo tính rõ ràng, hoàn chỉnh và đồng bộ.
- Quản lý yêu cầu: Thường xuyên sắp xếp các yêu cầu để có thể cắt hoặc thêm lại vào các giai đoạn khác nhau, theo dõi các yêu cầu và thay đổi, đặc biệt là các thay đổi vì nó sẽ ảnh hưởng đến quá trình phát triển của sản phẩm.
Các loại yêu cầu PM cần lưu ý:
- Yêu cầu về kinh doanh (Business requirement): Những yêu cầu này xác định mục đích của dự án và thường liên quan đến các giá trị kinh doanh có thể định lượng được, như tăng doanh thu theo một tỷ lệ nhất định.
- Quy tắc kinh doanh (Business rules): Những hạn chế về cách thức hoạt động của sản phẩm, thường liên quan đến ngân sách, chính sách hoặc quy định.
- Yêu cầu về người dùng (User requirements): Xác định các mục đích mà người dùng có thể thực hiện với sản phẩm, loại yêu cầu này là chức năng cốt lõi của sản phẩm.
- Yêu cầu chức năng (Functional requirements): Mô tả sản phẩm làm gì ,được thể hiện dưới dạng input, output hoặc các mô tả hành vi chức năng, thường được thể hiện theo đồ thị flowchart.
- Yêu cầu phi chức năng (Non-functional requirements) : còn gọi là yêu cầu chất lượng, loại yêu cầu này tập trung vào hiệu suất và chất lượng của sản phẩm, bao gồm các khía cạnh như độ chính xác, bảo mật, khả năng sử dụng và hiệu quả.
- Quan hệ hệ thống bên ngoài: Cách sản phẩm tương tác với hệ thống hoặc máy chủ lớn hơn.
- Yêu cầu hoạt động vật lý: Chỉ định cách sản phẩm sẽ được thiết kế để hoạt động trong môi trường vật lý của nó.
- Ràng buộc phát triển: Đề cập đến các hạn chế liên quan đến việc tạo ra sản phẩm, chẳng hạn như các thiết bị được hỗ trợ hoặc các hạn chế về tài nguyên.Khi xứ lý các thay đổi về yêu cầu trong dự án PM cần để ý đến độ lớn của các yêu cầu và cả dự án, khi các yêu cầu trở lên quá phức tạp, mập mờ hoặc nhiều hơn mong đợi thì dự án khó có thể thực hiện được. Ở đây ta có khái niêm Scope (phạm vi dự án).
- Scope là phạm vi thực tế mà dự án có thể phát triển.PM cần xác định Scope trong khi khơi gợi yêu cầu để định hướng đúng cho khách hàng phạm vi phát triển của sản phẩm, và không hứa hẹn quá mức thực tế.
- Mất phạm vi dự án (scope creep) là khi phạm vi dự án nổi phồng lên do thay đổi về yêu cầu, có thể do không xác định trước.
Để tránh rơi vào trường hợp này PM cần thiết xác định kỳ vọng hợp lý cho khách hàng và team , đặt ưu tiên yêu cầu hợp lý và thường xuyên có sự phản hồi của khách hàng trong dự án.
Làm việc với khách hàng về yêu cầu:
PM cần cân nhắc các loại người dùng khi thiết kế một sản phẩm:
- Người dùng cuối (end-user): là những người dùng sản phẩm trực tiếp.
- Stakeholder là những người liên quan đến dự án, có thể ảnh hưởng đến sự thành công của dự án.
Có 3 loại end user ,stakeholder cụ thể là:
- Người dùng mức 1: những người sử dụng sản phẩm trực tiếp
- Người dùng mức 2: những người thỉnh thoảng sử dụng sản phẩm hoặc dùng một cách gián tiếp.
- Người dùng mức 3: những người mà sản phẩm có tạo ảnh hưởng đến, hoặc những người ra quyết định về sản phẩm, vd. Khách hàng.
PM cần đảm bảo răng thiết kế sản phẩm có sự thân thiệt với người dùng đặc biệt qua thiết kế giao diện UI để đảm bảo tính dễ sử dụng vì người dùng có thể chuyển sang sản phẩm khác dễ dùng hơn nhưng ít chức năng hơn.
Trong quá trình làm việc với khách hàng, PM cần cân nhắc các khó khăn:
- Người dùng không thể hiện được ra họ cần gì trong sản phẩm
- Có thiên vị về thiết kế của sản phẩm trước đó cầu kì nhưng họ đã dùng quen lâu năm.
PM cũng cần cân nhắc các hạn chế của người dùng:
- Hạn chế về giác quan: có vấn đề về 5 giác quan hoặc mù màu.
- Thể chất: người dùng thuận tay trái hoặc tay phải.
- Nhận thức: người dùng chỉ nhớ được một số lượng yếu tố nhất định, nên thiết kế giao diện giúp cho người dùng đỡ phải nhớ nhiều.
Tạo cơ hội cho khách hàng tham gia thảo luận, đặt câu hỏi thích hợp, giao tiếp rõ ràng và sử dụng bảng chú giải thuật ngữ để thiết lập các thuật ngữ chung cho mọi người thống nhất ý hiểu.
Các kỹ thuật hỗ trợ về yêu cầu:
Use case là công cụ cần thiết để hiểu sản phẩm giúp xác định và làm rõ và sắp xếp các chi tiết đầu việc, một bản use case thường có các thành phần như :
- Tên
- Các bên tham gia
- Mục tiêu
- Trình kích hoạt
- Điều kiện trước
- Điều kiện sau
- Luồng cơ bản
- Luồng phụ
- Trường hợp ngoại lệ.
Ví dụ:
| Tên | Đặt hàng trực tuyến |
| Các bên tham gia | Khách hàng: Là người có nhu cầu đặt mua sản phẩm trực tuyến
Website thương mại điện tử: Trang web chịu trách nhiệm xử lý đơn hàng của khách hàng |
| Mục tiêu | Khách hàng: đặt hàng thành công sản phẩm mong muốn.
Trang web thương mại điện tử: Xử lý đơn đặt hàng của khách hàng và chuẩn bị giao hàng. |
| Trình kích hoạt | Khách hàng: Click vào nút “Đặt hàng” sau khi chọn sản phẩm. |
| Luồng cơ bản | 1. Khách hàng chọn sản phẩm và thêm vào giỏ hàng.
2. Khách hàng nhấn vào nút “Đặt hàng”. 3. Trang web xác minh tính sẵn có của sản phẩm và tính toán tổng chi phí. 4. Khách hàng cung cấp địa chỉ giao hàng và thông tin thanh toán. 5. Website xác nhận đơn hàng và gửi email xác nhận cho khách hàng. 6. Website chuẩn bị đơn hàng để vận chuyển. |
| Trường hợp ngoại lệ | Nếu sản phẩm không có sẵn, trang web sẽ thông báo cho khách hàng và xóa sản phẩm đó khỏi đơn hàng.
Nếu thanh toán không thành công, website sẽ nhắc khách hàng cung cấp thông tin thanh toán hợp lệ. |
- Wireframe cung cấp một bản phác thảo cơ bản về thiết kế của sản phẩm, tập trung vào bố cục và vị trí của các thành phần giao diện.
- Wireframe giúp khai triển và phản hồi thay đổi ý kiến của khách hàng với team nhanh chóng, giúp tiết kiệm thời gian. Những kỹ thuật khi viết yêu cầu.
- User story là một kỹ thuật quan trọng để thể hiện các yêu cầu thường sử dụng định dạng như: “Tôi là [vai trò], tôi muốn [làm điều gì đó] để [đạt được mục tiêu].” (“As a who, I want to what, so that why”.)
User story thường là những câu ngắn, có kiểm thử được và ước tính công việc được. - Acceptance test: là cách kiểm tra các yêu cầu của một User story có đã được hoàn thành hay không, dựa trên tiêu chí chấp nhận (acceptance criteria) do khách hàng đặt ra.
- Backlog là danh sách user story của người dùng hoặc các đầu việc đã được xác định để tiến hành thực hiện.
User story hoặc đầu việc trong backlog được ưu tiên dựa trên các cuộc thảo luận của khách hàng và nhóm dev.
Backlog giúp sắp xêp công việc và lập kế hoạch ưu tiên, là một quan trọng trong các phương pháp Agile như Scrum.
Bài tiếp theo: Các kỹ thuật lập kế hoạch dự án theo Agile