Use Case Specification

การอธิบาย functional requirement แบบละเอียด แนะนำรูปแบบการอธิบายแบบ ‘Use Case Specification’ หรือ บ้างก็เรียกว่า ‘Use Case Description’ เนื่องจากมีการแบ่งประเด็นเป็นหัวข้อๆ ชัดเจน ทำให้เราไม่ต้องการอธิบายเป็นข้อความยาวเหยียดเป็นเรียงความ ทำให้อ่านยากและจับประเด็นยาก

หัวข้อที่ควรอธิบายใน Use Case Specification มีดังนี้

  • ชื่อ หมายถึง ชื่อ use case ซึ่งควรใช้คำหรือข้อความสั้นๆ แล้วขึ้นต้นด้วยคำกริยา เพราะเวลาอ่านความต้องการ มักเริ่มอ่านจากไคลเอ็นต์หรือผู้ใช้มาที่ use case เช่น บุคคลทั่วไปสมัครสมาชิกทางอินเทอร์เน็ต
  • รหัส หมายถึง รหัส use case เนื่องจากทุกความต้องการและทุกประเภทควรมีรหัส ซึ่งควรขึ้นต้นด้วยอักษรย่อประเภทความต้องการ หรือขึ้นต้นด้วยรหัสระบบ แล้วปิดท้ายสุดด้วยลำดับตัวเลขของความต้องการ
  • Brief Description หมายถึง ข้อความบรรยายความต้องการสั้นๆ ไม่ควรเกิน 3 บรรทัด
  • Flow of Events หมายถึง ขั้นตอนที่ไคลเอ็นต์หรือผู้ใช้กระทำกับระบบ ย้ำนะครับว่าเป็นขั้นตอนที่ไคลเอ็นต์หรือผู้ใช้ใช้ระบบ ให้อธิบายในมุมว่าเขามาใช้ระบบ ไม่ใช่อธิบายในมุมระบบทำอะไรให้เขานะ เพราะเรากำลังอธิบายความต้องการ ซึ่งเป็นกิจกรรมในงาน requirement ที่เน้นที่ปัญหาและความต้องการ เพราะหากเผลอไปอธิบายในมุมระบบทำอะไรให้ไคลเอ็นต์หรือผู้ใช้ แสดงว่าสมาธิคุณหลุดไปคิดถึงโซลูชั่นแล้ว และนั่นมันคืองาน system analysis เพราะการคิดถึงระบบว่าจะทำอะไรมันคือการเข้าสู่งาน system analysis แล้ว และหากยิ่งถลำลึกอาจยิ่งเผลอหลุดลึกเข้าไปถึง system design โดยไม่รู้ตัว กลายเป็นว่ากำลังเขียนอธิบายความต้องการและโซลูชั่นปนกัน กลายเป็นการล็อกสเป๊กโซลูชั่นไปโดยไม่รู้ตัวFlow of Events มี 2 ประเภท ได้แก่ Basic Flow บางทีก็เรียกว่า Default Flow หรือ Main Flow หรือ Main Course (หยั่งกะอาหารแน่ะ) หรือ Success Flow และ  Alternative Flow บางทีก็เรียก Exceptional Flowการอธิบาย Flow of Events สามารถอธิบายบรรยายเป็นขั้นตอนก็ได้ หรือวาดเป็นรูป business process หรือ flow chart ก็ได้ แนะนำให้วาดด้วยไดอะแกรม BPMN (Business Model Notation) หรือ UML Activity Diagram เพราะละเอียด มีสัญลักษณ์ให้เลือกใช้หลากหลาย และได้มาตรฐาน

  • Basic Flow หมายถึง โฟลว์หลักหรือขั้นตอนหลักที่ไคลเอ็นต์หรือผู้ใช้เข้ามาใช้ระบบ โดยไม่มี error เกิดขึ้นเลย และ ทำทุกขั้นตอนผ่านด้วยดีไม่มีติดเงื่อนไข busines rule ใดๆ เลย
    เช่น การถอนเงินที่ตู้ ATM มีขั้นตอนหลักๆ ได้แก่ 1) เสียบบัตร 2) กดรหัส  3) เลือกเมนู 4) เลือกประเภทบัญชี 5) กดจำนวนเงิน 6) รับเงินและบัตร
  • Alternative Flow(s) หมายถึง โฟลว์ที่ไม่เป็นไปตาม Basic Flow ซึ่งเกิดได้จาก 2 สาเหตุ ได้แก่ เกิดจากผิดเงื่อนไขใน Basic Flow หรือ เกิด error ใน Basic Flow สำหรับ use case ใดจะมี Alternative Flow หรือไม่มีก็ได้ และสามารถมีได้หลายโฟลว์
    เช่น เลือกเมนูถอนเงินผิดเป็นเลือกเมนูดูยอดคงเหลือ โฟลว์เลยเปลี่ยนไปหน้าจอแสดงยอดเงินคงเหลือ
  • Pre-Condition หมายถึง action หรือ use case ที่ไคลเอ็นต์หรือผู้ใช้ต้องทำก่อนจะมาทำ use case นี้ หรือระบุเป็นเงื่อนไขก็ได้ แต่หากไม่ชำนาญระวังอย่าระบุเงื่อนไขมากเกินไป ให้เน้นที่ action หรือ use case ที่ต้องทำก่อนมาทำ use case นี้ดีกว่า เพราะจะทำให้คุมโฟลว์ภาพรวมได้ดี
    เช่น ต้องมีบัตร ATM ก่อน จึงจะถอนเงินที่ตู้ ATM ได้
  • Post-Condition หมายถึง action หรือ use case ที่ไคลเอ็นต์หรือผู้ใช้ต้องทำหลังจากทำ use case นี้เสร็จแล้ว หรือระบุเป็นเงื่อนไขก็ได้ แต่หากไม่ชำนาญระวังอย่าระบุเงื่อนไขมากเกินไป ให้เน้นที่ action หรือ use case ที่ต้องทำหลังทำ use case นี้ดีกว่า เพราะจะทำให้คุมโฟลว์ภาพรวมได้ดี
    เช่น ถอนเงินเสร็จต้องเลือกว่าจะรับใบสลิปหรือไม่รับ
  • Special Requirements หมายถึง non-functional requirement ที่เฉพาะเจาะจงกับฟังก์ชั่นหรือ use case นี้เท่านั้น
    เช่น หน้าจอกดเงินต้องใช้ง่าย การถอนเงินที่ตู้ ATM ต้องมีความปลอดภัย ต้องทำงานรวดเร็ว
  • Business Rules หมายถึง เงื่อนไขหรือตรรกะ คำว่า ‘business rule’ เป็นคำที่นิยมใช้ในทางธุรกิจ ในไอทีอาจคุ้นกับคำว่า ‘business logic’ มากกว่า ซึ่งทั้ง 2 คำก็มีความหมายเหมือนๆ กัน ใช้แทนกันได้ แต่ในงาน requirement นิยมใช้คำว่า business rule มากกว่า
    เช่น กดเงินตั้งแต่หลักร้อยขึ้นไป ห้ามถอนเงินเกินจากยอดคงเหลือ กดรหัสบัตรให้ถูก

