Software Requirements ที่ดี หน้าตาเป็นยังไง (Software The Series)

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

  1. ก่อนพัฒนา คือส่วนของการเขียนความต้องของซอฟต์แวร์ (Software Requirements)
  2. ช่วงพัฒนา คือส่วนของการออกแบบ และพัฒนา (Design & Development)
  3. หลังพัฒนา คือส่วนของการทดสอบ และ บำรุงรักษา (Testing & Maintanance)

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

 

ระดับความลึกของ Requirements (ควรละเอียดแค่ไหน)

ก่อนอื่นต้องบอกก่อน Requirement Document เป็นเอกสารที่เอาไว้ยืนยันระหว่าง ลูกค้า/ผู้ใช้(Customers/Users) กับทีมพัฒนา(Development Team) ดังนั้นการวัดความรู้ของผู้อ่านเอกสารจึงสำคัญมาก ถ้าจะให้แบ่งเป็นรูปแบบน่าจะได้ประมาณนี้

นิยามให้ตรงกันก่อน:
ความรู้ – คือรู้เกี่ยวกับธุรกิจ สิ่งที่ต้องการ ความเชื่อมโยง กระบวนการทางธุรกิจ วิธี ขั้นตอนการทำงาน
รู้น้อย ฝั่งลูกค้า – คือ ยังใหม่กับธุรกิจ กับระบบที่ต้องการจะทำ หรือยังไม่รู้ว่าต้องการอะไร
รู้มาก ฝั่งลูกค้า – คือ อยู่ในธุรกิจมานาน รู้แล้วว่าต้องการอะไร เพียงแค่ขาดคนมาทำให้เป็นจริง
รู้น้อย ฝั่งทีมพัฒนา – คือ ใหม่กับ business domain ของลูกค้า ไม่คุ้นเคยกับกระบวนการ ใหม่ในด้านเทคโนโลยี และการพัฒนา
รู้มาก ฝั่งทีมพัฒนา – คือ มีทีมพัฒนาที่มีประสบการณ์ กับระบบงานนั้นๆ (อย่างน้อย 3-5 ปี ขึ้นไป) เชี่ยวชาญในเทคโนโลยีที่ใช้ และจะพัฒนา

  • ลูกค้า-รู้น้อย  ทีมพัฒนา-รู้มาก  ควรเน้นเอกสารให้อ่านง่ายๆ ไม่ลงเทคนิคเยอะ (เพราะลงลึกไป เค้าก็อ่านไม่รู้เรื่อง) เน้นภาพรวมของระบบและให้เข้าใจว่าลูกค้าจะได้อะไร การทำงานเป็นอย่างไร ฝั่งทีมพัฒนาจะเป็นพวกมองตาก็รู้ใจ อาจใช้ wireframe หรือแค่คุยกันก็รู้ว่าต้องทำอะไรแล้ว ส่วนมากจะเกิดจากลูกค้าที่มีทุน อยากสร้างของจากไอเดียที่เพิ่งปิ้งขึ้นมา (และอาจจะไม่ได้เกิดจาก pain จริงๆ) ส่วนใหญ่จะเป็นการสร้างระบบใหม่
  • ลูกค้า-รู้มาก  ทีมพัฒนา-รู้น้อย เอกสารจะมีความละเอียดในเชิงธุรกิจ และฟังก์ชันการทำงาน และรายละเอียดเงื่อนไขยิบย่อย ให้ครบ จำเป็นต้องได้ SA ที่เก็บงานที่ละเอียดและเข้าใจธุรกิจเป็นอย่างดี แต่ต้องระวัง เพราะอันนี้ลูกค้าจัดเต็ม ถ้ารับมาหมดโดยไม่กรอง จะหนักทีมพัฒนา และอาจจะเป็นต้องมีเอกสาร Program Spec เสริมพร้อมกับมีการคุย กำกับงานที่ถึ่ขึ้น เพื่อไม่ให้เข้าใจกันคลาดเคลื่อน
  • ลูกค้า-รู้มาก ทีมพัฒนา-รู้มาก เน้นเอกสารที่กระชับ ลงถึงตัวเนื้องาน ต้องการอะไร เน้นส่วนที่เป็นสาระสำคัญและนิยามพวกศัพท์เฉพาะให้เข้าใจตรงกัน แบบนี้งานจะเสร็จเร็วมาก บางครั้งอาจเป็นลักษณะของการทำ เอกสารเพื่อส่งต่อให้ทีมพัฒนาที่เป็นมืออาชีพ ดังนั้นเรื่องมาตรฐานการและรูปแบบการเชื่อมต่อ เพราะลูกค้าอาจมีทีมพัฒนาด้วยบางส่วน เช่นทีมเราทำ front-end ส่วน ทีมไอทีของลูกค้าทำส่วนของ back-end หรืออาจเป็นอีกทีมที่ถูกว่าจ้างมา
  • ลูกค้า-รู้น้อย ทีมพัฒนา-รู้น้อย สิ่งนี้ต้องพยายามหลีกเลี่ยง มักเกิดกับบริษัทซอฟต์แวร์เปิดใหม่ ต้องได้ PM กับ SA มือดีจริงๆ ถึงจะเอาอยู่ คอยตบงานให้อยู่ใน scope กับต้องเร่งพัฒนาทีมให้ความรู้ทั้งวิธีทำงานร่วมกัน เทคนิค เทคโนโลยีที่ใช้ เรียกได้ว่าเหนื่อยสุดๆ แต่ถ้าผ่านไปได้ ทีมก็จะพัฒนาขึ้น (หรือไม่ก็ปิดบริษัทในที่สุด)

