Functional Specification พิมพ์เขียวแห่งการสร้างซอฟต์แวร์

ผมเชื่อว่านักพัฒนาซอฟต์แวร์หลาย ๆ คน ทั้งที่กำลังศึกษาอยู่และกำลังทำงานอยู่ หลาย ๆ คนคงจะมีลักษณะร่วมกันอย่างนึงนั่นก็คือ ไม่ชอบการทำเอกสาร ใช่มั้ยครับ?

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

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

ปัญหามันมาปูดตอนที่เมื่อมีคนเข้ามาเรียบร้อยแล้ว ผมต้องสลัดทักษะทางเทคนิคออกไปครึ่งหนึ่งครับ เพื่อไปเรียนรู้ทักษะทางระบบแทน ซึ่งไม่มีใครสอนเลยว้อยยยยยยยยยยย ทำไงดีเนี่ย??? ก็ต้องหัดกันไปครับ

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

“พี่ไท้ครับ มีวิธีไหนบ้างมั้ยครับที่ผมจะเข้าใจซอฟต์แวร์ของพี่ไท้ โดยไม่ต้องไล่ซอร์สโค้ดของพี่ไท้อ่ะครับ?”

“พี่ไท้ครับ ซอฟต์แวร์ของพี่ไท้รับเข้าข้อมูลหลายทาง แถมแสดงผลหลายรูปแบบด้วย พี่พอจะบอกผมได้มั้ยครับ ว่ามันรับเข้า ส่งออกข้อมูลยังไงบ้าง?”

“พี่ไท้ ซอฟต์แวร์ของพี่ไท้มันต้องปรับแต่ง ODBC ใช่มั้ยครับ แล้วต้องปรับแต่งไงบ้างล่ะครับเนี่ย แถมซอฟต์แวร์ของพี่มีการยิง Message TCP/IP Socket ไปหาซอฟต์แวร์ตัวอื่นด้วย มันมีจังหวะการทำยังไงเหรอครับ ผม Debug ลำบากมากเลย”

“เฮ้ย เพ่ไท้ ว้อยยยยยยยย ซอฟต์แวร์เพ่มีการเข้ารหัสด้วย แล้วผมจะรู้มั้ยเนี่ย ว่ากลไกเข้ารหัสถอดรหัสของเพ่มันทำงายยยยยยยล่ะเนี่ย หา????????”

เป็นไงครับ เจอเข้าไปแบบนี้ อึ้งกิมกี่ไปเลย เห็นมั้ยครับ ว่าปัญหาที่เกิดมันเกิดจากสิ่งดังต่อไปนี้ครับ

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

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

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

เอ้อ แล้ว Functional Specification ควรประกอบไปด้วยอะไรบ้างล่ะ? อาจจะมีคนเริ่มจะถามแล้ว ซึ่งจริง ๆ มันควรประกอบไปด้วยรายละเอียดตามลำดับขั้นดังนี้ครับ

