อธิบาย Functional Requirement สไตล์ User Story

ในกระบวนการพัฒนาซอฟต์แวร์แบบ Agile นิยมทำเอกสารแบบสั้นกระชับอธิบายมุ่งเน้นจุดสำคัญ มากกว่าการบรรยายยืดยาวและการใช้เทมเพลตเอกสารที่เป็นทางการมีพิธีรีตรองมากมาย ในการอธิบาย functional requirement ในแบบ Agile มีรูปแบบที่เป็นที่นิยมกันคือ ‘User Story‘ เป็นคำง่ายๆ ตรงไปตรงมา นั่นก็คือ การอธิบายเรื่องราวของผู้ใช้ (ที่เข้ามาปฏิสัมพันธ์กับระบบ) เป็นคำที่ผมชอบมาก เพราะตรงไปตรงมาชัดเจน

การอธิบาย functional requirement คือ การอธิบายรายละเอียดที่ผู้ใช้หรือไคลเอ็นต์เข้ามาปฏิสัมพันธ์กับระบบ ซึ่งก็คือการเข้ามาใช้งานระบบนั่นเอง ถ้าไคลเอ็นต์เป็นคนมักเรียกว่า ‘ผู้ใช้’ (user) เข้ามาเรียกใช้ ‘ฟังก์ชั่น’ ของระบบ ถ้าไคลเอ็นต์เป็นอุปกรณ์ (device) หรือระบบภายนอก (external system) สมัยนี้มักเรียกว่า ‘ไคลเอ็นต์’ (หรือระบุชื่ออุปกรณ์หรือชื่อระบบไปเลย) เข้ามาเรียกใช้ ‘เซอร์วิส’ (หรือ API) ของระบบ

อย่าลืมว่าในช่วงที่อธิบายความต้องการนั้นเป็นช่วงของงาน requirement ยังไม่เข้าสู่ช่วงวิเคราะห์และออกแบบระบบ ดังนั้นงาน requirement คืองานที่จะต้องจดจ่ออยู่กับปัญหาและความต้องการ ยังไม่ข้ามไปสนใจเรื่องโซลูชั่นเท่าใดนัก การอธิบายความต้องการจึง ‘ยัง‘ ไม่ควรอธิบายเกี่ยวกับโซลูชั่น ซึ่งหมายถึงไม่ควรอธิบายในมุมมองว่าระบบต้องทำอะไร ระบบทำอะไรได้บ้าง ระบบมีฟังก์ชั่นอะไร ซึ่งเป็นสิ่งที่คนจำนวนมากชอบทำกัน แสดงว่าใจร้อนรีบไปคิดถึงระบบ สาเหตุหนึ่งเพราะนักไอทีมักมีกระบวนทัศน์แบบ ‘ในออกนอก’ (inside-out) แต่สำหรับงาน requirement ผู้รับผิดชอบด้านนี้ควรคิดแบบ ‘นอกเข้าใน’ (outside-in) คล้ายกับนักการตลาด ที่ต้องทำความเข้าใจตลาดและลูกค้าก่อน แล้วค่อยมาคิดถึงผลิตภัณฑ์ ฉะนั้นการอธิบายความต้องการโดยเฉพาะความต้องการประเภท functional requirement จึงควรอธิบายในมุมมอง ‘เรื่องราวของผู้ใช้ที่เข้ามาปฏิสัมพันธ์กับระบบ

User Story เป็นคำที่ชัดเจน ตอกย้ำว่าให้อธิบายในมุมมองจากผู้ใช้เข้ามาที่ระบบ (outside-in) อธิบายความต้องการของผู้ใช้ ความคาดหวังของผู้ใช้ โดยอธิบายด้วยภาษาที่เรียบง่ายอ่านเข้าใจง่าย ไม่ใช้ศัพท์เทคนิคยุ่งยาก

รูปแบบ หรือ pattern ในการอธิบาย User Story มีหลากหลาย อาทิ (อ้างอิงจาก Wikipedia.org)

“As a <role>, I want <goal/desire> so that <benefit>

“As a <role>, I want <goal/desire>

“In order to <receive benefit> as a <role>, I want <goal/desire>

“As <who> <when> <where>, I <what> because <why>.

“As a <role>, I can <action with system> so that <external benefit>

