Kỹ thuật yêu cầu trong phát triển phần cứng

Hãy thành thật mà nói: rất ít người cảm thấy hào hứng với các yêu cầu. Thế nhưng, mọi nhóm phát triển phần cứng đều từng cảm nhận cái giá của những yêu cầu không rõ ràng: phải làm lại ở giai đoạn muộn, hoặc một bản dựng không đáp ứng đúng điều mà các bên liên quan thực sự yêu cầu. 

Requirements engineering (RE) là một bộ môn áp dụng quy trình có cấu trúc để xác định, tài liệu hóa và quản lý các yêu cầu nhằm bảo đảm sản phẩm cuối cùng giải quyết đúng vấn đề. Khi được áp dụng tốt, nó giúp phát hiện sai sót từ sớm, giữ cho cả nhóm luôn thống nhất, và đem lại sự tin tưởng rằng sản phẩm được phát hành chính là sản phẩm đã được thống nhất xây dựng.

Tuy nhiên, thuật ngữ này thường dễ gây nhầm lẫn vì nó bắt nguồn từ cả kỹ nghệ phần mềm lẫn kỹ nghệ hệ thống của các sản phẩm phần cứng. 

Trong bài viết này, bạn sẽ có được một định nghĩa rõ ràng về requirements engineering và vai trò của nó trong phát triển sản phẩm phần cứng. Chúng tôi sẽ trình bày cả phần tổng quan lý thuyết lẫn một khung thực hành về cách áp dụng nó trong một dự án phần cứng, kèm theo các ví dụ thực tế và danh sách những cạm bẫy phổ biến nhất cùng cách tránh chúng.

Những điểm chính

• Requirements engineering giúp các nhóm phần cứng chuyển hóa ý định thiết kế thành các yêu cầu rõ ràng và giữ cho mọi người trong nhóm luôn đồng bộ.
• Các yêu cầu định hướng dự án từ giai đoạn lập kế hoạch và thiết kế ban đầu cho đến thử nghiệm, thay đổi và tài liệu cuối cùng.
• Một quy trình yêu cầu tốt giúp các nhóm phát triển phát hiện vấn đề sớm, tránh các lần thiết kế lại tốn kém và bảo đảm sản phẩm cuối cùng đáp ứng đúng những gì đã được thống nhất.

Requirements Engineering là gì?

Requirements engineering là một phương pháp tiếp cận có hệ thống và kỷ luật để xác định, tài liệu hóa và quản lý các yêu cầu trong suốt quá trình phát triển sản phẩm phần cứng.

Nó giúp các nhóm hiểu vấn đề cần giải quyết, làm rõ và phân tích nhu cầu của các bên liên quan, giải quyết xung đột và đánh đổi, ghi lại sản phẩm cần đạt được điều gì, đồng thời luôn cập nhật hiểu biết đó khi sản phẩm tiếp tục phát triển.

Trong thực tế, các yêu cầu tạo ra sự hiểu biết chung giữa các bên liên quan và nhóm kỹ thuật về việc đang xây dựng cái gì, vì sao phải xây dựng nó, và làm thế nào để nhóm biết được liệu sản phẩm cuối cùng có đáp ứng đúng ý định thiết kế hay không.

Lợi ích của Requirements Engineering

Khi RE được thực hiện tốt, nó giúp ngăn ngừa hiểu lầm và những sai sót tốn kém, giữ cho cả nhóm thống nhất, đồng thời giúp bảo đảm sản phẩm cuối cùng đáp ứng các yêu cầu của nó.

Các lợi ích chính của RE bao gồm:

