ประเภทความต้องการ


ReqType

Common requirement types

โดยทั่วไปความต้องการที่มีผลต่อการพัฒนาซอฟต์แวร์มากๆ แบ่งออกเป็น 2 ประเภทคือ Functional Requirement (FR) และ Non-Functional Requirement (NFR) หรือสมัยนี้บางทีก็เรียกว่า Quality Attribute (QA)

แต่ยังมีความต้องการอีกประเภทที่มักถูกมองข้าม หรือให้ความสำคัญน้อย แต่ในความเป็นจริงกลับเป็นความต้องการที่มีความสำคัญและมีผลต่อการพัฒนาระบบอย่างมาก นั่นคือ ความต้องการเชิงธุรกิจ หรือ Business Goal (มีคำอื่นใช้แทนกันได้เช่น Business Requirement, Business Need, Stakeholder Need แต่ไม่ควรใช้คำว่า High Level Requirement เพราะกว้างและกำกวมเกินไป) และ ความต้องการประเภท ความสามารถของระบบหรือ Feature

นอกจากนี้แต่ละความต้องการและแต่ละประเภทควรเชื่อมโยง (trace) หากันได้ จะช่วยให้ทราบว่ามีความเกี่ยวข้องกัน และยังสามารถเชื่อมโยงความต้องการไปยัง software artifact อื่นๆ ได้อีก อาทิ design, test case, user manual, screen, source code เป็นต้น ดังภาพด้านล่าง

ReqTraceability

Requirement traceability

Functional Requirement หรือในทาง Object-Orientation เรียกว่า Use Case คือฟังก์ชั่นของระบบที่มีปฏิสัมพันธ์กับผู้ใช้ หรือในทางกลับกันคือฟังก์ชั่นของระบบที่ผู้ใช้เข้ามาเรียกใช้ได้ ซึ่งฟังก์ชั่นเหล่านี้สนับสนุนและสนองตอบการทำงานของผู้ใช้โดยตรง ดังนั้นอาจพิจารณาได้ว่า Functional Requirement ก็คือฟังก์ชั่นระบบที่เอื้อประโยชน์ต่อผู้ใช้โดยตรง ส่วนความต้องการที่เกี่ยวข้องกับฟังก์ชั่นของระบบที่ส่งผลต่อคุณภาพของระบบและต่อผู้ใช้เรียกว่า Non-Functional Requirement

หลายคนคุ้นเคยกับ Functional Requirement มากกว่าประเภทอื่น เพราะสมมติฐานสำคัญคือ จากพื้นฐานความรู้ ทักษะและประสบการณ์จากการศึกษาและทำงานในการพัฒนาโปรแกรมเชิงโครงสร้าง (Structural Program หรือ Procedural Program) ซึ่งมักเน้นความต้องการประเภทฟังก์ชั่น และโดยธรรมชาติของคนเราที่คุ้นเคยกับ ‘ฟังก์ชั่น’ หรือการทำงานของสิ่งต่าง ๆ คนเรามักใส่ใจในการทำงานของสิ่งต่าง ๆ ว่าทำอะไรได้บ้าง ทำอะไรไม่ได้บ้าง และการพัฒนาซอฟต์แวร์ที่ผู้คนมักมองข้ามหรือไม่ใส่ใจนักกับคุณภาพของซอฟต์แวร์เอง การควบคุมคุณภาพส่วนใหญ่มักนำไปใช้กับกระบวนการพัฒนาซอฟต์แวร์ (Software Engineering) เสียมากกว่า

Business Goal หรือ ความต้องการเชิงธุรกิจ เป็นความต้องการที่กำหนดโดย stakeholder ซึ่งเป็นความต้องการในระดับแรกเมื่อเริ่มต้นโครงการเลยทีเดียว โดยมักมีจำนวนไม่มากนัก ถือว่าเป็นความต้องการในระดับ ‘problem space’

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

  • พัฒนาเสร็จรวดเร็วเพื่อทันต่อการใช้งานหรือขาย (Time to Market)
  • ต้นทุนต่ำ หรือให้อยู่ภายในงบประมาณ (Low Cost)
  • ตอบสนองพฤติกรรมของผู้ใช้งานที่หลากหลาย (Support a Variety of Customer Behavior)
  • ปรับปรุงแก้ไขง่ายเพื่อผู้ใช้งานที่หลากหลาย (Highly Customizable)
  • ช่วยเพิ่มกำไรสุทธิได้ 10% (Increase Net Profit)
  • ลดงานเอกสารลง (Reduce Paper Work)
  • มีความสามารถในการแข่งขันกับคู่แข่งได้ (High Competitiveness)
  • สร้างการรับรู้และเข้าใจในตัวสินค้า (ซอฟต์แวร์) ได้เร็ว (Build Awareness)

