ในทางวิศวกรรมข้อกำหนด คือ เงื่อนไขที่ต้องได้รับการตอบสนองเพื่อให้ผลลัพธ์ของงานเป็นที่ยอมรับได้ เป็นคำอธิบายที่ชัดเจน เป็นกลาง ชัดเจน และมักจะเป็นเชิงปริมาณของเงื่อนไขที่ต้องได้รับการตอบสนองโดยวัสดุ การออกแบบ ผลิตภัณฑ์ หรือบริการ^{[ 1 ]}

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

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

ข้อกำหนดต่างๆ ถูกนำไปใช้ในสาขาวิศวกรรมหลายแขนง รวมถึงการออกแบบทางวิศวกรรมวิศวกรรมระบบวิศวกรรมซอฟต์แวร์วิศวกรรมองค์กรการพัฒนาผลิตภัณฑ์และการเพิ่มประสิทธิภาพกระบวนการ

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

คำว่า " ข้อกำหนด"ถูกนำมาใช้ในชุมชนวิศวกรรมซอฟต์แวร์มาอย่างน้อยตั้งแต่ทศวรรษ 1960 ^{[ 2 ]}

ตามคู่มือ Business Analysis Body of Knowledge®เวอร์ชัน 2 จาก IIBA (BABOK) ^{[ 3 ]}ข้อกำหนดคือ:

1. เงื่อนไขหรือความสามารถที่ผู้มีส่วนได้ส่วนเสียต้องการเพื่อแก้ไขปัญหาหรือบรรลุเป้าหมาย
2. เงื่อนไขหรือความสามารถที่โซลูชันหรือส่วนประกอบของโซลูชันต้องมีเพื่อให้เป็นไปตามสัญญา มาตรฐาน ข้อกำหนด หรือเอกสารอื่น ๆ ที่กำหนดไว้อย่างเป็นทางการ
3. การแสดงเอกสารเกี่ยวกับสภาพหรือความสามารถตาม (1) หรือ (2)

คำจำกัดความนี้อ้างอิงจาก IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology ^{[ 4 ]}

อาจกล่าวได้ว่าข้อกำหนดต่างๆ เกี่ยวข้องกับสองด้าน ได้แก่:

• ข้อกำหนดของผลิตภัณฑ์ระบุคุณสมบัติของระบบหรือผลิตภัณฑ์
• ข้อกำหนดด้านกระบวนการระบุถึงกิจกรรมที่องค์กรที่กำลังพัฒนาจะต้องดำเนินการ ตัวอย่างเช่น ข้อกำหนดด้านกระบวนการอาจระบุถึงวิธีการที่ต้องปฏิบัติตาม และข้อจำกัดที่องค์กรต้องเคารพ

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

โดยทั่วไป ข้อกำหนดจะถูกจำแนกประเภทตามขั้นตอนต่างๆ ในกระบวนการพัฒนา โดยการจัดหมวดหมู่จะขึ้นอยู่กับแบบจำลองโดยรวมที่ใช้ ตัวอย่างเช่นสถาบันวิเคราะห์ธุรกิจระหว่างประเทศ ได้กำหนดแผนผังต่อไปนี้ไว้ ในองค์ความรู้ด้านการวิเคราะห์ธุรกิจ^{[ 5 ]} (ดูเพิ่มเติมที่FURPSและประเภทของข้อกำหนด )

ข้อกำหนดทางสถาปัตยกรรม

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

ในวิศวกรรมซอฟต์แวร์เรียกว่าข้อกำหนดที่มีความสำคัญทางสถาปัตยกรรมซึ่งกำหนดไว้ว่าเป็นข้อกำหนดที่มีผลกระทบที่วัดได้ต่อ สถาปัตยกรรมของ ระบบซอฟต์แวร์ ^{[ 6 ]}

ข้อกำหนดทางธุรกิจ

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

ข้อกำหนดของผู้ใช้ (ผู้มีส่วนได้ส่วนเสีย)

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

ข้อกำหนดด้านการทำงาน (โซลูชัน)

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

ข้อกำหนดด้านคุณภาพการบริการ (ที่ไม่เกี่ยวข้องกับฟังก์ชันการทำงาน)

โดยทั่วไปแล้วจะมีคำอธิบายโดยละเอียดเกี่ยวกับเงื่อนไขที่โซลูชันต้องยังคงมีประสิทธิภาพ คุณสมบัติที่โซลูชันต้องมี หรือข้อจำกัดที่ต้องปฏิบัติตาม[ ^{7 ] ตัวอย่าง}เช่น ความน่าเชื่อถือ ความสามารถในการทดสอบ ความสามารถในการบำรุงรักษา ความพร้อมใช้งาน นอกจากนี้ยังเรียกอีกอย่างว่าลักษณะข้อจำกัดหรือคุณสมบัติ

ข้อกำหนดการดำเนินการ (การเปลี่ยนผ่าน)

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

ข้อกำหนดด้านกฎระเบียบ

