Từ tốt hơn cho các yêu cầu tùy chọn? [đóng cửa]


12

Một từ tốt hơn cho một yêu cầu tùy chọn trong công nghệ phần mềm là gì? Các cụm từ là mâu thuẫn. Tôi đã sử dụng "Yêu cầu không cốt lõi" trong các dự án trước đó.


9
Tôi đoán anh ta có nghĩa là một cái gì đó không thể được yêu cầu (như trong 'yêu cầu') và tùy chọn (như trong 'không bắt buộc')
Scrwtp

2
Điều này thực sự thuộc về tiếng Anh. Và tôi chỉ gọi họ là "lựa chọn."
Blrfl

13
@Blrfl Nó không thuộc về tiếng Anh. Trong ngôn ngữ tiếng Anh, cụm từ "yêu cầu tùy chọn" là mâu thuẫn. Tuy nhiên, nó có một ý nghĩa được chấp nhận rộng rãi trong phát triển phần mềm và có nhiều cách khác để thực hiện khái niệm này trong bối cảnh của một dự án phần mềm. Nó không có ý nghĩa để có nó bất cứ nơi nào ngoài đây.
Thomas Owens

3
@ThomasOwens: Tôi không đồng ý. Bất kỳ lĩnh vực nào mà công việc có yêu cầu đều có thể gặp phải vấn đề này, điều này sẽ khiến đây trở thành một câu hỏi quản lý dự án. Nó cũng là một oxymoron, làm cho nó tốt hơn cho tiếng Anh, và chủ đề đầu tiên trong Câu hỏi thường gặp đầu tiên có nói lựa chọn từ là chủ đề. Nhưng phù hợp với bản thân.
Blrfl

5
"Những thứ sẽ không được xây dựng" là ý nghĩa của nhiều dự án.

Câu trả lời:


13

Thuật ngữ "yêu cầu ngoài phạm vi" có thể có thể được sử dụng. Điều này có nghĩa là yêu cầu đã được nắm bắt trong quy trình của bạn và có thể theo dõi được, nhưng nó đã được xác định rằng yêu cầu là một cái gì đó vượt quá phạm vi hiện tại của hệ thống, do một số lý do, chẳng hạn như ngân sách, lịch trình, thời gian, hoặc tính khả thi.

Tuy nhiên, cụm từ "yêu cầu tùy chọn" thường được sử dụng để biểu thị một cái gì đó trong phạm vi, nhưng không nhất thiết phải được hệ thống yêu cầu. Nó là một thước đo mức độ ưu tiên của yêu cầu. Theo kinh nghiệm của tôi, các yêu cầu thường được ưu tiên là bắt buộc, mong muốn hoặc tùy chọn (mặc dù cũng có các chương trình khác). Để một dự án được coi là đầy đủ và đầy đủ chức năng, tất cả các yêu cầu bắt buộc phải được thỏa mãn. Được cung cấp đủ nguồn lực, các yêu cầu mong muốn sẽ được thực hiện tiếp theo. Cuối cùng, bất cứ điều gì được coi là tùy chọn sẽ được bao gồm.

Tôi tin rằng sự nhầm lẫn xuất phát từ thuật ngữ "yêu cầu". Trong ngôn ngữ tiếng Anh, một yêu cầu là "một điều cần thiết" hoặc "một điều kiện bắt buộc, bắt buộc hoặc cần thiết". Tuy nhiên, trong công nghệ phần mềm, yêu cầu thuật ngữ chỉ đơn giản là một đặc tính được ghi lại của một hệ thống phần mềm. Khái niệm tùy chọn và bắt buộc mô tả mức độ ưu tiên của đặc tính được ghi lại của hệ thống phần mềm.


1
Một thuật ngữ liên quan là 'trường hợp thay đổi', đây là một yêu cầu được mong đợi tại một thời điểm nào đó trong tương lai, nhưng không có trong phạm vi ngay bây giờ. Bằng cách nắm bắt các trường hợp thay đổi, bạn có thể thử và tránh làm điều gì đó trong thiết kế hiện tại khiến cho các trường hợp thay đổi trở nên khó khăn. Khi làm điều này, bạn cần phải để mắt đến YAGNI.
Kris C

IMHO, 'yêu cầu tùy chọn' ngụ ý tùy chọn trong thì hiện tại và yêu cầu trong thì tương lai cũng có thể đọc yêu cầu tiềm năng tùy chọn. Dù bằng cách nào, tôi đồng ý rằng ngoài phạm vi phù hợp hơn trong trường hợp kinh doanh mà sự mong đợi của khách hàng cần phải được quản lý.
Evan Plaice

