การอธิบายความต้องการ

การอธิบายความต้องการมีหลายชื่อให้เรียก อย่างแนวทางการพัฒนาระบบแบบ Object-Orientation เป็นแนวทางพัฒนาระบบบนแนวคิด Use Case Driven หรือ Function-Driven นั่นเอง จึงเรียกความต้องการหลักว่า use case ซึ่งก็คือฟังก์ชั่นนั่นล่ะ แล้วเรียกความต้องการทางคุณภาพว่า non-functional requirement หรือ special requirement หรือ supplimentary requirement ใช้หลักการรวมคือ ‘FURPS+’ (Functionality, Usability, Reliability, Performance, Supportability, และอื่นๆ อีกมากมาย) หรืออย่างในแนวทางพัฒนาระบบแบบ Agile มักเรียกความต้องการว่า use case หรือ user story หรือไม่ก็ใช้คำว่า use case แทนความหมายความต้องการ ส่วนคำว่า user story แทนความหมายการอธิบายความต้องการ

นอกจากนี้ความต้องการในงานพัฒนาซอฟต์แวร์ยังมีตั้งหลายประเภท อาทิ business goal, system feature, functional requirement/use case, non-functional requirement, glossary, system requirement, environment requirement, user requirement ฯลฯ หนำซ้ำบางทีมยังแบ่งระดับความต้องการอีกเป็น high level requirement, detailed requirement เละเทะซับซ้อนยุ่งเหยิงกันไปหมด คำถามที่ผมเจอบ่อยมากคือ ความต้องการนี้เป็นประเภทไหน? ควรจัดอยู่ในเอกสารไหนดี? หรือในหัวข้อไหนดี? โธ่! เอาเวลาไปอธิบายความต้องการให้ดีดีกว่าไหม? ไม่ต้องจัดให้มันมีหลายประเภทนักหรอกครับ คำตอบที่ได้รับกลับมาบ่อยครั้งก็คือ ก็ template (พวก SRS: Software Requirement Specification) มันมีแยกเป็นหัวข้อๆ… วุ้ย ช่างหัว template มัน ไม่ต้องแบ่งแบบนั้นเสมอไปก็ได้ อย่าให้ template มาชี้นำการทำงานจนเกินไป ควรให้ process ชี้นำมากกว่า จะแบ่งความต้องการเป็นกี่ประเภทก็ควรแบ่งให้เหมาะสมกับงาน มาเน้นการอธิบายความต้องการดีกว่าครับ…นะ (ดู ประเภทความต้องการ)

การอธิบายความต้องการมี  2 รูปแบบใหญ่ๆ คือ

  • แบบเรียบง่าย
    เป็นการอธิบายสั้นๆ ใช้ภาษาที่สั้นกระชับ เช่น มีปริมาณไม่เกิน 1-3 บรรทัดต่อ 1 ความต้องการ หรือไม่เกิน 1 สไลด์ใน MS PowerPoint (ใช้ตัวอักษรใหญ่ๆ นะ) หรือ 1 ความต้องการต่อกระดาษ post-it 1 แผ่น หรือ 1/6 ของกระดาษ A4 หรือการพูดบรรยายโดยใช้เวลาอธิบาย 1 ความต้องการสั้นๆ เช่น ไม่เกิน 1-3 นาทีต่อ 1 ความต้องการ (ดู User Story)
  • แบบละเอียด
    เป็นการอธิบายรายละเอียดแบบละเอียดๆ โดยแจกแจ่งเป็นประเด็นย่อยๆ เช่น การอธิบาย functional requirement หรือ use case ก็แบ่งเป็นหัวข้อ ชื่อความต้องการ, รหัสความต้องการ, brief description, pre-condition, post-condition, basic flow, alternative flows, special requirements เป็นต้น (ดู Use Case Specification) และ การอธิบาย non-functional requirement ก็แบ่งเป็นหัวข้อ stimulus, source of stimulus, artifact, environment, response, response measure (ดูการอธิบาย Quality Scenario ใน Non-Functional Requirement)

การนำไปใช้

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

ประยุกต์กฏ Pareto (80/20) และ หลักการบริหารความเสี่ยง
ความต้องการส่วนใหญ่ที่เก็บรวบรวมมาควรอธิบายแบบเรียบง่ายสั้นๆ (50-80%) ส่วนที่เหลือควรอธิบายให้ละเอียดๆ และชัดเจนที่สุด การทำงานด้าน requirement ต้องพอมองความเสี่ยงเป็น หากไม่ชำนาญต้องให้ architect หรือ project manager ช่วย เพื่อระบุว่าความต้องการใดที่สำคัญมากๆ มีความเสี่ยงต่อการพัฒนาและการใช้งานมาก เมื่อระบุเสร็จแล้วก็ใช้การอธิบายแบบละเอียดชัดเจน

