คำที่ดีกว่าสำหรับข้อกำหนดเพิ่มเติมหรือไม่ [ปิด]

อะไรคือคำที่ดีกว่าสำหรับข้อกำหนดทางเลือกในวิศวกรรมซอฟต์แวร์ วลีนี้ขัดแย้งกัน ฉันใช้ "ข้อกำหนดที่ไม่ใช่คอร์" ในโครงการก่อนหน้านี้

สามารถใช้คำว่า "เกินขอบเขตความต้องการ" ได้ ซึ่งหมายความว่ามีการบันทึกข้อกำหนดในกระบวนการของคุณและสามารถติดตามได้ แต่ได้มีการพิจารณาแล้วว่าความต้องการนั้นเป็นสิ่งที่เกินขอบเขตปัจจุบันของระบบเนื่องจากเหตุผลหลายประการเช่นงบประมาณตารางเวลาเวลา หรือความเป็นไปได้

อย่างไรก็ตามมักใช้วลี "ข้อกำหนดที่เป็นทางเลือก" เพื่อแสดงถึงบางสิ่งที่อยู่ในขอบเขต แต่ไม่จำเป็นต้องใช้โดยระบบ เป็นการวัดลำดับความสำคัญของข้อกำหนด จากประสบการณ์ของฉันความต้องการมักจะถูกจัดลำดับความสำคัญเป็นข้อบังคับเป็นที่ต้องการหรือเป็นทางเลือก (แม้ว่าจะมีรูปแบบอื่น ๆ ด้วย) เพื่อให้โครงการได้รับการพิจารณาอย่างสมบูรณ์และใช้งานได้อย่างสมบูรณ์ข้อกำหนดทั้งหมดที่บังคับใช้จะต้องเป็นไปตามข้อกำหนด ด้วยทรัพยากรที่เพียงพอความต้องการที่พึงประสงค์จะถูกนำมาใช้ในครั้งต่อไป ในที่สุดสิ่งใดก็ตามที่ถือว่าเป็นตัวเลือกจะรวมอยู่ด้วย

ฉันเชื่อว่าความสับสนนั้นมาจากคำว่า "ข้อกำหนด" ในภาษาอังกฤษข้อกำหนดคือ "สิ่งที่จำเป็น" หรือ "เงื่อนไขที่บังคับ, บังคับหรือเงื่อนไขที่จำเป็น" อย่างไรก็ตามในวิศวกรรมซอฟต์แวร์ข้อกำหนดของคำศัพท์นั้นเป็นเพียงลักษณะเอกสารของระบบซอฟต์แวร์ แนวคิดของทางเลือกและข้อบังคับอธิบายถึงลำดับความสำคัญของคุณลักษณะที่เป็นเอกสารของระบบซอฟต์แวร์

เราอ้างถึงพวกเขาว่าเป็นคุณลักษณะ "ดีที่มี" ซึ่งตรงข้ามกับข้อกำหนด

สำหรับเอกสารข้อกำหนดของซอฟต์แวร์ถ้อยคำข้อกำหนดเพิ่มเติมคือตกลงอย่างสมบูรณ์ตราบใดที่คุณใช้คำนี้ตามRFC 2119 คำสำคัญในการระบุระดับความต้องการ - เช่นเพื่อระบุรายการที่เป็นตัวเลือกอย่างแท้จริง

เมื่อข้อความข้อกำหนดของคุณแสดงถึงคำกริยาแทนคำคุณศัพท์ให้ใช้ "MAY" แทน "OPTIONAL"