การกำหนด Business Goal จำเป็นต้องมีความรู้และทักษะด้านธุรกิจอยู่บ้าง มิเช่นนั้นแล้วอาจมองหรือสังเกตไม่ออก วิธีที่ดีสุดคือการวิเคราะห์จากแผนธุรกิจ (Business Plan) ของลูกค้า ลูกค้าหรือเจ้าของระบบฯ ควรมีการทำแผนธุรกิจเสมอก่อนที่จะเริ่มพัฒนาซอฟต์แวร์ เนื่องจากในแผนธุรกิจจะมีบอกรายละเอียดที่จำเป็นอยู่มากมาย เช่น วิสัยทัศน์ พันธกิจ วัตถุประสงค์ เป้าหมาย แผนการดำเนินงาน แผนกลยุทธ์ แผนการตลาด แผนการเงิน ฯลฯ ดั้งนั้นจำเป็นต้องวิเคราะห์จากแผนธุรกิจ แต่หากลูกค้าไม่มีการทำแผนธุรกิจก่อนจะทำให้พบอุปสรรคสำคัญได้ สิ่งที่จำเป็นต้องทำคือ ต้องรู้ให้ได้ว่าลูกค้าต้องการซอฟต์แวร์หรือโปรแกรมนี้ไปเพื่ออะไร ทำไมจึงคิดว่าจำเป็นต้องใช้ซอฟต์แวร์หรือต้องว่าจ้างบริษัทฯ มาพัฒนาซอฟต์แวร์หรือซื้อซอฟต์แวร์ โดยทางฝั่งลูกค้าเองต้องมีการกำหนด stakeholder และแบ่งเป็นกลุ่มต่าง ๆ จัดลำดับความสำคัญ

หากลูกค้าไม่มีแผนธุรกิจและยังไม่มีเป้าหมายที่ชัดเจน ซึ่งหมายความอีกอย่างหนึ่งได้ว่าลูกค้าเองก็ยังไม่ชัดเจนและมีความน่าจะเป็นที่ stakeholder แต่ละกลุ่มของลูกค้าอาจยังมีวิสัยทัศน์และความต้องการที่ยังไม่เป็นไปในทิศทางเดียวกันนั่นเอง ดังนั้นการดำเนินงานในเฟสนี้จึงต้องเล่นบทบาทเป็น Business Analyst หรือนักวิเคราะห์ธุรกิจ หรือเล่นบทบาทที่ปรึกษาก่อนเสมอ จะเข้าไปเก็บความต้องการเลยยังไม่ได้ เพราะต้องทำให้ลูกค้ามีความชัดเจนเสียก่อน เพราะจุดประสงค์คือ เพื่อกำหนด business goal

Feature หรือความสามารถของระบบฯ ถือเป็นความเป็นความต้องการระดับ ‘solution space’ เพราะเมื่อได้ business goal มาแล้วต้องนำมาวิเคราะห์ว่าซอฟต์แวร์ที่จะพัฒนาขึ้นจะต้องมีความสามารถอะไรบ้าง แล้วแต่ละ feature ตอบสนอง (trace) กับ business goal ใดบ้าง จากรูปสไลด์ลูกศรที่แสดงหมายถึงเส้น Traceability โดยระบบหนึ่งๆ ควรมี feature ประมาณ 25 – 99 (จริงๆ แค่ 50 ตัวก็ถือว่าเยอะแล้ว) ซึ่งเมื่อกำหนด feature แล้ว จะต้องนำเสนอต่อลูกค้า และเมื่อลูกค้ายอมรับ เราจะใช้ feature เพื่อเป็นฐานในการบริหารโครงการ (Project Planning and Management) หรือหมายความว่าผู้บริหารโครงการจะบริหารโครงการโดยยึด feature เป็นหลัก ไม่ลงมาดูในความต้องการระดับล่างมากนัก เช่น Functional Requirement และ Non-Functional Requirement เพราะ feature คือสิ่งที่ทีมพัฒนาฯ ได้เสนอให้ลูกค้าดังนั้นจึงต้องพัฒนาซอฟต์แวร์ให้มีความสามารถตามที่เสนอให้ได้นั่นเอง ในงานภาครัฐหรืองานประมูลจึงนิยมทำตารางเปรียบเทียบคุณสมบัติหรือความสามารถของระบบที่ลูกค้ากำหนดกับที่บริษัทไอทีเสนอ

สำหรับ Feature ควรเขียนให้สั้นกระชับและมีแรงจูงใจ เช่น จูงใจให้ลูกค้าอยากจ้าง อยากซื้อ อยากใช้ ดังนั้นจึงควรใช้ภาษาทางการตลาดสักหน่อย ใครที่ต้องเขียน proposal ยื่นเสนองานหรือประมูลงานบ่อยๆ ยิ่งต้องฝึกเขียน Feature ให้ชำนาญ

