Giải pháp thăm quan


HỖ TRỢ
Đăng ký
Đăng nhập
Bắt đầu dùng thử miễn phí

Cách triển khai Công cụ quản lý yêu cầu

Cách triển khai Công cụ quản lý yêu cầu

Mục lục

Làm cách nào để triển khai Công cụ quản lý yêu cầu?

Để triển khai Công cụ quản lý yêu cầu, bạn có thể thực hiện một số bước.

Trước tiên, bạn cần xác định các bên liên quan và người dùng công cụ. Điều này bao gồm người quản lý dự án, nhà phân tích kinh doanh, nhà phát triển, người thử nghiệm và những người khác sẽ sử dụng nó. Bạn cũng cần xác định loại hệ thống quản lý yêu cầu nào là tốt nhất cho tổ chức của mình dựa trên quy mô, mức độ phức tạp của dự án và các yếu tố khác.

Tiếp theo, bạn nên quyết định công cụ phần mềm hoặc nền tảng nào bạn muốn sử dụng cho quy trình quản lý yêu cầu của mình. Hiện nay trên thị trường có rất nhiều loại khác nhau như Visure. Khi bạn đã quyết định cái nào là tốt nhất cho nhu cầu của tổ chức mình thì đã đến lúc thiết lập hệ thống. Điều này có thể bao gồm tạo tài khoản người dùng, thiết lập cấp truy cập cho những người dùng khác nhau và định cấu hình cài đặt để đảm bảo chức năng thích hợp của phần mềm.

Khi công cụ quản lý yêu cầu của bạn được thiết lập đúng cách thì đã đến lúc bắt đầu sử dụng nó! Bạn nên xác định các mẫu để thu thập và tổ chức các yêu cầu từ các bên liên quan. Ngoài ra, bạn nên tạo một bộ quy trình và quy tắc để đảm bảo từng yêu cầu được ghi lại chính xác để chúng được theo dõi phù hợp trong suốt vòng đời của nó. Cuối cùng, bạn nên thiết lập một quy trình xem xét để tất cả các thay đổi hoặc cập nhật đối với một yêu cầu đều được xem xét đúng cách trước khi được triển khai.

Tại sao bạn cần Công cụ quản lý yêu cầu?

Không có gì bí mật rằng các yêu cầu kém dẫn đến các sản phẩm kém chất lượng và các dự án này thường chứa đầy phạm vi leo thang. Có rất nhiều thách thức với cách tiếp cận dựa trên tài liệu đối với các yêu cầu, bao gồm thực tế là rất khó để cập nhật chúng trong quá trình phát triển phần mềm luôn thay đổi. Ngay cả khi bạn đã hoàn thành xuất sắc công việc thu thập và ghi lại các yêu cầu của người dùng, nhiệm vụ quản lý các yêu cầu chỉ mới bắt đầu.

Dưới đây là một số lý do chính để sử dụng công cụ Quản lý yêu cầu tự động theo Karl Wiegers (bài viết trên www.processimpact.com về Quản lý yêu cầu tự động).

Quản lý các phiên bản và thay đổi. Ngày nay, hầu hết các hệ thống được phát hành theo kiểu lặp lại (hoặc Agile). Điều này có nghĩa là các yêu cầu sẽ có các phiên bản được liên kết với bản phát hành. Có khả năng theo dõi các thay đổi và xác định tác động của các thay đổi trong việc kiểm soát thay đổi và leo thang phạm vi.

Lưu trữ thông tin bổ sung về yêu cầu trong thuộc tính yêu cầu. Có rất nhiều điều chúng ta cần biết về một yêu cầu ngoài tuyên bố của yêu cầu. Ví dụ: trạng thái của các yêu cầu, mức độ ưu tiên, người yêu cầu và trạng thái thử nghiệm. Ở đây chỉ có một vài đề nghị.

Liên kết các yêu cầu với các phần tử hệ thống khác. Để đảm bảo tất cả các yêu cầu là một phần của sản phẩm, tất cả các yêu cầu đều được kiểm tra, các thay đổi được đánh giá, v.v. chúng ta cần có khả năng liên kết các yêu cầu với các thành phần hệ thống khác.

