Requirement Attribute, Traceability, Matrix

TraceabilitySample5

Requirement Attribute, Traceability และ ตาราง Matrix มีประโยชน์มากต่อการระบุคุณสมบัติและคุณลักษณะของความต้องการ ทั้งยังใช้ในด้านอื่นและมีประโยชน์ต่อด้านอื่นได้อีกมาก โดยเฉพาะการจัดลำดับความสำคัญขอความต้องการ การเชื่อมโยงองค์ประกอบต่างๆ ในโครงการ เช่น เอกสาร, หน้าจอ, ความต้องการ, test case, โมดูล เป็นต้น ช่วยสนับสนุนการบริหารการเปลี่ยนแปลงและบริหารความเสี่ยงได้ดี และยังเป็นการช่วยลดการใช้ทัศนคติหรือความรู้สึกส่วนตัวในการพิจารณาความสำคัญของแต่ละความต้องการได้ด้วย

Requirement Attribute คือ คุณสมบัติของความต้องการ เช่น ข้อความบรรยายรายละเอียด, traceability  และแอททริบิวต์อื่นๆ ซึ่งควรระบุค่าด้วย เช่น Yes / No, 1-10, High / Medium / Low อาทิเช่น

  • Priority คือ ระดับความสำคัญของความต้องการ
  • Difficulty คือ ระดับความยาก/ง่ายของความต้องการ
  • Risk คือ ระดับความเสี่ยงของความต้องการ
  • Owner คือ ผู้รับผิดชอบความต้องการตัวนั้นๆ
  • Status คือ สถานะของความต้องการ เช่น proposed, approved, accepted, rejected, deleted
  • Customer Needs คือ ระดับความต้องการในความต้องการตัวนั้นๆ ในมุมมองลูกค้าหรือผู้ใช้
  • Iteration Planned คือ iteration / release / phase ที่จะอิมพลีเม้นต์ความต้องการตัวนั้นๆ
  • Architecture Impact คือ ระบุว่าความต้องการตัวนั้นๆ มีผลกระทบต่อหรือเกี่ยวข้องกับสถาปัตยกรรมระบบหรือไม่
  • Stability คือ ระดับเสถียรภาพของความต้องการ หรือ ที่มักเรียกกันว่า ความต้องการนิ่งแค่ไหนแล้ว เช่น ถ้านิ่งแล้วก็ให้คะแนะน 8/10 หมายถึง ยังพอแก้ไขรายละเอียดเล็กน้อยได้ แต่ส่วนหลักนิ่งแล้ว เป็นต้น
  • Benefit คือ ประโยชน์ของความต้องการ
  • Effort คือ ทรัพยากรที่จะใช้อิมพลีเม้นต์ความต้องการ นิยมระบุเป็น man day, man hour เป็นต้

แต่ละ requirement มี requirements attribute เป็นของตัวเอง และ ควรเปิดเผยให้ทุกคนในฝ่ายผู้พัฒนาระบบฯ สามารถดูรายละเอียดได้

ตัวย่าง Requirement Attribute ที่อธิบายเป็นตาราง Matrix

ReqAttributeSample

 

Traceability คือ ความสามารถในการตรวจสอบย้อนกลับ (trace) ของอิลิเม้นต์ (element) ในโครงการกับอิลิเม้นต์อื่นๆ ในโครงการ โดยเฉพาะที่เกี่ยวข้องกับ requirement  อิลิเม้นต์ในโครงการเหล่านี้เรียกว่า traceability item ซึ่งโดยปกติแล้ว item เหล่านี้ประกอบด้วยประเภทของ requirements โมเดลอิลิเม้นต์จากการวิเคราะห์และออกแบบ, อิลิเม้นต์ที่เกี่ยวกับการ test, เอกสารการอบรมและใช้งานสำหรับ end user

ReqTraceability

แต่ละ traceability item ต้องมีการระบุเซ็ตของแอททริบิวต์ (ดูในเรื่อง Requirements Attributes) ซึ่งมีประโยชน์ในการติดตามสถานะ, ประโยชน์, ความเสี่ยง ฯลฯ ที่สัมพันธ์กับ item นั้น ๆ

วัตถุประสงค์ของ Traceability คือ

  • เพื่อให้เข้าใจที่มาของ requirements
  • บริหารขอบเขตของโครงการ
  • บริหารการเปลี่ยนแปลงที่มีต่อ requirements
  • ประเมินผลกระทบจากการเปลี่ยนแปลง requirement
  • ประเมินผลกระทบจากความผิดพลาดจากการ test ที่เกี่ยวข้อง requirements (เช่น ผลการ test อาจไม่เป็นที่พอใจ)
  • ตรวจสอบให้แน่ใจได้ว่าทุก requirements ได้ถูกอิมพลีเม้นต์
  • ตรวจสอบให้แน่ใจได้ว่าระบบฯ ทำงานได้ตรงตามสิ่งที่ควรจะเป็น (ตรงตาม requirements)

