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 đó.
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 đó.
Câu trả lời:
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.
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.
Đố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 đá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.)
Một từ tốt hơn cho một yêu cầu tùy chọn là " Khuyến nghị "
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.
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:
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õ.
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 ...
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ự.
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.
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.
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.