Yêu cầu chức năng hay phi chức năng?

Tôi đang tự hỏi về các yêu cầu chức năng hoặc phi chức năng. Tôi đã tìm thấy rất nhiều định nghĩa khác nhau cho các thuật ngữ đó và tôi không thể gán một số yêu cầu của mình cho danh mục phù hợp.

Tôi đang tự hỏi về các yêu cầu không được kết nối với một số hành động hoặc có một số điều kiện bổ sung, ví dụ:

1. Trên danh sách các thiết bị được chọn, thiết bị có thể được lặp lại.
2. Cơ sở dữ liệu phải chứa ít nhất 100 mục
3. Tiền tệ của một số giá trị phải được tính bằng đô la Mỹ.
4. Thiết bị phải có tên và giá trị tiêu thụ điện năng trong Watts.

là những yêu cầu chức năng hoặc không chức năng?

Các yêu cầu chức năng xác định những gì hệ thống hoặc ứng dụng sẽ làm - cụ thể là trong bối cảnh tương tác bên ngoài (với người dùng hoặc với hệ thống khác).

Khi đặt hàng mới, hệ thống sẽ hiển thị tổng chi phí và yêu cầu xác nhận từ người dùng. Đó là một yêu cầu chức năng; nó mô tả một chức năng của hệ thống.

Tham khảo Wikipedia: Yêu cầu chức năng để biết thêm chi tiết.

Các yêu cầu phi chức năng là bất kỳ yêu cầu nào không mô tả hành vi đầu vào / đầu ra của hệ thống. Lưu ý rằng chúng tôi vẫn đang nói về các yêu cầu , không phải chi tiết triển khai , vì vậy chỉ vì chúng tôi đang sử dụng cụm từ "phi chức năng" không có nghĩa là bất cứ điều gì là trò chơi công bằng để đưa vào phần đó.

Các loại yêu cầu phi chức năng phổ biến nhất bạn sẽ thấy liên quan đến hoạt động của hệ thống (tính khả dụng, tính liên tục, DR), hiệu suất (thông lượng, độ trễ, dung lượng lưu trữ) và bảo mật (xác thực, ủy quyền, kiểm toán, quyền riêng tư).

Đây là tất cả các mối quan tâm xuyên suốt ảnh hưởng đến mọi "tính năng" chưa thực sự là tính năng; họ có nhiều tính năng như siêu dữ liệu, giúp mô tả không chỉ cho dù hệ thống làm những gì nó nghĩ đến mà còn tốt như thế nào nó có phải nó. Tuy nhiên, đừng mang sự tương tự đó đi quá xa - đó chỉ là một sự tương tự.

Các yêu cầu phi chức năng không phải là chủ quan hay sóng tay, trái với những gì một số người ở đây dường như đang đề xuất. Trên thực tế, họ thực sự nên có một số liệu cứng gắn liền với chúng (tức là thời gian phản hồi không quá 100 ms). Các yêu cầu của NF cũng không phải là chi tiết triển khai hoặc các nhiệm vụ như "nâng cấp khung ORM" - không có đầu mối nơi ai có thể có ý tưởng đó.

Thêm chi tiết tại Wikipedia: Yêu cầu phi chức năng .

Để giải quyết cụ thể các ví dụ trong câu hỏi:

1. Trên danh sách các thiết bị được chọn, thiết bị có thể được lặp lại.

   • Rõ ràng là một yêu cầu chức năng. Mô tả đầu ra của hệ thống trông như thế nào.

2. Cơ sở dữ liệu phải chứa ít nhất 100 mục

   • Âm thanh như một quy tắc kinh doanh, vì vậy cũng là một yêu cầu chức năng. Tuy nhiên, nó có vẻ không đầy đủ. Lý do cho quy tắc này là gì? Điều gì sẽ xảy ra / nên xảy ra nếu cơ sở dữ liệu chứa ít hơn 100 mục?

3. Tiền tệ của một số giá trị phải được tính bằng đô la Mỹ.

   • Yêu cầu chức năng, nhưng không thực sự là một yêu cầu đúng. Một từ ngữ hữu ích hơn sẽ là: Hệ thống sẽ hỗ trợ một loại tiền tệ (USD). Rõ ràng điều này sẽ được sửa đổi nếu cần nhiều hơn một loại tiền tệ, và sau đó yêu cầu sẽ phải bao gồm thông tin về chuyển đổi tiền tệ, v.v.