เนื่องจากมีขนาดเล็กและอ่านง่ายข้อความ RFC จึงถูกยกมาด้านล่าง:

    เครือข่ายคณะทำงานเอส. แบรดเนอร์
    ขอความคิดเห็น: 2119 Harvard University
    BCP: 14 มีนาคม 1997
    หมวดหมู่: แนวปฏิบัติที่ดีที่สุดในปัจจุบัน


            คำสำคัญสำหรับใช้ใน RFC เพื่อระบุระดับความต้องการ

    สถานะของบันทึกนี้

       เอกสารนี้ระบุวิธีปฏิบัติที่ดีที่สุดในปัจจุบันของอินเทอร์เน็ตสำหรับ
       ชุมชนอินเทอร์เน็ตและขอการสนทนาและคำแนะนำสำหรับ
       การปรับปรุง การกระจายของบันทึกนี้ไม่ จำกัด

    นามธรรม

       ในเอกสารมาตรฐานหลายฉบับมีการใช้คำหลายคำเพื่อสื่อความหมาย
       ข้อกำหนดในข้อกำหนด คำเหล่านี้มักจะ
       พิมพ์ใหญ่ เอกสารนี้กำหนดคำเหล่านี้ตามที่ควรจะเป็น
       ตีความในเอกสาร IETF ผู้เขียนที่ปฏิบัติตามแนวทางเหล่านี้
       ควรรวมวลีนี้ใกล้กับจุดเริ่มต้นของเอกสาร:

          คำสำคัญ "ต้อง", "ต้องไม่", "ต้องใช้", "SHALL", "SHALL
          ไม่ใช่ "," SHOULD "," ไม่ควร "," แนะนำ "," อาจ "และ
          "OPTIONAL" ในเอกสารนี้จะตีความตามที่อธิบายไว้ใน
          RFC 2119

       โปรดทราบว่าแรงของคำเหล่านี้ถูกแก้ไขโดยข้อกำหนด
       ระดับของเอกสารที่ใช้

    1. ต้องใช้คำนี้หรือคำว่า "จำเป็น" หรือ "SHALL" ซึ่งหมายความว่า
       คำจำกัดความเป็นข้อกำหนดที่แน่นอนของข้อกำหนด

    2. ต้องไม่ใช้วลีนี้หรือวลี "จะไม่" หมายความว่า
       คำจำกัดความเป็นข้อห้ามที่แน่นอนของข้อกำหนด

    3. ควรคำนี้หรือคำคุณศัพท์ "แนะนำ" หมายความว่ามี
       อาจมีเหตุผลที่ถูกต้องในบางสถานการณ์ที่จะเพิกเฉย
       รายการเฉพาะ แต่ผลกระทบที่สมบูรณ์จะต้องเข้าใจและ
       ชั่งน้ำหนักอย่างรอบคอบก่อนเลือกหลักสูตรอื่น

    4. ไม่ควรใช้วลีนี้หรือวลี "ไม่แนะนำ" หมายความว่า
       อาจมีเหตุผลที่ถูกต้องในบางกรณีเมื่อ
       พฤติกรรมบางอย่างเป็นที่ยอมรับหรือมีประโยชน์ แต่เต็มรูปแบบ
       ควรเข้าใจความหมายและกรณีที่มีการชั่งน้ำหนักอย่างรอบคอบ
       ก่อนที่จะใช้พฤติกรรมใด ๆ ที่อธิบายไว้กับป้ายกำกับนี้

    5. อาจคำนี้หรือคำคุณศัพท์ "OPTIONAL" หมายถึงรายการนั้น
       ตัวเลือกอย่างแท้จริง ผู้ขายรายหนึ่งอาจเลือกที่จะรวมรายการเพราะ
       ตลาดเฉพาะต้องการหรือเพราะผู้ขายรู้สึกว่า
       มันช่วยเพิ่มผลิตภัณฑ์ในขณะที่ผู้ผลิตรายอื่นอาจละเว้นรายการเดียวกัน
       การใช้งานที่ไม่มีตัวเลือกเฉพาะต้องเป็น
       เตรียมที่จะทำงานร่วมกันกับการใช้งานอื่นที่ไม่
       รวมถึงตัวเลือกแม้ว่าอาจจะมีฟังก์ชั่นลดลง ใน
       หลอดเลือดดำเดียวกันการดำเนินการซึ่งจะรวมถึงตัวเลือกโดยเฉพาะ
       จะต้องเตรียมที่จะทำงานร่วมกันกับการดำเนินการอื่นซึ่ง
       ไม่รวมตัวเลือก (ยกเว้นแน่นอนสำหรับคุณสมบัติของ
       ตัวเลือกให้.)

    6. คำแนะนำในการใช้งานของสารเหล่านี้

       จำเป็นต้องใช้ชนิดที่กำหนดในบันทึกนี้ด้วยความระมัดระวัง
       และเท่าที่จำเป็น โดยเฉพาะอย่างยิ่งพวกเขาจะต้องใช้ในที่ที่มันอยู่เท่านั้น
       จำเป็นจริงๆสำหรับการทำงานร่วมกันหรือเพื่อ จำกัด พฤติกรรมที่มี
       โอกาสในการก่อให้เกิดอันตราย (เช่น จำกัด การส่งสัญญาณซ้ำ) สำหรับ
       ตัวอย่างพวกเขาจะต้องไม่ถูกใช้เพื่อพยายามที่จะกำหนดวิธีการเฉพาะ
       บน implementors ที่ไม่จำเป็นต้องใช้วิธีการสำหรับการทำงานร่วมกัน

    7. ข้อควรพิจารณาด้านความปลอดภัย

       ข้อกำหนดเหล่านี้มักใช้เพื่อระบุพฤติกรรมที่มีความปลอดภัย
       ผลกระทบ ผลกระทบต่อความปลอดภัยของการไม่ใช้งานต้องหรือ
       ควรหรือทำอะไรบางอย่างสเปคบอกว่าจะต้องไม่หรือควร
       ไม่ทำอาจจะบอบบางมาก ผู้เขียนเอกสารควรใช้เวลา
       เพื่ออธิบายความหมายของการรักษาความปลอดภัยไม่ได้ติดตามอย่างละเอียด
       คำแนะนำหรือข้อกำหนดตามที่ผู้ดำเนินการส่วนใหญ่จะไม่มี
       ได้รับประโยชน์จากประสบการณ์และการอภิปรายที่ก่อให้เกิด
       สเปค

    8. กิตติกรรมประกาศ

       คำจำกัดความของคำเหล่านี้เป็นการรวมกันของคำจำกัดความที่ใช้
       จาก RFC จำนวนหนึ่ง นอกจากนี้คำแนะนำได้รับ
       รวมตัวกันจากผู้คนจำนวนมากรวมถึง Robert Ullmann, Thomas
       Narten, Neal McBurnett และ Robert Elz