ข้อกำหนดที่กำหนดโดยกฎหมาย (รัฐบาลกลาง รัฐบาลท้องถิ่น เทศบาล หรือระดับภูมิภาค) สัญญา (ข้อกำหนดและเงื่อนไข) หรือนโยบาย (ระดับบริษัท ระดับแผนก หรือระดับโครงการ)

ลักษณะของข้อกำหนดที่ดีนั้นถูกกล่าวถึงแตกต่างกันไปโดยผู้เขียนหลายคน โดยผู้เขียนแต่ละคนมักจะเน้นลักษณะที่เหมาะสมที่สุดกับการอภิปรายทั่วไปหรือโดเมนเทคโนโลยีเฉพาะที่กำลังกล่าวถึง อย่างไรก็ตาม ลักษณะต่อไปนี้ได้รับการยอมรับโดยทั่วไป^{[ 8 ] [ 9 ]}

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

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

ข้อกำหนดทั้งหมดจะต้องสามารถตรวจสอบได้ วิธีที่พบได้บ่อยที่สุดคือการทดสอบ หากไม่สามารถทำได้ ควรใช้วิธีการตรวจสอบอื่นแทน (เช่น การวิเคราะห์ การสาธิต การตรวจสอบ หรือการทบทวนการออกแบบ)

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

ข้อกำหนดที่ไม่เกี่ยวข้องกับการทำงาน ซึ่งไม่สามารถตรวจสอบได้ในระดับซอฟต์แวร์ ยังคงต้องเก็บไว้เป็นเอกสารแสดงเจตนาของลูกค้า อย่างไรก็ตาม อาจสามารถสืบย้อนไปถึงข้อกำหนดด้านกระบวนการที่กำหนดว่าเป็นวิธีที่ใช้ได้จริงในการตอบสนองข้อกำหนดเหล่านั้น ตัวอย่างเช่น ข้อกำหนดที่ไม่เกี่ยวข้องกับการทำงานที่ต้องปราศจากช่องโหว่อาจได้รับการตอบสนองโดยการแทนที่ด้วยข้อกำหนดด้านกระบวนการในการใช้การเขียนโปรแกรมแบบคู่ (pair programming ) ข้อกำหนดที่ไม่เกี่ยวข้องกับการทำงานอื่นๆ จะสืบย้อนไปถึงส่วนประกอบอื่นๆ ของระบบและได้รับการตรวจสอบในระดับนั้น ตัวอย่างเช่น ความน่าเชื่อถือของระบบมักได้รับการตรวจสอบโดยการวิเคราะห์ในระดับระบบซอฟต์แวร์การบินที่มีข้อกำหนดด้านความปลอดภัยที่ซับซ้อนต้องปฏิบัติตามกระบวนการพัฒนา DO-178B

กิจกรรมที่นำไปสู่การได้มาซึ่งข้อกำหนดของระบบหรือซอฟต์แวร์ วิศวกรรมข้อกำหนดอาจเกี่ยวข้องกับการศึกษาความเป็นไปได้หรือขั้นตอนการวิเคราะห์เชิงแนวคิดของโครงการและการรวบรวมข้อกำหนด (การรวบรวม ทำความเข้าใจ ตรวจสอบ และอธิบายความต้องการของผู้มีส่วนได้ส่วนเสีย ) และการวิเคราะห์ข้อกำหนด^{[ 10 ]} ( การตรวจสอบความสอดคล้องและความสมบูรณ์) การกำหนดรายละเอียด (การจัดทำเอกสารข้อกำหนด) และการตรวจสอบความถูกต้อง (การตรวจสอบให้แน่ใจว่าข้อกำหนดที่ระบุไว้นั้นถูกต้อง) ^{[ 11 ] [ 12 ]}

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

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

• ใช้เวลานานในการผลิต บางครั้งอาจนานจนล้าสมัยไปเมื่อผลิตเสร็จแล้ว
• จำกัดตัวเลือกการใช้งานที่มีอยู่
• มีต้นทุนการผลิตสูง

แนวทางการพัฒนาแบบ Agileพัฒนาขึ้นเพื่อแก้ไขปัญหาเหล่านี้ โดยกำหนดข้อกำหนดพื้นฐานในระดับสูง และขยายรายละเอียดในเวลาที่เหมาะสมหรือ ใน เวลา สุดท้ายที่รับผิดชอบ

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

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

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

หลายโครงการประสบความสำเร็จโดยแทบไม่มีข้อตกลงเกี่ยวกับข้อกำหนด^{[ 13 ]}หลักฐานบางส่วนยังบ่งชี้ว่าการระบุข้อกำหนดสามารถลดความคิดสร้างสรรค์และประสิทธิภาพการออกแบบได้^{[ 14 ]}ข้อกำหนดขัดขวางความคิดสร้างสรรค์และการออกแบบเนื่องจากนักออกแบบหมกมุ่นอยู่กับข้อมูลที่ได้รับมากเกินไป^{[ 15 ] [ 16 ] [ 17 ]}โดยทั่วไปแล้ว งานวิจัยบางชิ้นชี้ให้เห็นว่าข้อกำหนดซอฟต์แวร์เป็นภาพลวงตาที่สร้างขึ้นจากการบิดเบือนการตัดสินใจด้านการออกแบบให้เป็นข้อกำหนดในสถานการณ์ที่ไม่มีข้อกำหนดที่แท้จริงปรากฏให้เห็น^{[ 18 ]}

