Tạo Kế Hoạch Quản Lý Yêu Cầu Kỹ Thuật

Xác định và thiết lập một bộ yêu cầu ngay từ điểm khởi đầu của bất kỳ dự án nào là rất quan trọng để đạt được thành công. Bài viết này, một cách đơn giản, nhằm giới thiệu cho bạn việc tạo ra một kế hoạch quản lý yêu cầu trong các dự án kỹ thuật thông qua một số khái niệm cơ bản và việc sử dụng Altium 365 Requirements & Systems Portal.

Blog này dành cho các kỹ sư, chuyên gia, quản lý dự án, quản lý sản phẩm và bất kỳ ai cần hiểu cách tạo một kế hoạch quản lý yêu cầu.

Yêu cầu là gì?

Dù rõ ràng, việc suy ngẫm về vấn đề 'yêu cầu là gì?' là đáng giá. Theo từ điển, yêu cầu là 'một hoàn cảnh hoặc điều kiện cần thiết cho điều gì đó.' Trong thế giới kỹ thuật, yêu cầu là một cách giao tiếp giữa người dùng hoặc khách hàng và những người phát triển dự án. Đôi khi, đặc biệt trong các dự án lớn, đây là một trong số ít các cách có thể mà người dùng có thể nói cho nhà phát triển biết họ muốn gì.

Ví dụ về một yêu cầu trong dự án ô tô:

'Người dùng phải có thể di chuyển tự động ở các tốc độ được định trước bằng cách sử dụng Cruise control.'

Tại sao Yêu cầu lại Quan trọng?

Người ta nói rằng: "việc định nghĩa và quản lý yêu cầu kém có thể tốn của bạn một gia tài và dẫn đến thất bại trong việc thực hiện dự án."

Việc định nghĩa yêu cầu quan trọng đến mức chúng thường xuyên tạo thành cơ sở của các hợp đồng giữa khách hàng và nhà cung cấp. Những gì được định nghĩa trong yêu cầu sẽ được xem xét trong dự án và có thể được yêu cầu bởi khách hàng, tuy nhiên, những gì không xuất hiện trong định nghĩa của yêu cầu sẽ không được yêu cầu trong giai đoạn giao hàng của dự án.

Vì vậy, nếu chúng ta chịu trách nhiệm viết yêu cầu, chúng ta nên:

• Tìm hiểu chính xác nhu cầu của khách hàng.
• Tạo một tài liệu với cấu trúc rõ ràng và yêu cầu được tổ chức tốt.
• Thiết lập một cuộc họp với khách hàng để xác minh cả hai bên đã viết lợi ích (hợp đồng).
• Đảm bảo giải pháp được chọn phải trung thành với yêu cầu khi dự án tiến triển.
• Xác minh và kiểm tra sự tuân thủ yêu cầu.

Nhóm hành động này được biết đến là kế hoạch quản lý yêu cầu. Rất quan trọng phải có một quản lý hoặc nhóm quản lý trong tổ chức xác định, định nghĩa, và theo dõi yêu cầu qua suốt quá trình sống của dự án.

Làm thế nào một Yêu cầu Nên Được Viết?

Việc viết một yêu cầu không hề đơn giản và nhỏ nhặt như nhiều người vẫn nghĩ. Đó là một tài liệu phải đáp ứng một số tiêu chí nhất định. Do đó, một yêu cầu phải:

• Rõ ràng, chính xác và cụ thể: nó phải mô tả một cách rõ ràng và chính xác những gì cần thiết.
• Ngắn gọn: sử dụng càng ít từ ngữ càng tốt.
• Sử dụng ngôn ngữ đơn giản: tránh làm người đọc bối rối với các thuật ngữ kỹ thuật hoặc từ ngữ phức tạp.

Ví dụ về một yêu cầu được viết tốt:

• Tất cả các linh kiện (SMD và thru-hole) phải được đặt trên mặt TRÊN.

Ví dụ về một yêu cầu được viết kém:

• Các linh kiện SMD phải được đặt cùng một bên, và phải đảm bảo rằng hàn của các linh kiện thru-hole ở phía đối diện với hàn của các linh kiện SMD.

Trong ví dụ trên, yêu cầu được viết tốt là ngắn gọn và xác định một cách hoàn hảo mà không mơ hồ những gì được yêu cầu, trong khi yêu cầu được viết kém có quá nhiều văn bản, không đóng góp vào điều gì, làm người đọc bối rối và không chính xác (nó không xác định mặt nào các linh kiện nên được đặt).