สำหรับ <role> เป็นการระบุ ‘บทบาท’ (who) ของผู้ใช้ แนะนำว่าให้ระบุบทบาทนะครับ เพราะมีความชัดเจนและสามารถนำไป map กับบทบาทผู้ใช้ในด้านการจัดการสิทธิของผู้ใช้งานระบบต่อได้สะดวก ไม่ควรระบุเป็นชื่อคนหรือตำแหน่งหน้าที่การทงาน ข้อดีหนึ่งคือจะได้วิเคราะห์เรื่องบทบาทตั้งแต่ตรงนี้เลย เพราะส่วนมากชอบระบุว่าระบบทำอะไร แล้วค่อยไปคิดต่อว่าใครจะเป็นคนใช้ ผู้ใช้มีบทบาทอะไรบ้าง เป็นเหมือนการ reverse-engineer แต่แนวทางการอธิบายความต้องการควรเป็นแบบ forward-engineer ซึ่งสอดคล้องกับหลักธรรมชาติมากกว่า นั่นคือ ประธาน -> กริยา -> กรรม

สำหรับ <goal/desire> เป็นการสิ่งที่ผู้ใช้จะเข้ามาใช้ระบบ (what) นั่นเอง หรือในอีกมุมหนึ่งคือความต้องการของผู้ใช้ที่อยากให้ระบบทำให้ตนเอง ซึ่งก็คือการระบุกริยานั่นเอง (functional requirement หรือ ชื่อฟังก์ชั่น) ควรขึ้นต้อนด้วยคำกริยา

สำหรับ <benefit> เป็นการระบุเหตุผลที่ผู้ใช้เข้ามาใช้ฟังก์ชั่นนี้ของระบบ (why) เพื่อเสริมน้ำหนักของความต้องการนี้ยิ่งขึ้น ซึ่งนิยมอธิบายในมุมมองประโยชน์ที่ผู้ใช้คาดหวัง ซึ่งตรง <benefit> นี้เอง ที่สามารถเพิ่มประเด็นด้าน non-functional requirement หรือ quality attribute เสริมเข้าไปได้ในมิติด้านคุณภาพของฟังก์ชั่นนี้ที่ผู้ใช้ต้องการ

คราวนี้มาสำหรับผมบ้าง 🙂 ผมชอบรูปแบบ 5 Ws: who, what, when, where, why มากกว่า เนื่องจากผมทำงานมาในสาย Enterprise System ที่อะไรๆ ก็ต้องเป็นทางการละเอียดชัดเจน ระบุหรืออธิบายอะไรสั้นกระชับมากไม่ได้เพราะเสี่ยงต่อการเกิดความกำกวม ทำให้ผู้อ่านหรือผู้ร่วมงานตีความเข้าใจคลาดเคลื่อนได้

แต่ก็สามารถปรับรูปแบบ 5 Ws ให้เข้ากับ <role>, <goal/desire>, <benefit> ได้ นั่นคือ อย่างน้อยในความต้องการควรระบุ who, what, why นั่นเอง เพื่ออธิบายออกมาว่า ใคร ต้องการทำอะไรกับระบบ เหตุผล/ประโยชน์/คุณภาพระบบ ที่ต้องการคืออะไร

ตัวอย่าง เช่น

Search for customers

As a user, I want to search for my customers by their first and last names.

Modify schedules

As a non-administrative user, I want to modify my own schedules but not the schedules of other users.

Run tests

As a mobile application tester, I want to test my test cases and report results to my management.

Start application with last edit

The application begins by bringing up the last document the user was working with.
Or
As a user, I want to start an application with the last edit.

Close application

As a user closing the application, I want to be prompted to save if I have made any change in my data since the last save.
Or
Upon closing the application, the user is prompted to save (when ANYTHING has changed in data since the last save!).
Or
As a user closing the application, I want to be prompted to save anything that has changed since the last save so that I can preserve useful work and discard erroneous work.

ใน Wikipedia ที่อ้างอิงมา (ซึ่งในนั้นก็อ้างอิงมาจากเว็บเกี่ยวกับ Agile ชื่อดังอีกทีหนึ่ง) ยังได้เปรียบเทียบ User Story กับ Use Case เอาไว้ด้วย ซึ่งจริงๆ แล้วสำหรับผมที่ทำทางด้าน Use Case และ กระบวนการพัฒนาซอฟต์แวร์แบบ RUP (Rational Unified Process) หรือ UP (Unified Process) มาก่อนนั้น มีความคิดเห็นว่าทั้ง 2 สิ่งนี้ไม่ได้ต่างกันนัก มีวัตถุประสงค์หลักเหมือนกัน คือ การอธิบายเรื่องราวของผู้ใช้ที่มาใช้ระบบ จะต่างกันแบบชัดเจนเลยก็คือ User Story เน้นความเรียบง่ายสั้นกระชับ ส่วน Use Case เน้นความเป็นทางการแจกแจงรายละเอียดละเอียดยิบ