ข้อสำคัญในการอธิบาย functional requirement / use case

  • อย่าอธิบายเกี่ยวกับหน้าจอ หรือใช้คำที่เฉพาะเจาะจงกับหน้าจอจนเกินไป เพราะหากรายละเอียดบนหน้าจอเปลี่ยน จะทำให้ต้องตามแก้เอกสารความต้องการบ่อยตาม
  • ใช้ข้อความสั้นกระชับ อย่าบรรยายน้ำท่วมทุ่ง
  • แยก business rule ออกมาจากข้อความอธิบายให้ชัดเจน เพราะมีประโยชน์ต่องานออกแบบ เขียนโปรแกรม ทดสอบระบบ มากๆ
  • ชื่อฟังก์ชั่นหรือ use case ควรใช้คำหรือข้อความสั้นๆ เจอมาหลายที่เล่นซัดเป็นประโยคเลย เพราะสั้นๆ จะช่วยให้จำง่าย
  • หา Alternative Flow ให้มากที่สุดเท่าที่จะมากได้ เพราะสำคัญมากๆๆๆ ต่องานออกแบบ เขียนโปรแกรม และ ทดสอบระบบ
  • หากออกแบบหน้าจอแล้ว สามารถ capture ภาพหน้าจอมาแปะใน use case specification ได้ จะช่วยให้ผู้อ่านเห็นภาพขึ้น