Các yêu cầu luôn là bắt buộc và, do đó, nên được viết bằng "phải". Khi yêu cầu là sở thích hoặc mong muốn (không bắt buộc) "nên" có thể được sử dụng để định nghĩa hoặc thậm chí "có thể" khi đó là một gợi ý hoặc được phép.

Quy tắc Cơ bản Để Định nghĩa một Yêu cầu

Ngoài những điều trên, khi chúng ta định nghĩa một yêu cầu, nó phải tuân theo một số quy tắc cơ bản:

• Nó phải có một ID duy nhất.
• Nó phải được hiểu một cách độc lập mà không cần thông tin bổ sung.
• Nó phải phù hợp với phần còn lại của các yêu cầu.
• Nó luôn phải được cập nhật (kiểm soát phiên bản).
• Nó phải khả thi (tránh các yêu cầu không thể thực hiện được).
• Việc triển khai của nó phải được xác minh thông qua kiểm tra, trình diễn, hoặc thử nghiệm.

Định danh Yêu cầu

Mỗi yêu cầu được định nghĩa phải có một ID duy nhất để có thể tham chiếu trong quá trình định nghĩa và xem xét yêu cầu, cũng như bất kỳ lúc nào trong giai đoạn thực hiện dự án. Một ví dụ về việc định danh yêu cầu được hiển thị sử dụng Altium 365 Requirements and Systems Portal.

Các Loại Yêu cầu Tồn tại và Chúng Được Phân loại Như thế nào?

Có chủ yếu hai loại yêu cầu:

• Yêu cầu chức năng: Đây định nghĩa chức năng của hệ thống.
• Yêu cầu phi chức năng: Đây đặt ra các ràng buộc hoặc hạn chế đối với giải pháp (môi trường, độ tin cậy, khả năng tương thích điện từ, an toàn, quy định áp dụng, yêu cầu về chi phí, thời gian biểu, v.v.).

Sự kết hợp của các yêu cầu chức năng và phi chức năng tạo nên cái được biết đến là thông số kỹ thuật hệ thống. Trong thông số kỹ thuật hệ thống, các yêu cầu được nhóm theo các cấp độ sau:

• Yêu cầu ban đầu hoặc của khách hàng
• Yêu cầu hệ thống
• Yêu cầu hệ thống con

Yêu cầu ban đầu hoặc của khách hàng là những yêu cầu được cung cấp trực tiếp bởi khách hàng hoặc người dùng trước khi dự án bắt đầu. Chúng rất quan trọng, vì chúng nắm bắt nhu cầu của khách hàng và do đó phục vụ như điểm xuất phát để tạo ra ma trận yêu cầu của chúng ta. Sau đó, thông số kỹ thuật hệ thống tổ chức các yêu cầu dựa trên mức độ chi tiết phù hợp với từng phần của dự án. Theo cách này, chúng ta có yêu cầu hệ thống, áp dụng cho toàn bộ hệ thống, và yêu cầu hệ thống con, chỉ áp dụng cho các phần cụ thể của hệ thống. Hãy minh họa điều này với một ví dụ.

Hãy giả sử rằng chúng ta đang phát triển một dự án nơi một chiếc smartwatch mới sẽ được tạo ra. Do đó, các yêu cầu hệ thống là những yêu cầu áp dụng cho bộ (xem các ví dụ dưới đây):

• REQ-01: Phải được thiết kế cho người dùng trưởng thành.
• REQ-02: Phải hiển thị tất cả thông tin trên màn hình.
• REQ-03: Phải có khả năng sạc lại.
• REQ-04: Phải có nút hoặc các cơ chế khác để người dùng điều hướng qua các menu.

Sau khi các yêu cầu hệ thống đã được xác định, các yêu cầu còn lại được chia thành các hệ thống phụ khác nhau.

Theo ví dụ về dự án phát triển smartwatch, các ví dụ về hệ thống phụ bao gồm:

• Hệ thống phụ 1 – Dây đeo
• Hệ thống phụ 2 – Màn hình
• Hệ thống phụ 3 – Nguồn điện
• Hệ thống phụ 4 – Giao tiếp
• Hệ thống phụ 5 – Giao diện người dùng

Do đó, việc xác định các yêu cầu hệ thống phụ có thể như sau:

• STRAP-01: Phải sử dụng vật liệu tái chế.
• STRAP-02: Phải có khả năng được gắn từ tính.
• DISPLAY-01: Màn hình phải có kích thước 2 inch.
• DISPLAY-02: Độ phân giải phải là 368 x 448 pixel.
• POWER-01: Phải được cung cấp năng lượng bởi một pin sạc.
• POWER-02: Thời lượng pin phải ít nhất 48 giờ.
• COMMS-01: Phải có khả năng giao tiếp Bluetooth.
• COMMS-02: Phải có khả năng giao tiếp Wi-Fi.
• UI-01: Phải có nút bên cạnh dưới dạng núm xoay để điều hướng menu.