มันจะไม่เจ็บถ้าเอกสารของคุณอ้างถึง RFC เป็นแหล่งที่มาของคำนิยาม:

เอกสารนี้ใช้คำจำกัดความขึ้นอยู่กับที่ระบุไว้ในRFC 2119

ฉันขอขอบคุณมันไม่ใช่คำตอบสำหรับคำถามของคุณ แต่ในโลกของฉันมันยังเป็นข้อกำหนดแม้ว่าจะไม่ว่าด้วยเหตุผลใดก็ตามคุณจะไม่ทำตามก็ตาม

ฉันชอบวิธี MoSCoW (ต้องมี, ควรมี, สามารถมีได้, จะไม่มีเวลานี้) ในการจัดหมวดหมู่ความต้องการกับผู้ใช้พร้อมกับปัจจัยอื่น ๆ (ในโลกที่มีกฎเกณฑ์ของฉันความต้องการอาจมีความสำคัญหรือไม่สำคัญ อาร์กิวเมนต์วูบวาบเกินข้อกำหนดที่จำเป็น แต่สำคัญ)

คำที่ดีกว่าสำหรับข้อกำหนดเพิ่มเติมคือ " คำแนะนำ "

วิธีการเกี่ยวกับการระบุว่าเป็นคุณสมบัติเพิ่มเติมหรืองานเสริม สิ่งเหล่านี้จะทำได้ก็ต่อเมื่อถึงเวลาที่กำหนดในโครงการซึ่งได้มีการพิจารณาแล้วว่ามีเวลาและเงินสำหรับการทำคุณสมบัติเหล่านี้ให้สมบูรณ์

นอกจากนี้ยังสามารถเรียกใช้หากมีเหตุการณ์ภายนอกเกิดขึ้น หากลูกค้าเปลี่ยนมาใช้ Windows 8 งานต่อไปนี้จะต้องเสร็จสิ้น ...

คำอธิบายของคุณลักษณะควรมีกำหนดเวลาสิ้นสุดเพื่อพิจารณาว่าจะเสร็จสิ้น

ความต้องการแบ่งออกเป็น 4 ด้านในสาขาวิศวกรรมซอฟต์แวร์:

1. ข้อกำหนดทางธุรกิจ : มุ่งเน้นไปที่เป้าหมายทางธุรกิจโดยรวมและวัตถุประสงค์ของระบบ
2. ความต้องการของผู้ใช้ : มุ่งเน้นไปที่วัตถุประสงค์ของผู้ใช้และสิ่งที่ผู้ใช้ต้องทำเพื่อใช้ระบบเพื่อให้บรรลุวัตถุประสงค์ทางธุรกิจ
3. ความต้องการด้านการใช้งาน : ฟังก์ชั่นและงานใดที่ระบบต้องปฏิบัติเพื่อให้บรรลุวัตถุประสงค์ทางธุรกิจ
4. ข้อกำหนดที่ไม่ได้ใช้งาน : มีข้อกำหนดอะไรบ้างนอกเหนือไปจากข้อกำหนดที่ใช้งานได้ ซึ่งรวมถึงสภาพแวดล้อมข้อ จำกัด ส่วนต่อประสานปัญหาการบำรุงรักษา ฯลฯ

ตอนนี้ข้อกำหนดอาจเป็นตัวเลือกหรือจำเป็นก็ได้ขึ้นอยู่กับ 4 หมวดหมู่ข้างต้นฉันได้อธิบายไว้ข้างต้น ข้อกำหนดเพิ่มเติมยังสามารถตกอยู่ในขอบเขตของระบบภายใต้การพิจารณาหรือนอกขอบเขตได้เช่นกัน ข้อกำหนดเพิ่มเติมคือวิธีที่ดีในการหลีกเลี่ยงการคืบขอบเขตและกำหนดขอบเขตของคุณในแง่ที่แม่นยำ

ข้อกำหนดเพิ่มเติมจะเป็นส่วนหนึ่งของวิศวกรรมซอฟต์แวร์เพราะช่วยให้เราระบุขอบเขตและเป็นวิธีที่ดีในการหลีกเลี่ยงขอบเขตการคืบ คุณไม่สามารถพูดได้ว่าพวกเขาขัดแย้งกับการปฏิบัติด้านวิศวกรรมของ SDLC อย่างไรก็ตามข้อกำหนดจะต้องจัดลำดับความสำคัญและกำหนดไว้อย่างดี

ในเทมเพลต Volere จะใช้คำว่า "Waiting room"

... เทมเพลตนี้มีจุดประสงค์เพื่อใช้เป็นพื้นฐานสำหรับข้อกำหนดข้อกำหนดของคุณ เทมเพลตจัดเตรียมสำหรับข้อกำหนดแต่ละประเภทที่เหมาะสมกับระบบธุรกิจวิทยาศาสตร์และซอฟต์แวร์ในปัจจุบัน มันมีรายการตรวจสอบโครงสร้างและการตรวจสอบย้อนกลับสำหรับความต้องการของคุณ ... แม่แบบเป็นเครื่องมืออิสระและได้รับการใช้อย่างประสบความสำเร็จกับ Yonix, Requisite, ประตู, Caliber RM, IRqA และเครื่องมือยอดนิยมอื่น ๆ ...

เทคนิคของ Volere ได้อธิบายไว้ในหนังสือMastering the Requirement Processโดย Suzanne Robertson และ James Robertson ...

ในธุรกิจของฉัน (ยานอวกาศ) พวกเขาถูกเรียกว่า "เป้าหมาย" ซึ่งระบุว่าพวกเขาได้รับการบันทึกและความพยายามจะถูกใช้เพื่อพบพวกเขา แต่ระบบจะยังถือว่าประสบความสำเร็จหากพวกเขาไม่ได้พบกัน "ความปรารถนา" (ไม่ใช่คำพูดจริง แต่มีคุณ) แสดงให้เห็นว่ามีคนต้องการพวกเขาและพวกเขาพยายามที่จะบรรลุสถานะของเป้าหมาย แต่ยังไม่ได้รับการยอมรับหรือทำเป็นเอกสาร; หรือ "ข้อกำหนดในการคืบคลาน" ซึ่งเป็นรุ่นที่เสื่อมเสียมากกว่าของความปรารถนาที่บ่งบอกถึงสิ่งต่าง ๆ ที่พยายามใช้ทรัพยากร แต่นั่นไม่คุ้มค่าในโครงการที่พยายามบรรลุ "ดีพอ" ซึ่งพวกเขาจะประนีประนอมหรือขู่ว่าจะบรรลุข้อกำหนดที่แท้จริง

