บทที่ 5 Software Requirement
Requirement คือ อะไรก็ตามที่เป็นความต้องการของลูกค้า
รวมตั้งแต่ประโยคที่เป็น Abstract มากๆจนถึงที่ละเอียดมากๆ อย่างเช่นประโยคที่บอกว่า
ระบบบัญชี นี่ก็คือ Requirement หนึ่งที่เป็น Abstract หรือประโยคที่ว่า
รองรับ User ได้ไม่น้อยกว่า 10 คน นี่ก็เป็น requirement ที่ลงลึกถึงรายละเอียด
เป็นต้น
ในขั้นตอนของการพัฒนาระบบเราจะมีการวิเคราะห์
Requirement เรียกว่า Requirement Specification หลังจากเราวิเคราะห์เสร็จก็จะมากำหนด
Requirement ว่ามีอะไรบ้าง โดย Requirement ที่เรากำหนดขึ้นมานั้นนำมาใช้ประโยชน์ได้
2 อย่าง คือ
1. มองในมุมมองของเจ้าของงาน จะใช้เป็นตัวอ้างอิงการเปิดประมูลให้กับผู้ที่จะทำการพัฒนา
| |
| |
|
Note :
- ถ้างานทั่วๆไป งานเล็กๆ ส่วนมากคนที่ทำการวิเคราะห์ , กำหนด Requirement
จะเป็นกลุ่มเดียวกับคนที่ทำการพัฒนา
- ถ้างานระบบใหญ่ ส่วนมากจะมีบริษัทที่ทำการวิเคราะห์และกำหนด Requirement
จากนั้นจะทำการประมูลเพื่อหาบริษัทที่ทำการพัฒนาอีกที
|
2. เป็นส่วนหนึ่งในสัญญาเพื่อใช้ในการจ่ายเงิน
กล่าวคือ ถ้าทำไม่ได้ตาม Requirement ก็ไม่จ่ายเงิน เป็นต้น
Type Of Requirement (
ประเภทของความต้องการ )
1. User Requirement - เป็นความต้องการที่รวบรวมจากผู้ใช้ระบบโดยตรง
เช่น ลำดับของช่องที่จะให้กรอกข้อมูล , จะกรอกอย่างไร , เรียงลำดับอย่างไร ,
ขนาดตัวอักษร , สีอะไร เป็นต้น
2. System Requirement ความต้องการของระบบ เช่น ระบบต้องสามารถส่งข้อมูลผ่านระบบเครือข่ายได้
, ข้อมูลต้องเก็บได้ทั้งที่ Server และ Work Station เป็นต้น
3. Software Specification รายละเอียดทางด้านเทคนิคของ SW ว่าต้องทำอะไรได้บ้าง
Definitions and specification
- Requirement Definition คือ การนิยามความต้องการของระบบ
โดยนิยามจากการสอบถาม,สังเกตและวิเคราะห์ความต้องการของระบบ จากนั้นเรานิยามขึ้นมาเป็นประโยคสั้นๆที่บอกถึงสิ่งที่เราต้องการอย่างชัดเจน
Requirement Specification เป็นรายละเอียดโดยที่จะบอกว่าจะต้องทำอะไรบ้าง
โดยที่ Definition จะเป็นการคุยกับเจ้าของงานหรือ
User แต่ถ้าคุยกับ Programmer จะคุยทางด้านเทคนิค จะลงลึกถึงรายละเอียด จะคุยกันในระดับล่างเป็น
Specification
Requirement แบ่งออกได้เป็น 3
กลุ่มใหญ่ๆ
1. Functional Requirement คือ Requirement
หรือสิ่งที่ระบบควรจะทำ , หน้าที่หลักของระบบที่จะต้องทำ เช่น
- user ต้องสามารถ Search จาก DB ทั้งหมดก็ได้หรือ
Search จากส่วนหนึ่งส่วนใดของ DB ก็ได้
- ระบบจะต้องมีโปรแกรมที่ช่วยให้อ่าน
Document ได้
2. Non-functional Requirement
คือ Requirement อื่นๆที่ไม่ใช่หน้าที่หลักๆที่ต้องทำ แต่เป็นคุณสมบัติอื่นๆที่เราอยากได้จากระบบ
เช่น ความปลอดภัยของระบบ , ความเชื่อถือได้ของระบบ , Respond Time , มีความสามารถทางด้าน
I/O , ความสามารถในการเชื่อมต่อกับระบบอื่นๆ ตัวอย่างเช่น ระบบบัญชี โดยที่หน้าที่หลักของระบบบัญชีคือ
บันทึกข้อมูล Transaction รายวัน , จะต้องมีการทำสรุปยอดบัญชีได้ สิ่งเหล่านี้คือสิ่งที่ระบบบัญชีควรทำคือ
Functional Requirement แต่ถ้าบอกว่าต้องมีการใส่ Password , สามารถเชื่อมโยง Internet
ได้ , เชื่อมโยงกับระบบบัญชีของบริษัทอื่นได้ อันนี้ไม่ใช่หน้าที่หลัก ของระบบบัญชี
แต่มันคือ Non-functional Requirement
3. Domain Requirement คือ เป็นเงื่อนไขอื่นจากสภาวะแวดล้อมที่ทำให้ระบบทำงานได้
หรือ เป็นการมองที่ว่าระบบที่พัฒนามานี้จะไปทำงานร่วมกับระบบอื่นๆหรือสภาวะแวดล้อมอื่นๆในองค์กร
มันจะต้องมีความต้องการอื่นๆภายนอกมากระทบบ้างหรือไม่ เช่น เราออกแบบระบบบัญชี
เมื่อนำไปใช้ จะไปทำงานร่วมกับระบบอื่นๆเช่นไปทำงานร่วมกับระบบการสมัครสมาชิกของ
UBC โดยนำระบบบัญชีไปใช้ในส่วนการรับสมัคร , ยกเลิก เป็นต้น
Non-functional Requirement
แบ่งออกได้เป็น 3 กลุ่ม ดังนี้
1. Product Requirement คือ Non-functional
ที่เกี่ยวข้องกับ Product เช่น ต้องสามารถติดต่อสื่อสารได้ระหว่างตัว Application
Software กับ User โดยใช้ Character Set ที่เป็นมาตรฐาน
2. Organizational Requirement
คือ Non-functional ที่เกี่ยวข้องกับองค์กร เช่น โปรแกรมจะต้องสอดคล้องกับกฎระเบียบขององค์กร
3. External Requirement คือ
Non-functional ที่เกี่ยวข้องกับภายนอกองค์กร เช่น การทำงานร่วมกันได้กับระบบอื่น
, ข้อบังคับ ,ข้อกำหนดของกฏหมาย เป็นต้น
โดยที่ Product Requirement อาจจะแบ่งออกเป็นแยกย่อยอีกก็ได้
เช่น Efficiency ของ Product , Performance เป็นอย่างไร เป็นต้น
| Note
: ในภาพรวมของ Requirement จะสรุปได้ดังนี้ |
Structure Presentation
หลังจากที่เราได้ทำการวิเคราะห์ความต้องการเรียบร้อยแล้ว
ก็จะทำการเขียนความต้องการออกมา โดยมีคำแนะนำว่าควรที่จะเขียนเป็นลักษณะโครงสร้าง
มีการแบ่งเป็นข้อใหญ่แล้วแยกเป็นข้อย่อยให้ชัดเจน
Guideline for Writing Requirement
1. ให้เขียนลักษณะเป็นโครงสร้าง ที่คิดขึ้นมาเองได้
ให้ใช้ในทุกๆ Requirement ที่มีในระบบให้เหมือนๆกันเพื่อจะได้เป็นมาตรฐาน ให้เป็นโครงสร้างที่ชัดเจนเป็นพอ
2. ใช้ภาษาให้คงเส้นคงวา แล้วมีคำที่จะต้องใช้ที่สำคัญอยู่
2 คำคือคำว่า จะต้อง กับ ควรจะ 2 คำนี้จะอยู่ในRequirement
เสมอ โดยจะอยู่ในสัญญา , เอกสาร และ Milestone
3. มีการทำ Highlight ตัวอักษร ,ตัวหนา ,
ตัวเอียง ต่างๆใน Requirement
4. หลีกเลี่ยงการใช้ศัพท์ทางคอมพิวเตอร์ และ
ศัพท์ทางเทคนิค เพราะว่าคนที่อ่าน Requirement ไม่ใช่คนพัฒนาระบบกลุ่มเดียว นักกฎหมายก็อ่านด้วยเพราะเค้าต้องดูสัญญาจต่างๆ
หรือ คนที่เปิดประมูลก็ต้องอ่านด้วย เป็นต้น เพราะฉะนั้นจึงควรใช้ในกรณีจำเป็นเท่านั้น
Problem with NL ( Natural Language
) Specification ( ข้อเสียของการใช้ภาษาธรรมชาติ )
1. กำกวม ( Ambiguity ) คำหรือประโยค 1 ประโยคตีความได้หลายอย่าง
ถ้า Requirement กำกวม โอกาสที่งานผิดพลาดมีได้สูง การตรวจ Milestone ก็มีปัญหาได้
2. ยืดหยุ่นเกินไป ( Over-Flexibility
) การใช้คำพูดในเชิงอธิบายมันไม่ชัดเจน
3. ไม่ได้แบ่งเป็นหมวดหมู่ที่ชัดเจน
( Lack of Modularisation ) ทำให้ต้องอ่านคำบรรยายทั้งหมดถึงจะเข้าใจ ทำให้เสียเวลา
Alternatives to NL Specification
ทางเลือกในการใช้ภาษาธรรมชาติให้ชัดเจนโดยการเขียนเป็นตาราง
มีหัวข้อบรรยาย หรือเขียนเป็นแบบฟอร์ม มีหัวข้อเขียนตามหัวข้อไป , Input คืออะไร
, Output คืออะไร , ลักษณะเป็นอย่างไร ถ้าเขียนแบบนี้ก็จะช่วยได้
The Requirement Document
- เมื่อเราวิเคราะห์ Rwquirement แล้ว ,
เขียน Document แล้ว เราจะได้เอกสารเกี่ยวกับ Requirement ออกมาทั้ง 2 อย่างคือ
Definition และ Specifications ต้องมีทั้ง 2 อย่าง (สำคัญมาก)
- เอกสาร Requirement ไม่ใช่เอกสารการออกแบบ
เป็นเพียงบอกว่าต้องการอะไร ( What ) เท่านั้น ไม่ใช่ทำอย่างไร (How )
User of a Requirement Document
( ไม่สำคัญ ไปอ่านเอง )
กลุ่มคนต่างๆที่มีบทบาทในระบบ จะใช้ประโยชน์อะไร
จะได้ประโยชน์อะไรจาก Requirement บ้าง หัวข้อส่วนนี้จะพูดถึงตารางเปรียบเทียบความสัมพันธ์ระหว่างผู้ใช้ที่เกี่ยวข้องกับระบบกับ
Requirement ต่างๆ
IEEE Requirement Standard
เป็นองค์กรที่กำหนดมาตรฐานหลายๆมาตรฐานขึ้นมาในวงการคอมพิวเตอร์
, วิศวะไฟฟ้า , อิเล็คทรอนิคส์ Requirement ก็เช่นกัน โดยที่ IEEE กำหนดมาตรฐานไว้ดังนี้
1. ต้องมีบทนำ ( Introduction )
2. อธิบายรายละเอียดทั่วๆไปของระบบ ( General
Desription )
3. Specification Requirements
4. Appendixs เป็นเอกสารแนบต่อท้าย
5. Index เป็นดัชนีเพื่อใช้ในการค้นหา
Requirement Document Structure
( อาจารย์ไม่ได้พูดอะไรมาก ไปดูในชีทเอาเอง )
บรรยายเมื่อ 27 ธค. 2544 เทอม 2/44
จากบทนี้เรื่องของ
Requirement หลังจากที่เราได้ Requirement มาเป็นเอกสารแล้ว เราจะนำ Requirement
มาทำเป็น Model ระดับขั้นแรกเรียกว่า Existing System หรือ Current System ซึ่งมีไว้เพื่ออธิบายระบบปัจจุบันที่เราศึกษามาว่ามีการทำงานเป็นยังไง
มีความสัมพันธ์เชื่อมโยงระหว่างการทำงานกันอย่างไร ถ้านศ.เรียนในวิชา System
Development ตรงนี้ก็คือ DFD ของระบบปัจจุบันนั้นเอง แต่เราใช้คำว่า Model ก็เพราะ
เขียนได้หลายวิธี
ในบทที่ 5 หลังจากเราเก็บ Requirement แล้วเราต้องมีการตรวจสอบ Requirement ว่าถูกต้องแค่ไหน
เรามักจะเอาโมเดลนี้ไปตรวจสอบ
หลังจากที่เราเขียนระบบปัจจุบันได้เป็น Model หัวหน้าโปรเจ็คก็จะเอาโมเดลนี้ไปคุยกับเจ้าของงานหรือเอาไปตรวจสอบความถูกต้องของ
Requirement หรือนักวิเคราะห์ระบบก็จะวิเคราะห์หาความต้องการของระบบ , ข้อดีข้อด้อย
และออกแบบระบบใหม่เขียนเป็นโมเดลเรียกว่าเป็น Proposed System หรือ New System
ซึ่งเราจะใช้เป็นโมเดลต้นแบบในขั้นตอนการพัฒนา
| Note
: ถ้ากรณีที่ระบบเดิมยังไม่มีระบบอะไรเลย อาจจะเพิ่งตั้งขึ้นมาใหม่ โมเดลของระบบเดิมก็อาจจะหาจากกระบวนการพื้นฐานที่ธุรกิจของเขาจำเป็นต้องมี
ซึ่งอาจจะไม่มีตัวตนจริงๆก็ได้ |