ข้อกำหนดซอฟต์แวร์^{[ 1 ]}สำหรับระบบคือคำอธิบายว่าระบบควรทำอะไรบริการหรือบริการที่ระบบจัดหาให้ และข้อจำกัดในการทำงานของซอฟต์แวร์ พจนานุกรมศัพท์วิศวกรรมซอฟต์แวร์มาตรฐานของ IEEE กำหนดข้อกำหนดไว้ดังนี้: ^{[ 2 ]}

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

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

โปรดทราบว่าคำว่า " ข้อกำหนดซอฟต์แวร์"ยังใช้ในบันทึกการเผยแพร่ ซอฟต์แวร์ เพื่ออธิบายว่าสิ่งใดจำเป็นสำหรับการสร้าง/ติดตั้ง/ใช้งานซอฟต์แวร์บางอย่าง ขึ้นอยู่กับ แพ็กเกจซอฟต์แวร์^{[ 1 ]}

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

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

การคัดกรองหรือจัดลำดับความสำคัญของข้อกำหนดเป็นกิจกรรมอีกอย่างหนึ่งที่มักจะตามมาหลังจากการวิเคราะห์^{[ 5 ]}ซึ่งเกี่ยวข้องกับการพัฒนาซอฟต์แวร์แบบ Agileในขั้นตอนการวางแผน เช่น โดยใช้Planning pokerอย่างไรก็ตาม อาจจะไม่เหมือนกันก็ได้ ขึ้นอยู่กับบริบทและลักษณะของโครงการและข้อกำหนดหรือผลิตภัณฑ์/บริการที่กำลังสร้าง

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

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

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

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

มีผู้เขียนอย่างน้อยหนึ่งรายที่สนับสนุนอย่างชัดเจนให้ใช้เครื่องมือสร้างแผนผังความคิดเช่นFreeMindและอีกทางเลือกหนึ่งคือการใช้ เครื่องมือ ระบุรายละเอียดโดยใช้ตัวอย่างเช่นConcordion [ ^{8 ]} นอกจากนี้ แนวคิดและข้อความที่ได้จากกิจกรรมเหล่านี้อาจถูกรวบรวมและจัดระเบียบด้วยวิกิและเครื่องมือการทำงานร่วมกัน^อื่น ๆ เช่นTrelloคุณสมบัติที่นำไปใช้จริงและการปฏิบัติตามมาตรฐานจะแตกต่างกันไปในแต่ละผลิตภัณฑ์

เอกสาร ข้อกำหนดซอฟต์แวร์ ( SRS) อาจถูกสร้างขึ้นโดยใช้ซอฟต์แวร์ทั่วไป เช่น โปรแกรมประมวลผลคำ หรือเครื่องมือเฉพาะทางต่างๆ เครื่องมือบางอย่างสามารถนำเข้า แก้ไข ส่งออก และเผยแพร่เอกสาร SRS ได้ การสร้างเอกสาร SRS โดยปฏิบัติตามโครงสร้างและวิธีการที่เป็นมาตรฐาน เช่น ISO/IEC/IEEE 29148:2018 อาจเป็นประโยชน์ ในทำนองเดียวกัน ซอฟต์แวร์บางตัวอาจใช้หรือไม่ใช้มาตรฐานบางอย่างในการนำเข้าหรือส่งออกข้อกำหนด (เช่นReqIF ) หรืออาจไม่อนุญาตให้มีการแลกเปลี่ยนข้อมูลเหล่านี้เลยก็ได้

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

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

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

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

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

ระดับความเป็นทางการและความซับซ้อนขึ้นอยู่กับวิธีการพื้นฐานที่เกี่ยวข้อง (ตัวอย่างเช่นi*มีความเป็นทางการมากกว่าSysMLและมีความเป็นทางการมากกว่าUML มาก )

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

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

• ความต้องการ
• วิศวกรรมความต้องการ
• เอกสารระบุความต้องการซอฟต์แวร์ (SRS)
• รายชื่อเครื่องมือวิศวกรรมข้อกำหนด
• ข้อกำหนดที่ไม่เกี่ยวข้องกับการทำงาน
• ข้อกำหนดด้านประสิทธิภาพซึ่งครอบคลุมโดยการทดสอบประสิทธิภาพซอฟต์แวร์
• ข้อกำหนดด้านความปลอดภัย
• ข้อกำหนดด้านความปลอดภัย

• Wiegers, Karl ; Beatty, Joy (2013). ข้อกำหนดซอฟต์แวร์ (ฉบับที่ 3). สำนักพิมพ์ Microsoft . ISBN 978-0-7356-7966-5.
• ค็อกเบิร์น, อลิสแตร์ (2001). การเขียนกรณีการใช้งานที่มีประสิทธิภาพ . เพียร์สัน เอ็ดดูเคชั่น . ISBN 0-201-70225-8.
• เลฟฟิงเวลล์, ดีน (2000). การจัดการข้อกำหนดซอฟต์แวร์: แนวทางแบบบูรณาการ . แอดดิสัน-เวสลีย์ โปรเฟสชันแน ล . ISBN 0-201-61593-2.
• บูเร็ก, พอล (2008). การสร้างข้อกำหนดโครงการที่ชัดเจนโดยแยกความแตกต่างระหว่าง "อะไร" กับ "อย่างไร"เอกสารการประชุม การจัดการข้อกำหนด การวิเคราะห์ธุรกิจ การจัดการขอบเขต
• คูปแมน, ฟิลิป (2020). ข้อกำหนดซอฟต์แวร์ฝังตัว . การบรรยายภาคฤดูใบไม้ร่วง.
• IEEE Xplore Search. "ข้อกำหนดซอฟต์แวร์" .