Tại sao phải phân biệt giữa các yêu cầu chức năng và không chức năng?

Tôi hiểu sự khác biệt giữa hai loại này, nhưng tôi bị các đồng nghiệp của mình nghi ngờ về lợi ích của các yêu cầu ghi nhãn là chức năng hoặc không chức năng (hoặc chuyển tiếp). Tại sao phải làm như vậy? Ông đã dành những gì ông nói là hai ngày để xem danh sách các yêu cầu cho một dự án và không thấy có lợi gì cho nó, vì kết quả cuối cùng là gửi tài liệu cho một thực thể kinh doanh khác với sắc lệnh, "Làm tất cả".

Điều tôi sợ là các yêu cầu gộp lại trong một tài liệu. Tôi đã cố gắng giải thích lợi ích trong điều kiện thực tế, nhưng không thể bán nó. Làm thế nào để tôi bán lợi ích của việc ghi lại các yêu cầu nào là chức năng và không phải là chức năng.

Các yêu cầu rõ ràng tách biệt sẽ giúp dễ dàng hơn để thiết kế hệ thống phù hợp.

Với các yêu cầu không chức năng (tôi thích các thuộc tính chất lượng khái niệm / thuật ngữ - nên cung cấp những hiểu biết mới ngoài chức năng so với không chức năng), bạn quan tâm nhiều hơn đến các thuộc tính của phần mềm hơn là chức năng. Đó là cách hệ thống thực hiện một số chức năng, không chỉ đơn giản là những gì hệ thống làm. Các yêu cầu chất lượng có ảnh hưởng đáng kể đến kiến ​​trúc của hệ thống theo cách mà các yêu cầu chức năng không làm được và vì lý do này, chúng nên được xử lý khác nhau.

Giữ các thuộc tính chất lượng tách biệt với các yêu cầu chức năng cho phép bạn phân tích, chỉ định và ưu tiên các loại yêu cầu khác nhau theo các cách khác nhau. Ví dụ: các thuộc tính chất lượng thường được chỉ định bằng cách sử dụng kịch bản thuộc tính chất lượng trong khi các yêu cầu chức năng có thể ở dạng câu chuyện, trường hợp sử dụng, câu lệnh hoặc bất kỳ định dạng nào khác. Hầu hết các hệ thống tôi đã làm việc có ít hơn một chục thuộc tính chất lượng và nhiều, nhiều yêu cầu chức năng hơn.

Tôi thực sự sẽ giới thiệu một loại yêu cầu khác - những hạn chế kỹ thuật . Một lần nữa, việc phân tách rõ ràng các yêu cầu trong ba nhóm này cung cấp cho bạn các tín hiệu về cách thực hiện sự đánh đổi đúng đắn trong khi xây dựng hệ thống. Các yêu cầu chức năng thường khá dễ thương lượng, các thuộc tính chất lượng sẽ ảnh hưởng lớn đến kiến ​​trúc của bạn và các cấu trúc bạn chọn, các ràng buộc kỹ thuật là không thể thương lượng.

Nếu đây là nhóm của tôi, tôi sẽ nói với họ các yêu cầu nên được chú thích rõ ràng theo loại để đảm bảo chúng tôi không bỏ lỡ điều gì quan trọng trong kiến ​​trúc. Hãy suy nghĩ về các trình điều khiển kiến ​​trúc, không chỉ là chức năng.

Anthony Lattanze trong Kiến trúc hệ thống chuyên sâu về phần mềm: Hướng dẫn cho các học viên đưa ra một cái nhìn tổng quan thực tế về các trình điều khiển kiến ​​trúc và lý do tại sao chúng nên được đối xử khác nhau, toàn diện hơn nhiều so với tóm tắt của tôi ở đây.

Khi mọi yêu cầu có mức độ ưu tiên / trọng lượng như nhau (đặc biệt là "Bắt buộc") thì bạn có thể phải lo lắng nhiều hơn là chỉ chia tách các yêu cầu Chức năng và Không chức năng.

Tuy nhiên, có một số lý do để phân tách Hai loại yêu cầu:

Trách nhiệm thực hiện Tôi đã thấy rằng nhiều yêu cầu phi chức năng - đặc biệt là những yêu cầu tập trung vào hiệu suất, chỉ được áp dụng ở mức độ vừa phải cho nhà phát triển. Mặc dù một thiết kế có thể hỗ trợ khả năng mở rộng và tốc độ (và các phần mã cụ thể có thể được điều chỉnh) nói chung có thể đáp ứng bất kỳ yêu cầu hiệu suất nào phụ thuộc vào Kiến trúc và thường là thời gian cấu hình phần cứng.

Trách nhiệm đối với việc kiểm tra Làm thế nào người dùng hoặc nhóm QA lão luyện trong việc kiểm tra các yêu cầu về bảo mật, dung sai, an toàn và độ tin cậy được đáp ứng?

