yêu cầu chức năng - sử dụng từ ngữ dựa trên động từ?

Câu hỏi

Các yêu cầu chức năng trong tài liệu yêu cầu có nên sử dụng từ ngữ dựa trên động từ không?

Bối cảnh

Phân công trường học, làm việc trong một nhóm, làm việc thông qua SDLC. Các yêu cầu doc ​​đã được thực hiện và bây giờ chúng tôi đang thiết kế.

Vấn đề

Tài liệu yêu cầu có một danh sách liệt kê những gì tôi gọi là các tính năng của ứng dụng - các yêu cầu chức năng. Trong danh sách đó là những thứ mà tôi nghĩ là "như thế nào" chứ không phải là "cái gì" và bây giờ, cố gắng làm việc trên thiết kế, tôi cảm thấy như một phần của thiết kế đã bị ra lệnh sớm.

Tôi chưa từng làm điều này trước đây! Đối với tôi, tôi nên xử lý nghiêm những điều mô tả "cái gì".

Ví dụ về hiện tại

Giả vờ rằng công việc là làm một món trứng tráng. Liệt kê: bẻ trứng, đập vào bát, tranh giành, v.v.; vượt qua dòng vào lãnh thổ như thế nào. Cùng theo dõi, từ ngữ như: tạo, tạo, liệt kê, tính toán, xác định, xác nhận, vv - động từ, về cơ bản. Ngay bây giờ, tôi có một danh sách các yêu cầu bắt nguồn một phần trong các động từ.

Ý tưởng của tôi về một tài liệu yêu cầu cho món trứng ốp la sẽ giống như: có hai quả trứng, x ounce giăm bông, x ounce thịt xông khói, x ounce phô mai montery-jack, x ounce rau mùi, v.v. .

Tôi có thể đã và có thể lên tiếng trước khi hoàn thành tài liệu yêu cầu nếu tôi có bất kỳ kinh nghiệm nào.

Bạn có thể và nên sử dụng động từ trong yêu cầu của bạn. Điều quan trọng là đảm bảo mỗi yêu cầu là:

• Không rõ ràng - mỗi yêu cầu chỉ có thể có nghĩa là một điều và chỉ có thể được diễn giải theo một cách.
• Nguyên tử - mỗi yêu cầu không thể được chia thành nhiều yêu cầu.
• Có thể kiểm tra - mỗi yêu cầu có thể được hiển thị là đã được đáp ứng hoặc không được đáp ứng thông qua một số hình thức kiểm tra.

Bạn sẽ ngạc nhiên khi thấy các yêu cầu của bạn tốt đến mức nào khi chỉ cần làm theo ba nguyên tắc này bằng mọi giá.

Ngoài ra, hãy chắc chắn để viết một lý do cho mỗi yêu cầu. Điều này rất quan trọng và hữu ích khi ai đó tự hỏi tại sao một yêu cầu cụ thể được tạo ra.

Và đúng, bạn đã đúng, các yêu cầu nên mô tả phần mềm sẽ làm gì, chứ không phải nó sẽ làm như thế nào.

"Các yêu cầu chức năng trong tài liệu yêu cầu có nên sử dụng từ ngữ dựa trên động từ không?"

Câu trả lời ngắn gọn là "có", nhưng con đường để đến đó là quanh co.

Nếu doc ​​yêu cầu là tập hợp các câu "sẽ" được viết dưới dạng câu tiếng Anh, bạn phải có cụm động từ. Và cụm động từ đó sẽ là "sẽ xxx" như trong "hệ thống sẽ xxx". Phần "xxx" là một trong ba loại động từ "be", "do" và "have". Những câu này phải mô tả hệ thống như một hộp đen, chỉ ghi lại những thứ có thể nhìn thấy từ bên ngoài. Như bạn đã nói, "cái gì hơn là làm thế nào". Nếu nó được nhìn thấy từ bên ngoài thì đó là "cái gì".

Chức năng duy nhất có thể có sẵn cho một hệ thống kỹ thuật số là thay đổi giá trị của một biến. Do đó, tất cả các yêu cầu chức năng phải nêu rõ biến nào được thay đổi và các tính toán được sử dụng để thực hiện thay đổi. Đây là những yêu cầu "làm".

