บทที่ 5 ความต้องการ วิศวกรรมความต้องการ แบบจําลองการวิเคราะห์

บทที่ 5 ความต้องการ วิศวกรรมความต้องการ แบบจําลองการวิเคราะห์
Requirement, Requirement Engineering & Analysis Model

ความต้องการ (Requirement)
ความต้องการ ถือเป็นวัตถุดิบที่สำคัญในการพัฒนาระบบหรือการผลิตซอฟต์แวร์ เพื่อสร้างข้อกำหนดถึงหน้าที่และรายละเอียดอื่น ๆ ตามความต้องการของลูกค้า เพื่อให้ซอฟต์แวร์ที่ถูกพัฒนาขึ้นสามารถตอบสนองตรงกับความต้องการที่แท้จริง ในแวดวงการผลิตซอฟต์แวร์ แบ่งความต้องการออกเป็น 2 ระดับ คือ 1. ความต้องการของผู้ใช้ (User Requirement)  แสดงถึงความคาดหวังในบริการหรือการทำงานที่จะได้จากระบบและเงื่อนไขที่ระบบต้องทำตาม เพื่อตอบสนองความต้องการของลูกค้าหรือผู้ที่เกี่ยวข้องกับระบบ  นับว่าเป็นความต้องการในระดับสูงสุด  บุคคลที่ระบุความต้องการในระดับนี้ -> ผู้ใช้ที่ต้องใช้ระบบ หรือผู้บริหาร

2. ความต้องการด้านระบบ (System Requirement)  เป็นการกำหนดความต้องการของการทำงาน ฟังก์ชัน และบริการต่าง ๆ ของระบบในระดับรายละเอียด และจัดทำเป็นข้อกำหนดหน้าที่ของระบบ (Functional Specification)  บุคคลที่ระบุความต้องการในระดับนี้ -> บุคคลที่ใช้ระบบโดยตรง และบุคคลที่จำเป็นต้องทราบการทำงานของระบบ 3

“ความต้องการด้านซอฟต์แวร์ (Software Requirement)”  มีความสัมพันธ์กันอย่างมากกับความต้องการด้านระบบ เนื่องจากซอฟต์แวร์เป็นองค์ประกอบหนึ่งของระบบ  เป็นการรวบรวมคุณสมบัติทางด้านเทคนิคของซอฟต์แวร์ ที่แสดงถึงคำสั่งและบริการต่าง ๆ ที่ซอฟต์แวร์สามารถทำได้ เป็นส่วนที่เตรียมไว้สำหรับการพัฒนาซอฟต์แวร์ [IEEE, 2004] 4

ประเภทของความต้องการด้านซอฟต์แวร์
ความต้องการด้านซอฟต์แวร์ แบ่งออกเป็น 3 ประเภท ได้แก่  ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement)  ความต้องการที่ไม่ใช่หน้าที่หลัก (Non- Functional Requirement)  ความต้องการด้านธุรกิจ (Domain Requirement) 5

ประเภทของความต้องการด้านซอฟต์แวร์ (ต่อ)
ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) สิ่งที่ซอฟต์แวร์ควรทำเป็นหน้าที่หลักในการทำงานหรือเป็นบริการที่ซอฟต์แวร์ควรมี ความต้องการที่เป็นหน้าที่หลักของระบบจะต้องครบถ้วนตามที่ผู้ใช้ต้องการ (Complete) และต้องสอดคล้องกัน (Consistency) ตัวอย่างระบบงานทะเบียนของมหาวิทยาลัย ซึ่งมีผู้ใช้คือ นิสิต อาจารย์ และเจ้าหน้าที่ฝ่ายทะเบียน ต้องการให้ซอฟต์แวร์ระบบทำหน้าที่ได้ ดังนี้  นิสิตสามารถตรวสอบผลการเรียนและสภาพนิสิตได้  อาจารย์สามารถตรวจสอบกลุ่มนิสิตในรายวิชาที่เป็นผู้สอนได้  เจ้าหน้าที่ฝ่ายทะเบียนสามารถเพิ่ม ลบ และแก้ไขข้อมูลต่าง ๆ ในระบบตามหน้าที่ได้ 6

ความต้องการที่ไม่ใช่หน้าที่หลัก (Non- Functional Requirement) เป็นความต้องการที่ไม่ได้เกี่ยวข้องโดยตรงกับหน้าที่หรือฟังก์ชันหลักของระบบ แต่เกี่ยวข้องในทางอ้อม เช่น เงื่อนไขการทำงานของฟังก์ชันหรือบริการ เงื่อนไขด้านเวลาที่ใช้ในการพัฒนาซอฟต์แวร์ ตลอดจนเงื่อนไขในการดำเนินงานและมาตรฐานที่ใช้ เช่น ระบบจะต้องเชื่อถือได้ ต้องมีระยะเวลาตอบสนองที่เร็ว และมีความปลอดภัยสูง เป็นต้น ตัวอย่างความต้องการที่ไม่ใช่หน้าที่หลัก เช่น ความต้องการด้านประสิทธิภาพของผลิตภัณฑ์ (Performance Requirement) ความต้องการด้านความน่าเชื่อถือ (Reliability Requirement) ความต้องการด้านการทำงานข้ามแพลตฟอร์มได้ (Portability Requirement) เป็นต้น 7

