#priwreadbooks Software Requirements — กระบวนการพัฒนาข้อกำหนด (Requirements Development)
ชี้แจง ความหมายของ Style ตัวอักษรในบทความ
- ตัวอักษรปกติ = แปลจากหนังสือ Software Requirements, 3rd Edition — Karl E. Wiegers, Joy Beatty
- ตัวอักษรแบบเอียง = เนื้อหาอื่น ใส่เข้าไปเพิ่ม
การพัฒนาข้อกำหนด เกี่ยวข้องกับการ ขุด เซาะ เจาะ หา การวิเคราะห์ การบันทึกข้อมูล และการตรวจสอบความถูกต้อง อย่าคาดหวังที่จะทำกิจกรรมเหล่านี้เป็นลำดับแบบเส้นตรงรอบเดียว ในทางปฏิบัติ กิจกรรมเหล่านี้จะเชื่อมโยง เป็นส่วนเพิ่ม (Incremental) และวนซ้ำ (Iterative) โดยเป็นกระบวนการเปลี่ยนจาก แนวคิดเริ่มต้น ไปสู่ความแม่นยำในการทำความเข้าใจ
(ปรับใช้ในชีวิตจริงตามรูปแบบการทำงานแบบ SCK)
พยายามผลักดัน Verification และ Validation มาอยู่ด้วยกันกับช่วง Elicitation และ Analysis ทำให้ เห็นภาพตรงกัน ใช้วิธีตรวจสอบ ทดสอบรูปแบบเดียวกัน ให้มากที่สุด ก่อนจะไปบันทึกเป็นเอกสาร (Specification) ลดความเข้าใจไม่ตรงกัน หรือ เอ๊ะ ไม่เหมือนที่คุยกันไว้นี่หน่า ให้น้อยลง
หากคุณเป็น BA หรือใครก็ตามที่เกี่ยวข้องกับกระบวนการนี้ คุณจะต้อง
- ถามคำถามลูกค้า ฟังสิ่งที่พวกเขาพูด และดูสิ่งที่พวกเขาทำ (elicitation)
- คุณจะประมวลผลข้อมูลเพื่อทำความเข้าใจ จำแนกเป็นหมวดหมู่ต่างๆ และเชื่อมโยงความต้องการของลูกค้ากับข้อกำหนดซอฟต์แวร์ที่เป็นไปได้ (analysis)
- การวิเคราะห์ของคุณ อาจทำให้คุณตระหนักว่า คุณต้องการข้อกำหนดบางอย่าง ดังนั้นคุณจึงกลับไปหาข้อมูลเพิ่มเติม (elicitation)
- จากนั้น คุณจะจัดโครงสร้างข้อกำหนดที่ได้รับ เป็นข้อความและไดอะแกรม ที่เป็นลายลักษณ์อักษร (specification)
- ในขณะที่เขียนข้อกำหนด (specification) คุณอาจต้องย้อนกลับไปวิเคราะห์เพิ่มเติม (analysis)เพื่อปิดช่องว่างในความรู้ที่มี
- ถัดไป คุณจะขอให้ผู้มีส่วนได้ส่วนเสีย ยืนยันว่า สิ่งที่คุณบันทึกไว้นั้นถูกต้องและครบถ้วน (validation)
- เพื่อไม่ให้มีข้อผิดพลาดใดๆ คุณจะทำทั้งหมดนี้ เพื่อให้ตรงตามข้อกำหนดที่สำคัญที่สุดและทันเวลาที่สุด สำหรับการเริ่มต้นการพัฒนาซอฟต์แวร์
- การตรวจสอบความถูกต้อง (validation) อาจทำให้คุณต้องเขียนข้อกำหนด (specification) ใหม่ ทบทวนกิจกรรมการวิเคราะห์ (analysis) บางอย่าง หรือแม้กระทั่งต้องย้อนกลับและดำเนินการหาข้อมูลเพิ่มเติม (elicitation)
นั่นเลยเป็นที่มา ที่เรา (SCK) พยายามเอา validation มาไว้ตั้งแต่ต้น
- จากนั้นคุณจะไปยังส่วนถัดไปของโครงการและทำทุกอย่างอีกครั้ง กระบวนการทำซ้ำนี้ดำเนินต่อไปตลอดการพัฒนาข้อกำหนด และอาจเป็นเช่นเดียวกับโครงการที่ดำเนินการในรูปแบบของ Agile ที่ถูกดำเนินการตลอดระยะเวลาโครงการทั้งหมด
เนื่องจากความหลากหลายของโครงการพัฒนาซอฟต์แวร์และวัฒนธรรมองค์กร จึงไม่มีแนวทางที่เป็นสูตรเดียวสำหรับข้อกำหนดในการพัฒนา
ภาพด้านบน เสนอ กรอบกระบวนการทำงานสำหรับการพัฒนาข้อกำหนด ที่จะใช้งานได้ พร้อมการปรับเปลี่ยนที่สมเหตุสมผล
สำหรับหลายโครงการ ความต้องการทางธุรกิจหรือโอกาสทางการตลาดเป็นลำดับแรก โดยทั่วไปขั้นตอนเหล่านี้จะดำเนินการตามลำดับตัวเลขโดยประมาณ แต่กระบวนการนี้ ไม่ได้ดำเนินการตามลำดับอย่างเคร่งครัด
โดยทั่วไป ขั้นตอนที่ 1–7 จะดำเนินการเพียงครั้งเดียวในช่วงแรกของโครงการ (แม้ว่าทีมงานจะต้องทบทวนกิจกรรมเหล่านี้ทั้งหมดเป็นระยะ)
ขั้นตอนที่เหลือ จะถูกดำเนินการในแต่ละรุ่นของซอฟต์แวร์ (การอัปเกรดเวอร์ชัน) หรือการพัฒนาซ้ำในแต่ละรอบการทำงาน
กิจกรรมหลายอย่างสามารถทำซ้ำได้ และสามารถผสมผสานกันได้ เช่น คุณสามารถดำเนินการขั้นตอนที่ 8, 9 และ 10 เป็นส่วนเล็กๆ โดยดำเนินการทบทวน (ขั้นตอนที่ 12) หลังจากทำซ้ำแต่ละครั้ง
ลองขยายความจากภาพ ตัวอย่างของกระบวนการพัฒนาซอฟต์แวร์ที่เน้นการเก็บและจัดการความต้องการของผู้ใช้ในรูปแบบเชิงวัฏจักร (Iterative Process) แต่ละขั้นตอนมีดังนี้:
- Define business requirements: ระบุความต้องการทางธุรกิจ เช่น วัตถุประสงค์ของระบบหรือปัญหาทางธุรกิจที่ต้องการแก้ไข
ตัวอย่าง: ต้องการสร้างระบบการจองตั๋วออนไลน์ เพื่อเพิ่มประสิทธิภาพในการขายและบริการลูกค้า (ถ้าให้ดี ใส่ ตัวชี้วัดที่จับต้องได้ลงไปด้วย) - Identify user classes: ระบุประเภทผู้ใช้ที่เกี่ยวข้องในระบบ
ตัวอย่าง: ลูกค้า (ผู้ใช้ระบบจองตั๋ว), เจ้าหน้าที่บริษัท, และแอดมินที่ดูแลระบบ - Identify user representatives: ระบุผู้แทนผู้ใช้ที่สามารถให้ข้อมูลหรือความต้องการได้ชัดเจน
ตัวอย่าง: ตัวแทนจากแผนกบริการลูกค้า และตัวแทนจากฝ่ายไอที - Identify requirements decision makers: ระบุผู้ที่มีอำนาจในการตัดสินใจเกี่ยวกับความต้องการระบบ
ตัวอย่าง: ผู้จัดการโครงการ, เจ้าของธุรกิจ หรือ Product Owner - Plan elicitation: วางแผนการเก็บข้อมูลความต้องการ เช่น การสัมภาษณ์ แบบสอบถาม การทำเวิร์คช็อปร่วมกัน
ตัวอย่าง: จัดประชุมผู้แทนผู้ใช้ เพื่อเก็บข้อมูลความต้องการระบบ - Identify user requirements: ระบุความต้องการของผู้ใช้โดยตรง
ตัวอย่าง: ผู้ใช้ต้องการให้ระบบจองตั๋วสามารถชำระเงินได้หลายวิธี เช่น บัตรเครดิต การโอนเงิน - Prioritize user requirements: จัดลำดับความสำคัญของความต้องการ
ตัวอย่าง: ความต้องการที่สำคัญก่อนคือ การชำระเงินที่รวดเร็วและปลอดภัย ก่อนจะพิจารณาคุณสมบัติอื่นๆ - Flesh out user requirements: เติมเต็มรายละเอียดของความต้องการให้ชัดเจน
ตัวอย่าง: ฟังก์ชันยืนยันการจองตั๋วผ่านอีเมล - Derive functional requirements: เปลี่ยนความต้องการผู้ใช้ให้เป็นความต้องการฟังก์ชันการทำงานของระบบ
ตัวอย่าง: ฟังก์ชันสำหรับตรวจสอบการชำระเงิน และส่งอีเมลยืนยัน - Model the requirements: สร้างโมเดลหรือแบบจำลองของความต้องการ เช่น Use Case Diagram หรือ Activity Diagram หรือ Swimlanes
ตัวอย่าง: สร้างแผนภาพที่แสดงให้เห็นว่าลูกค้าจะจองตั๋วและชำระเงินอย่างไร - Specify nonfunctional requirements: ระบุความต้องการที่ไม่ใช่เชิงฟังก์ชัน เช่น ประสิทธิภาพหรือความปลอดภัย
ตัวอย่าง: ระบบต้องสามารถรองรับผู้ใช้ได้ 1,000 คนพร้อมกันใน 1 นาที และมีความปลอดภัยสูง (ระบุเพิ่มด้วยว่าสูงขนาดไหนได้จะดีมาก) - Review requirements: ทบทวนความต้องการกับทีมและผู้ใช้เพื่อความถูกต้อง
ตัวอย่าง: จัดประชุมรีวิวความต้องการกับผู้แทนผู้ใช้เพื่อยืนยันความถูกต้อง - Develop prototypes: สร้างต้นแบบของระบบเพื่อให้ผู้ใช้ทดลองและให้ฟีดแบค
ตัวอย่าง: สร้างต้นแบบหน้าจอการจองตั๋วเพื่อให้ผู้ใช้ทดสอบการใช้งาน - Develop or evolve architecture: ออกแบบหรือพัฒนาสถาปัตยกรรมของระบบเพื่อรองรับความต้องการ
ตัวอย่าง: ออกแบบระบบ backend และ APIs สำหรับจัดการข้อมูลการจองและการชำระเงิน - Allocate requirements to components: จัดสรรความต้องการไปยังส่วนต่างๆ ของระบบ
ตัวอย่าง: ความต้องการเรื่องการชำระเงิน ถูกจัดสรรให้ระบบการเงิน - Develop tests from requirements: สร้างกรณีทดสอบจากความต้องการ
ตัวอย่าง: สร้างกรณีทดสอบสำหรับตรวจสอบว่าการชำระเงินและการส่งอีเมลยืนยันทำงานถูกต้อง (ระบุค่าให้ได้ว่า ถูกต้อง เป็นเช่นไร) - Validate user requirements, functional requirements, nonfunctional requirements, analysis models, and prototypes: ตรวจสอบความถูกต้องของความต้องการทุกประเภท ผ่านการทดสอบและต้นแบบที่ถูกนำเสนอ
ตัวอย่าง: ผู้ใช้ยืนยันว่าฟังก์ชันทั้งหมดทำงานตามที่กำหนดในต้นแบบ
Repeat for iteration: ทำซ้ำกระบวนการนี้ในแต่ละ iteration เพื่อนำ feedback ที่ได้รับมา ไปปรับปรุงระบบให้ดีขึ้น
สาขาวิชาที่ห้าของวิศวกรรมความต้องการ (requirements engineering) คือการจัดการความต้องการ (requirements management) การจัดการความต้องการครอบคลุมแนวปฏิบัติที่ช่วยให้คุณจัดการกับความต้องการหลังจากที่คุณมีข้อกำหนดเหล่านั้นแล้ว แนวทางปฏิบัติเหล่านี้รวมถึงการควบคุมเวอร์ชันและ baseline การควบคุมการเปลี่ยนแปลง (change control) สถานะข้อกำหนดในการติดตาม (tracking status) และข้อกำหนดในการติดตามไปยังองค์ประกอบอื่นๆ ของระบบ (tracing) การจัดการความต้องการจะเกิดขึ้นตลอดระยะเวลาของโครงการ
ในการทำงานแบบ Waterfall หรือ Sequential คุณวางแผนที่จะดำเนินการเผยแพร่หลักเพียงครั้งเดียวเท่านั้น ดังนั้นความพยายามในการพัฒนาข้อกำหนดส่วนใหญ่จึงได้รับการจัดสรรเวลาในช่วงต้น (เส้นทึบ) แนวทางนี้ยังคงใช้กับบางโครงการและเหมาะสำหรับบางโครงการ
แม้ว่าคุณจะวางแผนแบบดั้งเดิมในช่วงเริ่มต้นของโครงการซึ่งนำไปสู่การออกแบบ คุณก็วางใจได้ว่า จะต้องพัฒนาข้อกำหนดเพิ่มเติมบางอย่างตลอดทั้งโครงการอยู่ดี
ส่วนโครงการที่ดำเนินงานแบบ Iterative และ Incremental จะตั้งเป้าหมายที่ จะเปิดตัวฟังก์ชันการทำงานใหม่ทุกๆ สองสามสัปดาห์ พวกเขาจะมีความพยายามในการพัฒนาข้อกำหนดบ่อยครั้ง แต่มีขนาดเล็ก (เส้นประ)
แนวทางนี้ คุณต้องเรียนรู้เรื่องราวให้เพียงพอ เพื่อที่คุณจะได้ประเมินความพยายามในการพัฒนาและจัดลำดับความสำคัญได้ การจัดลำดับความสำคัญของข้อกำหนดผู้ใช้เหล่านี้ช่วยให้คุณสามารถกำหนดได้ว่า ข้อกำหนดใดที่จะถูกจัดสรรให้กับรอบการทำงานใด ข้อกำหนดที่ได้รับการจัดสรรเหล่านั้น สามารถเพิ่มรายละเอียดได้ในเวลาที่เหมาะสมสำหรับแต่ละรอบการพัฒนา
ไม่ว่าโครงการของคุณจะใช้วิธีการพัฒนาแบบใด คุณควรถามตัวเองว่าแต่ละรุ่นของซอฟต์แวร์ หรือการทำซ้ำกิจกรรมใด จะเพิ่มมูลค่าและลดความเสี่ยง
หลังจากที่คุณเสร็จสิ้นขั้นตอนที่ 17 (Validate user requirements, functional requirements, nonfunctional requirements, analysis models, and prototypes) สำหรับส่วนใดส่วนหนึ่งของข้อกำหนดแล้ว คุณก็พร้อมที่จะเริ่มสร้างส่วนนั้นของระบบ
จากนั้น ทำซ้ำขั้นตอนที่ 8 ถึง 17 กับข้อกำหนดของผู้ใช้ชุดถัดไป ซึ่งจะวางรากฐานสำหรับการเปิดตัวหรือการเพิ่มความสามารถของระบบในภายหลัง
ในหนังสือมีตัวอย่าง Good Practices ของแต่ละขั้นตอนด้วยนะ ถ้าไม่ขี้เกียจจะมา อ่าน แปล และเขียนต่อ 5555
