สเปกแอปมือถือ: เทมเพลตหน้าเดียว
โดย Mehdi Azizi
อัปเดตเมื่อ , 10 นาที
สเปกแอป iOS หน้าเดียวที่ช่วยกำหนดกรอบแอปและนำทาง AI: 10 คำถาม เทมเพลตพร้อมคัดลอก และสิ่งที่ไม่ควรใส่เด็ดขาด
สเปกแอปมือถือ: คำตอบแบบสั้น
สเปกแอปมือถือที่ดีเมื่อคุณสร้างแอปของตัวเอง ใช้แค่หน้าเดียว มันตอบคำถามสิบข้อ: ใช้สำหรับใคร แก้ปัญหาอะไร ฟังก์ชันหลักคืออะไร แอปหาเงินอย่างไร ไม่มีบัญชีแล้วทำอะไรได้ ข้อมูลไหนต้องอยู่รอด ใช้แพลตฟอร์มอะไร อะไรอยู่นอกเวอร์ชันแรก คุณจะรู้ได้อย่างไรว่ามันได้ผล และมีข้อจำกัดอะไร เทมเพลตให้คัดลอกอยู่ด้านล่าง คุณยังดาวน์โหลดโครงร่างพร้อมตารางตรวจสอบ (.md) ได้ โดยไม่ต้องสมัครสมาชิก
เทมเพลต 40 หน้าที่คุณเจอในเน็ตเขียนขึ้นเพื่อการใช้งานอีกแบบ: ลูกค้าที่จ้างผู้รับเหมาทำแอปและต้องการเอกสารเชิงสัญญา ส่วนคุณเป็นทั้งคนตัดสินใจและคนสร้าง ซึ่งบ่อยครั้งก็ใช้ AI ช่วย สเปกของคุณมีไว้สองอย่าง: ตัดสินใจเรื่องต่าง ๆ ให้เด็ดขาดก่อนเขียนโค้ด และให้บริบทที่ชัดเจนกับ Claude, ChatGPT หรือ Cursor เพื่อให้มันสร้างแอปที่ถูกต้อง
ผมเผยแพร่แอป iOS ของตัวเอง Solys นาฬิกาปลุกที่มีมินิเกม และ TradaZen แอปจำลองการเทรด อยู่บน App Store แล้ว ส่วน Nolera กับ Clic เคยถูก Apple ปฏิเสธ แล้วผมก็แก้ไข นี่คือวิธีที่ผมใช้กับทุกแอป และเป็นวิธีที่ผมเสนอให้คุณในบทความนี้
ทำไมหน้าเดียวก็พอสำหรับกำหนดกรอบแอปของคุณเอง
เอกสารยาว ๆ ทำให้รู้สึกว่างานคืบหน้า แต่ในความเป็นจริง มันถูกเขียนครั้งเดียว แทบไม่มีใครอ่านซ้ำ และโปรเจกต์ก็เบี่ยงออกไปตั้งแต่สัปดาห์แรก ๆ ในทางกลับกัน หน้าเดียวอ่านซ้ำได้ในสองนาทีก่อนเริ่มทำงานแต่ละรอบ
ข้อจำกัดเรื่องพื้นที่ยังมีประโยชน์อีกอย่าง: มันบังคับให้คุณตัดสินใจ ถ้าคำตอบไหนยาวเกินสองประโยค ส่วนใหญ่แปลว่ายังไม่ได้ตัดสินใจ รู้เรื่องนี้บนกระดาษดีกว่ามารู้ในโค้ดอีกสามสัปดาห์ให้หลัง
สุดท้าย หน้าเดียวคือขนาดที่เหมาะกับ AI คุณวางทั้งหน้าลงในบทสนทนาได้ หรือเก็บไว้ในไฟล์บริบทของโปรเจกต์ เอกสารสั้นอ่านทวนง่ายและลดคำสั่งที่ขัดแย้งกัน แต่ไม่ได้รับประกันว่า AI จะทำตาม: ตรวจสอบสิ่งที่มันเสนอเทียบกับกรอบนี้เสมอ
สเปกแอปมือถือต้องมีอะไรบ้าง?
ตอบแต่ละคำถามด้วยหนึ่งหรือสองประโยค
- ใครใช้แอป และในสถานการณ์ไหน? ไม่ใช่ "คนอายุ 18-35 ปี" แต่เป็นคนคนหนึ่งที่ชัดเจน ในช่วงเวลาที่ชัดเจนของวัน
- แอปแก้ปัญหาอะไร ในหนึ่งประโยค? ถ้าคุณต้องใช้คำว่า "และยัง" แปลว่าคุณกำลังอธิบายสองแอป
- ฟังก์ชันหลัก "หนึ่งเดียว" ของเวอร์ชันแรกคืออะไร? แค่อย่างเดียว ที่เหลือรอดูตัวเลขก่อน หน้า MVP ของแอป iOS อธิบายวิธีเลือก
- แอปหาเงินอย่างไร? สมัครสมาชิก ซื้อครั้งเดียว หรือฟรี คำตอบนี้เปลี่ยนแอปตั้งแต่หน้าจอแรก ถ้ายังลังเล อ่าน สมัครสมาชิกหรือซื้อครั้งเดียวสำหรับแอป iOS
- ไม่สร้างบัญชีแล้วทำอะไรได้บ้าง? ตัดสินใจตั้งแต่เนิ่น ๆ ว่าอะไรใช้ได้โดยไม่ต้องสมัคร จะช่วยให้คุณไม่ต้องรื้อขั้นตอนต้อนรับผู้ใช้ใหม่ทั้งหมด
- ข้อมูลไหนต้องอยู่รอดเมื่อเปลี่ยนโทรศัพท์? คำถามนี้ตัดสินว่าคุณต้องมี backend อย่าง Supabase หรือเก็บทุกอย่างไว้บนเครื่องได้
- iOS อย่างเดียว หรือทั้ง iOS และ Android? คำแนะนำของผมสำหรับมือใหม่: iOS ก่อน ผมอธิบายเหตุผลไว้ใน แอป iOS และ Android พร้อมกัน
- อะไรที่อยู่ "นอก" เวอร์ชันแรกอย่างชัดเจน? ส่วนที่มีประโยชน์ที่สุดของเอกสาร มันตัดการถกเถียงก่อนจะเกิดขึ้น ทั้งกับตัวเองและกับ AI
- คุณจะรู้ได้อย่างไรว่ามันได้ผล? สัญญาณเดียวที่วัดได้ในไม่กี่สัปดาห์หลังเปิดตัว: จำนวนคนเริ่มทดลองใช้ฟรี จำนวนสมาชิก ผู้ใช้ที่กลับมาใช้ซ้ำ
- ข้อจำกัดจริงของคุณคืออะไร? เวลาที่คุณให้ได้ต่อสัปดาห์ อุปกรณ์ของคุณ และบัญชี Apple Developer ของคุณซึ่งมีค่าใช้จ่าย 99 ดอลลาร์ต่อปี ไม่มี Mac? ไม่ใช่ปัญหา อย่างที่ผมอธิบายไว้ใน เผยแพร่แอป iOS โดยไม่มี Mac
เทมเพลตสเปกให้คัดลอก
คัดลอกเทมเพลตนี้ไปไว้ในโน้ตหรือไฟล์ข้อความที่ root ของโปรเจกต์ แล้วแทนที่ทีละบรรทัด
- ชื่อแอปชั่วคราว: …
- สำหรับใคร: คนที่ … ในตอนที่ …
- ปัญหาที่แก้ ในหนึ่งประโยค: …
- ฟังก์ชันหลักของเวอร์ชัน 1: …
- สิ่งที่ผู้ใช้เห็นเมื่อเปิดแอปครั้งแรก: …
- โมเดลธุรกิจ: สมัครสมาชิก / ซื้อครั้งเดียว / ฟรี และส่วนที่ต้องจ่ายเงิน: …
- ไม่มีบัญชีก็ทำได้: …
- ข้อมูลที่ต้องเก็บไว้ข้ามโทรศัพท์: ไม่มี / …
- แพลตฟอร์ม: iOS ก่อน (Android ทีหลังถ้าตัวเลขดี)
- นอกเวอร์ชัน 1: …, …, …
- สัญญาณความสำเร็จ: …
- Stack: React Native, Expo, Supabase ถ้าต้องมีบัญชีผู้ใช้, RevenueCat สำหรับการสมัครสมาชิก
- ข้อจำกัด: … ชั่วโมงต่อสัปดาห์, เปิดบัญชี Apple Developer แล้วหรือยัง, มี Mac หรือไม่
- แอปที่ผมชอบประสบการณ์การใช้งาน และเหตุผล: …
เพิ่มภาพหน้าจอของแอปที่คุณชอบ สามถึงห้าภาพ พร้อมคำอธิบายสั้น ๆ ว่าชอบตรงไหน มันสื่อได้ชัดกว่าคู่มือแบรนด์ ทั้งสำหรับคุณและสำหรับ AI
สเปกไม่ใช่รายการสิ่งที่อยากได้ แต่เป็นรายการการตัดสินใจที่ทำไปแล้ว
ตัวอย่าง: หน้าที่กรอกแล้วสำหรับแอปสมมติ
เพื่อให้เห็นระดับรายละเอียดที่ควรมี นี่คือเทมเพลตที่กรอกแล้วสำหรับแอปที่แต่งขึ้นเป็นตัวอย่าง: ตัวจับเวลาสำหรับอ่านหนังสือ
- สำหรับใคร: นักศึกษาที่อ่านหนังสือคนเดียวตอนกลางคืนและหลุดโฟกัสหลังผ่านไปสิบนาที
- ปัญหา: เขาทำงานให้จบหนึ่งรอบไม่ได้โดยไม่แตะโทรศัพท์
- ฟังก์ชันหลัก: เริ่มรอบการอ่านแบบจับเวลาและดูสถิติจำนวนวันต่อเนื่องที่ทำได้
- หน้าจอแรก: ปุ่มเดียวสำหรับเริ่มรอบ
- โมเดลธุรกิจ: สมัครสมาชิกเพื่อดูสถิติแบบละเอียด รอบพื้นฐานใช้ฟรี
- ไม่มีบัญชี: ใช้ได้ทุกอย่าง ยกเว้นการสำรองข้อมูลข้ามโทรศัพท์
- นอกเวอร์ชัน 1: โหมดกลุ่ม การจัดอันดับระหว่างเพื่อน วิดเจ็ต เวอร์ชัน Android
- สัญญาณความสำเร็จ: ผู้ใช้ที่กลับมาใช้หลายวันติดกัน
สังเกตสิ่งที่ตั้งใจไม่ใส่: ไม่มีรายการหน้าจอยี่สิบหน้า ไม่มีสีที่บังคับ ไม่มีสถาปัตยกรรม ตัวเลือกเหล่านี้จะมาระหว่างที่สร้าง และหน้านี้มีไว้ให้คุณตรวจว่ามันยังรับใช้ฟังก์ชันหลักอยู่
ใช้สเปกนำทาง AI อย่างไร
นี่คือจุดที่หน้าเดียวของคุณให้ผลตอบแทนมากที่สุด AI ที่เขียนโค้ดโดยไม่มีบริบทจะเดา และมักเดาออกมาเป็นแอปอื่นที่ไม่ใช่ของคุณ
ใส่หน้านี้ไว้ในบริบทถาวรของโปรเจกต์ Claude Code อ่านไฟล์ CLAUDE.md ที่ root ส่วน Cursor มีไฟล์กฎของตัวเอง วางสเปกของคุณลงไปพร้อม stack แล้วทุกคำขอจะเริ่มจากฐานเดียวกัน
อ้างถึงส่วน "นอกเวอร์ชัน 1" เมื่อ AI ทำเกินขอบเขต ผู้ช่วย AI ชอบเสนอฟังก์ชันเพิ่ม: โหมดมืด ปุ่มแชร์ การแจ้งเตือน รายการสิ่งที่ไม่ทำให้คำตอบสำเร็จรูปกับคุณ: ยังไม่ใช่ตอนนี้
ขอแผนที่เคารพหน้านี้ ก่อนงานใหญ่ ให้เขียนว่า: "นี่คือสเปกของผม เสนอแผนสำหรับฟังก์ชันหลัก ยังไม่ต้องเขียนโค้ด" คุณจะเห็นทันทีถ้าแผนเบี่ยงออกจากสิ่งที่ตัดสินใจไว้
ให้มันอ่านทวนหน้านี้ ไม่ใช่แค่โค้ด ถามว่า: "คำถามไหนในสเปกนี้ที่คลุมเครือหรือขัดแย้งกัน?" เป็นการใช้ AI ที่คนมองข้าม และช่วยให้คุณไม่เสียเวลาหลายสัปดาห์ไปผิดทาง
ถ้าอยากลงลึกกว่านี้ ผมอธิบายกับดักและสิ่งที่ต้องตรวจไว้ใน สร้างแอป iOS ด้วย AI
เปลี่ยนการตัดสินใจให้เป็นเกณฑ์ตรวจสอบ
ฟังก์ชันหลักต้องมีผลลัพธ์ที่สังเกตได้ สำหรับตัวจับเวลาสมมติในตัวอย่างนี้ "ตัวจับเวลาใช้งานได้" กว้างเกินไป ให้เขียนแบบนี้แทน: "ผมเริ่มรอบ เวลาที่เหลือแสดงขึ้น ผมหยุดได้ และเห็นรอบล่าสุดที่จบแล้วหลังเปิดแอปใหม่" ส่วนเรื่องที่ว่าตัวจับเวลาต้องทำงานต่อตอนล็อกหน้าจอหรือไม่ ให้ตัดสินใจแยกต่างหาก เพราะอาจเปลี่ยนงานด้านเทคนิค
สำหรับแต่ละฟังก์ชัน ให้เพิ่มสามบรรทัด: การกระทำ ผลลัพธ์ที่คาดหวัง หลักฐาน หลักฐานอาจเป็นเทสต์อัตโนมัติสำหรับการคำนวณ หรือการตรวจบนเครื่องจริงสำหรับขั้นตอนการใช้งาน จดด้วยว่าอะไรยังไม่ได้ทดสอบ ตารางเล็ก ๆ นี้ช่วยไม่ให้สับสนระหว่างหน้าจอที่ทำเสร็จกับฟังก์ชันที่พร้อมใช้งาน
นี่คือตารางที่กรอกแล้วสำหรับตัวจับเวลาสมมติของเรา เป็นเกณฑ์ที่ต้องตรวจ ไม่ใช่เทสต์ที่ผ่านแล้ว:
| การตัดสินใจในกรอบ | สิ่งที่ต้องทดสอบ | ผลลัพธ์ที่คาดหวัง |
|---|---|---|
| รอบพื้นฐานใช้ได้โดยไม่มีบัญชี | ติดตั้งแอปและเริ่มรอบโดยไม่สมัคร | ไม่มีฟอร์มสมัครสมาชิกมาขวางการเริ่ม |
| รอบที่เลิกกลางคันไม่นับในวันต่อเนื่อง | หยุดรอบก่อนจบ แล้วเปิดประวัติ | ไม่มีรอบที่จบแล้วถูกเพิ่มเข้าไป |
| ประวัติเก็บอยู่บนเครื่อง | จบรอบหนึ่ง ปิดแล้วเปิดแอปใหม่ | รอบนั้นแสดงแค่ครั้งเดียวพร้อมระยะเวลาที่ถูกต้อง |
| ตัวจับเวลาพื้นฐานใช้ได้โดยไม่มีเน็ต | เปิดโหมดเครื่องบินแล้วจบรอบหนึ่ง | ตัวจับเวลาและการบันทึกในเครื่องยังใช้ได้ |
| สถิติแบบละเอียดต้องจ่ายเงิน | เปิดหน้าสถิติโดยไม่ได้สมัครสมาชิก | ข้อเสนอแสดงขึ้น และรอบพื้นฐานยังใช้ได้ |
เรื่องที่ยังคลุมเครือจะกลายเป็นการตัดสินใจที่ต้องทำ เช่น: ถ้าผู้ใช้ล็อกหน้าจอหรือเปลี่ยนเวลาในโทรศัพท์ระหว่างรอบ ควรทำอย่างไร? อย่าปล่อยให้เอเจนต์เลือกเองเงียบ ๆ เขียนพฤติกรรมที่ต้องการ แล้วเพิ่มกรณีนั้นลงในตาราง ถ้าจะจัดการทดสอบนี้บนการติดตั้งจริง ให้ใช้คู่มือ ทดสอบแอป iPhone ด้วย TestFlight
ตัดสินใจว่าจะตัดอะไรเมื่อเวอร์ชันแรกล้น
ไล่ดูทีละฟังก์ชันแล้วถามว่า: "ถ้าไม่มีมัน ผู้ใช้ยังได้ผลลัพธ์ตามที่สัญญาไว้ไหม?" สำหรับตัวจับเวลาของเรา การจัดอันดับระหว่างเพื่อน รอได้ การเห็นรอบที่จบแล้วเป็นสิ่งจำเป็นถ้าคุณสัญญาเรื่องวันต่อเนื่อง ส่วนหน้าจอสมัครสมาชิกจำเป็นก็ต่อเมื่อคุณขายสถิติจริง ๆ ตั้งแต่เวอร์ชันนี้
จดการตัดสินใจและเหตุผลไว้ในบันทึกของเทมเพลตที่ดาวน์โหลดได้ คุณจะกลับมาทบทวนได้หลังการทดสอบ โดยไม่ลืมว่าทำไมขอบเขตตอนแรกเป็นแบบนั้น จากนั้นบทเรียน สร้างแอปด้วย Claude Code จะแสดงวิธีเปลี่ยนกรอบนี้เป็นคำขอที่จำกัดขอบเขตและตรวจสอบได้
ถ้าอยากดูประสบการณ์จริง TradaZen เปลี่ยนขอบเขตหลังเผยแพร่ การกำหนดกรอบมีไว้เพื่อปล่อยเวอร์ชันแรกที่วัดผลได้ แล้วค่อยตัดสินใจเวอร์ชันถัดไปจากฟีดแบ็กจริง
กับดักของรายการฟีเจอร์
ปฏิกิริยาตามธรรมชาติคือการลิสต์ทุกอย่างที่แอป "ต้องทำ": แผนที่ แชต การแจ้งเตือน ระบบชวนเพื่อน โหมดออฟไลน์ รายการแบบนี้คือสัญญาณที่แม่นที่สุดของโปรเจกต์ที่ไปไม่ถึงไหน ด้วยเหตุผลง่าย ๆ: ทุกฟังก์ชันที่เพิ่มก่อนเปิดตัวจะเลื่อนเวลาที่ผู้ใช้จริงจะบอกคุณว่าอะไรสำคัญ
เวอร์ชันแรกที่ดีทำสิ่งเดียว และทำให้ดี แต่ระวังสุดขั้วอีกด้านด้วย: Apple กำหนดให้แอปต้องมีอะไรมากกว่าเว็บไซต์ที่ถูกห่อไว้ ตามข้อ 4.2 ของ App Review Guidelines ฟังก์ชันหลักเดียวน่ะได้ แต่เปลือกกลวงไม่ได้ นั่นคือเหตุผลของ guideline 4.2
สิ่งที่สเปกแอปมือถือไม่ควรมี
- คู่มือแบรนด์ฉบับเต็ม ภาพหน้าจออ้างอิงไม่กี่ภาพก็พอสำหรับตอนเริ่ม
- แผนงานรายวัน คุณยังไม่มีข้อมูลพอจะทำตามได้ เป้าหมายรายสัปดาห์ก็พอ
- สถาปัตยกรรมทางเทคนิคแบบละเอียด เลือก stack ที่พิสูจน์แล้ว แล้วปล่อยให้รายละเอียดตัดสินใจระหว่างสร้าง
- ฟังก์ชัน "ไว้ทีหลัง" ที่ปนอยู่กับส่วนอื่น ทั้งหมดต้องไปอยู่ในส่วนนอกเวอร์ชัน 1
ควรอัปเดตสเปกเมื่อไร?
อ่านทวนทุกต้นสัปดาห์ที่ทำงาน อัปเดตเฉพาะเมื่อการตัดสินใจเปลี่ยนด้วยเหตุผลจริง: การทดสอบบน iPhone ที่แสดงว่าหน้าจอหนึ่งใช้ไม่ได้ ฟีดแบ็กจากผู้ทดสอบ ข้อกำหนดของ Apple ที่เพิ่งเจอระหว่างทาง ถ้าคุณแก้มันทุกวัน แปลว่ามันไม่ได้กำหนดกรอบอะไรแล้ว
เมื่อเวอร์ชันแรกเผยแพร่แล้ว หน้านี้จะกลายเป็นฐานของเวอร์ชันถัดไป: สิ่งที่อยู่นอกเวอร์ชัน 1 จะขยับขึ้นมา โดยจัดลำดับตามที่ตัวเลขบอก ภาพรวมของเส้นทางตั้งแต่ไอเดียจนถึงการเผยแพร่อยู่ที่หน้า สร้างแอป iPhone
จากหน้าเดียวสู่แอปที่เผยแพร่แล้ว
ถ้าคุณตอบคำถามสิบข้อแล้ว คุณได้ทำงานที่หลายโปรเจกต์ข้ามไป ขั้นต่อไปคือสร้างฟังก์ชันหลัก ทดสอบบน iPhone เชื่อมระบบสมัครสมาชิก และเตรียมเอกสารสำหรับ Apple
เส้นทางนี้คือเส้นทางของ iOS Kit ซึ่งมีสี่ขั้นตอนให้ทำตามจังหวะของคุณ: ขั้นแรกคือการเลือกแอปที่ทำเงินได้ กลุ่มเป้าหมาย และราคา และสเปกของคุณคือจุดเริ่มต้นของขั้นนั้น
ไม่แน่ใจว่าไอเดียของคุณพร้อมจะอยู่ในหน้าเดียวหรือยัง? การวินิจฉัยฟรี จะบอกว่าอะไรกำลังขวางโปรเจกต์ของคุณอยู่ และควรเริ่มขั้นไหนก่อน จากนั้นหน้าแรกจะแสดงวิธีสร้างแอปมือถือจากกรอบนี้ด้วย Claude Code
ผมไม่สัญญาเรื่องรายได้หรือการได้เผยแพร่: Apple เป็นคนอนุมัติ และตลาดเ��็นคนตัดสินที่เหลือ ถ้าไม่ใช้ kit เทมเพลตนี้ก็พอให้คุณเริ่มต้นได้
คำถามที่พบบ่อย
เขียนสเปกแอปมือถืออย่างไร?
ทำให้สเปกอยู่ในหน้าเดียว: สิบคำถาม ตอบข้อละหนึ่งหรือสองประโยค ครอบคลุมกลุ่มเป้าหมาย ปัญหา ฟังก์ชันหลัก โมเดลธุรกิจ สิ่งที่ทำได้โดยไม่มีบัญชี ข้อมูลที่ต้องอยู่รอด แพลตฟอร์ม สิ่งที่อยู่นอกเวอร์ชันแรก สัญญาณความสำเร็จ และข้อจำกัด ถ้าคำตอบไหนยาวเกินสองประโยค ส่วนใหญ่แปลว่ายังไม่ได้ตัดสินใจ
ควรใช้โปรแกรมอะไรเขียนสเปกแอป?
แค่โน้ตธรรมดาหรือไฟล์ข้อความที่ root ของโปรเจกต์: คัดลอกเทมเพลตไปวาง แล้วแทนที่ทีละบรรทัด คุณยังดาวน์โหลดโครงร่างพร้อมตารางตรวจสอบ (.md) ได้ โดยไม่ต้องสมัครสมาชิก ถ้าจะใช้นำทาง AI ให้เก็บไว้ในไฟล์บริบทของโปรเจกต์
แอปต้องมีสเปก 40 หน้าไหม?
ไม่ เมื่อคุณสร้างแอปของตัวเอง หน้าเดียวก็พอ เทมเพลต 40 หน้าในเน็ตเขียนขึ้นสำหรับลูกค้าที่จ้างผู้รับเหมาทำแอปและต้องการเอกสารเชิงสัญญา ส่วนคุณเป็นคนตัดสินใจและคนสร้าง: หน้าเดียวของคุณมีไว้ตัดสินใจก่อนเขียนโค้ดและให้บริบทกับ AI
จะส่งสเปกให้ AI ที่เขียนโค้ดอย่างไร?
ใส่หน้านี้ไว้ในบริบทถาวรของโปรเจกต์: Claude Code อ่านไฟล์ CLAUDE.md ที่ root ส่วน Cursor มีไฟล์กฎของตัวเอง อ้างถึงส่วน "นอกเวอร์ชัน 1" เมื่อ AI ทำเกินขอบเขต ก่อนงานใหญ่ ให้ขอแผนที่เคารพหน้านี้ โดยยังไม่ต้องเขียนโค้ด
จะตรวจได้อย่างไรว่าฟังก์ชันตรงตามสเปก?
สำหรับแต่ละฟังก์ชัน ให้เพิ่มสามบรรทัด: การกระทำ ผลลัพธ์ที่คาดหวัง และหลักฐาน หลักฐานอาจเป็นเทสต์อัตโนมัติสำหรับการคำนวณ หรือการตรวจบนเครื่องจริงสำหรับขั้นตอนการใช้งาน จดด้วยว่าอะไรยังไม่ได้ทดสอบ เพื่อไม่ให้สับสนระหว่างหน้าจอที่ทำเสร็จกับฟังก์ชันที่พร้อมใช้งาน
อะไรที่ไม่ควรใส่ในสเปกแอป?
สี่อย่างที่ควรเลี่ยง: คู่มือแบรนด์ฉบับเต็ม แผนงานรายวัน สถาปัตยกรรมทางเทคนิคแบบละเอียด และฟังก์ชัน "ไว้ทีหลัง" ที่ปนอยู่กับส่วนอื่น ภาพหน้าจออ้างอิงไม่กี่ภาพก็พอสำหรับตอนเริ่ม และเป้าหมายรายสัปดาห์ก็พอสำหรับแผนงาน ฟังก์ชันไว้ทีหลังทั้งหมดต้องไปอยู่ในส่วนนอกเวอร์ชัน 1