ความต้องการด้านธุรกิจ (Domain Requirement) เป็นความต้องการที่เกี่ยวข้องกับงานหลักของระบบธุรกิจที่ต้องการซอฟต์แวร์มาสนับสนุนโดยเฉพาะ เป็นได้ทั้งความต้องการที่เป็นหน้าที่หลักของระบบ เป็นเงื่อนไขของฟังก์ชันใด ๆ หรือเป็นเงื่อนไขในการคำนวณหาผลลัพธ์ใด ๆ ของระบบ ตัวอย่าง การคำนวณหาปริมาณสั่งซื้อที่ประหยัดที่สุด ให้ใช้สูตรในการคำนวณ ดังนี้ เมื่อ Q = ปริมาณการสั่งซื้อที่เหมาะสม (ต้นทุนรวมต่ำสุด) D = ปริมาณความต้องการต่อปี S = ค่าใช้จ่ายในการสั่งซื้อต่อครั้ง H = ค่าใช้จ่ายในการเก็บรักษาต่อชิ้นต่อปี 8

เอกสารความต้องการด้านซอฟต์แวร์
เอกสารความต้องการด้านซอฟต์แวร์ (Software Requirement Document) เรียกได้อีกอย่างหนึ่งว่า “ข้อกำหนดความต้องการด้านซอฟต์แวร์ (Software Requirement Specification: SRS)” ควรระบุทั้งข้อมูลความต้องการของผู้ใช้ (User Requirement) และความต้องการด้านระบบ (System Requirement) ต้องมีรูปแบบที่มีมาตรฐานและเป็นทางการ เพื่อให้ผู้ที่เกี่ยวข้องกับการใช้เอกสารเข้าใจตรงกัน  IEEE ได้กำหนดโครงสร้างของเอกสารความต้องการด้านซอฟต์แวร์ไว้ [Davis, 1993] ดังนี้ 9

โครงสร้างของเอกสารความต้องการด้านซอฟต์แวร์ มีรายละเอียดดังต่อไปนี้ 1. บทนำ (Introduction) 1.1 วัตถุประสงค์ของเอกสาร 1.2 ขอบเขตของผลิตภัณฑ์ 1.3 นิยาม คำย่อ และตัวอักษรย่อต่าง ๆ 1.4 เอกสารอ้างอิง 1.5 สรุปส่วนอื่น ๆ ของเอกสาร 2. รายละเอียดทั่วไป (General Description) 2.1 มุมมองเกี่ยวกับผลิตภัณฑ์ 2.2 ฟังก์ชันของผลิตภัณฑ์ 2.3 คุณสมบัติของผู้ใช้ 2.4 ข้อบังคับทั่วไป 2.5 สมมติฐานและส่วนเพิ่มเติม 10

โครงสร้างของเอกสารความต้องการด้านซอฟต์แวร์ มีรายละเอียดดังต่อไปนี้ (ต่อ) 3. ข้อกำหนดความต้องการ (Specification Requirement) กล่าวถึงความต้องการที่เป็นหน้าที่หลักและไม่ใช่หน้าที่หลัก เช่น ความต้องการด้านฐานข้อมูล ข้อบังคับในการออกแบบ ฟังก์ชัน และการแสดงผล เป็นต้น 4. ภาคผนวก (Appendices) 5. ดัชนี (Index) 11

วิศวกรรมความต้องการ วิศวกรรมความต้องการ (Requirement Engineering)
 หมายถึง กระบวนการที่จะทำให้วิศวกรรมซอฟต์แวร์ เข้าใจและเข้าถึงความต้องการของลูกค้าได้อย่างแท้จริง  ด้วยการสกัดความต้องการ ตรวจสอบ และนิยามความต้องการ เพื่อนำไปสร้างเป็นข้อกำหนดความต้องการด้านระบบหรือซอฟต์แวร์ ที่จะใช้เป็นจุดเริ่มต้นในการพัฒนาระบบในขั้นตอนต่อไป [Jawadekar, 2004]  นอกจากนี้ วิศวกรรมความต้องการยังรวมไปถึงกระบวนการควบคุมการเปลี่ยนแปลงของความต้องการที่จะเกิดขึ้นด้วย เรียกว่า “การจัดการความต้องการ (Requirement Management)”  ดังนั้น การวิศวกรรมความต้องการจึงช่วยให้ซอฟต์แวร์ที่ผลิตออกมา สามารถแก้ปัญหาหรือช่วยสนับสนุนการทำงานของลูกค้าได้อย่างถูกต้องตรงตามความต้องการที่แท้จริง 12