4. Thiết bị phải có tên và giá trị tiêu thụ điện năng trong Watts.

   • Không thực sự có bất kỳ loại yêu cầu, điều này giống như một đặc điểm kỹ thuật. Một yêu cầu chức năng sẽ được nêu là xếp hạng năng lượng được giả định là ở Watts. Nếu có nhiều hơn một UOM, thì với tiền tệ, các yêu cầu chức năng sẽ có các phần về chuyển đổi đơn vị, nơi / cách chúng được định cấu hình, v.v. (nếu có).

Đã có một câu trả lời tuyệt vời của Aaronaught, nhưng vì đã có những câu trả lời khác, hiện đã bị xóa, hoàn toàn sai về yêu cầu phi chức năng là gì, tôi nghĩ sẽ hữu ích khi thêm một vài lời giải thích để tránh những sai lầm về những gì yêu cầu phi chức năng là.

Yêu cầu phi chức năng là "chất lượng hoặc tài sản mà sản phẩm phải có" . James Taylor nói rằng một yêu cầu phi chức năng "[...] dù sao cũng là một yêu cầu và điều quan trọng đối với khách hàng, đôi khi còn quan trọng hơn cả yêu cầu chức năng" . Sau đó, ông đưa ra hai ví dụ: logo của sản phẩm, độ chính xác và độ tin cậy của thiết bị. Cả hai ví dụ cho thấy rất rõ rằng:

• Các yêu cầu phi chức năng không phải là một jibber-jabber tiếp thị như: "Internet ngày nay rất quan trọng và chúng tôi muốn có một trang web".
• Các yêu cầu phi chức năng liên quan đến khách hàng, vì họ có thể ảnh hưởng lớn đến năng suất và khả năng sử dụng sản phẩm của họ.
• Các yêu cầu phi chức năng là hoàn toàn khách quan.

Điểm cuối cùng là cần thiết. Nếu yêu cầu là chủ quan, nó không có gì để làm trong danh sách các yêu cầu. Không thể xây dựng các bài kiểm tra xác nhận từ một cái gì đó chủ quan . Mục đích duy nhất của danh sách các yêu cầu là liệt kê những kỳ vọng không mơ hồ của khách hàng. "Tôi muốn hình vuông này có màu đỏ" là một yêu cầu. "Tôi muốn hình vuông này có màu sắc đẹp" là một điều ước cần có lời giải thích.

Hãy nhớ rằng danh sách các yêu cầu giống như một hợp đồng (và trong hầu hết các trường hợp là một phần của hợp đồng). Nó được ký bởi khách hàng và công ty phát triển, và trong trường hợp kiện tụng, nó sẽ được sử dụng hợp pháp để xác định xem bạn đã thực hiện đúng công việc của mình chưa. Điều gì sẽ xảy ra nếu tôi đặt hàng cho bạn một sản phẩm phần mềm, xác định rằng "sản phẩm phải tuyệt vời" và từ chối thanh toán khi sản phẩm được hoàn thành, bởi vì đối với tôi, những gì bạn thực sự đã làm không phải là một sản phẩm tuyệt vời ?

Vì vậy, hãy xem một số ví dụ.

  1. Sản phẩm phần mềm đáp ứng cho người dùng cuối.

Đây không phải là một yêu cầu. Không phải là một chức năng. Không phải là một chức năng. Nó không phải là một yêu cầu. Ở tất cả. Nó có giá trị bằng không. Bạn không thể kiểm tra xem hệ thống phần mềm có đáp ứng yêu cầu này trong quá trình kiểm tra xác nhận hay không. Không phải bạn - bộ phận QA, cũng không phải khách hàng.

  2. Việc tải lại số liệu thống kê người dùng thực hiện 90% thời gian dưới 100 ms. khi được thử nghiệm trên máy với hiệu suất được chỉ định trong phụ lục G phần 2 và tải dưới 10% cho CPU, dưới 50% cho bộ nhớ và không có hoạt động đĩa R / W hoạt động.

