## 1. SDLC

### 1.1 ความหมายของ SDLC
        SDLC ย่อมาจาก Software Development Life Cycle หมายถึงกระบวนการพัฒนาซอฟต์แวร์อย่างเป็นลำดับขั้นตอน ตั้งแต่เริ่มคิดว่าจะสร้างระบบอะไร ไปจนถึงการนำระบบไปใช้งานและดูแลหลังส่งงาน โดยกระบวนการนี้ช่วยให้ทีมพัฒนามองเห็นงานทั้งหมดเป็นลำดับขั้นตอน และใครเป็นผู้รับผิดชอบ แม้แต่ละโครงการอาจเลือกวิธีดำเนินงานต่างกัน แต่แนวคิดหลักยังคงเน้นการพัฒนาที่มีระบบที่สามารถตรวจสอบได้

### 1.2 ขั้นตอนของ SDLC

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

### 1.3 Waterfall Model

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

### 1.4 Agile Model

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

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

### 1.5 ความสำคัญของ SDLC ในการพัฒนาซอฟต์แวร์

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

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

## 2. SRS

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

### 2.2 โครงสร้างของเอกสาร SRS

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

        ส่วนสำคัญถัดมาคือ ข้อกำหนดโดยละเอียด ซึ่งประกอบด้วย Functional Requirements, Non-functional Requirements, ข้อกำหนดด้านส่วนติดต่อผู้ใช้ ฮาร์ดแวร์ ซอฟต์แวร์ เครือข่าย และข้อมูลอาจมี Use Case แผนภาพ ตาราง หรือภาคผนวกเพื่อช่วยให้เข้าใจง่ายขึ้น การจัดหัวข้อและรหัสข้อกำหนดอย่างเป็นระเบียบทำให้สามารถอ้างอิง แก้ไข และติดตามผลการทดสอบได้สะดวก

### 2.3 Functional Requirements

        Functional Requirements คือข้อกำหนดที่ระบุพฤติกรรมหรือความสามารถที่ระบบต้องทำได้ โดยมักเกี่ยวข้องกับข้อมูลนำเข้า กระบวนการ และผลลัพธ์ ตัวอย่างเช่น ระบบสมุดรายชื่อต้องสามารถเพิ่มข้อมูลผู้ติดต่อ ค้นหาผู้ติดต่อ แก้ไขข้อมูล ลบข้อมูล และบันทึกข้อมูลลงไฟล์ได้ ข้อกำหนดประเภทนี้ตอบคำถามว่า **ระบบต้องทำอะไร**

        การเขียน Functional Requirements ควรใช้ถ้อยคำที่ชัดเจนและสามารถทดสอบได้ เช่น **เมื่อผู้ใช้กรอกข้อมูลครบและกดปุ่มบันทึก ระบบต้องบันทึกข้อมูลผู้ติดต่อลงในไฟล์** ประโยคเช่น **ระบบควรใช้งานได้ดี** ยังไม่ชัดว่าโปรแกรมต้องทำอะไรและตรวจสอบอ+ย่างไร แต่ละข้อจึงควรมีรหัส เช่น FR-01 และระบุเงื่อนไข ผลลัพธ์ หรือกรณีผิดพลาดที่เกี่ยวข้อง

### 2.4 Non-functional Requirements

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

        Non-functional Requirements ควรเขียนให้วัดผลได้เช่น **ระบบต้องแสดงผลการค้นหาภายใน 2 วินาทีเมื่อมีข้อมูลไม่เกิน 10,000 รายการ** หรือ **ผู้ใช้ต้องเข้าสู่ระบบก่อนเข้าถึงข้อมูลส่วนบุคคล** การเขียนเพียง **ระบบต้องเร็ว** หรือ **ระบบต้องปลอดภัย** นั้นกว้างเกินไปและไม่สามารถตัดสินได้ชัดเจนว่าผ่านการทดสอบหรือไม่ ข้อกำหนดด้านคุณภาพยังมีผลต่อการออกแบบโครงสร้างระบบโดยรวมอย่างมาก

### 2.5 ความสำคัญของ SRS ในโครงการซอฟต์แวร์

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

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

## เอกสารอ้างอิง

Amazon Web Services. (n.d.). *SDLC (วงจรชีวิตของการพัฒนาซอฟต์แวร์) คืออะไร*. https://aws.amazon.com/th/what-is/sdlc/

Foxbith. (2024, February 22). *SDLC คืออะไร? เจาะลึก 6 ขั้นตอนการพัฒนาซอฟต์แวร์ให้มีประสิทธิภาพ*. https://www.foxbith.com/blog/what-is-sdlc

GeeksforGeeks. (2023, September 20). *Software requirement specification (SRS) format*. https://www.geeksforgeeks.org/software-engineering/software-requirement-specification-srs-format/

HOCCO. (2023, August 2). *SRS document เอกสารสำคัญที่ธุรกิจควรมี เมื่อเริ่มต้นใช้ซอฟต์แวร์*. https://hocco.co/blog/what-is-srs-document/

Mahesh, H. (n.d.). *What is a software requirement specification document (SRS)?* testRigor. https://testrigor.com/blog/software-requirement-specification-document/