1. ส่วนปกหน้า ใช้สำหรับบอกว่า เอกสารนี้อธิบายระบบอะไร?, ใครเป็นคนทำเอกสารนี้, เอกสารนี้เป็นรุ่นที่เท่าไหร่, เอกสารนี้สร้างขึ้นวันที่และเวลาใด, ผู้เกี่ยวข้องกับระบบนี้ประกอบไปด้วยหน่วยงานใดบ้าง เป็นต้น
2. ส่วนอารัมภบท ส่วนนี้ก็เล่าถึงความเป็นมาเป็นไปครับ ว่าเกิดอะไรขึ้นหนอ มีความจำเป็นอะไร ทำไมต้องสร้างซอฟต์แวร์สำหรับระบบนี้ขึ้นมา อารัมภบทถือว่าเป็นหัวใจครับ เพราะเป็นการอธิบายถึงความเป็นจริง และความจำเป็น ยิ่งมีรูปภาพพวก Context Diagram อยู่ในนั้นด้วยยิ่งดีครับ
3. ส่วนข้อมูลนำเข้า ใช้อธิบายว่าข้อมูลอะไรที่จะเข้ามาในซอฟต์แวร์ของเราครับ ถ้ามาเป็น Text File ก็ต้องบอกครับว่าเรคคอร์ดนึงประกอบไปด้วยกี่ฟิลด์ และแต่ล่ะฟิลด์เป็นประเภทอะไรและขนาดเป็นเท่าไหร่ ซึ่งถ้ามาเป็น Text File ขอแนะนำให้ทำเป็นตารางครับ จะเข้าใจได้ดีมาก, แต่ถ้าให้ผู้ใช้กรอกข้อมูลเข้า ก็ต้องบอกครับ ว่ากรอกอะไรเข้ามาบ้าง เป็นข้อมูลประเภทอะไร และขนาดเท่าไหร่, และถ้ามาเป็น Message แล้วส่งมาทาง TCP/IP Socket ก็ต้องบอกครับ ว่ากำหนดคุณสมบัติของ Message ยังไงบ้าง
4. ส่วนประมวลผล ส่วนนี้เป็นส่วนที่นักพัฒนาซอฟต์แวร์เข้าใจผิดครับ คิดว่าเป็นการบรรจุโค้ดของโปรแกรมเข้าไปเลย หรือไม่ก็ต้องมาทำ PsedoCode ซึ่งในความเป็นจริงไม่ต้องหรอกครับ แค่อธิบายด้วยใจความอย่างละเอียดเป็นภาษาชาวบ้านเนี่ยแหล่ะครับ พร้อมทั้งวาดภาพประกอบจำพวก FlowChart ได้ก็ดี
5. ส่วนผลลัพท์ เป็นส่วนที่อธิบายครับว่าผลลัพท์เราจะแสดงผลที่หน้าจอ หรือแสดงเป็นรายงาน หรือส่งออกมาเป็น Message TCP/IP Socket หรือส่งเป็น Stream ฝากไว้ใน Virtual Memory เพื่อให้ซอฟต์แวร์อื่นทำงานต่อไป ส่วนนี้ก็สำคัญครับ ควรบอกให้ละเอียด เช่น ถ้าแสดงผลที่หน้าจอก็ต้องบอกครับว่าสำหรับแสดงผลที่ความละเอียดเท่าไหร่ แล้วฟิลด์แต่ล่ะฟิลด์ที่แสดงผล ได้มาจากฟิลด์ชื่ออะไรบ้างตอนประมวลผล หรือถ้าเป็นรายงานก็ต้องบอกครับว่าเป็นแนวนอน หรือ แนวตั้ง เป็นแบบฟอร์ม หรือพิมพ์ออกกระดาษต่อเนื่อง, มี Header หรือ Footer หรือเปล่า แล้วมี Sub Total แต่ล่ะหน้ามั้ย เป็นต้น
6. ส่วนที่ต้องเตรียมมาก่อน เป็นส่วนที่อธิบายว่าซอฟต์แวร์ของเราตามเอกสารนี้จะทำงานไม่ได้เลย ถ้าไม่ได้เตรียมอย่างอื่นมาก่อนบ้าง อย่างอื่นที่ว่าอาจจะยกตัวอย่างเช่น ระบบฐานข้อมูล, ระบบเครือข่าย, ตารางเทียบค่า หรือระบบอื่น ๆ ที่ต้องส่งค่ามาให้ เป็นต้น
7. ส่วนอธิบายข้อจำกัด ผมจะใช้ส่วนนี้เพื่ออธิบายครับ ว่าซอฟต์แวร์ที่ถูกสร้างขึ้นโดยเอกสารฉบับนี้จะเกิดปัญหาอะไรขึ้นบ้าง อย่าสับสนกับ Troubleshooting นะครับ เพราะส่วนนี้แค่บอกข้อจำกัด ไม่ได้บอกว่าเกิดข้อจำกัดแล้วจะแก้ไงบ้าง ยกตัวอย่างเช่น ซอฟต์แวร์จะทำงานไม่ได้หากมีข้อมูลเกิน 5,000 เรคคอร์ด หรือ ซอฟต์แวร์จะทำงานด้วยความเร็วไม่เกิน 5 รายการต่อหนึ่งวินาทีเป็นต้น

จะเห็นนะครับว่าการทำเอกสาร Functional Specification เนี่ยมันวุ่นวายและรายละเอียดเยอะมาก และถ้าระบบหรือซอฟต์แวร์ดังกล่าว ต้องมีการเปลี่ยนแปลงบ่อย ๆ ด้วย ก็จะต้องมาหมั่นแก้ไขให้มันทันสมัยเสมอ ๆ ครับ และต้องไม่ลืมที่จะก๊อปปี้มันไว้เป็นรุ่น ๆ ด้วย เผื่อว่าเราอาจจะต้องย้อนรุ่นเมื่อไหร่ก็ได้

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

Functional Specification คือคำตอบครับ