Traceability ช่วยให้ได้เข้าใจและได้บริหารได้ว่าจะอินพุตอะไรใส่ใน requirement บ้าง เช่น Business Rules และ Stakeholder Requests ที่จะถูกแปลไปเป็นเซ็ตของ stakeholder/user needs และฟีจเจอร์ของระบบฯ เช่นที่ระบุในเอกสาร Vision สำหรับ Use Case Model เป็นโครงร่างที่แสดงให้เห็นว่าจากฟีจเจอร์ได้ถูกแปลไปเป็น functionality ของระบบได้อย่างไร โดยรายละเอียดที่แสดงว่าระบบฯ มีการปฏิสัมพันธ์กับโลกภายนอกอย่างไรจะกำหนดใน Use Case ซึ่งประกอบไปด้วยรายละเอียดสำคัญ เช่น non-functional requirements, เงื่อนไขในการออกแบบ (design constraints) สำหรับ Traceability ทำให้คุณเข้าใจ requirements และแปลงจาก requirements ไปสู่ผลการออกแบบ, ไปสู่การ test, จนไปถึงว่าจะทำเอกสารสำหรับ user อย่างไร ในระบบขนาดใหญ่รายละเอียดของ Use Case และ Non-Functional Requirement ต่าง ๆ อาจถูกรวมไว้ในเอกสารเดียวกันคือ Software Requirements Specification (SRS) สำหรับหนึ่งฟีจเจอร์ หรือ subsystem ไปเลยก็ได้

แนวคิดหลักอีกหนึ่งประการในการช่วยจัดการการเปลี่ยนแปลงของ requirements คือ ลิงค์ความสัมพันธ์ระหว่าง requirements แบบ ‘suspect’ (น่าที่สงสัย) เมื่อมีการเปลี่ยนแปลงใน requirement ใด ความสัมพันธ์ของ requirements อื่นที่เกี่ยวข้องกับ requirement นั้นจะถูกมาร์กว่า “suspect” ซึ่งเป็น flag เพื่อช่วยในการรีวิวเพื่อช่วยในการตัดสินใจในการบริหารการเปลี่ยนแปลงว่า requirement อื่นที่เกี่ยวข้องได้รับผลกระทบและมีการเปลี่ยนแปลงตามไปด้วยหรือไม่ แนวคิดนี้ช่วยอย่างยิ่งในการวิเคราะห์ผลกระทบจากการเปลี่ยนแปลงที่เกิดขึ้นได้อย่างมีประสิทธิภาพ

นอกจากนี้ traceability ยังช่วยตอบคำถามเกี่ยวกับ requirements ได้เช่น

  • แสดงให้ดูหน่อยว่า user needs / business goals ตัวใดที่ไม่ได้ถูกลิงค์ไปยังฟีจเจอร์ของ product
  • แสดงผลการทดสอบของทุก use case ใน iteration #n ให้ดูหน่อย
  • แสดงผล non-functional requirements ที่ลิงค์ไปยัง test ที่มีสถานะ ‘ยังไม่ได้ทำการทดสอบ’ ให้ดูหน่อย
  • แสดงผลของทุกการทดสอบที่ fail โดยเรียงลำดับตามสำคัญให้ดูหน่อย
  • แสดงฟีจเจอร์ที่ลูกค้ามีความต้องการสูง ซึ่งจะถูกพัฒนาสำหรับ release นี้ และบอกมาสถานะปัจจุบันมาด้วย

นั่นหมายความว่า traceability ยังช่วยสนับสนุนการบริหารความเสี่ยงได้นั่นเอง ในทาง software architecture นั้นการจัดการด้าน traceability เป็นการช่วยบูรณาการ (integrate) ประเด็นหรือองค์ประกอบต่างๆ ให้สามารถเชื่อมโยงกันได้ จะได้เข้าใจภาพรวม เข้าใจผลเกี่ยวกับระหว่างกัน เข้าใจผลกระทบระหว่างกัน

Business Rules และ issue ก็น่าสนใจที่จะนำมารวมไว้ใน traceability ด้วย โดยปกติ diagram จะมีหน้าตาดังรูปด้านล่าง

TraceabilitySample2

ตัวอย่าง Traceability 1

TraceabilitySample1

ตัวอย่าง Traceability 2

TraceabilitySample3

ตัวอย่าง Traceability 3

TraceabilitySample4

ตัวอย่าง Traceability 4

TraceabilitySample5

ในการทำงานจริงอาจไม่สะดวกที่จะวาดรูป traceability ดังรูปด้านบน เพราะดูยาก และในงานจริงอาจมีความต้องการและ traceability item อื่นๆ อีกจำนวนมาก จึงนิยมนำมาอธิบายด้วยตาราง Traceability Matrix ซึ่งอาจประยุกต์ MS Excel มาใช้ก็ได้ หรือจะบันทึกลง database ก็ได้

ตัวอย่างตาราง Traceability Matrix 1

Matrix_UC_QA

ตัวอย่างตาราง Traceability Matrix 2

Matrix_UC_Mechanism

ส่วนมากผมเห็นใช้ MS Excel บันทึกกัน แต่ไหนๆ ก็ไหนๆ แล้ว ควรใช้ความสามารถของ Excel ให้เป็นประโยชน์ขึ้น เช่น เขียนสูตร หรือเขียนโปรแกรมด้วยภาษา Visual Basic for Application เพื่อใช้วิเคราะห์ข้อมูลในตารางด้วยจะยิ่งดี

สรุป

การจัดการด้าน Traceability เป็นหัวใจสำคัญมาก ที่จะช่วยให้เราสามารถเชื่อมโยงสิ่งต่างๆ ในโครงการเข้าด้วยกันได้ มีประโยชน์ต่อการบริหารจัดการด้านอื่นๆ อีกมาก ส่วนการใช้ Requirement Attribute ก็ช่วยให้เข้าใจ ‘ความลึก’ ของความต้องการได้มากขึ้น เห็นมิติต่างๆ ได้รอบด้านขึ้น

ในงาน software architecture และ enterprise architecture ที่ผมทำอยู่ ผมให้น้ำหนักความสำคัญกับ traceability เสียยิ่งกว่าการจัดการ change request เสียอีก เพราะการเชื่อมโยงองค์ประกอบต่างๆ ในระบบ ถือเป็นหนึ่งในหัวใจสำคัญของงาน architecture

ใส่ความเห็น

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