• Tầm nhìn chung: Giữ cho các bên liên quan, nhà quản lý và nhóm kỹ thuật cùng thống nhất về một cách hiểu chung đối với sản phẩm đang được xây dựng.
• Phạm vi rõ ràng: Làm rõ điều gì thuộc phạm vi dự án và điều gì không thuộc, từ đó giúp ngăn chặn việc bổ sung không kiểm soát, còn gọi là scope creep.
• Giảm các sai sót tốn kém: Giúp phát hiện sớm các vấn đề trong yêu cầu, trước khi chúng trở thành chi phí lớn do phải làm lại thiết kế, tạo nguyên mẫu mới hoặc thử nghiệm lặp đi lặp lại.
• Cải thiện lập kế hoạch và tiến độ: Giúp nhóm có cái nhìn rõ hơn về những gì cần xây dựng, từ đó dễ ước lượng khối lượng công việc và lập ra các mốc thời gian thực tế hơn.
• Cải thiện chất lượng sản phẩm: Giúp bảo đảm sản phẩm cuối cùng thực hiện đúng những gì đã thống nhất và đáp ứng các tiêu chuẩn chất lượng yêu cầu.

Sự phát triển của bộ môn Requirements Engineering

Requirements engineering có nguồn gốc từ cả kỹ nghệ hệ thống lẫn kỹ nghệ phần mềm. Hai nhánh này phát triển trong những bối cảnh kỹ thuật khác nhau, vì vậy thuật ngữ này đến nay vẫn có thể mang phạm vi ý nghĩa hơi khác nhau tùy theo nguồn tham chiếu.

Trong bối cảnh kỹ nghệ phần mềm, trọng tâm chủ yếu là các yêu cầu phát triển phần mềm: phần mềm phải làm gì, phải hoạt động như thế nào, và phải đáp ứng những thuộc tính chất lượng nào. Các kỹ sư phần mềm thường nghĩ đến các yêu cầu chức năng và phi chức năng được ghi lại dưới dạng user story, use case và acceptance criteria. Trong bối cảnh kỹ nghệ hệ thống, phạm vi rộng hơn. Yêu cầu đề cập đến toàn bộ hệ thống, bao gồm phần cứng, phần mềm, con người, quy trình, giao diện, điều kiện vận hành và các đặc tính hệ thống khác. Các kỹ sư hệ thống nói đến các yêu cầu ở cấp hệ thống được phân rã xuống phần cứng, cơ khí, điện, firmware và các yếu tố an toàn, được ghi lại dưới dạng phát biểu yêu cầu chính thức và ma trận truy vết yêu cầu.

Trong phát triển phần cứng, RE kết hợp cả hai góc nhìn này. Nó kết hợp tính chặt chẽ và phạm vi đa ngành của kỹ nghệ hệ thống — cần thiết để xử lý chi phí bill of materials (BOM), các ràng buộc nhiệt và giới hạn sản xuất — với khả năng truy vết xuyên suốt vòng đời vốn được dùng trong kỹ nghệ phần mềm để giữ cho các yêu cầu có thể kiểm thử được và luôn được liên kết trong suốt quá trình phát triển.

Các bộ môn liên quan đến Requirements Engineering

Requirements engineering có quan hệ chặt chẽ với các bộ môn khác trong phát triển sản phẩm, đặc biệt là kỹ nghệ hệ thống và quản lý sản phẩm.

Kỹ nghệ hệ thống

Kỹ nghệ hệ thống xem sản phẩm như một hệ thống hoàn chỉnh. Kỹ sư hệ thống bảo đảm rằng các phần khác nhau như phần cứng, phần mềm, các chi tiết cơ khí và thử nghiệm phối hợp đúng cách với nhau và không xung đột.

Điều này gắn chặt với RE vì các yêu cầu cung cấp cho tất cả những nhóm này một điểm tham chiếu chung về những gì sản phẩm cần đạt được.

Nếu bạn thích phép so sánh, hãy hình dung việc xây một ngôi nhà. Các chuyên gia khác nhau phụ trách móng, điện, nước và sưởi ấm, nhưng vẫn cần có ai đó bảo đảm rằng tất cả các phần đó thực sự ăn khớp với nhau để tạo thành một kết cấu hoàn chỉnh. Kỹ nghệ hệ thống đóng đúng vai trò đó trong phát triển sản phẩm.

Quản lý sản phẩm