วิศวกรรมความต้องการ วิศวกรรมความต้องการ (Requirement Engineering) (ต่อ)  เป้าหมายของวิศวกรรมความต้องการ คือการสร้างและปรับปรุงเอกสารข้อกำหนดความต้องการ ทั้งทางด้านระบบและด้านซอฟต์แวร์ ให้เป็นเอกสารที่มีคุณภาพมากที่สุด 13

งานย่อยของงานวิศวกรรมความต้องการ
งานย่อยในกระบวนการด้านวิศวกรรมความต้องการ  แบ่งออกได้เป็น 7 ด้าน ดังนี้ 1. การเริ่มต้นวิเคราะห์ (Inception) 2. การเจาะลึกความต้องการ (Elicitation) 3. การขยายความรายละเอียด (Elaboration) 4. การเจรจาต่อรอง (Negotiation) 5. การจัดทำข้อกำหนด (Specification) 6. การตรวจสอบความถูกต้อง (Validation) 7. การจัดการความต้องการ (Requirement Management)  งานบางอย่างสามารถทำไปพร้อม ๆ กัน แบบขนานได้ และทุกงานต้องปรับให้เข้ากับความจำเป็นของโครงการ เพื่อให้บรรลุถึงสิ่งที่ลูกค้าต้องการอย่างแท้จริง 14

1. การเริ่มต้นวิเคราะห์ (Inception) เริ่มต้นจากการตั้งคำถามเปิด เพื่อทำความเข้าใจพื้นฐานของปัญหาและทางแก้ปัญหา รวมถึงการสื่อสารที่มีประสิทธิภาพกับบุคลากรที่ต้องการทางแก้ปัญหา และสร้างความร่วมมือระหว่างลูกค้ากับผู้พัฒนาระบบ 15

2. การเจาะลึกความต้องการ (Elicitation) ถามความต้องการของลูกค้า และผู้ใช้งานระบบ ว่าต้องการอะไร เป้าหมายของระบบคืออะไร ปัญหาที่พบในการทำงานย่อยนี้ คือ - ปัญหาของการหาขอบเขตระบบ (Problem of Scope) ขอบเขตระบุไม่ชัดเจน ระบุรายละเอียดที่ไม่จำเป็น - ปัญหาของการทำความเข้าใจ (Problem of Understanding) ลูกค้าไม่แน่ใจว่าอะไรเป็นสิ่งที่เขาต้องการ หรือไม่มีความเข้าใจอย่างเต็มที่เกี่ยวกับโดเมนของปัญหา - ปัญหาการไม่คงทน (Problem of volatility) ความต้องการของระบบมักเปลี่ยนไปตามกาลเวลา จึงต้องมีระบบระเบียบแบบแผนในการรวบรวมความต้องการ 16

เทคนิคการเก็บรวบรวมความต้องการ 1. การสัมภาษณ์ (Interview) นิยมใช้มากที่สุด 2. การแสดงลำดับเหตุการณ์ (Scenario) เป็นการเตรียมคำถามตามลำดับงานของผู้ใช้ การรวบรวมความต้องการด้วยเทคนิคนี้ จะเชื่อมโยงไปยังการสร้างแบบจำลอง Use Case ได้ง่าย 3. สร้างต้นแบบ (Prototype) เป็นเทคนิคที่ทำให้ผู้ใช้เข้าใจสถานการณ์และคำถามได้ง่าย ตัวอย่างเช่น การออกแบบจอภาพบนกระดาษ เพื่อทดสอบการยอมรับความต้องการในเบื้องต้น 17

เทคนิคการเก็บรวบรวมความต้องการ (ต่อ) 4. การประชุม (Facilitated Meeting) เป็นการเรียกกลุ่มบุคคลที่เกี่ยวข้องมาประชุม เพื่อขอความคิดเห็นและความต้องการ เป็นการระดมความคิดเพื่อแก้ไขปัญหาเมื่อพบข้อขัดแย้งในความต้องการ เทคนิคนี้ จะทำให้ได้ข้อมูลความต้องการที่มีคุณภาพมากกว่าวิธีอื่น แต่ต้องระมัดระวังเรื่องความขัดแย้งระหว่างกลุ่มบุคคลที่อาจเกิดขึ้นได้ 5. การสังเกต (Observation) โดยการตรวจสอบสภาพแวดล้อมการทำงานของผู้ใช้ในระบบเดิม จะทำให้พบกับปัญหาและวิธีการแก้ไขที่เกิดขึ้นกับผู้ใช้อย่างแท้จริง เป็นวิธีการที่ทำให้เข้าใจกระบวนการทางธุรกิจได้ดีมากขึ้น แต่มีค่าใช้จ่ายค่อนข้างสูง 18