Các yêu cầu "được" có xu hướng mô tả các tính năng hơn là các chức năng. "Hệ thống sẽ có thể ...". Họ mô tả một "trạng thái hiện hữu".

Yêu cầu "có" là những danh từ mà bạn đã nói đến. "Hệ thống sẽ có ..." Họ cung cấp các danh từ cho các câu yêu cầu chức năng.

Ở cấp độ cao có rất ít yêu cầu chức năng. Hầu hết các yêu cầu là yêu cầu tính năng, yêu cầu hiệu suất hoặc yêu cầu thành phần (có).

Tất cả các yêu cầu cấp cao cần trẻ em, theo định nghĩa, mơ hồ. Nếu chúng không rõ ràng, chúng sẽ không cần trẻ em để định nghĩa chúng. Hơn nữa, một yêu cầu chỉ rõ ràng nếu phần lớn những người trong đánh giá yêu cầu tuyên bố rằng đó là. Tức là sự mơ hồ là chủ quan. Định nghĩa gần nhất cho một yêu cầu CHỨC NĂNG rõ ràng mà tôi biết là ở BarBaraBea.com trên trang "Yêu cầu chức năng rõ ràng". Về cơ bản là nói rằng tất cả các danh từ trong một yêu cầu chức năng phải được bắt nguồn từ các đầu vào hệ thống thông qua một chuỗi các yêu cầu chức năng rõ ràng và tuyên bố tính toán trong yêu cầu phải mô tả một thuật toán. Định nghĩa của "thuật toán" ít chủ quan hơn nhiều so với định nghĩa "yêu cầu không rõ ràng".

... Giả vờ rằng công việc là làm món trứng tráng. Liệt kê: bẻ trứng, đập vào bát, tranh giành, v.v.; vượt qua ranh giới vào lãnh thổ như thế nào ...
...
Ý tưởng của tôi về một tài liệu yêu cầu cho món trứng tráng sẽ giống như: có hai quả trứng, x ounce giăm bông, x ounce thịt xông khói, x ounce phô mai montery-jack , x ounce của rau mùi, v.v. - không có gì ngoài những gì (danh từ) ...

Đối với món trứng tráng, tôi thích các yêu cầu phiên bản thứ nhất hơn món thứ hai, đơn giản vì phiên bản thứ hai khiến tôi có nguy cơ bị hai quả trứng, x ounce giăm bông, v.v. - không có gì ngoài điều đó, không chiên cũng không được xào.

Phiên bản thứ hai đảm bảo nhận được những gì tôi cần, nhưng nó cũng hơi tệ - chỉ vì cách duy nhất để đảm bảo rằng các yêu cầu được đáp ứng dường như là ở trong nhà bếp theo dõi chặt chẽ từng bước của bữa ăn.

Bạn thấy đấy, tôi thích các yêu cầu bằng cách nào đó cho phép tôi kiểm tra / xác minh kết quả mà không bị buộc phải xem cách bạn chuẩn bị bữa ăn.

Một cách để đạt được điều đó sẽ là xác định các yêu cầu như vượt qua so sánh với tham chiếu. Sử dụng ví dụ omelet, tôi sẽ tạo ra món trứng tráng "tham khảo" của riêng mình theo các hướng dẫn tương tự như bạn, sau đó so sánh của bạn để đủ gần với nó.

• ^{Tôi đã sử dụng phương pháp đó khi tôi cần kiểm tra một phiên bản thuật toán cụ thể được tối ưu hóa mạnh mẽ. "Trứng tráng tham chiếu" trong trường hợp này được trình bày bằng thuật toán đơn giản hóa, không tối ưu hóa. Tôi chạy cùng một đầu vào với hai loại thuật toán sau đó kiểm tra xem đầu ra được tạo ra bởi phiên bản tối ưu có đủ gần với tham chiếu không.}

Một cách khác là yêu cầu nhà nước để những mô tả kết quả này. Đối với món trứng tráng giống như "4 oz trứng, quẩy và chiên, v.v ...". Tôi giải quyết chủ yếu với loại yêu cầu này - tôi nghĩ đây là cách điển hình nhất.