25

Chúng tôi gọi chúng là các tính năng "tốt để có" trái ngược với yêu cầu.


2
Từ góc độ kỹ thuật yêu cầu, "các tính năng tốt đẹp" vẫn cần được nắm bắt như một yêu cầu (trong một đặc tả, như một câu chuyện của người dùng, như các thử nghiệm chấp nhận - tuy nhiên quy trình của bạn chỉ ra rằng các yêu cầu được nắm bắt) và được theo dõi trong suốt vòng đời của dự án.
Thomas Owens

11

Đối với tài liệu yêu cầu phần mềm, từ ngữ Yêu cầu tùy chọn là hoàn toàn OK, miễn là bạn sử dụng thuật ngữ này phù hợp với RFC 2119 Từ khóa để chỉ mức độ yêu cầu - nghĩa là chỉ ra các mục thực sự là tùy chọn.

Khi văn bản đặc tả của bạn ngụ ý động từ thay vì tính từ, hãy sử dụng "CÓ THỂ" thay vì "TÙY CHỌN".

Vì nó nhỏ và dễ đọc, văn bản RFC được trích dẫn đầy đủ bên dưới:

    Nhóm làm việc mạng S. Bradner
    Yêu cầu cho ý kiến: 2119 Đại học Harvard
    BCP: 14 tháng 3 năm 1997
    Thể loại: Thực hành tốt nhất hiện nay


            Từ khóa để sử dụng trong RFC để chỉ mức độ yêu cầu

    Trạng thái của bản ghi nhớ này

       Tài liệu này chỉ định một Thực tiễn tốt nhất hiện tại trên Internet cho
       Cộng đồng Internet và yêu cầu thảo luận và đề xuất cho
       cải tiến. Phân phối của bản ghi nhớ này là không giới hạn.

    trừu tượng

       Trong nhiều tiêu chuẩn tài liệu theo dõi, một số từ được sử dụng để biểu thị
       các yêu cầu trong đặc điểm kỹ thuật. Những từ này thường
       viết hoa Tài liệu này định nghĩa những từ này là cần thiết
       được giải thích trong các tài liệu của IETF. Các tác giả làm theo các hướng dẫn này
       nên kết hợp cụm từ này gần đầu tài liệu của họ:

          Các từ khóa "PHẢI", "KHÔNG PHẢI", "BẮT BUỘC", "SALL", "SALL
          KHÔNG "," NÊN "," KHÔNG NÊN "," KHUYẾN NGHỊ "," CÓ THỂ ", và
          "TÙY CHỌN" trong tài liệu này sẽ được diễn giải như được mô tả trong
          RFC 2119.

       Lưu ý rằng lực của những từ này được sửa đổi theo yêu cầu
       mức độ của tài liệu mà chúng được sử dụng.

    1. PHẢI Từ này, hoặc các thuật ngữ "BẮT BUỘC" hoặc "SALLN", có nghĩa là
       định nghĩa là một yêu cầu tuyệt đối của đặc điểm kỹ thuật.

    2. PHẢI KHÔNG Cụm từ này, hoặc cụm từ "SALL KHÔNG", có nghĩa là
       định nghĩa là một sự cấm đoán tuyệt đối của đặc điểm kỹ thuật.

    3. NÊN Từ này, hoặc tính từ "RECOMMENDED", có nghĩa là ở đó
       có thể tồn tại những lý do hợp lệ trong các trường hợp cụ thể để bỏ qua một
       mục cụ thể, nhưng ý nghĩa đầy đủ phải được hiểu và
       cân nhắc cẩn thận trước khi chọn một khóa học khác nhau.

    4. KHÔNG NÊN Cụm từ này, hoặc cụm từ "KHÔNG ĐƯỢC ĐỀ XUẤT" có nghĩa là
       có thể tồn tại những lý do hợp lệ trong các trường hợp cụ thể khi
       hành vi cụ thể là chấp nhận được hoặc thậm chí hữu ích, nhưng đầy đủ
       ý nghĩa nên được hiểu và trường hợp cân nhắc cẩn thận
       trước khi thực hiện bất kỳ hành vi nào được mô tả với nhãn này.

    5. CÓ THỂ Từ này, hoặc tính từ "TÙY CHỌN", có nghĩa là một mục là
       thực sự tùy chọn. Một nhà cung cấp có thể chọn bao gồm các mặt hàng vì một
       thị trường cụ thể đòi hỏi nó hoặc bởi vì các nhà cung cấp cảm thấy rằng
       nó tăng cường sản phẩm trong khi nhà cung cấp khác có thể bỏ qua cùng một mặt hàng.
       Việc triển khai không bao gồm một tùy chọn cụ thể PHẢI
       chuẩn bị để tương tác với việc thực hiện khác
       bao gồm tùy chọn, mặc dù có lẽ với chức năng giảm. bên trong
       cùng một cách thực hiện bao gồm một tùy chọn cụ thể
       PHẢI được chuẩn bị để tương tác với việc thực hiện khác
       không bao gồm tùy chọn (tất nhiên, ngoại trừ cho tính năng
       tùy chọn cung cấp.)

    6. Hướng dẫn sử dụng các mệnh lệnh này

       Các mệnh lệnh của loại được xác định trong bản ghi nhớ này phải được sử dụng cẩn thận
       và tiết kiệm Đặc biệt, chúng PHẢI chỉ được sử dụng ở nơi có
       thực sự cần thiết cho sự tương tác hoặc để hạn chế hành vi có
       có khả năng gây hại (ví dụ: hạn chế truyền lại) Đối với
       ví dụ, chúng không được sử dụng để cố gắng áp đặt một phương thức cụ thể
       trên những người triển khai trong đó phương pháp không bắt buộc về khả năng tương tác.

    7. Cân nhắc bảo mật

       Những thuật ngữ này thường được sử dụng để chỉ định hành vi với bảo mật
       hàm ý. Những ảnh hưởng đến bảo mật của việc không thực hiện PHẢI hoặc
       NÊN, hoặc làm một cái gì đó đặc điểm kỹ thuật nói KHÔNG PHẢI hoặc NÊN
       KHÔNG được thực hiện có thể rất tinh tế. Tác giả tài liệu nên dành thời gian
       để xây dựng ý nghĩa bảo mật của việc không tuân theo
       khuyến nghị hoặc yêu cầu vì hầu hết những người thực hiện sẽ không có
       có lợi ích của kinh nghiệm và thảo luận đã tạo ra
       sự chỉ rõ.

    8. Lời cảm ơn

       Các định nghĩa của các thuật ngữ này là một sự pha trộn của các định nghĩa được thực hiện
       từ một số RFC. Ngoài ra, các đề xuất đã được
       hợp nhất từ ​​một số người bao gồm Robert Ullmann, Thomas
       Narten, Neal McBurnett và Robert Elz.