การนำไปใช้

  • สำหรับ User Story เหมาะกับการอธิบายความต้องการแบบเรียบง่าย สั้น กระชับ เน้นการสื่อสารด้วยปาก นั่นคือ เน้นการทำงานเป็นทีมเวิร์ก พูดคุยหารือกัน ร่วมกันทำงานช่วยกันระดมสมอง สมาชิกในทีมมีจำนวนไม่มากจนเกินไป สามารถร่วมกันทำงานพร้อมๆ กันได้ ไม่มีการแยกบทบาทหน้าที่หรือตำแหน่งที่มากจนเกินไป เพราะหากทีมเวิร์กดี งานเอกสารก็ไม่จำเป็นยืดยาวและเป็นทางการนัก
  • สำหรับ Use Case เหมาะกับการอธิบายความต้องการแบบเป็นทางการ แจกแจงรายละเอียดออกมาเป็นหัวข้อๆ ละเอียดยิบ หลีกเลี่ยงการตีความคลาดเคลื่อน และการเกิดความกำกวมในการอธิบาย การอธิบายแบบ Use Case มักเรียกว่า Use Case Specification หรือ Use Case Description นั่นคือ เหมาะกับทีมงานขนาดใหญ่ มีการแบ่งสมาชิกในทีมออกเป็นหลายบทบาทหน้าที่ และมีโอกาสน้อยที่ทุกคนจะได้มาร่วมกันทำงานพร้อมหน้าพร้อมตา ในแง่ทีมเวิร์กจึงเน้นไปที่การสื่อสารด้วยเอกสาร และ process การทำงานที่เข้มงวด นอกจากนี้ยังเหมาะกับงานที่ต้องทำเอกสารเป็นทางการ มีการส่งมอบ-ตรวจรับเป็นทางการ มีการจัดเก็บเป็นทางการ

สำหรับผมเองในงานที่ปรึกษาบางงานผมก็ใช้ทั้ง User Story กับ Use Case ด้วยกัน เพราะแต่ละสไตล์ก็มีข้อดีแตกต่างกัน อย่างในช่วงการเก็บรวบรวมความต้องการผมมักแนะนำให้อธิบายเป็น User Story เพราะจะได้ไม่เสียเวลาจดหรือพิมพ์มาก จะได้มีเวลาเก็บความต้องการให้ได้เยอะๆ จากนั้นนำมาระดมสมองวิเคราะห์และจัดลำดับความสำคัญความต้องการเบื้องต้น ระบุว่าความต้องการตัวไหนที่มีความเสี่ยงมากๆ ลูกค้าต้องการมากๆ มีผลต่อธุรกิจมากๆ มีความยากเชิงเทคนิคมากๆ มีผลกระบทต่อสถาปัตยกรรมมากๆ มีรายละเอียดเรื่องราวที่ยากมีศัพท์เฉพาะหรือ business rule มากๆ จนกลัวจะเกิดการตีความเข้าใจผิด ผมก็จะแนะนำให้แยกความต้องการเหล่านี้ออกมา แล้วให้นำมาอธิบายเพิ่มในแบบ Use Case เพื่อให้ละเอียด ชัดเจน และเป็นทางการขึ้น

สรุป

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

ดังนั้นผู้รับผิดชอบด้านนี้จึงต้องมีทักษะทางภาษาที่ดี โดยเฉพาะภาษาเขียน และ ต้องแม่นกับบทบาทและจังหวะการทำงาน ว่ากำลังทำด้าน requirement อยู่ หรือกำลังออกแบบระบบอยู่

การอธิบายความต้องการด้าน functional requirement จึงควรมองระบบเป็น ‘กล่องดำ’ (black box) แล้วเน้นความสนใจไปที่เรื่องราวที่ผู้ใช้เข้ามาใช้งานระบบเป็นหลัก

3 thoughts on “อธิบาย Functional Requirement สไตล์ User Story

    • ใช่ครับ เวลาพิจารณา func. req. ให้มองแบบ outside-in คิดว่าระบบหรือโมดูลจะให้บริการใคร (ใครจะไปเรียกใช้มัน) นั่นคือ คิดถึงจากมุมมองไคลเอ็นต์เข้าไป เหมือนเราใช้ตู้ ATM เราไม่ได้สนใจการทำงานภายในของมัน จึงคิดแค่ว่า input คืออะไรและมีรายละเอียดอะไร เพื่อให้ได้ output ที่ไคลเอ็นต์ต้องการ
      ดังนั้นเวลาพิจารณา func. req. ให้มองระบบหรือโมดูลเป็น black box ให้คิดแค่ ‘what’ ห้ามคิดถึง ‘how’ เพราะหากเผลอไปคิดถึง how จะเผลอคิดไปถึงการทำงานภายใน
      การพิจารณา func. req. จึงสนใจแค่ระดับอินเตอร์เฟส หรือ ระดับ abstraction ไม่สนใจระดับ implementation ก่อนหรือเร็วเกินไปครับ

ใส่ความเห็น

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