screen-shot-2562-08-04-at-14-17-30

วิธีการให้ได้มาซึ่ง Requirements

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

  1. คุยเรื่อง Vision, Mission และที่มาที่ไปของโครงการ ให้ชัดเจนก่อน ว่าจะสร้างซอฟต์แวร์นี้เพื่ออะไร จะได้ไม่หลงประเด็น ไม่หลุด scope อาจจะได้ concept คร่าวๆ ระบบเก่าเป็นยังไง ระบบใหม่ที่ต้องการเป็นแบบไหน ไว้มาร่างภาพที่ไว้คุยกันในขั้นตอนต่อไป เช่น ระบบควรทำอะไรได้บ้าง ผู้ใช้เป็นใคร ใครใช้อะไรได้บ้าง (อาจจะใช้ User Story ในการเล่าเรื่อง) ใช้เวลาคุยประมาณ 30 นาที – 1 ชม. สำหรับระบบขนาดกลาง (ควรเก็บความคาดหวังพื้นฐานของระบบด้วย เช่น รองรับกี่ภาษา ต้องมีเลือกธีมได้ด้วยรึเปล่า ระดับในการรักษาความปลอดภัย platform ที่ต้องการรองรับ เป็นต้น)
  2. ขึ้น Model ด้วย Use Case แล้วโยงเส้น ระหว่าง Use Case กับ Actor เพื่อสร้างความเข้าใจที่ตรงกันก่อน และเก็บตกส่วนที่อาจขาดหายไป (ตรงนี้ ต้องการประสบการณ์ของคนเก็บข้อมูล ต้องรู้พื้นฐานของธุรกิจของลูกค้า หรือของระบบที่จะทำ จะทำให้ตั้งคำถามได้ตรงประเด็น)
  3. สร้าง Flow สำหรับอธิบายงานที่จะต้องทำความเข้าใจให้ตรงกัน โดยสามารถเลือกใช้ Activity, Sequence, หรือ State Diagram ในการอธิบายความเข้าใจ
  4. เมื่อเงื่อนไขทุกอย่างชัดเจน ค่อยส่งให้ทีมปั้น Wireframe เพื่อเอาไว้ confirm ความเข้าใจระหว่างผู้ใช้ และเติมเต็มในด้านของ Ux/Ui
  5. เก็บตกในส่วนของการรับส่งข้อมูล และข้อมูลทางเทคนิค เช่นรูปแบบของ JSON Schema ที่ใช้ในการรับส่งข้อมูล. Protocol ที่ใช้ การเชื่อมต่อกับระบบอื่น ฐานข้อมูล Single Sign-On , Payment Gateway, SMS Gateway, Mailer
  6. รวมรวม เรียบเรียง เพื่อเขียนเป็น เอกสารความต้องการ โดยควรคุยตกลงเรื่อง ระดับความลึก (Level of Detail) ของ Requiremnt Document เมื่อเข้าใจตรงกันแล้วก็ลุยได้เลย (ตรงนี้ เมื่อข้อมูลและเงื่อนไขทุกอย่างครบ จะใช้เวลาน้อยมากในการสร้างเอกสาร …ถ้าให้แนะนำคือ ควรสร้าง Template ไว้สำหรับทีมงานด้วย)