Sẽ không hại gì nếu tài liệu của bạn đề cập đến RFC là nguồn định nghĩa:

Tài liệu này sử dụng các định nghĩa dựa trên những định nghĩa được chỉ định trong RFC 2119 .


Tôi thậm chí còn không biết đây là RFC. Tuy nhiên, tôi không ngạc nhiên khi một cái gì đó như thế này tồn tại, như là một tiêu chuẩn IEEE, tiêu chuẩn ISO, RFC hoặc một số tài liệu được xuất bản tương tự khác.
Thomas Owens

Tài liệu này có vẻ hơi quá cụ thể để được áp dụng rộng rãi như hướng dẫn cho các yêu cầu phần mềm. Nó không có tiêu đề "Từ khóa cho các yêu cầu", nó có tiêu đề "Từ khóa cho các yêu cầu trong RFC," và trong Chỉ thị 6, nó cố tình giới hạn phạm vi của chính nó.
Robert Harvey

1
@RobertHarvey, quan điểm của tôi là giải quyết ý tưởng câu hỏi rằng người ta nên tìm từ tốt hơn để thay thế thuật ngữ chuyên môn được xác định bằng ngữ nghĩa được xác định rõ ràng và tài liệu chỉ vì họ tin rằng đó không phải là một tiếng Anh hoàn hảo. Còn về việc nó quá cụ thể hay không, đó có phải là một câu hỏi hoàn toàn khác không bạn nghĩ? Tôi cho người ta có thể tưởng tượng nhiều trường hợp tôi thích phân loại phong cách MoSCoW .
gnat

@gnat, Anh ấy không cần một động từ. Bài đăng này chưa trả lời từ nào tốt hơn cho "yêu cầu tùy chọn"?
Pacerier

7

Tôi đánh giá cao nó không phải là một câu trả lời cho câu hỏi của bạn, nhưng trong thế giới của tôi, nó vẫn là một yêu cầu, ngay cả khi vì bất kỳ lý do gì bạn sẽ không thực hiện nó.

Tôi thích cách tiếp cận MoSCoW (Phải có, nên có, có thể có, không có thời gian này) để phân loại các yêu cầu với người dùng, cùng với các yếu tố khác (trong thế giới được quy định của tôi, các yêu cầu có thể quan trọng hoặc không quan trọng, và nhiều đối số bùng lên trên các yêu cầu tùy chọn nhưng quan trọng.)