งานย่อยในกระบวนการด้านวิศวกรรมความต้องการ (ต่อ) 3. การขยายความรายละเอียด (Elaboration) การนำสารสนเทศที่ได้รับจากลูกค้าระหว่างการเริ่มต้นวิเคราะห์ และการเจาะลึกความต้องการมาขยายและแจกแจงรายละเอียดเพิ่มเติม ด้วยการสร้างและการเพิ่มเติมรายละเอียดการใช้งานของผู้ใช้ (User Scenario) ซึ่งจะอธิบายว่าผู้ใช้งานสุดท้าย หรือ Actor อื่น ๆ จะทำงานกับระบบอย่างไร กิจกรรมนี้มุ่งจะพัฒนาแบบจำลองทางเทคนิคที่ละเอียดของหน้าที่การทำงาน รวมถึงลักษณะและข้อจำกัดของซอฟต์แวร์ 19

งานย่อยในกระบวนการด้านวิศวกรรมความต้องการ (ต่อ) 4. การเจรจาต่อรอง (Negotiation) ลูกค้าหรือผู้ใช้งานมักร้องขอมากกว่าที่ระบบจะทำให้สำเร็จและอ้างว่าความต้องการเหล่านั้นสำคัญมากต่อความจำเป็นทางธุรกิจ นักวิศวกรความต้องการต้องประสานงานผ่านกระบวนการเจรจาต่อรองกับลูกค้า ถึงการจัดลำดับความต้องการ ตามลำดับความสำคัญ ระบุและวิเคราะห์ความเสี่ยงที่มากับแต่ละความต้องการ พร้อมทั้งประมาณค่าความพยายามในการพัฒนาระบบอย่างคร่าว ๆ เพื่อใช้ในการประมาณผลกระทบของแต่ละความต้องการต่อค่าใช้จ่ายของโครงการและเวลาส่งมอบ และปรับเปลี่ยนความต้องการบางส่วน เพื่อให้ทุกฝ่ายบรรลุความพอใจ 20

งานย่อยในกระบวนการด้านวิศวกรรมความต้องการ (ต่อ) 5. การจัดทำข้อกำหนด (Specification) จัดทำเป็นเอกสาร เป็นการรวบรวมข้อกำหนด เป็นต้นแบบของโปรแกรม การจัดทำข้อกำหนด ที่บ่งบอกถึงคุณลักษณะของซอฟต์แวร์ โดยเอกสารเหล่านี้จะต้องสามารถตรวจสอบ ประเมินค่า และยอมรับได้ จำเป็นต้องมีความยืดหยุ่น โดยเฉพาะสำหรับระบบขนาดใหญ่ 21

5. การจัดทำข้อกำหนด (Specification) (ต่อ) เอกสารที่เกี่ยวข้อง เอกสารนิยามระบบ (System Definition Document) เรียกอีกชื่อหนึ่งว่า “เอกสารความต้องการของผู้ใช้ (User Requirement Document)” เป็นเอกสารบันทึกความต้องการด้านระบบของผู้ใช้ตามหลักการและเหตุผล หรือที่มาของระบบ เอกสารต้องเขียนด้วยภาษาที่เข้าใจง่าย เช่น ใช้คำศัพท์ที่ลูกค้าใช้ในงานธุรกิจแต่ละวัน เป็นต้น เอกสารยังต้องแสดงรายละเอียดของสภาพแวดล้อมภายนอกระบบ ข้อจำกัด สมมติฐาน ความต้องการที่ไม่ใช่หน้าที่หลักของระบบ และอาจแนบแบบจำลองความต้องการในระดับสูง (Context System) แผนภาพลำดับเหตุการณ์ (Scenario) หรือเอ็นติตี้ (Entity) ที่สำคัญ ตลอดจนข้อมูลและลำดับขั้นตอนการทำงาน 22

5. การจัดทำข้อกำหนด (Specification) (ต่อ) เอกสารที่เกี่ยวข้อง เอกสารข้อกำหนดความต้องการด้านระบบ (System Requirement Specification) นักพัฒนาระบบจะแยกรายละเอียดความต้องการด้านระบบออกจากรายละเอียดความต้องการด้านซอฟต์แวร์ เอกสารนี้จะต้องถูกกำหนดขึ้นมาก่อน เพื่อนำไปใช้กำหนดความต้องการด้านซอฟต์แวร์ภายหลัง 23

5. การจัดทำข้อกำหนด (Specification) (ต่อ) เอกสารที่เกี่ยวข้อง เอกสารข้อกำหนดความต้องการด้านซอฟต์แวร์ (Software Requirement Specification: SRS) เป็นเอกสารที่ระบุถึงหน้าที่ของซอฟต์แวร์ ช่วยให้ทีมพัฒนาทราบว่าต้องพัฒนาอะไรบ้าง เปรียบเสมือนข้อตกลงพื้นฐานระหว่างลูกค้ากับบริษัทผู้ผลิต เพื่อให้เข้าใจตรงกันว่า สิ่งใดที่ซอฟต์แวร์ต้องทำและสิ่งใดที่เป็นเงื่อนไข 24

