วิธีปฏิบัติที่ดีที่สุดสำหรับการใช้งาน Shall และ Must ขณะเขียนข้อกำหนด

ฉันส่งอีเมลแจ้งเตือนนักพัฒนาของเราว่าการใช้คำว่า 'จะ' ในข้อกำหนดที่ได้รับของคุณไม่ควรทำตามข้อกำหนดด้านการใช้งานของคุณ เมื่อเขียนข้อกำหนดของฟังก์ชันคำว่า 'ต้องใช้' จะใช้เพื่ออธิบายฟังก์ชันที่ข้อกำหนดที่ได้รับจะต้องทำ
ที่ได้มา = ความต้องการของระบบจะเป็นความต้องการ
ใช้งาน = ระบบจะต้องทำ requirment

มันถูกส่งกลับโดยผู้อาวุโสของเราคนหนึ่งว่านั่นเป็นสิ่งที่ผิดและควรจะใช้ในทุก ๆ ความต้องการ

ฉันผิดตรงนี้และควรใช้ทุกความต้องการ ฉันไม่สามารถค้นหาข้อมูลสำรองได้

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

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

จากเอกสารนี้:

• MUSTเทียบเท่าREQUIREDและSHALLบ่งชี้ว่าคำจำกัดความเป็นข้อกำหนดที่แน่นอน
• MUST NOTเทียบเท่าSHALL NOTและบ่งชี้ว่าเป็นข้อห้ามที่แน่นอนของรายละเอียด
• SHOULDเทียบเท่ากับRECOMMENDEDหมายความว่ามีเหตุผลที่ถูกต้องในการเพิกเฉยต่อข้อกำหนดเฉพาะ แต่ต้องคำนึงถึงผลกระทบที่จะเกิดขึ้น
• SHOULD NOTและNOT RECOMMENDEDหมายความว่าพฤติกรรมบางอย่างอาจเป็นที่ยอมรับหรือมีประโยชน์ แต่ต้องคำนึงถึงผลกระทบอีกครั้ง
• MAYหมายถึงOPTIONALและข้อกำหนดนั้นเป็นทางเลือกอย่างแท้จริง การทำงานร่วมกันกับระบบที่แตกต่างกันซึ่งอาจจะหรืออาจไม่ใช้ข้อกำหนดที่เป็นทางเลือกต้องทำ

การทำตาม RFC นี้SHOULDจะกระทำเพื่อช่วยให้มั่นใจว่าการสื่อสารระหว่างเอกสารภายในของบุคคลนั้นกับโลกมาตรฐานนั้นมีความสอดคล้องกัน

ไม่แน่ใจว่าคุณมาถึงข้อสรุปที่shallและmustอยู่ในระดับเอกสารแยกต่างหาก นั่นคือความแตกต่างโดยพลการที่ไม่ได้รับการสนับสนุนจากแหล่งข้อมูลใด ๆ ที่ฉันรู้จัก

Shallและmustเทียบเท่ากับคำศัพท์ มันเป็นการกระทำที่จำเป็น

ไม่ว่าคุณจะใช้shallหรือmustขึ้นอยู่กับส่วนที่เหลือของเอกสารที่คุณกำลังเขียนอยู่ภายในและสิ่งที่ทำให้รู้สึกทางไวยากรณ์สำหรับประโยคนั้น

ใช่แล้วคุณคิดผิด แต่คุณยังไม่ถูกต้องเสมอใช้แทนshall mustพวกเขาเป็นตัวแทนระดับเดียวกันของภาระผูกพัน

หากคุณเกิดขึ้นในการทำงานภายใต้กรอบของDO-178หรือDO-254แนวทางเหล่านี้มีความหมายของตัวเองสำหรับความต้องการทั่วไปและความต้องการที่ได้มา แนวทางเหล่านี้ไม่ได้ แต่ระบุว่าคำเช่นจะต้องควรต้องควรจะใช้สำหรับการระบุความต้องการ

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

ทราบว่าใน DO-178 และ DO-254 ต้องการมาจริงหมายถึงความต้องการที่มีไม่ได้รับมาจากความต้องการในระดับสูง ข้อกำหนดที่ได้รับจึงเป็นจุดเริ่มต้นของการตรวจสอบย้อนกลับได้

ทั้ง DO-178 และ DO-254 เป็นเอกสารแนวทางเชิงพาณิชย์ที่ใช้สำหรับการพัฒนาซอฟท์แวร์ avionics และอุปกรณ์อิเล็กทรอนิกส์โดยมีค่าธรรมเนียมจากwww.rtca.orgเท่านั้น