ในขณะเดียวกัน วิธีการพัฒนาซอฟต์แวร์แบบ Agileส่วนใหญ่ ตั้งคำถามถึงความจำเป็นในการกำหนดข้อกำหนดของซอฟต์แวร์อย่างเข้มงวดตั้งแต่เริ่มต้น ซึ่งพวกเขาถือว่าเป็นเป้าหมายที่เปลี่ยนแปลงได้ตลอดเวลา แทนที่จะเป็นเช่นนั้น ตัวอย่างเช่น Extreme Programmingจะอธิบายข้อกำหนดอย่างไม่เป็นทางการโดยใช้User Story (บทสรุปสั้นๆ ที่เขียนลงบนการ์ดดัชนี อธิบายถึงแง่มุมหนึ่งของสิ่งที่ระบบควรทำ) และถือว่าเป็นหน้าที่ของนักพัฒนาที่จะสอบถามลูกค้าโดยตรงเพื่อขอคำชี้แจงเพิ่มเติม วิธีการแบบ Agile พยายามรวบรวมข้อกำหนดผ่านชุดของการทดสอบการยอมรับ แบบ อัตโนมัติ

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

มีการจัดหมวดหมู่ข้อกำหนดหลายแบบขึ้นอยู่กับกรอบการทำงานที่ใช้ (ตัวอย่างเช่น มาตรฐานที่ระบุไว้ของ IEEE เทียบกับแนวทางของ IIBA หรือกระทรวงกลาโหมสหรัฐฯ) ภาษาและกระบวนการที่แตกต่างกันในสถานที่ต่างๆ หรือแม้แต่การพูดคุยทั่วไป อาจทำให้เกิดความสับสนและเบี่ยงเบนจากกระบวนการที่ต้องการได้

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

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

ในกระบวนการของกระทรวงกลาโหมสหรัฐฯ ตัวอย่างในอดีตเกี่ยวกับปัญหาด้านข้อกำหนดมีดังนี้

• ปัญหาของรถถัง M-2 Bradley ที่เกี่ยวข้องกับการเคลื่อนย้ายตามความต้องการที่ไม่แน่นอน ปรากฏให้เห็นในภาพยนตร์สารคดีเรื่อง Pentagon Wars ;
• การพัฒนาของ F-16 มาจากแนวคิดเครื่องบินขับไล่น้ำหนักเบาของกลุ่มผู้ผลิตเครื่องบินขับไล่ รายใหญ่ เป็นผลมาจากการที่โครงการ F-15 พยายามบ่อนทำลายคู่แข่ง หรือหน่วยงานต่างๆ นำเอาความต้องการเฉพาะของตนเองมาปรับใช้ ทำให้แนวคิดเรื่องเครื่องบินน้ำหนักเบาและต้นทุนต่ำนั้นเสื่อมถอยลง
• ความกระตือรือร้นเกี่ยวกับ 'Net-Ready' ในช่วงประมาณปี 1998 นำไปสู่การกำหนดให้เป็นตัวชี้วัดประสิทธิภาพหลัก (Key Performance Parameter หรือ KPP) จากสำนักงาน Net-Ready ซึ่งอยู่นอกเหนือกระบวนการกำหนดข้อกำหนดของสำนักงาน และไม่สอดคล้องกับกระบวนการที่สำนักงานกำหนดไว้ก่อนหน้านี้ รวมถึงคำจำกัดความของ KPP หรือความพยายามบางอย่างอาจไม่เหมาะสมหรือไม่สามารถกำหนดได้ว่าอะไรคือ 'Net-Ready'

• ข้อกำหนดทางธุรกิจ
• ข้อกำหนดซอฟต์แวร์
• วิศวกรรมความต้องการ
• การวิเคราะห์ความต้องการ
• การรวบรวมข้อกำหนด
• การจัดการข้อกำหนด
• การจัดลำดับความสำคัญของข้อกำหนด
• การตรวจสอบย้อนกลับข้อกำหนด
• ข้อกำหนด (มาตรฐานทางเทคนิค)
• Shall และ will - การใช้ถ้อยคำ
• วิธีการ MoSCoW - เทคนิคการจัดลำดับความสำคัญ
• เรื่องราวของผู้ใช้
• กรณีศึกษา

ค้นหาคำว่า "requirement"ใน Wiktionary ซึ่งเป็นพจนานุกรมฟรี

• การค้นหาความต้องการของระบบ