งานย่อยในกระบวนการด้านวิศวกรรมความต้องการ (ต่อ) 6. การตรวจรับ (Validation) ขั้นตอนนี้จะเป็นการประเมินในแง่ของคุณภาพ เป็นการทบทวนข้อกำหนด เพื่อให้มั่นใจว่าทุก ๆ ความต้องการได้ระบุไว้อย่างชัดเจน มีการตรวจสอบและแก้ไขข้อความที่ยังคลุมเครือ ข้อความที่ละเลยไปและข้อผิดพลาดอื่น ๆ ทีมทบทวนประกอบด้วย นักวิศวกรซอฟต์แวร์ ลูกค้าผู้ใช้งาน และผู้มีส่วนได้ส่วนเสียในธุรกิจอื่น ๆ ทำหน้าที่ตรวจสอบข้อกำหนด เพื่อมองหาข้อผิดพลาดในเนื้อหาหรือการตีความ 25

6. การตรวจรับ (Validation) (ต่อ) การตรวจสอบเอกสารข้อกำหนดความต้องการ ควรตรวจสอบตามลักษณะดังต่อไปนี้ 1. มีความเที่ยงตรง (validity) ความต้องการเกิดจากความต้องการของผู้ใช้อย่างทั่วถึงและยุติธรรม 2. มีความสอดคล้อง (consistency) ความต้องการในเอกสารจะต้องไม่มีการทับซ้อนหรือไม่มีความขัดแย้งกัน 3. มีความครบถ้วนสมบูรณ์ (completeness) ระบุรายละเอียดฟังก์ชันและบริการอย่างครบถ้วน 4. มีความเป็นไปได้ (feasibility) ทางด้านเทคโนโลยี งบประมาณ และระยะเวลาในการพัฒนา 5. สามารถพิสูจน์ได้ ( verifiability) ต้องสามารถทดสอบและทดลองให้ลูกค้าเห็นถึงการทำงานจริงของระบบได้ 26

6. การตรวจรับ (Validation) (ต่อ) เทคนิคในการตรวจสอบความต้องการ 1. การทบทวนความต้องการ (Requirement Review) เป็นการตรวจสอบเอกสารความต้องการอย่างละเอียด เพื่อตรวจหาข้อผิดพลาด ที่ไม่ชัดเจน และไม่ตรงตามมาตรฐานที่กำหนด 2. การจัดทำต้นแบบ (Prototyping) เป็นการสร้างต้นแบบของระบบเพื่อสาธิตให้ผู้ใช้ดู เป็นเทคนิคที่ดีที่สุดในการตรวจสอบความต้องการ และมีความชัดเจน แต่ต้องใช้เงินทุนสูง 3. การสร้างแบบทดสอบ (Test-Case Generation) โดยนำแบบทดสอบนั้นไปออกแบบหรือพัฒนาระบบขึ้นใช้ ถ้าทำได้ยาก ควรพิจารณาความต้องการนั้นใหม่ มักใช้กับการพัฒนาซอฟต์แวร์แบบ eXtreme Programming (XP) 27

Extreme programming (XP)
เป็นกระบวนการพัฒนาซอฟต์แวร์ที่ได้ กำหนดวิธีการที่จะทำให้ลูกค้าและโปรแกรมเมอร์ ทำงานร่วมกันในทีม เพื่อสร้างบรรยากาศใน การสื่อสารให้เกิดขึ้นในทีม การทำงานร่วมกัน สามารถช่วยแก้ปัญหาจำนวนมากที่เกิดขึ้น ระหว่างและหลังการสร้างซอฟต์แวร์ได้

งานย่อยในกระบวนการด้านวิศวกรรมความต้องการ (ต่อ) 7. การจัดการความต้องการ (Requirement Management) ความต้องการในระบบมักเปลี่ยนแปลงได้ตลอดช่วงชีวิตของระบบ การจัดการความต้องการเป็นชุดของกิจกรรมที่ช่วยให้ทีมงานกำหนดกลไกในการควบคุมและติดตามความสำเร็จ และการเปลี่ยนแปลงความต้องการ ณ เวลาใดเวลาหนึ่งขณะที่โครงการกำลังดำเนินไป กิจกรรมเหล่านี้ จะเหมือนกับเทคนิคการจัดการโครงแบบซอฟต์แวร์ (Software Configuration Management: SCM) 29

7. การจัดการความต้องการ (Requirement Management) (ต่อ) สาเหตุของการเปลี่ยนแปลงความต้องการ 1. ผู้ใช้มีหลายกลุ่ม ทำให้ความต้องการและลำดับความสำคัญของความต้องการแตกต่างกันออกไป ทำให้เกิดความขัดแย้ง จำเป็นต้องมีการปรับสมดุลของความต้องการใหม่ 2. เกิดความขัดแย้งระหว่างผู้ใช้ที่จ่ายเงินลงทุน กับผู้ใช้ที่เป็นผู้ใช้ระบบโดยตรง จึงอาจทำให้ต้องเพิ่มฟังก์ชันบางอย่างตามความต้องการของผู้ใช้โดยตรง 3. มีการเปลี่ยนสภาพแวดล้อมทางธุรกิจและเทคโนโลยีภายหลังจากที่มีการติดตั้งใช้ระบบงานแล้ว 30