• ^{Để hoàn thiện, có lẽ tôi phải mô tả một loại yêu cầu cụ thể khác mà tôi đã giải quyết - dựa trên thử nghiệm. Tôi không thể tưởng tượng ra một cách nghe có vẻ khập khiễng cho ví dụ omelet - đại loại như "khi chuyên gia nhìn và nếm thử, họ nói OK" - nhưng phải thừa nhận, trong trường hợp duy nhất tôi thấy nó được sử dụng cho phần mềm , nó cũng không cảm thấy đặc biệt thông minh.}

Một chương trình chức năng bao gồm các chức năng. Chức năng là gì? Chúng là các phương thức thực hiện các hành động. Từ hành động là gì? Động từ.

Nếu bạn đang làm lập trình hướng đối tượng, thì bạn sẽ làm việc với các danh từ. Trên thực tế, bạn sẽ làm việc với cả danh từ và động từ.

Phong cách chức năng:

crack(egg)

Phong cách hướng đối tượng:

egg.Crack();

Ở cấp độ yêu cầu, tôi không chắc chắn bất kỳ vấn đề nào trong số này, mặc dù điều này chắc chắn sẽ hữu ích nếu các yêu cầu được nêu dưới dạng hành động, vì các chức năng là những gì bạn sẽ viết.

Tất cả các yêu cầu về cơ bản có thể được giảm xuống thành một tập hợp các câu xoay quanh việc sử dụng các động từ. Vâng, bạn có thể sử dụng một vài danh từ và tính từ, nhưng đó là những động từ mô tả cách thức hoạt động của một hệ thống và khách hàng muốn phần mềm làm gì. Thậm chí rất nhiều chức năng cụ thể của trạng thái của một chương trình có thể được nghĩ về các hành vi khi bạn trình bày trạng thái thông qua các phương thức getter và setter.

Nó giống như CFL_Jeff đề cập trong câu trả lời của anh ấy , rằng bạn muốn có các yêu cầu của bạn mô tả những gì một hệ thống sẽ làm, và không mô tả cách nó nên được thực hiện. Đây có thể là lý do tại sao tôi thấy sự phát triển theo hướng hành vi rất hấp dẫn, bởi vì nó khuyến khích việc sử dụng các động từ mô tả các yêu cầu và sử dụng các động từ khi viết các bài kiểm tra đơn vị để mô tả các yêu cầu như các hành vi cần kiểm tra.

Hãy xem xét các yêu cầu và mẫu kịch bản sau đây:

• As an {actor} I want to {do something} in order to {achieve an outcome}
• Given {an initial context} When {something is done} Then {expect an outcome}

Trong BDD, các tính năng luôn là bit được mô tả trong phần "Tôi muốn" của mẫu và chúng luôn được tải với các động từ mô tả những gì tính năng này làm. Khi kiểm tra, một Given-When-Thenmẫu được sử dụng để xác thực các kịch bản cụ thể liên quan đến tính năng và một lần nữa phần "Khi" của mẫu luôn được xác định bởi các động từ được sử dụng, liên quan trở lại theo cách nào đó với các động từ được sử dụng trong đặc tả tính năng.

Sử dụng ví dụ omelete của bạn, việc xác định một số hành vi là một chuỗi có rất nhiều ý nghĩa. Bạn có một tập hợp các hành vi và kết quả, và như một chuỗi chúng tạo thành một quy trình công việc. Thay vào đó, nếu bạn định nghĩa một danh sách các thành phần, bạn đang mô tả kiến ​​trúc một cách rất lỏng lẻo, tuy nhiên bạn còn rất nhiều câu hỏi. Quy trình làm việc là gì? Làm thế nào là các thành phần được sử dụng? Về cơ bản, bạn đang thiếu "chất keo" sẽ hướng dẫn các quyết định của bạn về cách đặt hệ thống của bạn với nhau và cách hệ thống của bạn được cho là hành xử.

Bằng cách xác định các yêu cầu về mặt hành vi và kết quả, bạn có thể cung cấp một bức tranh rất rõ ràng về những gì bạn muốn phần mềm đạt được, mà không phải lo lắng về cách đạt được kết quả cụ thể như vậy trong phần mềm.