Quản lý sản phẩm giúp quyết định nên xây dựng gì và vì sao. Các quản lý sản phẩm trao đổi với khách hàng, nghiên cứu thị trường, xem xét đối thủ cạnh tranh và làm việc với doanh nghiệp để quyết định vấn đề nào đáng giải quyết và tính năng nào quan trọng nhất.

Điều này cũng liên quan đến RE vì những nhu cầu khách hàng ở mức cao và các mục tiêu kinh doanh đó trở thành điểm khởi đầu để xác định các yêu cầu sản phẩm.

Các giai đoạn của quy trình Requirements Engineering

Quy trình RE có thể được tổ chức theo nhiều cách khác nhau tùy vào lĩnh vực ứng dụng, những người tham gia và tổ chức. Ở một số dự án, các hoạt động diễn ra chủ yếu theo trình tự, còn ở những dự án khác, chúng được lặp lại và xem xét lại khi nhóm hiểu rõ hơn.

Như được mô tả trong một bài báo đăng trên tạp chí Requirements Engineering, một cách tiếp cận phổ biến trong giáo trình chia quy trình RE thành bốn hoạt động cốt lõi (giai đoạn):

• Thu thập yêu cầu: thu thập yêu cầu từ các bên liên quan và các nguồn khác để hiểu hệ thống phải làm gì và phải vận hành trong những điều kiện nào.
• Phân tích và đặc tả yêu cầu: xem xét những gì đã thu thập, giải quyết thông tin chưa rõ hoặc mâu thuẫn, và chuyển chúng thành các yêu cầu rõ ràng mà nhóm kỹ thuật có thể sử dụng.
• Thẩm định yêu cầu: kiểm tra rằng các yêu cầu là đúng, đầy đủ và mô tả chính xác những gì hệ thống được kỳ vọng sẽ đạt được.
• Quản lý yêu cầu: theo dõi các yêu cầu và những thay đổi của chúng theo thời gian, bao gồm lý do thay đổi và những yêu cầu, công việc thiết kế hay thử nghiệm nào khác có thể bị ảnh hưởng.

Ai tham gia vào quy trình

Một số vai trò chủ chốt tham gia vào khung RE, cùng phối hợp để xác định sản phẩm cần làm gì:

• Chủ sở hữu yêu cầu: Kỹ sư tiếp nhận các nhu cầu còn mơ hồ từ bên liên quan, đặt ra đúng câu hỏi và chuyển chúng thành một bộ yêu cầu mà nhóm kỹ thuật thực sự có thể dùng cho phát triển sản phẩm. Vai trò này thường là Kỹ sư Hệ thống, Kỹ sư trưởng hoặc người có trách nhiệm tương tự.
• Lãnh đạo sản phẩm kỹ thuật: Những người giao tiếp với phía stakeholder/doanh nghiệp, hiểu nhu cầu của họ, rồi chuyển yêu cầu đó thành một mục tiêu sản phẩm rõ ràng. Vai trò này có thể bao gồm Product Manager, Program Manager hoặc các vai trò tương tự.
• Kỹ sư triển khai: Kỹ sư sử dụng các yêu cầu đã được xác định để thiết kế và xây dựng phần việc của mình trong sản phẩm. Vai trò này có thể bao gồm các kỹ sư Điện tử, Cơ khí, Phần mềm hoặc Firmware.
• Người phụ trách thẩm tra: Người quyết định các yêu cầu sẽ được kiểm tra như thế nào và bảo đảm các bước rà soát, thử nghiệm cần thiết được hoàn tất. Vai trò này có thể bao gồm Kỹ sư Verification, Kỹ sư Test hoặc Kỹ sư QA.

Khung Requirements Engineering thực tiễn cho phát triển phần cứng

Mặc dù bốn hoạt động ở trên xác định phần cốt lõi của quy trình RE, các nhóm phần cứng cần một cách thực tế để áp dụng chúng xuyên suốt dự án.

Sau đây là góc nhìn thực tiễn về khung requirements engineering cho phát triển phần cứng, cho thấy các yêu cầu phù hợp với từng giai đoạn như thế nào.

Khởi động dự án: Ghi nhận ý định