7. การจัดการความต้องการ (Requirement Management) (ต่อ) เนื่องจากการจัดการความต้องการเป็นกระบวนการที่ต้องใช้งบประมาณค่อนข้างสูง ดังนั้น จึงต้องมีการวางแผนก่อนเริ่มดำเนินงาน ตามกิจกรรมต่อไปนี้ 1. จำแนกความต้องการที่เปลี่ยนแปลง (Volatile Requirement) และความต้องการที่ไม่เปลี่ยนแปลง (Enduring Requirement) 2. วางแผนการจัดการความต้องการ โดยระบุความเป็นเอกลักษณ์ให้กับทุกความต้องการ กำหนดกิจกรรมการประเมินผลกระทบและต้นทุนที่เกิดจากการเปลี่ยนแปลง กำหนดความสัมพันธ์ของความต้องการแต่ละรายการ และใช้ Case Tool เข้าช่วยจัดการความต้องการเพื่อให้จัดการข้อมูลได้ง่ายขึ้น 3. จัดการกับการเปลี่ยนแปลงความต้องการ เพื่อให้การเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นมีความสอดคล้องกัน โดยอาศัยหลักการจัดการโครงแบบของระบบ (Configuration Management) ความเป็นเอกลักษณ์ คือ ไม่ให้ความต้องการซ้ำซ้อนกันและเพื่อการอ้างอิงถึง 31

การวิเคราะห์ความต้องการ (Requirement Analysis) การแบ่งกลุ่มความต้องการ (Requirement Classification) เพื่อให้การสร้างแบบจำลองและการออกแบบสถาปัตยกรรมง่ายขึ้น จึงควรจำแนกประเภทความต้องการไว้เป็นกลุ่ม ตามลักษณะดังต่อไปนี้ แบ่งเป็นความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) และไม่ใช่หน้าที่หลัก (Non-Functional Requirement) แบ่งเป็นความต้องการที่เกี่ยวกับผลิตภัณฑ์ (Product) และกระบวนการ (Process) แบ่งกลุ่มตามลำดับความสำคัญของความต้องการ โดยทั่วไปแบ่งเป็นระดับ ได้แก่ จำเป็น (Mandatory) จะเป็นความต้องการที่สำคัญที่สุดขององค์กร ปรารถนาสูง (Highly Desirable), ปานกลาง (Desirable) และละเว้นได้ (Optional) 32

การวิเคราะห์ความต้องการ (Requirement Analysis) การแบ่งกลุ่มความต้องการ (Requirement Classification) (ต่อ) แบ่งกลุ่มตามขอบเขตของความต้องการ จะให้ความสำคัญต่อความต้องการที่มีขอบเขตกว้าง ซึ่งจะส่งผลกระทบต่อการพัฒนาซอฟต์แวร์มากกว่า แบ่งกลุ่มตามการเปลี่ยนแปลงของความต้องการ ได้แก่ ความต้องการที่เปลี่ยนแปลงได้ (Volatility) และความต้องการที่ไม่สามารถเปลี่ยนแปลงได้ (Stability) เพื่อความยืดหยุ่นหากต้องมีการแก้ไขซอฟต์แวร์ 33

การวิเคราะห์ความต้องการ (Requirement Analysis) การสร้างแบบจำลองความต้องการ (Requirement Modeling) หรือเรียกว่า “แบบจำลองแนวคิด (Conceptual Model)” ใช้เพื่อจำลองความต้องการที่รวบรวมมาได้ ทำให้มองเห็นภาพรวมของความต้องการได้ตรงกัน และชี้ถึงจุดผิดพลาดของความต้องการได้ง่าย สามารถแก้ไขได้ทันทีก่อนนำไปออกแบบ ชนิดและวิธีการสร้างแบบจำลอง จะแตกต่างกันไปตามแนวทางของการวิเคราะห์ระบบ เช่น แนวทางเชิงโครงสร้าง (Structured System Analysis And Design: SSAD) จะใช้ DFD (Data Flow Diagram) และ ERD (Entity Relationship Diagram) แนวทางเชิงวัตถุ (Object-Oriented Analysis And Design: OOSAD) จะใช้แบบจำลอง Use case, Class/Object Diagram 34

การวิเคราะห์ความต้องการ (Requirement Analysis) การออกแบบสถาปัตยกรรมและการจัดสรรความต้องการ (Architectural Design and Requirement Allocation) การออกแบบสถาปัตยกรรม (Architectural Design) เพื่อต้องการแสดงให้ผู้ใช้หรือลูกค้ามองเห็นได้ชัดเจนว่าคอมโพเน้นท์หรือส่วนประกอบใดของซอฟต์แวร์ ที่เข้ามาสนับสนุนและรองรับความต้องการส่วนใดของผู้ใช้ การจัดสรรความต้องการ (Requirement Allocation) จัดสรรความต้องการให้เข้ากับองค์ประกอบแต่ละส่วนของซอฟต์แวร์ เพื่อนำไปวิเคราะห์ ในระดับรายละเอียดเพิ่มมากขึ้น 35