หากความต้องการของคุณได้รับการจัดลำดับความสำคัญคุณอาจพิจารณาให้เป็นความต้องการลำดับความสำคัญต่ำ

ฉันค่อนข้างประหลาดใจที่ไม่มีใครพูดถึงสิ่งเหล่านั้นที่เรียกว่า "วัตถุประสงค์" ทุก บริษัท ที่ฉันทำงานให้เรียกมันว่า พวกเขาจะแสดงโดยใช้คำว่า "จะ" หรือ "ควร" แทนที่จะเป็น "จะ" บางครั้งพวกเขาจะรวมอยู่ในการจัดฟันเมื่อพูดถึงตัวเลข เช่นระบบจะทำงานอย่างต่อเนื่องโดยไม่จำเป็นต้องให้ความสนใจกับผู้ปฏิบัติงานเป็นเวลา 100 {250} ชั่วโมง หมายความว่าข้อกำหนดที่ต้องปฏิบัติตามคือ 100 ชั่วโมง แต่วัตถุประสงค์คือ 250 ชั่วโมง

ในฐานะที่เป็นข้อความด้านข้างแทบจะทุกคนไม่เคยออกแบบมาเพื่อตอบสนองความต้องการวัตถุประสงค์เว้นแต่จะมีแรงจูงใจบางประเภทที่เกี่ยวข้อง

บางครั้งคำว่า "ความต้องการ" ใช้สำหรับข้อกำหนดเพิ่มเติม อย่างไรก็ตามมันอาจไม่เหมาะสมสำหรับเอกสารที่เป็นทางการ

ฉันประหลาดใจที่คำตอบทั้งหมดเกี่ยวข้องกับข้อกำหนดการติดตามในการพัฒนาโครงการ แม้จะเป็นนักพัฒนา แต่ก็ไม่เคยกังวลมากนักเกี่ยวกับคำศัพท์นี้ในบริบทนั้น เมื่อฉันอ่านคำถามแรกฉันคิดว่ามันเกี่ยวข้องกับข้อมูลจำเพาะของผู้ใช้ไม่ใช่การพัฒนาผลิตภัณฑ์ ตัวอย่างเช่นสารานุกรมอาจแสดงรายการเครื่องพิมพ์สีเป็นข้อกำหนดเพิ่มเติม มันจำเป็นถ้าคุณต้องการได้ประโยชน์อย่างเต็มที่จากแอพ แต่เป็นทางเลือกถ้าคุณต้องการดูหน้าจอ แต่ถ้าคุณมีเครื่องพิมพ์ขาวดำล่ะ? จะทำให้ชัดเจนได้อย่างไรว่าแอปของคุณทำงานด้วยข้อ จำกัด ที่ไม่สุภาพซึ่งรูปภาพบางรูปอาจดูไม่ดี? หรือจะไม่พิมพ์เลย? เป็นอีกตัวอย่างหนึ่ง ฉันควรตรวจสอบเครื่องพิมพ์เพื่อตรวจสอบว่าหมึกเป็นข้อกำหนดหรือข้อกำหนดทางเลือกในเครื่องพิมพ์มัลติฟังก์ชั่นหรือไม่ กล่าวอีกนัยหนึ่งฉันยังสามารถสแกนได้หรือไม่? คำแนะนำบางอย่างเกี่ยวกับคำศัพท์และสิ่งที่จะค้นหาจะได้รับการต้อนรับทั้งในฐานะนักพัฒนาผลิตภัณฑ์ / ผู้ขายและในฐานะผู้บริโภค

ฉันจะเรียกพวกเขาว่า "คุณสมบัติเสริม" ไม่ใช่ข้อกำหนดเพิ่มเติม ต้องการเสียงเหมือนสิ่งที่คุณต้องมีในขณะที่คุณสมบัติเสียงเหมือนส่วนเสริมของผลิตภัณฑ์ดั้งเดิม