Khi bắt đầu một dự án, các Trưởng nhóm kỹ thuật thường nhận được những đầu vào còn mơ hồ như yêu cầu từ khách hàng, yêu cầu mời thầu (RFP), mục tiêu kinh doanh hoặc các ràng buộc về chi phí, kích thước hay tiến độ. Ví dụ, khách hàng có thể yêu cầu một thiết bị nhỏ hơn để hỗ trợ một trường hợp sử dụng cụ thể.

Cùng với Chủ sở hữu yêu cầu, các Trưởng nhóm kỹ thuật sẽ làm rõ nhu cầu và chuyển những đầu vào đó thành các yêu cầu ở mức cao mô tả sản phẩm cần đạt được điều gì.

Requirements Engineering: Xác định yêu cầu

Các yêu cầu mức cao từ giai đoạn Khởi động dự án vẫn còn quá rộng để phục vụ thiết kế chi tiết. Ở giai đoạn này, Chủ sở hữu yêu cầu xác định hệ thống tổng thể, chia nó thành các phần và phân hệ, rồi chuyển các yêu cầu mức cao đó thành những yêu cầu cụ thể hơn cho từng phần.

Họ cũng kiểm tra để bảo đảm các yêu cầu không mâu thuẫn, không thiếu nội dung quan trọng, và từng yêu cầu đều rõ ràng cũng như có thể kiểm thử. Kết quả là một bộ yêu cầu đã được thống nhất mà nhóm kỹ thuật có thể dùng làm điểm xuất phát cho thiết kế sản phẩm.

Triển khai: Phát triển thiết kế

Các Kỹ sư triển khai sử dụng các yêu cầu đã được thống nhất để thiết kế và xây dựng phần việc của mình trong sản phẩm, चाहे đó là tạo sơ đồ nguyên lý, mô hình hóa một chi tiết 3D, hay viết phần mềm hoặc firmware. Khi thiết kế phát triển, họ liên kết từng yêu cầu với đặc tính thiết kế đáp ứng nó. Những liên kết này tạo nên khả năng truy vết của dự án và giúp Chủ sở hữu yêu cầu thấy được các yêu cầu đã được triển khai như thế nào.

Verification & Validation: Kiểm thử và xác minh

Các yêu cầu cũng xác định những gì cần được kiểm tra trong quá trình rà soát và thử nghiệm. Kỹ sư Verification xác định cách thức kiểm tra từng yêu cầu và phối hợp với các Kỹ sư triển khai để thực hiện các bước rà soát, đo lường hoặc thử nghiệm cần thiết, đồng thời ghi lại kết quả. Điều này kết nối giữa những gì sản phẩm được yêu cầu phải đạt được với bằng chứng cho thấy liệu nó có thực sự đạt được hay không.

Quản lý thay đổi: Sửa đổi và lặp lại

Các yêu cầu và thiết kế sản phẩm thường thay đổi trong quá trình phát triển. Một yêu cầu có thể được chứng minh là không thể đáp ứng, một linh kiện có thể không còn sẵn có trên thị trường, hoặc một ràng buộc mới có thể xuất hiện. Khi điều này xảy ra, Chủ sở hữu yêu cầu theo dõi điều gì đã thay đổi, vì sao nó thay đổi, và những yêu cầu, phần thiết kế hoặc thử nghiệm nào bị ảnh hưởng.

Tài liệu hóa & Bàn giao: Bàn giao dự án

Vào cuối dự án, Chủ sở hữu Yêu cầu phối hợp với Kỹ sư Xác minh và các thành viên còn lại trong nhóm để hoàn tất việc đóng yêu cầu, rà soát thiết kế và các hoạt động xác minh. Tài liệu cuối cùng cần cung cấp hồ sơ có thể truy vết về những gì đã được yêu cầu, những gì đã được xây dựng và cách chúng đã được xác minh. Khách hàng, nhà sản xuất, kiểm toán viên hoặc các nhóm tiếp tục làm việc trên sản phẩm sẽ cần thông tin này về sau.

Ví dụ về Kỹ thuật Yêu cầu

Kỹ thuật Yêu cầu trong Thiết bị Y tế