การวิเคราะห์ความต้องการ (Requirement Analysis) ตัวอย่างเช่น ความต้องการให้พัฒนาประสิทธิภาพของระบบห้ามล้อ (Brake System) ของรถยนต์ หัวข้อความต้องการคือ ระยะหยุด การขับขี่ในสภาพไม่ปลอดภัย ความนุ่มนวลในการทำงาน และแรงดันของเบรก ความต้องการจะถูกจัดสรรให้กับฮาร์ดแวร์ของระบบเบรก และระบบป้องกันล้อตาย (ABS: Anti-Lock Breaking System) และทำให้การกำหนดความต้องการในด้านอื่น ๆ ตามไปด้วย เช่น ความต้องการด้านประสิทธิภาพของ ABS เป็นต้น 36

แบบจำลองการวิเคราะห์ (Analysis Model)
 แบบจำลอง คือ สัญลักษณ์ที่ใช้จำลองข้อเท็จจริงต่าง ๆ ที่เกิดขึ้นในระบบ เป็นแผนภาพที่แสดงให้เห็นในแต่ละมุมมองของระบบ ช่วยให้การสื่อสารระหว่างกลุ่มบุคคลมีความถูกต้องตรงกัน  แบบจำลองการวิเคราะห์ คือ แบบจำลองที่เขียนขึ้นจากข้อกำหนดความต้องการของระบบ สะท้อนให้เห็นถึงหน้าที่การทำงานของระบบด้านต่าง ๆ และจะถูกนำไปใช้ในระยะการออกแบบต่อไป 37

การจำแนกกลุ่มของแบบจำลองแตกต่างกันออกไปตามแนวทางที่เลือกใช้ ในที่นี้จะขอจำแนกแบบจำลองตามแนวทาง 2 แนวทาง ดังนี้  แนวทางเชิงโครงสร้าง (Structured System Approach) – Process Model(DFD) + Data Model (ER)  แนวทางเชิงวัตถุ (Object-Oriented Approach) – UML (Unified Modeling Language) 38

 แบบจำลองตามแนวทางเชิงโครงสร้าง (Structured Analysis) จะพิจารณากระบวนการทำงาน (Process) กับข้อมูล (Data) ของระบบแยกออกจากกัน แบบจำลองที่ต้องสร้างมี 2 ชนิด ได้แก่ แบบจำลองกระบวนการ (Process Model) ใช้จำลองขั้นตอนการทำงานของระบบ แผนภาพที่ใช้เรียกว่า “แผนภาพกระแสข้อมูล (Data Flow Diagram: DFD)” แบบจำลองข้อมูล (Data Model) ใช้จำลองโครงสร้างข้อมูลทั้งหมดในระบบ แผนภาพที่ใช้เรียกว่า “แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล (Entity Relationship Diagram: ERD)” 39

 แบบจำลองกระบวนการ (Process Model) แผนภาพกระแสข้อมูล (Data Flow Diagram: DFD) หมายถึง แผนภาพที่แสดงถึงทิศทางการไหลของข้อมูลที่มีอยู่ในระบบ จากกระบวนการทำงานหนึ่งไปอีกกระบวนการหนึ่ง หรือไปยังส่วนอื่นที่เกี่ยวข้อง เช่น แหล่งจัดเก็บข้อมูล (Data Store) ผู้ที่เกี่ยวข้องที่อยู่นอกระบบ (External Agent) 40

แสดงตัวอย่าง DFD ของระบบสารสนเทศเพื่อการขายรองเท้า
รูปภาพจาก: 41

 แบบจำลองกระบวนการ (Process Model) (ต่อ) ประเภทของแผนภาพกระแสข้อมูล แผนภาพกระแสข้อมูลเชิงตรรกะ (Logical DFD) – แสดงกระบวนการของระบบในระดับแนวคิด (Conceptual) เท่านั้น นั่นคือ แสดงให้เห็นถึงการไหลของข้อมูลพอสังเขป ไม่ลงลึกถึงรายละเอียดและไม่ได้ใช้คำศัพท์ทางเทคนิคมากนัก นิยมใช้ในขั้นตอนการวิเคราะห์ความต้องการ แผนภาพกระแสข้อมูลเชิงกายภาพ (Physical DFD) – แสดงรายละเอียดภายในกระบวนการ เช่น ชื่อกระบวนการ วิธีการทำงาน แหล่งกำเนิด และปลายทาง เป็นต้น มีการใช้ศัพท์เทคนิคเพื่อสื่อสารกับโปรแกรมเมอร์ได้ง่ายขึ้น แผนภาพชนิดนี้ใช้ในขั้นตอนการออกแบบระบบ 42

 แบบจำลองกระบวนการ (Process Model) (ต่อ) Context Diagram หมายถึง แผนภาพกระแสข้อมูลระดับบนสุดที่แสดงภาพรวมการทำงานของระบบที่มีความสัมพันธ์กับสภาพแวดล้อมนอกระบบ Context Diagram ช่วยกำหนดขอบเขตของระบบที่จะพัฒนาได้ 43

