Software requirement specification ตัวอย่าง

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

อะไรคือ SRS Document

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

ส่วนประกอบสำคัญของ SRS Document มีอะไรบ้าง

- ตัวขับเคลื่อนธุรกิจ

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

- รูปแบบธุรกิจ

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

- ข้อกำหนดด้านการทำงานและระบบ

- กรณีการใช้งานระบบ

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

- ข้อกำหนดทางเทคนิค

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

- คุณภาพของระบบ

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

- ข้อจำกัดและสมมติฐาน

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

- เกณฑ์การยอมรับ

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

โครงสร้างของ SRS Document

1. บทนำ

บทนำจะเป็นตัวอธิบายความหมายของ SRS Document โดยทั่วไป รวมไปถึงขอบเขตสำหรับทีมและโครงสร้าง

1.1. วัตถุประสงค์

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

1.2. กลุ่มเป้าหมาย

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

1.3. การใช้งานที่ตั้งใจไว้

อธิบายว่าทีมว่าจะใช้ SRS ในสถานการณ์ใดบ้าง โดยปกติจะใช้ในกรณีต่อไปนี้

- การออกแบบและระดมสมองคุณสมบัติใหม่

- การวางแผนระยะเวลาโครงการ การดำเนินการ การประมาณราคา

- การประเมินความเสี่ยง

- การติดตามและวัดผลความสำเร็จของทีม

- สถานการณ์ที่ขัดแย้งกัน เมื่อฝ่ายที่เกี่ยวข้องมีวิสัยทัศน์ที่แตกต่างกัน เกี่ยวกับผลิตภัณฑ์ที่ได้รับการดำเนินการอยู่

1.4 ขอบเขต

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

ส่วนที่จำเป็นจะต้องอธิบาย

- ผู้ใช้ทุกประเภทคาดว่าจะมีส่วนร่วมกับระบบ

- ทุกส่วนที่สำคัญของสถาปัตยกรรม

1.5 คำจำกัดความและคำย่อ

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

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

2. คำอธิบายโดยรวม

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

2.1 ความต้องการของผู้ใช้

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

2.2 สมมติฐานและการพึ่งพา

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

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

3. คุณสมบัติและข้อกำหนดของระบบ

ส่วนนี้จะครอบคลุมคุณลักษณะของผลิตภัณฑ์ และเกณฑ์การดำเนินการโดยละเอียด เนื่องจากสองส่วนก่อนหน้านี้กล่าวถึงผลิตภัณฑ์โดยรวมเป็นส่วนใหญ่

3.1 ข้อกำหนดด้านการทำงาน

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

3.2 ข้อกำหนดอินเทอร์เฟซภายนอก

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

ข้อกำหนดอินเทอร์เฟซภายนอกสามารถประกอบด้วย 4 ประเภทขึ้นอยู่กับลักษณะของโปรเจ็กต์ ดังนี้

- ส่วนติดต่อผู้ใช้

- อินเทอร์เฟซซอฟต์แวร์

- อินเทอร์เฟซฮาร์ดแวร์

- อินเตอร์เฟซการสื่อสาร

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

3.3 ความต้องการของระบบ

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

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

3.4 ข้อกำหนดที่ไม่เป็นไปตามข้อกำหนด

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

สรุป

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

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

REF

https://visuresolutions.com/th/requirements-management-traceability-guide/how-write-system-requirement-documents/