Đừng lặp lại chính mình Tài liệu phải tuân theo nguyên tắc DRY giống như mã. Các yêu cầu kiểu dáng UI chung nên được nhóm lại với nhau. Nếu người chịu trách nhiệm cho các yêu cầu thực sự muốn, họ có thể tham chiếu các yêu cầu phi chức năng (cá nhân hoặc theo nhóm) trong các yêu cầu chức năng.

Phiên bản Nếu bạn ở trong môi trường công ty có nhiều "tiêu chuẩn" - bạn có thể Viết các tài liệu yêu cầu về UI hoặc Bảo mật (để đặt tên cho một cặp đôi) có thể được phiên bản. Bằng cách đó, bạn có thể viết trong các yêu cầu cụ thể của ứng dụng (chủ yếu là Yêu cầu về chức năng): "Ứng dụng phải tuân thủ V2.3 của Yêu cầu bảo mật được xác định trong XYZ-Company-SecReq-DocumnentNamingSt Chuẩn.docx".

Tại sao phải phân biệt giữa các yêu cầu chức năng và không chức năng?

Một lý do để phân biệt là mức độ trừu tượng giữa hai loại. Các yêu cầu không chức năng là ở cấp độ hệ thống và cho biết toàn bộ hệ thống phải hành xử như thế nào. Các yêu cầu chức năng đề cập đến một tính năng cụ thể và các tính năng và chức năng phải được cung cấp cho khách hàng.

Các yêu cầu không chức năng cũng ràng buộc hệ thống, trong khi các yêu cầu chức năng cho biết hệ thống phải làm gì. Các yêu cầu không chức năng cung cấp các hạn chế về cách các yêu cầu chức năng được thiết kế và thực hiện sau này. Bằng cách tách chúng ra, có thể xác định rõ các tính năng khỏi các ràng buộc và hạn chế.

Điều tôi sợ là các yêu cầu gộp lại trong một tài liệu. Tôi đã cố gắng giải thích lợi ích trong điều kiện thực tế, nhưng không thể bán nó. Làm thế nào để tôi bán lợi ích của việc ghi lại các yêu cầu nào là chức năng và không phải là chức năng.

Theo kinh nghiệm của tôi, các yêu cầu chức năng và phi chức năng thực sự được nhóm vào cùng một tài liệu hoặc được theo dõi trong cùng một hệ thống. Tuy nhiên, họ được cung cấp các phần riêng biệt của tài liệu cũng như các tiêu chí thành công để đáp ứng từng phần.

Nói chung, bạn phân loại các yêu cầu để giúp nhóm cung cấp chống lại chúng. Nếu có một yêu cầu đặc biệt nhắm vào nhu cầu kiến ​​trúc, gọi đó là yêu cầu "Kiến trúc" sẽ giúp nhóm khi làm việc với kiến ​​trúc.

Một tài liệu lớn về tất cả các yêu cầu không nhất thiết là điều xấu ... Dành 2 ngày để xem xét nó cũng không phải là xấu. Vấn đề thường xảy ra là một khi một người đã xem xét các yêu cầu, họ sẽ hiểu chúng, nhưng sẽ không dễ dàng hơn cho bất kỳ ai khác làm điều tương tự. Nó có thể là một trợ giúp lớn để bắt đầu yêu cầu ghi nhãn với siêu dữ liệu sẽ giúp những người khác tham gia dự án.

Có lẽ cố gắng để mô tả nó như là một vấn đề trừu tượng. Nếu bạn cần làm việc trong một cơ sở mã kế thừa, bạn không chỉ cần đọc qua tất cả các dòng mã hiện có sau đó bắt đầu làm việc. Bạn làm theo cấu trúc của mã để giúp bạn. Có một số cấu trúc trong các yêu cầu giúp theo cùng một cách.

Có nhiều lợi ích cho sự tách biệt.

1. Tiết kiệm thời gian kiểm tra (tức là chỉ kiểm tra các yêu cầu chức năng)
2. Tiết kiệm thời gian cho những thay đổi trong tương lai đối với các yêu cầu (nghĩa là các yêu cầu phi chức năng sẽ mất ít thời gian hơn để xem xét / phê duyệt / thực hiện / kiểm tra)
3. Trong một thế giới được quy định (ví dụ như FDA, v.v.), các yêu cầu phi chức năng đòi hỏi 1/10 số lượng giấy tờ mà một yêu cầu chức năng yêu cầu.
4. Cung cấp cho nhóm khả năng phân chia công việc giữa các thành viên nhóm cấp cao (chức năng) và cấp dưới (không chức năng).

Tôi có thể tiếp tục...

Nhìn bề ngoài hai ngày dường như là một khoảng thời gian dài, về lâu dài nó có thể tiết kiệm hàng tuần hoặc thậm chí hàng tháng làm việc trong tương lai.