แสดงตัวอย่าง Context Diagram ของระบบการเช่าหนังสือ
รูปภาพจาก

 แบบจำลองข้อมูล (Data Model) แผนภาพแสดงความสัมพันธ์ของข้อมูล (Entity Relationship Diagram : ERD) หมายถึง แผนภาพที่ใช้สำหรับจำลองข้อมูล ซึ่งจะประกอบด้วย Entity และความสัมพันธ์ของข้อมูล (Relationship) ที่เกิดขึ้นทั้งหมดในระบบ Entity จะแทนกลุ่มของข้อมูลที่เป็นเรื่องเดียวกันหรือเกี่ยวข้องกัน เช่น Entity-Customer, Entity-Order และ Entity-Sale Order เป็นต้น ทุก Entity จะมี Attribute เป็นตัวบ่งบอกถึงลักษณะหรือคุณสมบัติของ Entity ERD มีประโยชน์อย่างมากในการออกแบบฐานข้อมูล 45

แสดงตัวอย่าง ERD ของระบบสารสนเทศเพื่อการขายรองเท้า

แสดงตัวอย่าง ER Diagram

 แบบจำลองตามแนวทางเชิงวัตถุ (Object Oriented Analysis)  จะพิจารณาทุก ๆ สิ่งในระบบที่สนใจเป็นวัตถุ (Object) ซึ่งประกอบไปด้วยข้อมูล (คุณลักษณะ: Attributes) และกระบวนการทำงาน (พฤติกรรม:Behavior/Method/Operation) รวมอยู่ด้วยกัน จึงเป็นการพิจารณาทั้งข้อมูลและกระบวนการทำงานไปพร้อม ๆ กัน  ระบบหนึ่ง ๆ จะประกอบด้วย Object จำนวนมากที่สัมพันธ์กัน เพื่อทำงานร่วมกัน ให้เกิดเป็นการทำงานของระบบ  หาก Object ใดที่มีคุณลักษณะและพฤติกรรมเหมือนกันจะถูกจัดให้อยู่ใน “คลาส (Class)” เดียวกัน เช่น Object “นักเรียน (Student)” กับ “ครู (Teacher)” มีลักษณะหู ตา จมูก หรือแขน ขา เหมือนกัน จึงจัดให้อยู่ในคลาสเดียวกัน คือ คลาส “คน (Person)” เป็นต้น 48

 แบบจำลองตามแนวทางเชิงวัตถุ (Object Oriented Analysis) (ต่อ)  ภาษารูปภาพที่ใช้สร้างแบบจำลองเชิงวัตถุ เรียกว่า “UML (Unified Modeling Language)” เป็นสัญลักษณ์ (Notation) ที่ใช้อธิบาย แสดงรายละเอียด จำลองการสร้าง และจัดการกับเอกสารต่าง ๆ ในระบบ เพื่อให้การออกแบบซอฟต์แวร์สามารถทำได้โดยง่าย และปรับปรุงวิธีการทำงานให้ดีขึ้น  UML แบ่งออกเป็น 2 กลุ่ม รวมทั้งหมด 9 แผนภาพ ดังนี้ 1. Structural Diagram เป็นกลุ่มแผนภาพที่แสดงให้เห็นโครงสร้างในส่วนที่ไม่มีการเปลี่ยนแปลง แม้จะมีเหตุการณ์ใด ๆ เกิดขึ้น แบ่งเป็นแผนภาพชนิดต่าง ๆ ดังนี้ - Class Diagram - Object Diagram - Component Diagram - Deployment Diagram 49

แสดงภาพจำลองของคลาส (Class)
50

Class Diagram

 แบบจำลองตามแนวทางเชิงวัตถุ (Object Oriented Analysis) (ต่อ) 2. Behavioral Diagram เป็นกลุ่มแผนภาพที่แสดงให้เห็นภาพเชิงกิจกรรมของระบบ (Dynamic) กล่าวคือ แสดงให้เห็นพฤติกรรมของระบบที่มีการเปลี่ยนแปลงไปเมื่อมีเหตุการณ์ใด ๆ เกิดขึ้น แบ่งเป็นแผนภาพชนิดต่าง ๆ ดังนี้ - Use Case Diagram - Sequence Diagram - Collaboration Diagram - Statechart Diagram - Activity Diagram 52

Use Case Diagram

Activity Diagram Start Stop

Sequence Diagram

Any Question? Q & A

บทที่ 5 ความต้องการ วิศวกรรมความต้องการ แบบจําลองการวิเคราะห์

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "บทที่ 5 ความต้องการ วิศวกรรมความต้องการ แบบจําลองการวิเคราะห์"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

บทที่ 5 ความต้องการ วิศวกรรมความต้องการ แบบจําลองการวิเคราะห์

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "บทที่ 5 ความต้องการ วิศวกรรมความต้องการ แบบจําลองการวิเคราะห์"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