การรวบรวมความต้องการ (requirement) เพื่อนำมาเขียนเป็นสเปคเป็นขั้นตอนที่สำคัญมากขั้นตอนหนึ่ง เราสามารถแบ่งความต้องการออกได้เป็น 2 แบบคือ (1) ต้องการให้ทำงานอย่างไร (functional requirement – จากนี้ไปจะใช้คำว่าฟังก์ชั่น) เช่น ผู้ใช้งานคลิกเมนูค้นหา แสดงหน้าต่างค้นหา ป้อนข้อความที่ต้องการค้นหา กดปุ่มค้นหา แสดงผลลัพธ์เป็นหัวข้อบทความที่มีคำที่ต้องการค้นหาเป็นรายการ หน้าละ 20 รายการ และ (2) คุณสมบัติเชิงคุณภาพควรเป็นอย่างไร (non-functional requirement – จากนี้ไปจะเรียกว่าคุณสมบัติ) ซึ่งชนิดของคุณสมบัติที่สนใจจะขึันอยู่กับผู้ที่เกี่ยวข้อง เช่น ผู้ใช้งานจะสนใจเรื่องความง่ายในการใช้งาน (usability) ประสิทธิภาพ (performance) และสามารถรองรับการใช้งานที่เพิ่มมากขึ้นได้ (scalability) ในขณะที่ทีมพัฒนาจะสนใจเรื่องความน่าเชื่อถือ (reliability) ความซับซ้อน (complexibility) การรองรับการทดสอบ (testability) ปัญหาที่มักจะพบคือคุณสมบัติมักจะขัดแย้งกัน เช่น การพัฒนาโปรแกรมแบบโดยไม่ใช้เทคนิกขั้นสูงอาจจะทำให้ได้โปรแกรมที่ประสิทธิภาพไม่ค่อยดี แต่ถ้าใช้เทคนิกขั้นสูง เช่น ใช้แคชมาช่วยในการทำงานจะทำให้ประสิทธิภาพในการทำงานดีขึ้น แต่โปรแกรมก็ซับซ้อนขึ้น หรือเรื่องความง่ายในการใช้งานกับเรื่องความปลอดภัย ยิ่งเราเพิ่มเรื่องความปลอดภัยเข้าไปมากเท่าไร จะยิ่งทำให้การใช้งานยากมากขึ้น ดังนั้นเรื่องคุณสมบัติจึงต้องการการพูดคุยระหว่างผู้ใช้งานและทีมพัฒนา เพื่อดูข้อดีและข้อเสียและหาข้อสรุปร่วมกันก่อนที่จะระบุในสเปค เพราะทุกสิ่งที่ตัดสินใจจะส่งผลกระทบที่ฝ่ายใดฝ่ายหนึ่งเสมอ ในการรวบรวมความต้องการต้องระลึกอยู่เสมอว่าเรากำลังรวบรวมว่าต้องการให้ซอฟต์แวร์ทำงานอะไร แต่จะไม่ระบุว่าจะทำงานนั้นๆอย่างไร ยกตัวอย่าง เช่น เราจะระบุว่าต้องการให้เรียงลำดับข้อมูลแบบไหน แต่ไม่พูดถึงว่าจะใช้อัลกอริธึมแบบใดในการเรียงลำดับข้อมูล เพราะอันนั้นเป็นหน้าที่ของทีมพัฒนา

     ในการรวบรวมความต้องการนั้นมี 4 หัวข้อที่เราต้องคำนึงถึงคือ (1) มีความครบถ้วน (complete) เพราะเราคงไม่ต้องการส่งมอบซอฟต์แวร์ที่ขาดสิ่งสำคัญที่ลูกค้าต้องการ (2) ไม่ขัดแย้งกันเอง  (consistent) บางครั้งความต้องการอาจจะแยกออกมาเป็นหัวข้อย่อยได้เป็นร้อยเป็นพันหัวข้อ และเมื่อลงมือพัฒนาไปแล้วอาจจะพบว่าความต้องการหัวข้อที่พัฒนาในช่วงหลังๆขัดแย้งกับความต้องการหัวข้อแรกๆ ก็จะเป็นปัญหากับทีมพัฒนาในภายหลัง (3) ชัดเจน (precise) เนื่องจากการรวบรวมความต้องการเป็นการบรรยายความตามปรกติ ดังนั้นต้องระวังความคลุมเครือของคำที่ใช้ (4) การอธิบายต้องกระชับ (concise) เพื่อที่ทีมพัฒนาจะได้ไม่เสียเวลากับการทำความเข้าใจเอกสาร และสามารถตรวจสอบสิ่งที่พัฒนาเทียบกับความต้องการได้ง่าย

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

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

กระทบจากโครงสร้างภายในของทีมพัฒนา เช่น การแยกกันระหว่างทีมพัฒนาส่วนติดต่อผู้ใช้งาน (UI) และทีมพัฒนาระบบหลังบ้าน (back-end system) เราก็ต้องแยกส่วนของการพัฒนาออกมาสำหรับแต่ละทีม การทำงานร่วมกับระบบงานอื่นทั้งภายในและภายนอกองค์กร การต้องเชื่อมต่อกับระบบงานอื่นหรือรับเอาซอฟต์แวร์อื่นมาเป็นส่วนประกอบ และการที่ทีมพัฒนาต้องเข้าใจว่าอะไรที่เป็นสิ่งที่สำคัญจริงๆสำหรับลูกค้า