Kỹ thuật Yêu cầu được sử dụng trong nhiều loại sản phẩm công nghệ y tế và chăm sóc sức khỏe. Các yêu cầu đồng hành cùng sản phẩm trong suốt quá trình phát triển. Các nhóm chuyển nhu cầu của các bên liên quan thành các yêu cầu hệ thống có cấu trúc, duy trì sự liên kết của chúng khi đặc tả thay đổi, và dùng chúng để lập kế hoạch xác minh cũng như ghi lại kết quả thử nghiệm.

Thiết bị y tế bổ sung thêm một lớp yêu cầu pháp lý. Các nhóm cần đầu tư nhiều công sức hơn vào khả năng truy vết, xác minh, tài liệu và giấy tờ. Điều này hỗ trợ việc xin phê duyệt theo các khung pháp lý như FDA 21 CFR Part 820 tại Hoa Kỳ và ISO 13485:2016 tại EU và các thị trường khác.

Miếng bảo vệ miệng HitIQ là một ví dụ về thiết bị đeo y tế, nơi các yêu cầu an toàn quyết định mọi đặc tả kỹ thuật. Tìm hiểu cách họ thực hiện điều đó trong câu chuyện thành công của khách hàng đầy đủ.

Kỹ thuật Yêu cầu trong Điện tử Tiêu dùng & Công nghiệp

Quy trình kỹ thuật yêu cầu cốt lõi là tương tự nhau trong điện tử tiêu dùng và điện tử công nghiệp, nhưng các sản phẩm được phát triển trong những điều kiện khác nhau. Các sản phẩm tiêu dùng như thiết bị nhà thông minh hoặc thiết bị đeo được bán với số lượng lớn và ra mắt nhanh. Các sản phẩm công nghiệp như bộ điều khiển logic khả trình (PLC) hoặc bộ truyền động động cơ phải hoạt động trong nhiều năm dưới điều kiện khắc nghiệt.

Trong cả hai trường hợp, các nhóm ghi lại sản phẩm phải làm gì, liên kết từng yêu cầu với thiết kế, cập nhật yêu cầu khi có thay đổi và kiểm thử dựa trên các yêu cầu đó.

Điều khác biệt là nơi các nhóm cần tập trung thêm công sức. Trong điện tử tiêu dùng, điều đó nằm ở việc theo kịp các thay đổi nhanh chóng, vì chỉ một yêu cầu bị hiểu sai cũng có thể dẫn đến việc phải thiết kế lại bo mạch. Trong điện tử công nghiệp, trọng tâm là xác minh, vì sản phẩm phải được kiểm thử về tuổi thọ dài và khả năng chịu điều kiện khắc nghiệt trước khi xuất xưởng.

Để xây dựng phần cứng đáng tin cậy và tuân thủ các quy định an toàn, việc giữ cho các yêu cầu và thay đổi thiết kế luôn được liên kết là yếu tố then chốt. Hãy đọc cách MakeSafe Tools quản lý điều này trong câu chuyện thành công đầy đủ.

Cách Tránh Những Sai sót Phổ biến trong Kỹ thuật Yêu cầu

Kỹ thuật yêu cầu đi kèm với một số thách thức phổ biến. Biết điều gì có thể xảy ra sai giúp bạn dễ phát hiện vấn đề sớm hơn và tránh chúng trong quá trình phát triển sản phẩm phần cứng.

Dưới đây là một số sai sót phổ biến nhất cần lưu ý và cách tránh chúng:

Công cụ Phần mềm cho Kỹ thuật Yêu cầu

Quản lý một tập yêu cầu nhỏ tương đối đơn giản. Khi dự án phát triển, việc giữ mọi thứ có tổ chức và luôn cập nhật đòi hỏi nhiều công sức hơn. Đến thời điểm đó, cách bạn quản lý yêu cầu bắt đầu trở nên quan trọng hơn.

Trong thực tế, các nhóm thường làm việc theo một trong những cách tiếp cận sau:

• Bảng tính và Tài liệu: Quen thuộc và dễ bắt đầu, nên hữu ích cho các dự án nhỏ hơn. Tuy nhiên, khi dự án phát triển, chúng đòi hỏi nhiều công việc thủ công hơn để duy trì.
• Công cụ Quản lý Yêu cầu (RM) Chuyên dụng: Cung cấp nhiều cấu trúc và khả năng kiểm soát hơn khi dự án trở nên phức tạp hơn. Đánh đổi là một số công cụ cũng kéo theo nhiều quy trình hơn mức mà một nhóm nhỏ cần.

Mục tiêu là sử dụng mức độ cấu trúc vừa đủ cho dự án mà không khiến việc quản lý yêu cầu trở nên phức tạp hơn mức cần thiết.

Đối với các nhóm phần cứng nhỏ đã vượt quá khả năng của bảng tính nhưng không cần một quy trình RM doanh nghiệp quy mô lớn, Requirements Portal là một lựa chọn thực tế đáng cân nhắc. Công cụ này được thiết kế để mang lại cho các nhóm nhỏ một cách có cấu trúc hơn để quản lý yêu cầu mà không phải chịu gánh nặng của một hệ thống doanh nghiệp truyền thống.

Kết luận & Các bước Tiếp theo

Đến thời điểm này, bạn hẳn đã hiểu rõ các khái niệm chính của kỹ thuật yêu cầu và cách chúng được áp dụng trong thực tế.

Nếu bạn muốn tiếp tục tìm hiểu về kỹ thuật yêu cầu, những tài nguyên này là điểm khởi đầu phù hợp:

• ISO/IEC/IEEE 29148:2018 cung cấp tiêu chuẩn quốc tế cho các quy trình và thực hành kỹ thuật yêu cầu. Tài liệu này đưa ra hướng dẫn bổ sung về cách viết, cấu trúc, tài liệu hóa và quản lý các yêu cầu.
• NASA Systems Engineering Handbook cung cấp hướng dẫn thực tế về cách các yêu cầu được tạo ra, viết ra, kiểm tra và sử dụng trong quá trình phát triển hệ thống.
• Guide to the Systems Engineering Body of Knowledge (SEBoK) giải thích cách các yêu cầu phù hợp với quy trình kỹ thuật hệ thống tổng thể và cách các phần khác nhau của một hệ thống được phát triển cùng nhau.
• Tạp chí Requirements Engineering công bố các nghiên cứu, ví dụ trong ngành và các cách tiếp cận khác nhau đối với kỹ thuật yêu cầu ở mức độ chuyên sâu hơn.

Nếu bạn đã sẵn sàng chuyển từ lý thuyết sang thực hành, hãy thử Requirements Portal và bắt đầu làm việc với các yêu cầu có cấu trúc trên một dự án phần cứng thực tế ngay hôm nay, miễn phí và không cần thiết lập.

Câu hỏi Thường gặp

Vì sao Kỹ thuật Yêu cầu Quan trọng?

Kỹ thuật yêu cầu quan trọng vì nó giúp nhóm xây dựng đúng sản phẩm bằng cách hiểu rõ nhu cầu của các bên liên quan trước khi thiết kế và phát triển đi quá xa.

Vai trò của một Kỹ sư Yêu cầu là gì?

Kỹ sư yêu cầu chuyển nhu cầu của các bên liên quan thành các yêu cầu rõ ràng để nhóm kỹ thuật có thể sử dụng, đồng thời giữ các yêu cầu đó được tổ chức tốt khi dự án thay đổi. Họ đóng vai trò là cầu nối giữa khách hàng và các nhóm phát triển. 

Sự khác biệt giữa Kỹ thuật Yêu cầu và Quản lý Yêu cầu là gì?

Kỹ thuật yêu cầu là toàn bộ quá trình khám phá, thấu hiểu và ghi lại những gì một hệ thống cần phải làm ngay từ đầu. Quản lý yêu cầu là phần cụ thể của công việc đó, tập trung vào việc giữ các yêu cầu được tổ chức tốt và theo dõi mọi thay đổi sau khi chúng đã được viết ra.