Đó là một yêu cầu. Nếu phụ lục G phần 2 đủ chính xác, tôi có thể lấy máy có phần cứng tương tự và thực hiện kiểm tra xác nhận trong bộ phận QA và tôi sẽ luôn nhận được kết quả nhị phân: đã vượt qua hoặc thất bại.

Đây có phải là một yêu cầu chức năng? Không. Nó không chỉ định những gì hệ thống phải làm. Có thể có một yêu cầu chức năng trước đó, xác định rằng ứng dụng phần mềm phải có thể tải lại số liệu thống kê người dùng.

Đây có phải là một yêu cầu phi chức năng? Nó là. Nó chỉ định một thuộc tính mà sản phẩm phải có, tức là thời gian phản hồi tối đa / trung bình, được đưa ra ngưỡng phần trăm.

  3. Ứng dụng này được viết bằng C #.

Đây có phải là một yêu cầu? Chúng tôi không thực sự biết mà không có bối cảnh. Đó có thể là mong muốn của nhà phát triển chính, người muốn, bằng cách chèn yêu cầu này, để tránh sau đó một cuộc thảo luận với các đồng nghiệp của mình về ngôn ngữ sẽ sử dụng. Nó cũng có thể là một yêu cầu dựa trên các yếu tố phần cứng / phần mềm, di sản hoặc khả năng tương thích. Chúng tôi không biết.

  4. Cơ sở mã C # của sản phẩm tuân theo Quy tắc khuyến nghị tối thiểu của Microsoft và Quy tắc toàn cầu hóa của Microsoft.