Việc tổ chức cấu trúc các yêu cầu như vậy giúp việc định nghĩa, theo dõi và quản lý trở nên dễ dàng hơn. 

Khả năng Truy Vết Yêu Cầu

Trong kế hoạch quản lý yêu cầu, khả năng truy vết yêu cầu là điều cần thiết; điều này có nghĩa là theo dõi hoặc quan sát sự phát triển của việc thực hiện yêu cầu xuyên suốt dự án.

Tiếp tục với ví dụ về dự án đồng hồ thông minh, một khi các sơ đồ sản phẩm đã được thiết kế, các kỹ sư và quản lý phải tổ chức bao nhiêu cuộc họp cần thiết để xác minh rằng giải pháp được thiết kế đáp ứng các yêu cầu đã định trước khi chuyển sang bước tiếp theo, trong trường hợp này, là bố trí PCB.

Cổng Thông tin Yêu cầu và Hệ thống hỗ trợ trong nhiệm vụ này, vì nó cung cấp khả năng hiển thị các yêu cầu được định nghĩa trực tiếp trong Altium 365. Điều này có nghĩa là quản lý và kỹ sư giờ đây có thể theo dõi yêu cầu trong thiết kế theo thời gian thực, qua trình duyệt web, cho phép họ thêm bình luận, giao nhiệm vụ cho các thành viên trong nhóm, và cung cấp khả năng hiển thị thời gian thực về sự thay đổi trong yêu cầu đối với kỹ sư thiết kế, từ đó hoàn toàn biến đổi mô hình thiết kế và đánh giá truyền thống.

Làm thế nào để Quản lý Yêu cầu?

Có nhiều cách để quản lý yêu cầu. Các công ty có ít nguồn lực tài chính và các chuyên gia độc lập thường sử dụng các công cụ đơn giản và ít tốn kém như bảng tính có kiểm soát phiên bản, trong khi các công ty lớn hơn thường sử dụng phần mềm chuyên biệt cho quản lý yêu cầu như DOORS, Valispace, Confluence, ReqView, trong số khác. Altium đã mua lại Valispace và bây giờ tích hợp công cụ quản lý yêu cầu vào hệ sinh thái Altium 365 thông qua Cổng Thông tin Yêu cầu và Hệ thống.

Quy Trình Kế Hoạch Quản lý Yêu cầu

Dựa trên các phần trước, chúng ta có thể định nghĩa kế hoạch quản lý yêu cầu là tập hợp các hành động thông qua đó công ty xác định, quản lý, kiểm tra, và xác nhận nhu cầu hoặc yêu cầu của các bên liên quan trong suốt quá trình thực hiện dự án, từ khái niệm đến thương mại hóa. Hình ảnh sau đây minh họa một sơ đồ luồng của kế hoạch quản lý yêu cầu tiêu chuẩn.

Kết luận

Tầm quan trọng của việc có một Kế hoạch Quản lý Yêu cầu

Mọi dự án kỹ thuật đều phải có một kế hoạch quản lý yêu cầu để đảm bảo rằng nhóm phát triển hiểu rõ nhu cầu của khách hàng và tất cả các yêu cầu của hệ thống và hệ thống phụ.

Biết Cách Viết, Định Nghĩa, và Nhận Diện một Yêu cầu một cách Chính xác

Cần phải tuân theo các quy tắc cơ bản khi viết và định nghĩa yêu cầu. Tương tự, việc hiểu các loại yêu cầu tồn tại và cách phân loại chúng một cách chính xác, cũng như hiểu được yêu cầu về khả năng truy vết là rất quan trọng.

Khả năng Truy Vết Yêu cầu

Yêu cầu được viết ra để được đáp ứng, do đó, việc quan sát và theo dõi chúng trong quá trình thực hiện dự án là rất quan trọng, vì càng sớm phát hiện sự lệch lạc hoặc không tuân thủ, nó sẽ càng ít ảnh hưởng đến dự án.

Sử dụng Phần mềm Phù hợp

Sử dụng Cổng Yêu cầu và Hệ thống để tối đa hóa tiềm năng của nó cùng với Altium 365. Điều này cho phép sự tương tác chặt chẽ hơn giữa kỹ thuật yêu cầu và kỹ thuật phát triển, giảm khả năng lệch hướng dự án và rút ngắn thời gian phát triển.

Bắt đầu sử dụng quản lý yêu cầu hiện đại và được hỗ trợ bởi AI ngay hôm nay!