สำหรับความต้องการประเภท Non-Functional Requirement คือความต้องการที่ไม่ใช่ functional! นั่นคือไม่ได้สนใจว่าระบบฯ ต้องทำอะไรได้บ้าง และมักเป็นการทำงานที่ผู้ใช้ไม่ได้เข้ามาใช้โดยตรง (ก็เลยเรียกว่า non-function ไง) แต่จะสนใจว่าระบบจะต้องมีคุณภาพด้านใดบ้างและในแต่ละ functional requirements ต้องมีคุณภาพด้านใดบ้าง สังเกตได้ว่ามีคำว่า ‘คุณภาพ’ เข้ามาเกี่ยวข้อง เพราะ NFR ถือเป็น ความต้องการที่ชี้วัดด้านคุณภาพของระบบฯ เลยทีเดียว ดังนั้นระบบฯ จะมีคุณภาพใดบ้าง มากน้อยแค่ไหน จึงจำเป็นต้องมีการระบุและอิมพลีเม้นต์ NFR ให้ถูกต้อง สำหรับ NFR เรียกได้หลายอย่าง บางตำราก็ใช้คำว่า ‘quality attribute’ เนื่องจาก NFR เปรียบเสมือนคุณสมบัติทางคุณภาพของสถาปัตยกรรมและระบบนั่นเอง

ตัวอย่าง Non-Functional Requirements เช่น

  • Availability คือ ความพร้อมในการให้บริการ ไม่ล่ม ไม่หยุด
  • Reliability คือ ความน่าเชื่อถือ
  • Performance คือ ความเร็ว อันเกิดจากประสิทธิภาพในการประมวลผล และการใช้ทรัพยากร
  • Scalability คือ ความสามารถด้านการรองรับการประมวลผลที่มากขึ้น รองรับการขยายตัวของระบบได้
  • Usability คือ ความสามารถด้านการสร้างคุณค่า คุณประโยชน์ และความง่ายในการใช้งาน
  • Testability คือ ความสามารถในการทดสอบ
  • Modifiability คือ ความสามารถในการปรับปรุงแก้ไขได้มีความยืดหยุ่น ผลกระทบข้างเคียงน้อย
  • Interoperability คือ ความสามารถในการทำงานร่วมกันได้ แม้มีข้อจำกัด เช่น ระบบบัญชีเป็น Java ระบบการเงินเป็น C#.NET
  • Security คือ ความปลอดภัย

NFR มีผลอย่างมากทั้งต่อ software architecture และกับระบบโดยรวม การระบุและวิเคราะห์จำเป็นต้องอาศัยความรู้และประสบการณ์ด้าน software architecture และด้านเทคนิคมาก และอาจจำเป็นต้องมี domain expert เพื่อช่วยในการระบุและวิเคราะห์ เช่น ผู้เชี่ยวชาญในระบบงาน (เช่น ระบบงานบัญชี) ผู้เชี่ยวชาญด้านฮาร์ดแวร์ ผู้เชี่ยวชาญด้านรักษาความปลอดภัย เป็นต้น

ดังจะเห็นได้ว่าความต้องการมีหลายประเภท ไม่ได้มีเพียงแค่ functional requirement อย่างเดียวเท่านั้น ซึ่งนอกเหนือจาก functional requirement แล้ว ความต้องการที่มีผลอย่างมากต่อการพัฒนาระบบและคุณภาพของระบบ คือ business goal และ NFR ดังนั้นการเก็บรวบรวมความต้องการจึงจำเป็นต้องระบุให้ครบถ้วนทุกประเภท และที่สำคัญอย่าลืมว่า บริหารโครงการควรยึด feature เป็นหลัก เพราะ feature คือ สิ่งที่ทีมพัฒนาฯ ‘รับปาก’ กับลูกค้าว่าจะพัฒนาระบบให้มีความสามารถได้ตามนั้น

คราวนี้ปัญหาที่พบได้บ่อย คือ ชอบทำเอกสารแยกหัวข้อกัน เช่น แบ่งเป็นหัวข้อ Business Goal, System Feature, Functional Requirement, Non-Functional Requirement ซึ่งจริงๆ แล้วจะแบ่งหัวข้อหรือไม่ก็ได้ ประเด็นสำคัญของงานเอกสารด้าน requirement ไม่ได้อยู่ที่ตรงนี้ แต่อยู่ที่เราได้สื่อสารความต้องการทุกประเภทได้ครอบคลุมหรือไม่? ทีมงานเข้าใจทั้งหมดหรือไม่? ดังนั้นหมายความว่าไม่ต้องแบ่งหัวข้อเลยก็ยังได้ หัวใจอยู่ที่การบรรยายความต้องการให้ทีมงานเข้าใจ…

ใส่ความเห็น

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