เทคนิคการจัดการกับความเปลี่ยนแปลง

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

  1. แบ่งงานออกเป็น Phase หรือ เป็น Release โดยกำหนดให้ชัดเจนว่า จบงานเฟสนี้ จะได้ผลลัพธ์ อะไรบ้าง ควรเก็บให้ครบถ้วนที่สุด ส่วนของที่งอกมาภายหลัง ก็ให้อยู่ในเฟสถัดไปแทน แบบนี้ win-win ทั้งลูกค้า ทั้งทีมพัฒนา
  2. จัดทำ Requirement Dependency โยงความสัมพันธ์ระหว่าง Requirement แต่ละก้อน และกำหนดระดับความสำคัญ เพื่อให้สามารถวิเคราะห์ได้ ว่าเมื่อมีการขอแก้ไข หรือขอเพิ่มตรงนี้แล้ว จะไปกระทบกับตรงไหนอีกบ้าง ทำให้สามารถวิเคราะห์ Impact และความเสี่ยงต่อโครงการได้โดยง่าย
  3. ซอยรอบของการส่งงานให้ลูกค้าได้เห็นของ และ comment งาน (เหมือนกับการทำ UAT ย่อย) และให้ user ได้เห็นพัฒนาการของระบบโดยตลอด (อาจใช้เทคนิค Agile หรือการแบ่ง Sprint เข้ามาช่วย) เมื่อเกิด Small Change และทำการ fixed issue ตั้งแต่แรกๆแล้ว โอกาศที่จะเกิด Big Change ประเภทเซอไพรซ์ ก็จะน้อยมาก
  4. คาดการณ์ล่วงหน้า ในทีมพัฒrาที่มีประสบการณ์ ย่อมสามารถคาดการณ์ฟีเจอร์ต่างๆ ที่จะเกิดขึ้นในอนาคตได้ล่วงหน้า เช่น ส่วนที่เกี่ยวกับการเปลี่ยนภาษา หรือเพิ่มภาษาใหม่ในระบบ การทำให้รองรับหน้าจอหลายขนาด หรือการรองรับการทำงานบน cloud ซึ่งถ้าสามารถทำสิ่งเหล่านี้ไปก่อนได้ แล้วปิด feature ไว้ก่อน เมื่อลูกค้าต้องการ ค่อยทำการเปิด feature ให้ใช้งาน ก็จะลดเวลาในการมาแก้เพิ่มทีหลังได้ (บ้านที่วางโครงไว้ต่อชั้นสอง กับบ้านที่ไม่ได้เตรียมการไว้ก่อน มีความแตกต่างกันอย่างมาก ทั้งเวลาในการรื้อถอน สร้างเพิ่ม ความเชื่อมโยงในระดับโครงสร้าง)

มาพัฒนา Requirements Template ไว้ใช้งานกันเถอะ แล้วชีวิตจะดี

จะดีกว่ามั้ย ถ้าการสร้างเอกสาร Requirement แต่ละครั้ง เหมือนกับการเล่นเติมคำ?  โดยที่มีโครงร่างสำคัญที่จำเป็นรอไว้แล้ว ตามหลักการของ CMMI หรือ ISO การพัฒนาและปรับปรุงกระบวนการถือเป็นเรื่องสำคัญ การสร้างเอกสาร Template ถือว่าเป็นอีกส่วนหนึ่งที่จะช่วยให้กระบวนการในการทำงาน มีความชัดเจนมากขึ้น ลดความซ้ำซ้อนในการทำงาน โดยตอนเริ่มต้นอาจอ้างอิงจาก มาตรฐานเช่น. IEEe 830-1998 IEEE Receommended Practice of Software Requiements. โดย Template ที่ดีจะต้องมีสิ่งเหล่านี้

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

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

สรุป หัวใจของ Requiremnts

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

*** บทความนี้ เขียนจากสิ่งที่เห็น และเป็นไป ในงานที่เจอและผ่านมา ทั้งงานจริงที่เจ็บจริง ทั้งการสอนที่เจอกับนักศึกษาที่เป็นมือใหม่ หวังว่าน่าจะพอมีประโยชน์ สำหรับคนที่มักมีการตั้งคำถามกับการทำ Requirement Document …ขอบคุณครับ ***

ติดตามข้อมูลผ่าน FanPage เข้าไปกด Like ที่: https://www.facebook.com/AjBeeMePage

กับฝากติดตาม FanPage สาขาวิศวกรรมซอฟต์แวร์ @ MFU ที่ https://www.facebook.com/sitsemfu/