เทคนิคเพิ่มเติมในการอธิบายความต้องการ

  • ใช้ภาษาที่ผู้อ่านอ่านแล้วเข้าใจง่าย อย่าใช้ภาษาที่ตัวเองเขียนเองเข้าใจเองคนเดียว
  • การอธิบายที่ดีที่สุด คือ การอธิบายด้วย ‘ปาก’ หรือ การพูดให้ลูกค้าหรือทีมงานฟังนั่นเอง แต่หากกลัวลืม หรือต้องการเก็บเป็นหลักฐาน ก็ค่อยทำเอกสาร
    ผมมักเรียกการทำเอกสารว่า เป็นการทำเพื่อกันลืม และ เพื่อส่งต่อให้คนอื่นมารับผิดชอบดูแลต่อได้ในกรณีที่เราไม่อยู่แล้ว เช่น อาจย้ายงาน ย้ายโครงการ
  • ควรมีทักษะทางภาษาเขียนที่ดี รู้จักเทคนิคการใช้สำนวนต่างๆ ในการอธิบาย เช่น บรรยายโวหาร (บรรยาย) พรรณาโวหาร (บรรยายให้เห็นภาพจินตนาการตามได้) อุปมาโวหาร (ยกตัวอย่างเปรียบเทียบ) สาทกโวหาร (ยกตัวอย่างประกอบ) เทศนาโวหาร (เอา 4 โวหารข้างต้นมาใช้ร่วมกัน)
  • หากพูดก็แล้ว อธิบายเป็นข้อความตั้งยาวเหยียดแล้ว ผู้อ่านก็ยังไม่เข้าใจ ไม่เคลียร์ ก็ควรวาดรูปประกอบ การวาดรูปในระดับงาน requirement ไม่ต้องใช้สัญลักษณ์ด้านไอทีมากก็ได้ โดยเฉพาะการวาดรูปให้ลูกค้าหรือผู้ใช้ดู ควรใช้สัญลักษณ์ที่เป็นรูปธรรม เช่น วาดด้วย Visio ส่วนการวาดรูปให้ทีมพัฒนาดูควรใช้สัญลักษณ์ด้านไอทีเยอะหน่อย เช่น UML, BPMN เพราะจะได้ตีความไปเป็นคลาส โมดูล อินเตอร์เฟส ฯ ต่อได้ง่าย
  • อย่าทำเอกสาร requirement จนเสร็จแล้วค่อยส่งต่อให้ลูกค้าอ่าน หรือให้ทีมอ่าน ให้ทำไปแล้วส่งให้เขาอ่านเรื่อยๆ ผู้อ่านจะได้ช่วยรีวิว หัวข้อไหนไม่เข้าใจไม่เคลียร์เราจะได้อธิบายให้ละเอียดชัดเจนขึ้น พอทำเอกสารเสร็จพวกเขาก็ไม่ต้องอ่านแล้ว จริงไหม? เพราะการสื่อสารที่ดีคือการร่วมกันทำงาน ไม่ใช่ทำเอกสารเสร็จแล้วส่งให้เขาอ่าน จึงเป็นการทำงานกันไปทำเอกสารไป
  • ผู้ที่ไปเก็บความต้องการมาก็กลับมาพูดอธิบายให้ทีมฟัง แล้วให้ทีมจด แล้วนำสิ่งที่จดมาสรุป จัดหมวดหมู่ เรียบเรียง ออกมาเป็นงานอธิบายความต้องการ นี่ก็เป็นอีกเทคนิคหนึ่งในการฝึกทีมเวิร์กและทำเวิร์กช็อปภายในทีม ได้ระดมสมองกันไปทำเอกสารกันไป ทำบ่อยๆ คล่องเมื่อไหร่จะเร็วมาก เอกสารก็ออกมาเร็วมาก
  • จบการอธิบายความต้องการเสร็จ ไม่ต้องถามทีมก็ได้ว่าเข้าใจไหม ให้แต่ละคนแยกย้ายหรือจับกลุ่มกันเขียน test case เบื้องต้นกันเลย หากเขียน test case ได้ครอบคลุมความต้องการดีแสดงว่าเข้าใจ แล้ว test case ยังนำไปใช้ประโยชน์ต่อได้อีก
Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s