Theo dõi trạng thái. Hãy nghĩ đến việc có thể tạo danh sách tất cả các yêu cầu không được phê duyệt, tất cả các yêu cầu không được liên kết với các yêu cầu cấp thấp hơn và tất cả các yêu cầu không được kiểm tra. Đây là những loại thông tin giúp chúng ta thực sự biết được tình trạng của dự án.

Xem các tập con yêu cầu. Hãy nghĩ đến việc có thể xem tất cả các yêu cầu có mức độ ưu tiên cao không được chỉ định phương pháp thử nghiệm. Hoặc một văn phòng bảo mật chỉ muốn xem xét các yêu cầu liên quan đến bảo mật. Khả năng lọc các yêu cầu để chỉ bao gồm thông tin mà người dùng muốn xem giúp giảm thời gian cần thiết để xem xét các yêu cầu này.

Kiểm soát truy cập. Bạn sẽ muốn đảm bảo rằng các nhà phân tích kinh doanh chỉ có thể sửa đổi các yêu cầu của người dùng; các nhà phân tích hệ thống chỉ có thể sửa đổi các yêu cầu hệ thống, v.v. Sau khi được phê duyệt, quyền truy cập vào các yêu cầu phải được giới hạn để không thể thực hiện thêm thay đổi nào mà không cần xem xét.

Giao tiếp với các bên liên quan. Thông báo về các thay đổi là điều cần thiết để đảm bảo các bên liên quan nhận thức được tất cả các thay đổi tiềm năng. Hầu hết các công cụ quản lý yêu cầu có thể hỗ trợ tự động cung cấp loại thông báo này.

Đối với những người trong chúng ta, những người đã sử dụng các công cụ quản lý yêu cầu, thật khó để tưởng tượng việc quay lại thực hiện công việc đó trên giấy. Và tôi tin rằng có rất ít người trong chúng ta chọn quay lại phương pháp đó. Cá nhân tôi sẽ sử dụng bất kỳ công cụ quản lý yêu cầu nào theo cách tiếp cận dựa trên tài liệu. Tuy nhiên, điều làm tôi ngạc nhiên là nhiều tổ chức thuộc mọi quy mô vẫn tiếp tục dựa vào các công cụ dựa trên tài liệu để quản lý các yêu cầu của họ. Sử dụng công cụ Quản lý yêu cầu là bước đầu tiên bắt buộc để kiểm soát các yêu cầu.

Trước khi mua Công cụ quản lý yêu cầu...

Không có gì bí mật khi các giải pháp kỹ thuật yêu cầu chuyên nghiệp giúp nâng cao hiệu quả khi làm việc với các yêu cầu. Chúng cũng giúp giảm thiểu số lỗi thường dẫn đến việc sửa chữa tốn kém khi được tìm thấy trong các giai đoạn sau của vòng đời phát triển. 

Do đó, nhiều công ty đang tìm kiếm các giải pháp kỹ thuật yêu cầu như vậy, nhưng thật không may, quy tắc tương tự đối với hầu hết mọi loại công cụ phần mềm khác cũng áp dụng cho các giải pháp kỹ thuật yêu cầu: kẻ ngốc có công cụ vẫn là kẻ ngốc…

Các giải pháp kỹ thuật yêu cầu tốt nhất trong lớp như nền tảng Visure Requirement ALM rất linh hoạt để có thể hỗ trợ hầu hết mọi loại quy trình kỹ thuật yêu cầu. Tất nhiên, chúng tôi - với tư cách là nhà cung cấp công cụ - rất vui được bán cho bạn một số phần mềm nhưng chúng tôi tin rằng điều này thôi sẽ không giúp được gì cho bạn. Thay vào đó, chúng tôi muốn giúp bạn thành công trong việc sử dụng các sản phẩm của chúng tôi.