ตัวอย่าง

Use Case Specification : Register Internet Member (UC-001)

Brief Description

สำหรับผู้ที่ต้องการสมัครเป็นสมาชิกประเภท Internet Member เพื่อที่จะสามารถทำการซื้อสินค้าได้ หากผู้สมัครเป็นสมาชิกของทางร้านอยู่แล้วเมื่อสมัครเป็น Internet Member แล้วจะสามารถลงประกาศขายสินค้าผ่านทางเว็บได้

Flow of Events

Basic Flow

  1. เลือกหัวข้อ ‘สมัครสมาชิก’ บนหน้าเว็บ
    ผู้ที่ต้องการสมัครเป็นสมาชิกต้องเข้ามาที่เว็บก่อน โดยในทุกหน้าจะแสดงหัวข้อ ‘สมัครสมาชิก’ ซึ่งอยู่ในบริเวณที่สังเกตง่าย
  2. ป้อนชื่อผู้ใช้และรหัสผ่าน [BR-001], [BR-002], [BR-003]
  3. ระบุว่าเป็นสมาชิกของทางร้านอยู่แล้วหรือไม่
  4. ป้อนที่อยู่อีเมล์
  5. กดปุ่ม ‘ตกลง’ เมื่อเสร็จสิ้น
    จากนั้นระบบจะส่งอีเมล์แจ้งยืนยันการสมัครไปให้ผู้สมัครตามที่อยู่อีเมล์ที่ป้อน

Alternative Flows

A1 ไม่ได้เป็นสมาชิกร้านค้า [BR-004]

เกิดขึ้นที่ขั้นตอนที่ 3 ของ Basic Flow

  1. เลือกประเภทอาชีพของผู้สมัครจากรายการ
  2. ป้อนช่วงรายได้ต่อเดือน
  3. ป้อนช่วงรายได้รวมของครอบครัวต่อเดือน
  4. ป้อนที่อยู่และเบอร์โทรศัพท์ติดต่อ
  5. กลับไปที่ขั้นตอนที่ 4 ของ Basic Flow

A2 เป็นสมาชิกร้านค้าอยู่แล้ว [BR-004]

เกิดขึ้นที่ขั้นตอนที่ 3 ของ Basic Flow

  1. ป้อนหมายเลขสมาชิกร้านค้า
  2. กลับไปที่ขั้นตอนที่ 4 ของ Basic Flow

Special Requirements

Security

การจัดเก็บและการเข้าถึงชื่อผู้ใช้และรหัสผ่านต้องมีความปลอดภัย ซึ่งต้องมีแต่เจ้าของชื่อผู้ใช้คนนั้นเท่านั้นที่เห็นรหัสผ่านได้ [BR-005]

Pre-Conditions

Post-Conditions

ตรวจสอบอีเมล์เพื่อ activate

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

Relevant Business Rules

  • BR-001 ชื่อผู้ใช้ใช้ภาษาไทยได้
  • BR-002 รหัสผ่านต้องป้อนสองครั้งให้เหมือนกัน
  • BR-003 รหัสผ่านต้องเป็นตัวเลขและตัวอักษรผสมกันและห้ามเกิน 8 ตัว
  • BR-004 ถ้าผู้สมัครเป็นสมาชิกร้านค้าอยู่แล้วให้ป้อนเฉพาะหมายเลขสมาชิก หากไม่ใช่ให้ป้อนรายละเอียดอื่นที่จำเป็นเพิ่มเติม
  • BR-005 การจัดเก็บและการเข้าถึงชื่อผู้ใช้และรหัสผ่านต้องมีความปลอดภัย ซึ่งต้องมีแต่เจ้าของชื่อผู้ใช้คนนั้นเท่านั้นที่เห็นรหัสผ่านได้
Advertisements

One thought on “Use Case Specification

ใส่ความเห็น

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