2

Làm thế nào về việc xác định nó là một tính năng tùy chọn hoặc các nhiệm vụ tùy chọn. Những điều này sẽ chỉ được thực hiện nếu tại một thời điểm nhất định trong dự án đã xác định rằng có thời gian và tiền bạc để hoàn thành các tính năng này.

Chúng cũng có thể được kích hoạt nếu một sự kiện bên ngoài xảy ra. Nếu khách hàng thực hiện chuyển đổi sang Windows 8, các tác vụ sau sẽ cần được thực hiện ...

Mô tả về tính năng nên bao gồm thời hạn để xác định xem chúng có được thực hiện hay không.


1

Các yêu cầu được phân loại thành 4 lĩnh vực trong Kỹ thuật phần mềm:

  1. Yêu cầu kinh doanh : Tập trung vào mục tiêu kinh doanh tổng thể và mục tiêu của hệ thống
  2. Yêu cầu của người dùng: Tập trung vào các mục tiêu của người dùng và những gì người dùng phải làm để sử dụng hệ thống để đạt được các mục tiêu kinh doanh
  3. Yêu cầu về chức năng : Chức năng và nhiệm vụ nào mà hệ thống phải thực hiện để đạt được mục tiêu kinh doanh
  4. Yêu cầu phi chức năng : Những yêu cầu nào khác ngoài những yêu cầu chức năng. Điều này bao gồm môi trường, các ràng buộc, giao diện, vấn đề bảo trì, v.v.

Bây giờ các yêu cầu có thể là Tùy chọn hoặc Bắt buộc , tùy thuộc vào 4 loại trên, tôi đã nêu ở trên. Các yêu cầu tùy chọn cũng có thể rơi vào phạm vi của hệ thống đang được xem xét hoặc ngoài phạm vi của nó. Các yêu cầu tùy chọn là phương tiện tốt để tránh Phạm vi Creep và xác định phạm vi của bạn theo các thuật ngữ chính xác.

Yêu cầu tùy chọn sẽ luôn là một phần của Kỹ thuật phần mềm vì chúng giúp chúng tôi xác định phạm vi và là một phương tiện tốt để tránh Phạm vi leo trèo. Bạn không bao giờ có thể nói rằng chúng mâu thuẫn với các hoạt động kỹ thuật của SDLC. Tuy nhiên, các yêu cầu phải được ưu tiên và xác định rõ.


1
Câu hỏi yêu cầu một thuật ngữ khác cho "các yêu cầu tùy chọn" không dành cho việc phân loại các yêu cầu.
yannis

1
Nếu anh ta biết phân loại, anh ta sẽ không bao giờ nói rằng Yêu cầu tùy chọn là mâu thuẫn trong Kỹ thuật phần mềm. :)
Maxood

1
mô tả hay, nhưng tôi vẫn hơi khó hiểu với cụm từ - hoặc là một cái gì đó là bắt buộc hoặc nó không phải là. Tôi nghĩ rằng chúng tôi đã đưa "yêu cầu" thành một thực thể riêng biệt có nghĩa là "nhu cầu khách hàng chính thức" ...
Aram Kocharyan

@Maxood Hmmm? Thuật ngữ này là mâu thuẫn, không phải là khái niệm, câu hỏi thảo luận về thuật ngữ này. Bạn có tham khảo rằng thuật ngữ này là một phần của bất kỳ mô hình yêu cầu chính thức nào (hoặc được chấp nhận rộng rãi) không? Tôi biết điều đó là phổ biến, nhưng việc ném những thứ như "Yêu cầu tùy chọn sẽ luôn là một phần của Kỹ thuật phần mềm" mà không có một tham chiếu nào thực sự không phải là tách trà của tôi.
yannis

@ Yannis Rizos Khi tôi nói "Yêu cầu tùy chọn sẽ luôn là một phần của Kỹ thuật phần mềm", tôi có nghĩa là trong bối cảnh khái niệm. Vì kỹ thuật là tìm ra một giải pháp hiệu quả trong ngân sách trong khi cân bằng các yêu cầu mâu thuẫn. Ngoài ra, người hỏi không bao giờ đề cập đến Yêu cầu tùy chọn như một thuật ngữ ở đây trong câu hỏi và tôi cũng vậy
Maxood

1

Trong mẫu Volere , thuật ngữ "Phòng chờ" được sử dụng.