Vì vậy, trước khi mua giải pháp kỹ thuật yêu cầu, vui lòng đảm bảo rằng bạn có quy trình kỹ thuật yêu cầu phù hợp được xác định với các hoạt động nhất định được chỉ định cho các vai trò nhất định. Tất nhiên, chúng tôi cũng có thể chia sẻ kinh nghiệm của chúng tôi với bạn trong lĩnh vực này. Nếu bạn biết các đặc điểm chi tiết của quy trình của mình, bạn sẽ dễ dàng tìm ra giải pháp thích hợp phù hợp với nhu cầu của quy trình của mình hơn nhiều.

6 mẹo để triển khai thành công công cụ quản lý yêu cầu

Nhiều năm trước, tôi đã dành nhiều năm nghiên cứu một hệ thống điều khiển vũ khí rất phức tạp. Như bạn có thể tưởng tượng, các yêu cầu rất lớn, phức tạp và thay đổi thường xuyên. Chúng tôi đã dành rất nhiều thời gian chỉ để cố gắng quản lý những thay đổi phiền phức vẫn tiếp tục được gửi đến, cả từ khách hàng và nhà phát triển. Trong những ngày đầu đó, chúng tôi không có bất kỳ công cụ quản lý yêu cầu nào để giúp chúng tôi đánh giá những thay đổi này. Chúng tôi đang sử dụng Interleaf và Excel (bây giờ tôi có thể nghe thấy tiếng rên rỉ đau đớn). Mọi thứ đều được thực hiện thủ công, bao gồm cả khả năng truy xuất nguồn gốc phức tạp của chúng tôi. Chúng tôi có một số người không làm gì ngoài việc duy trì ma trận truy xuất nguồn gốc và đánh giá tác động của những thay đổi. Tại thời điểm này, chúng tôi chỉ có khả năng truy xuất nguồn gốc từ Khái niệm Hoạt động đến Yêu cầu Hệ thống đến Yêu cầu Hệ thống Con. Tôi nói “chỉ” nhưng vào thời điểm đó, chỉ cần có mức độ truy xuất nguồn gốc này đã là một thành tựu lớn. 

Khi chúng tôi có đủ thay đổi, chúng tôi đã ban hành tài liệu yêu cầu hệ thống mới và tài liệu yêu cầu hệ thống con mới. Những nhà thầu kém cỏi đó đã phải trải qua các yêu cầu lớn của hệ thống phụ và xác định thủ công những gì đã thay đổi. Tôi không thể tưởng tượng được thời gian mà các nhà thầu dành ra chỉ để cố gắng tìm ra những thay đổi mà họ cần quan tâm.

Chính giữa dự án nâng cấp này, khách hàng đã nói đủ và giao nhiệm vụ cho nhóm của tôi đánh giá và lựa chọn một công cụ quản lý yêu cầu. Công cụ chúng tôi đã chọn không quan trọng đối với cuộc thảo luận cụ thể này, nhưng những gì chúng tôi học được từ việc lựa chọn và triển khai công cụ này mới quan trọng. Dưới đây là một số bài học kinh nghiệm.

(1) – Không có một công cụ nào có thể làm hài lòng tất cả mọi người. Chúng tôi có những người dùng yêu thích lựa chọn của chúng tôi và những người đã chống lại chúng tôi trên mọi bước đường. Nếu không có khách hàng hỗ trợ và thực thi thay đổi thì sẽ không thể thực hiện được trên một chương trình lớn như thế này. Một người dùng đã phàn nàn về kích thước cột của ma trận truy xuất nguồn gốc do công cụ tạo ra, hoàn toàn phớt lờ thực tế rằng nó đã giúp anh ta tiết kiệm được nhiều ngày cho nỗ lực thủ công.

(2) – Truy xuất nguồn gốc thủ công của chúng tôi không được sạch sẽ cho lắm. Khi chúng tôi đã nhập tất cả thông tin của mình vào công cụ và liên kết nó với nhau, chúng tôi đã tìm thấy nhiều lỗ hổng trong quá trình truy xuất nguồn gốc. Điều đáng lo ngại hơn là chúng tôi có những liên kết thực sự không có ý nghĩa gì. Chúng tôi đã phải làm rất nhiều việc để làm sạch ma trận truy xuất nguồn gốc của mình.

