Lập kế hoạch Yêu cầu Tốt
Vậy, điều gì tạo nên một yêu cầu tốt? Một yêu cầu tốt phải có giá trị và có thể hành động được; nó sẽ xác định nhu cầu cũng như cung cấp một con đường dẫn đến một giải pháp. Mọi người trong đội nên hiểu ý nghĩa của nó. Các yêu cầu khác nhau về mức độ phức tạp.
Tài liệu Yêu cầu tốt có thể là một phần của một nhóm với các yêu cầu cấp cao được chia thành các yêu cầu phụ.
Chúng cũng có thể bao gồm các thông số kỹ thuật rất chi tiết bao gồm một tập hợp các yêu cầu chức năng mô tả hành vi hoặc các thành phần của sản phẩm cuối.
Yêu cầu tốt cần ngắn gọn và cụ thể, đồng thời phải trả lời câu hỏi “chúng ta cần gì?” Thay vào đó, "làm thế nào để đáp ứng nhu cầu?"
Các yêu cầu tốt đảm bảo rằng tất cả các bên liên quan hiểu được phần kế hoạch của họ; nếu các bộ phận không rõ ràng hoặc bị hiểu sai, sản phẩm cuối cùng có thể bị lỗi hoặc hỏng.
Việc ngăn ngừa thất bại hoặc hiểu sai các yêu cầu có thể được hỗ trợ bằng cách nhận phản hồi từ nhóm liên tục trong suốt quá trình khi các yêu cầu phát triển. Cộng tác liên tục và tham gia với mọi người là chìa khóa thành công.
Thu thập và phân tích yêu cầu
Yêu cầu là điều kiện hoặc khả năng cần thiết của một bên liên quan để giải quyết vấn đề hoặc đạt được mục tiêu của tổ chức; một điều kiện hoặc khả năng mà một hệ thống phải đáp ứng hoặc sở hữu.
Phân tích yêu cầu trong kỹ thuật phần mềm bao gồm những nhiệm vụ đi vào xác định nhu cầu hoặc điều kiện để đáp ứng cho một sản phẩm mới hoặc đã thay đổi có tính đến các yêu cầu xung đột có thể có của các bên liên quan khác nhau, phân tích, lập tài liệu, xác nhận và quản lý các yêu cầu phần mềm hoặc hệ thống.
Các yêu cầu phải là -
- Documented
- Actionable
- Measurable
- Testable
- Traceable
Các yêu cầu phải liên quan đến nhu cầu hoặc cơ hội kinh doanh đã được xác định, và được xác định ở mức độ chi tiết đủ để thiết kế hệ thống.
Một nhà phân tích kinh doanh thu thập thông tin thông qua việc quan sát các hệ thống hiện có, nghiên cứu các quy trình hiện có, thảo luận với khách hàng và người dùng cuối. Nhà phân tích cũng phải có kỹ năng tưởng tượng và sáng tạo nếu không có Hệ thống hoạt động. Phân tích yêu cầu đã tập hợp để tìm ra các liên kết còn thiếu là phân tích yêu cầu.
Phương pháp tiếp cận gợi ý
Để gợi ra các mục tiêu, hãy hỏi chuyên gia kinh doanh, giám đốc phát triển và nhà tài trợ dự án những câu hỏi sau:
Dự án này sẽ giúp đạt được những mục tiêu kinh doanh nào của công ty?
Tại sao chúng tôi thực hiện dự án này bây giờ?
Điều gì sẽ xảy ra nếu chúng ta làm điều đó sau này?
Điều gì sẽ xảy ra nếu chúng ta không làm điều đó?
Ai sẽ được lợi từ dự án này?
Những người sẽ được hưởng lợi từ nó có coi đây là cải tiến quan trọng nhất có thể được thực hiện vào lúc này không?
Thay vào đó, chúng ta có nên thực hiện một dự án khác không?
Các mục tiêu khả thi có thể là giảm chi phí, cải thiện dịch vụ khách hàng, đơn giản hóa quy trình làm việc, thay thế công nghệ lỗi thời, thử nghiệm một công nghệ mới và nhiều công nghệ khác. Ngoài ra, hãy đảm bảo rằng bạn hiểu chính xác cách dự án được đề xuất sẽ giúp hoàn thành mục tiêu đã nêu.
Các loại yêu cầu khác nhau
Các loại yêu cầu phổ biến nhất mà Nhà phân tích kinh doanh quan tâm sẽ là:
Yêu cầu kinh doanh
Yêu cầu kinh doanh là các hoạt động quan trọng của một doanh nghiệp phải được thực hiện để đáp ứng các mục tiêu của tổ chức trong khi vẫn giữ được giải pháp độc lập. Tài liệu yêu cầu kinh doanh (BRD) nêu chi tiết giải pháp kinh doanh cho một dự án bao gồm tài liệu về nhu cầu và mong đợi của khách hàng.
Yêu cầu người sử dụng
Yêu cầu của người dùng nên chỉ rõ các yêu cầu cụ thể mà người dùng mong đợi / muốn từ phần mềm được xây dựng từ dự án phần mềm. Yêu cầu của người dùng phải có thể xác minh, rõ ràng và ngắn gọn, hoàn chỉnh, nhất quán, có thể theo dõi, khả thi.
Tài liệu yêu cầu người dùng (URD) hoặc đặc tả yêu cầu người dùng là một tài liệu thường được sử dụng trong kỹ thuật phần mềm chỉ định những gì người dùng mong đợi phần mềm có thể thực hiện.
yêu cầu hệ thống
Yêu cầu hệ thống liên quan đến việc xác định các yêu cầu tài nguyên phần mềm và các điều kiện tiên quyết cần được cài đặt trên máy tính để cung cấp chức năng tối ưu của ứng dụng.
Yêu cầu chức năng
Các yêu cầu chức năng nắm bắt và xác định hành vi dự kiến cụ thể của hệ thống đang được phát triển. Chúng xác định những thứ như tính toán hệ thống, thao tác và xử lý dữ liệu, giao diện người dùng và tương tác với ứng dụng cũng như các chức năng cụ thể khác cho thấy yêu cầu của người dùng được thỏa mãn như thế nào. Chỉ định một số ID duy nhất cho mỗi yêu cầu.
Những yêu cầu phi lý
Yêu cầu phi chức năng là yêu cầu xác định các tiêu chí có thể được sử dụng để đánh giá hoạt động của một hệ thống hơn là các hành vi cụ thể. Kiến trúc hệ thống nói lên kế hoạch thực hiện các yêu cầu phi chức năng.
Các yêu cầu phi chức năng nói lên cách hệ thống trông như thế nào hoặc nó có thể được đề cập như "hệ thống sẽ như thế nào". Các yêu cầu phi chức năng được gọi là phẩm chất của hệ thống.
Yêu cầu chuyển đổi
Yêu cầu Chuyển đổi mô tả các khả năng mà giải pháp phải đáp ứng để tạo điều kiện chuyển đổi từ trạng thái hiện tại của doanh nghiệp sang trạng thái mong muốn trong tương lai, nhưng điều đó sẽ không cần thiết khi quá trình chuyển đổi đó hoàn tất.
Chúng được phân biệt với các loại yêu cầu khác, bởi vì chúng luôn có bản chất tạm thời và vì chúng không thể được phát triển cho đến khi cả giải pháp hiện tại và giải pháp mới được xác định. Chúng thường bao gồm việc chuyển đổi dữ liệu từ các hệ thống hiện có, các lỗ hổng kỹ năng phải được giải quyết và các thay đổi liên quan khác để đạt được trạng thái mong muốn trong tương lai. Chúng được phát triển và xác định thông qua đánh giá và xác nhận giải pháp.
Quản lý truy xuất nguồn gốc và thay đổi
Truy xuất nguồn gốc yêu cầu là một cách để tổ chức, lập tài liệu và theo dõi tất cả các yêu cầu của bạn từ khi hình thành ý tưởng ban đầu cho đến giai đoạn thử nghiệm.
Ma trận khả năng theo dõi các yêu cầu (RTM) cung cấp một phương pháp để theo dõi các yêu cầu chức năng và việc thực hiện chúng thông qua quá trình phát triển. Mỗi yêu cầu được đưa vào ma trận cùng với số phần liên quan của nó.
Khi dự án tiến triển, RIM được cập nhật để phản ánh trạng thái của từng yêu cầu. Khi sản phẩm đã sẵn sàng để kiểm tra hệ thống, ma trận liệt kê từng yêu cầu, thành phần sản phẩm giải quyết nó và kiểm tra nào xác minh rằng nó được thực hiện đúng
Bao gồm các cột cho từng điều sau đây trong RTM -
- Mô tả yêu cầu
- Tham chiếu yêu cầu trong FRD
- Phương thức xác minh
- Tham chiếu yêu cầu trong Kế hoạch thử nghiệm
Example- Kết nối các dấu chấm để xác định mối quan hệ giữa các hạng mục trong dự án của bạn. Nó là một đầu nối của dòng chảy hạ lưu chung.
Yêu cầu ý tưởng Thiết kế thử nghiệm Mục tiêu kinh doanh
Bạn sẽ có thể theo dõi từng yêu cầu của mình trở lại mục tiêu kinh doanh ban đầu của nó.
Bằng cách theo dõi các yêu cầu, bạn có thể xác định các thay đổi về hiệu ứng gợn sóng, xem liệu một yêu cầu đã được hoàn thành và liệu nó có được kiểm tra đúng cách hay không. Khả năng truy xuất nguồn gốc và quản lý thay đổi cung cấp cho các nhà quản lý sự an tâm và khả năng hiển thị cần thiết để dự đoán các vấn đề và đảm bảo chất lượng liên tục.
Đảm bảo chất lượng
Việc đáp ứng các yêu cầu ngay từ lần đầu tiên có thể có nghĩa là chất lượng tốt hơn, chu kỳ phát triển nhanh hơn và sự hài lòng của khách hàng cao hơn với sản phẩm. Quản lý yêu cầu không chỉ giúp bạn thực hiện đúng mà còn giúp nhóm của bạn tiết kiệm tiền và nhiều vấn đề đau đầu trong suốt quá trình phát triển.
Các yêu cầu cụ thể, ngắn gọn có thể giúp bạn phát hiện và khắc phục sự cố sớm, thay vì để muộn hơn khi sửa chữa tốn kém hơn nhiều. Ngoài ra, nó có thể có giá lên đến100 times nhiều hơn để sửa một khiếm khuyết sau này trong quá trình phát triển sau khi nó được mã hóa, hơn là sửa sớm khi có yêu cầu.
Bằng cách tích hợp quản lý yêu cầu vào quy trình đảm bảo chất lượng, bạn có thể giúp nhóm của mình tăng hiệu quả và loại bỏ công việc làm lại. Hơn nữa, làm lại là nơi mà hầu hết các vấn đề chi phí xảy ra.
Nói cách khác, các nhóm phát triển đang lãng phí phần lớn ngân sách của họ cho những nỗ lực không được thực hiện đúng trong lần đầu tiên. Ví dụ: một nhà phát triển mã hóa một tính năng dựa trên một tài liệu đặc tả cũ, chỉ để tìm hiểu sau, rằng các yêu cầu cho tính năng đó đã thay đổi. Các loại vấn đề này có thể tránh được bằng các phương pháp hay nhất về quản lý yêu cầu hiệu quả.
Tóm lại, quản lý yêu cầu nghe có vẻ giống một kỷ luật phức tạp, nhưng khi bạn rút gọn nó thành một khái niệm đơn giản - đó là việc giúp các nhóm trả lời câu hỏi, "Mọi người có hiểu những gì chúng tôi đang xây dựng và tại sao không?" Từ các nhà phân tích kinh doanh, giám đốc sản phẩm và lãnh đạo dự án đến các nhà phát triển, quản lý QA và người kiểm tra, cùng với các bên liên quan và khách hàng liên quan - vì vậy nguyên nhân gốc rễ của sự thất bại của dự án thường là do hiểu sai về phạm vi của dự án.
Khi tất cả mọi người đang cộng tác và có đầy đủ bối cảnh và khả năng hiển thị các cuộc thảo luận, quyết định và thay đổi liên quan đến các yêu cầu trong suốt vòng đời của dự án, đó là khi thành công xảy ra một cách nhất quán và bạn duy trì chất lượng liên tục. Ngoài ra, quá trình này diễn ra suôn sẻ hơn với ít xích mích và khó chịu hơn cho tất cả mọi người tham gia.
Note- Nghiên cứu đã chỉ ra rằng các nhóm dự án có thể loại bỏ 50-80% các khiếm khuyết của dự án bằng cách quản lý hiệu quả các yêu cầu. Theo viện kỹ thuật phần mềm Carnegie Mellon, “60-80 phần trăm chi phí phát triển phần mềm là làm lại.”
Đạt được Yêu cầu Ký hiệu
Các yêu cầu ký kết chính thức hóa sự đồng ý của các bên liên quan trong dự án rằng nội dung và cách trình bày các yêu cầu, như được lập thành văn bản, là chính xác và đầy đủ. Thỏa thuận chính thức làm giảm rủi ro mà trong hoặc sau khi thực hiện, một bên liên quan sẽ đưa ra một yêu cầu mới (trước đây chưa đạt được).
Việc đạt được các yêu cầu ký kết thường bao gồm việc xem xét trực tiếp lần cuối các yêu cầu, như đã được lập thành văn bản, với từng bên liên quan của dự án. Vào cuối mỗi lần xem xét, bên liên quan được yêu cầu chính thức phê duyệt tài liệu yêu cầu đã được xem xét. Sự chấp thuận này có thể được ghi lại bằng vật lý hoặc điện tử.
Thu thập các yêu cầu ký kết thường là nhiệm vụ cuối cùng trong Truyền thông Yêu cầu. Nhà phân tích kinh doanh sẽ yêu cầu kết quả đầu ra từ (các) Đánh giá Yêu cầu Chính thức, bao gồm cả việc lưu giữ bất kỳ nhận xét hoặc phản đối nào được nêu ra trong quá trình xem xét.