Đây là một điều kỳ lạ. Cá nhân, tôi không muốn gọi nó là một yêu cầu, và đưa nó vào một tài liệu riêng quy định các tiêu chuẩn và thực tiễn tốt nhất.

  5. Cửa sổ chính của ứng dụng có viền 10px màu xanh lam (# 00f) với các vòng tròn được tô màu hồng (#fcc), các vòng tròn đó được đặt ở cạnh trong của đường viền và có đường kính 3px, cách nhau 20px.

Đây là một yêu cầu, và không có chức năng. Nó chỉ định một cái gì đó chúng tôi có thể kiểm tra trong quá trình kiểm tra xác thực và nó chỉ định một thuộc tính của sản phẩm, chứ không phải những gì sản phẩm dự định làm.

  6. Hệ thống theo dõi xe đo tốc độ với độ chính xác ± 0,016 dặm / giờ.

Cũng là một yêu cầu phi chức năng. Nó đưa ra một ngưỡng có thể đo lường được về độ chính xác của hệ thống. Nó không cho biết hệ thống phải làm gì, nhưng cho biết chính xác thì nó hoạt động như thế nào. Nhưng còn chờ gì nữa? Nó nói rằng hệ thống theo dõi xe đo tốc độ, phải không? Vì vậy, đó là một yêu cầu chức năng quá? Chà, không, vì chúng tôi nhấn mạnh vào độ chính xác của phép đo, chứ không phải trên thực tế là phép đo được thực hiện.

  7. Hệ thống theo dõi xe đo tốc độ của xe.

Bây giờ nó là một yêu cầu chức năng. Nó không cho biết hệ thống hoạt động như thế nào, nhưng nó đang làm gì. Thông qua các yêu cầu chức năng, chúng ta có thể biết rằng hệ thống theo dõi xe đo tốc độ, năng lượng pin, áp suất của tôi không biết đèn nào sáng và có bật hay không.

  8. Các trang của trang web mất 850 ms. để tải.

Đây không phải là một yêu cầu. Là cố gắng là một, nhưng hoàn toàn không hợp lệ. Làm thế nào bạn có tài sản này? Những trang nào? Tất cả các? Đã thử nghiệm qua mạng 1Gbps cục bộ trên máy khách lõi tứ và máy chủ tám lõi với SSD được sử dụng ở mức 2% hoặc qua modem của máy tính xách tay cũ và xảo quyệt trong khi trang web được lưu trữ bởi một máy chủ nhỏ được sử dụng ở mức 99% ? "Tải" nghĩa là gì? Có nghĩa là tải xuống trang? Tải về và hiển thị nó? Gửi yêu cầu POST với một số dữ liệu lớn, sau đó tải phản hồi và hiển thị nó?

Để kết luận, một yêu cầu phi chức năng luôn là một yêu cầu, có nghĩa là nó mô tả một cái gì đó là hoàn toàn khách quan và có thể được kiểm tra thông qua một bài kiểm tra xác nhận tự động hoặc bằng tay, nhưng thay vì nói những gì hệ thống đang làm, nó giải thích cách hệ thống đang làm một cái gì đó hoặc làm thế nào hệ thống là chính nó .

^{Quản lý các dự án công nghệ thông tin: Áp dụng các chiến lược quản lý dự án cho các sáng kiến ​​tích hợp phần cứng, phần cứng và tích hợp, James Taylor, ISBN: 0814408117.}

Một yêu cầu chức năng mô tả các kết quả của tương tác với hệ thống (những gì hệ thống làm trong những tình huống nhất định), trong khi yêu cầu phi chức năng thường dùng để chỉ chi tiết cụ thể về hiệu suất, năng lực, thời gian đáp ứng, vv ... những điều mà không thể hiện chức năng, một quá trình trong hệ thống, hoặc kết quả của một tương tác.

Phải nói rằng, yêu cầu phi chức năng mà bạn đang mô tả thực sự là một yêu cầu chức năng với một đặc tả kỹ thuật (điều này thực sự sẽ làm cho nó trở thành một yêu cầu tồi). Một ví dụ về yêu cầu phi chức năng cho trường hợp của bạn sẽ giống như thế này:

- Không được khóa UI trong khi hình động của xúc xắc đang chạy.

Yêu cầu người dùng thường là các yêu cầu UI cụ thể, tùy thuộc vào ngữ cảnh sẽ là chức năng hoặc không chức năng, trong khi yêu cầu hệ thống (ví dụ như năng lực người dùng) thường không phải là chức năng.

Chỉ cần thêm vào một số câu trả lời tốt hiện có rằng các yêu cầu phi chức năng đôi khi được gọi là "bất hợp pháp" - những phẩm chất mà hệ thống cần sở hữu bổ sung cho chức năng đơn giản của nó. "Bất hợp pháp" bao gồm tính khả dụng, tính khả dụng, bảo mật, tính linh hoạt - và thậm chí cả tính thẩm mỹ chủ quan hơn.

Một số trong số này là rất khó để xác định và đánh giá. Tuy nhiên, họ quan trọng. Nếu bạn đăng ký với họ theo hợp đồng, thì bạn sẽ muốn tránh các phiên bản lượn sóng tay vô nghĩa, ví dụ: "Hệ thống phải được bảo mật". Vấn đề với việc cố gắng đưa ra những yêu cầu như vậy là mọi người có xu hướng hấp dẫn những thứ dễ đo lường hơn là những thứ quan trọng (và những yêu cầu có thể được viết bởi những người không có căn cứ nào trong các chuyên ngành liên quan ). Kết quả cuối cùng là bạn thường kết thúc với các hệ thống không an toàn, có thể sử dụng được hoặc không linh hoạt (tính khả dụng không quá khó để chỉ định và đo lường, mặc dù nó vẫn gây ra nhiều vấn đề đau đầu).

Có sự khác biệt về văn hóa ở đây giữa những người giao dịch với hợp đồng và công cụ chính thức, và những người liên quan đến phân tích tổng quát, kiến ​​trúc, nghiên cứu, v.v ... Một yêu cầu lượn sóng tay mơ hồ vẫn là một yêu cầu liên quan, bởi vì nó thể hiện những điều quan trọng đối với khách hàng, ngay cả khi họ đồng cảm hoàn toàn với những người theo hợp đồng rằng đó không phải là một yêu cầu hợp đồng hữu ích cho đến khi nó được khám phá chi tiết và đóng đinh triệt để.

Một điểm cuối cùng - nếu bạn không thể (chưa) đưa ra một thước đo khách quan về "tính bất hợp pháp", điều đó không có nghĩa là khách hàng không cần nó. Mơ hồ! = Không cần thiết. Tuy nhiên, điều đó có thể có nghĩa là chúng ta cần phát triển những cách tốt hơn để đo lường những thứ đó, khơi gợi và tinh chỉnh các yêu cầu phi chức năng tăng dần hoặc hợp đồng theo cách (Agile, v.v.) có thể hoạt động mà không cần các biện pháp khách quan trước mắt cho mọi thứ.

Những bình luận này đều rất tốt nhưng chúng quá chín và không cung cấp một khuôn mẫu rõ ràng để làm việc. Sẽ không rõ ràng khi chỉ định nó là:

Theo tôi, một yêu cầu chức năng là những gì người dùng trải nghiệm khi sử dụng ứng dụng. Đó là yêu cầu cần phải được đáp ứng khi nhà phát triển cố gắng thực hiện điều này từ đầu, thực hiện các cải tiến hoặc sửa đổi. Ví dụ: người dùng nên đăng nhập. Giả sử nếu bạn cũng thêm một cách mới để chạy ứng dụng thông qua dấu nhắc lệnh thì người dùng vẫn phải đăng nhập.

Một yêu cầu phi chức năng xảy ra dưới nắp ca-pô. Người dùng không biết về nó, nhưng nó phải ở đó tuy nhiên nó được thực hiện. Ví dụ: Ứng dụng nên được phát triển trong C #. Nếu nó được phát triển bằng bất kỳ ngôn ngữ nào khác, người dùng sẽ không nhận thấy. Nhưng đó có thể là một yêu cầu vì nó dựa trên mã hiện có. Một ví dụ khác là nó phải được cài đặt trên một máy chủ nhất định. Người dùng di chuyển sẽ không được người dùng chú ý.

Chức năng hay không chức năng? Tôi cũng không nói. Hầu hết, nếu không phải tất cả các ví dụ được liệt kê trông giống như các quy tắc kinh doanh đối với tôi (chỉ định các ràng buộc liên quan đến quy trình và quy tắc quyết định mà quy trình hệ thống phải tuân theo).

Chúng là thứ mà nhiều kỹ sư quên hoặc không biết, vì các quy tắc kinh doanh thường được thu thập như một phần của phân tích kinh doanh (và thường được nhúng trong các thông số kỹ thuật yêu cầu chức năng thay vì được tham chiếu bên ngoài).

Một yêu cầu chức năng thường là một cái gì đó mà hệ thống có thể hoặc sẽ làm. Nó có thể được biểu thị như là kết quả của một hành động (Của một kết quả tiêu cực). Yêu cầu không liên quan là điều mà khách hàng / người dùng cuối không quan tâm và không ảnh hưởng đến kết quả - ví dụ:
Windows sẽ có viền màu xanh với các chấm màu hồng. - Chương trình sẽ được viết bằng Java
- Bất cứ điều gì để làm với các tiêu chuẩn, phương pháp và quy trình mã hóa.

Được cảnh báo mặc dù các yêu cầu phi chức năng có thể được chuyển thành các yêu cầu chức năng của khách hàng. ví dụ có thể là - Chương trình sẽ được viết bằng Erlang vì khách hàng đã đọc một bài báo trên tạp chí về nó và muốn nó được viết bằng Erlang. - Chương trình phải sử dụng DB 2. vì khách hàng sẽ chạy nó trên các hệ thống DB 2 hiện có của mình, có nhiều năm kinh nghiệm và một nhóm CNTT quen thuộc với nền tảng đó.
- Mã nguồn phải vượt qua tất cả các khuyến nghị của MISRA.

Tóm lại - nếu khách hàng quan tâm đến nó, thì đó là một yêu cầu chức năng, nếu không thì đó là một yêu cầu không có chức năng hoặc thậm chí có thể không phải là một yêu cầu.

Tôi nghĩ rằng các yêu cầu chức năng là điều cần thiết mô tả hệ thống và hành vi của nó nhưng các yêu cầu phi chức năng là không cần thiết đối với hệ thống và không được tập hợp trong các cuộc đàm phán thiết kế hệ thống chỉ là sự xuất hiện của hệ thống như chất lượng bảo hiểm tốc độ , bảo mật, khả năng bảo trì, vv từ hệ thống được xây dựng.