(3) - Chỉ cần theo dõi các yêu cầu là tuyệt vời, nhưng bây giờ chúng tôi có thể sử dụng nỗ lực tương tự để liên kết các yêu cầu với các kế hoạch kiểm tra và tiến xa hơn là liên kết các yêu cầu của hệ thống con với các tài liệu thiết kế mà chúng tôi có thể xem xét. Điều này đã không xảy ra qua đêm, nhưng nó đã xảy ra. Cuối cùng, chúng tôi có thể theo dõi các yêu cầu hệ thống từ yêu cầu hệ thống con đến tài liệu thiết kế đến mô-đun mã. Chúng tôi thậm chí đã sử dụng một công cụ để xác định độ phức tạp của các mô-đun mã và sử dụng công cụ này để giúp xác định mức độ khó thực hiện và thử nghiệm của một thay đổi.

(4) – Các số liệu từ một công cụ yêu cầu là chìa khóa để hiểu được tính đầy đủ của các hoạt động thử nghiệm. Chúng tôi thường nghĩ rằng chúng tôi đã hoàn thành 50% việc thử nghiệm. Rốt cuộc, 50% bài kiểm tra đã được hoàn thành. Tuy nhiên, những gì chúng tôi nhận thấy là chúng tôi có xu hướng thử nghiệm những phần đơn giản nhất và dễ hiểu nhất của hệ thống trước tiên. Vì vậy, mặc dù chúng tôi đã hoàn thành 50% nhưng mọi thứ còn lại đều có rủi ro rất cao. Chúng tôi đã học cách ưu tiên thử nghiệm của mình bằng cách xem xét mức độ ưu tiên của yêu cầu và độ phức tạp của phần mềm, thông tin mà chúng tôi không thể xác định thông qua truy xuất nguồn gốc thủ công.

(5) – Rất dễ bị choáng ngợp. Bắt đầu đơn giản. Chúng tôi đã phải từ bỏ những ý tưởng đầy tham vọng của mình và bắt đầu với một mô hình truy xuất nguồn gốc đơn giản. Khi chúng tôi học hỏi và có thêm kinh nghiệm với công cụ này, chúng tôi đã thêm nhiều thông tin hơn vào mô hình của mình. Chúng tôi liên tục đánh giá quá trình của mình để tìm ra những gì chúng tôi có thể làm để làm cho nó tốt hơn.

(6) - Đừng bỏ qua việc đào tạo và cố vấn. Chúng tôi đã đào tạo mọi người trong dự án và tạo ra các chuyên gia giúp người dùng vượt qua những trở ngại ban đầu. Chúng tôi đã cử các chuyên gia đến các nhà thầu của mình trong nhiều tuần liền để giúp họ bắt kịp tốc độ sử dụng công cụ này. Chúng tôi thậm chí còn có nhóm người dùng nội bộ của riêng mình. Hãy chuẩn bị cho loại nỗ lực này.

Đây là một trải nghiệm học tập tuyệt vời đối với tôi. Nếu bạn quan tâm đến việc bắt tay vào thay đổi như thế này để cải thiện quy trình yêu cầu của mình, hãy liên hệ với Visure Solutions. Chúng tôi sẽ vui lòng thảo luận về quy trình của bạn với bạn.

Đừng quên chia sẻ bài viết này!

Áo sơ mi

Hợp lý hóa việc quản lý và xác nhận yêu cầu

Tháng Bảy 11th, 2024

10 giờ sáng giờ EST | 4 giờ chiều CET | 7 giờ sáng theo giờ Thái Bình Dương

Louis Arduin

Louis Arduin

Chuyên gia tư vấn cấp cao, Visure Solutions

Thomas Dirsch

Chuyên gia tư vấn chất lượng phần mềm cấp cao, Razorcat Development GmbH

Phương pháp tiếp cận tích hợp với Giải pháp Visure và Phát triển Razorcat TESSY

Tìm hiểu cách hợp lý hóa việc quản lý và xác thực yêu cầu để có kết quả tốt nhất.