... Mẫu này được thiết kế để sử dụng làm nền tảng cho các thông số kỹ thuật yêu cầu của bạn. Mẫu cung cấp cho từng loại yêu cầu phù hợp cho các hệ thống kinh doanh, khoa học và phần mềm ngày nay. Nó cung cấp danh sách kiểm tra, cấu trúc và truy xuất nguồn gốc cho các yêu cầu của bạn ... Mẫu độc lập với công cụ và đã được sử dụng thành công với Yonix, Requisite, DOORS, Calibre RM, IRqA và các công cụ phổ biến khác ...

Các kỹ thuật của Volere được mô tả trong cuốn sách Làm chủ quy trình yêu cầu của Suzanne Robertson và James Robertson ...


0

Trong doanh nghiệp của tôi (tàu vũ trụ), chúng được gọi là "mục tiêu", chỉ ra rằng chúng được ghi lại và nỗ lực sẽ được dành để đáp ứng chúng, nhưng hệ thống vẫn sẽ được coi là thành công nếu chúng không được đáp ứng; "Mong muốn" (không phải là một từ thực sự, nhưng có bạn), chỉ ra rằng ai đó muốn chúng và họ đang cố gắng đạt được trạng thái của các mục tiêu nhưng chưa được chấp nhận hoặc ghi lại; hoặc "yêu cầu leo" là phiên bản khinh miệt hơn của những mong muốn chỉ ra những thứ đang cố gắng chiếm dụng tài nguyên nhưng điều đó không đáng để dự án cố gắng đạt được "đủ tốt" trong đó chúng sẽ thỏa hiệp hoặc đe dọa đạt được yêu cầu thực sự.


0

Nếu các yêu cầu của bạn được ưu tiên , bạn có thể coi chúng là các yêu cầu ưu tiên thấp .


Tôi nghĩ "không ưu tiên" có thể gần với "tùy chọn" hơn.
Pacerier

0

Tôi khá ngạc nhiên khi không ai đề cập rằng những cái đó được gọi là "mục tiêu". Mỗi công ty tôi đã làm việc đã gọi họ như vậy. Chúng được biểu thị bằng cách sử dụng các từ "sẽ" hoặc "nên" thay vì "sẽ". Đôi khi chúng được bao gồm trong Niềng răng khi nói về số. ví dụ: Hệ thống sẽ hoạt động liên tục mà không cần người vận hành chú ý trong 100 {250} giờ. Có nghĩa là yêu cầu phải được đáp ứng là 100 giờ, nhưng mục tiêu là 250 giờ.

Như một lưu ý phụ, rất hiếm khi có ai thực sự thiết kế để đáp ứng yêu cầu khách quan, trừ khi có một số loại khuyến khích liên quan.


0

Thuật ngữ "Tuyệt vọng" đôi khi được sử dụng cho các yêu cầu tùy chọn. Tuy nhiên, nó có thể không phù hợp cho một tài liệu chính thức.


0

Tôi ngạc nhiên khi tất cả các phản hồi đều quan tâm đến các yêu cầu theo dõi trong phát triển dự án. Mặc dù là một nhà phát triển nhưng tôi chưa bao giờ lo lắng về thuật ngữ này trong bối cảnh đó. Khi tôi lần đầu tiên đọc câu hỏi, tôi cho rằng nó liên quan đến đặc điểm kỹ thuật sản phẩm của người dùng, không phải phát triển sản phẩm. Ví dụ, bách khoa toàn thư có thể liệt kê một máy in màu là một yêu cầu tùy chọn. Nó được yêu cầu nếu bạn muốn toàn bộ lợi ích của ứng dụng nhưng tùy chọn nếu bạn muốn xem màn hình. Nhưng nếu bạn có một máy in đơn sắc thì sao? Làm thế nào để làm rõ liệu ứng dụng của bạn có hoạt động với hạn chế đáng ghét mà một số ảnh có thể trông không đẹp lắm không? Hoặc không in tất cả? Như một ví dụ khác, Làm thế nào tôi nên kiểm tra đánh giá máy in để kiểm tra xem mực là yêu cầu hay yêu cầu tùy chọn tùy chọn trong máy in đa chức năng? Nói cách khác tôi vẫn có thể quét? Một số gợi ý về thuật ngữ và những gì cần tìm kiếm sẽ được hoan nghênh cả với tư cách là nhà phát triển / người bán sản phẩm và người tiêu dùng.


Uhm, vậy từ nào tốt hơn cho "yêu cầu tùy chọn"?
Pacerier

0

Tôi sẽ gọi chúng là "các tính năng tùy chọn", không phải là yêu cầu tùy chọn. Yêu cầu nghe có vẻ giống như một thứ gì đó mà bạn phải có , trong khi các tính năng nghe giống như một tiện ích bổ sung cho sản phẩm gốc.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.