Chapter 6 Requirements Engineering

บทที่ 6  วิศวกรรมความต้องการ

6.1 ความหมายของวิศวกรรมความต้องการ 

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

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

6.2 กระบวนการวิศวกรรมความต้องการ 

        กิจกรรมของวิศวกรรมความต้องการ จะรวมอยู่ในระยะการวิเคราะห์ความต้องการของกระบวนการผลิตซอฟต์แวร์และเป็นกิจกรรมที่ต้องดำเนินการอย่างเป็นขั้นตอน มีกระบวนการและทีมงานเฉพาะ ประกอบไปด้วยขั้นตอนดังนี้

        ขั้นตอนที่ 1 สกัดความต้องการ (Requirement Elicitation)

        การสกัดความต้องการก็คือ การรวบรวมหรือค้นหาความต้องการ เป็นขั้นตอนของการทำความเข้าใจกับปัญหาที่เกิดขึ้นที่ต้องการแก้ไขด้วยซอฟต์แวร์ โดยเก็บรวบรวมด้วยเทคนิคต่างๆ

        ขั้นตอนที่ 2 วิเคราะห์ความต้องการ (Requirement Analysis)

        เป็นขั้นตอนในการประเมินความต้องการที่รวบรวมมาได้ เพื่อจัดกลุ่มความต้องการ จัดลำดับความสำคัญของความต้องการ แก้ไขความขัดแย้งระหว่างความต้องการ เพื่อให้เกิดความสอดคล้องกัน จากนั้นสร้างแบบจำลองความต้องการในระดับแนวคิด นำเสนอให้ผู้ที่เกี่ยวข้องเพื่อพิจารณายอมรับ หรือแก้ไข 

        ขั้นตอนที่ 3 กำหนดความต้องการ (Requirement Specification) 

        เมื่อได้แบบจำลองที่ได้รับการยอมรับแล้ว จะจัดทำเป็นเอกสารข้อกำหนดความต้องการ โดยเริ่มจากการนิยามความต้องการของระบบ แล้วจัดทำเป็นข้อกำหนดความต้องการด้านระบบ เพื่อนำมาแจกจ่ายเป็นข้อกำหนด ความต้องการด้านซอฟต์แวร์ เอกสารทั้งหมดต้องสามารถตรวจสอบคุณภาพได้ 

        ขั้นตอนที่ 4 ตรวจสอบความต้องการ (Requirement Validation)

        เป็นการทบทวนและตรวจสอบข้อกำหนดความต้องการในเอกสารทั้งหมด เพื่อให้เกิดความเที่ยงตรง สอดคล้อง ครบถ้วนสมบูรณ์ มีความเป็นไปได้ และสามารถพิสูจน์ได้ตามเป้าหมายของกระบวนการ วิศวกรรมซอฟต์แวร์ จากนั้นจะนำไปทดสอบเพื่อให้เกิดการยอมรับจากบุคคลทุกฝ่ายที่เกี่ยวข้อง 

แสดงกระบวนการวิศวกรรมความต้องการ (แบบ Spiral Somerville)

6.3 การสกัดความต้องการ 

        การสกัดความต้องการ (Requirement Elicitation) เป็นขั้นตอนในการเก็บรวบรวมข้อเท็จจริง เพื่อทำความเข้าใจกับปัญหาที่เกิดขึ้น และบทบาทของซอฟต์แวร์ในการทำหน้าที่แก้ปัญหาดังกล่าวนั้น ในขั้นตอนนี้วิศวกรซอฟต์แวร์จะสามารถเข้าถึงเป้าหมายและวัตถุประสงค์ของลูกค้าเป็นอย่างดี 

        เทคนิคการเก็บรวบรวมความต้องการ 

        1. การสัมภาษณ์ (Interview) เป็นวิธีที่นิยมใช้มากที่สุดวิธีหนึ่ง 

        2. การแสดงลำดับเหตุการณ์ (Scenario) เป็นการเตรียมคำถามตามลำดับงานของผู้ใช้ ในแต่ละงานจะมีการตั้งคำถาม 

        3. ต้นแบบ (Prototype) เป็นเทคนิคที่ทำให้ผู้ใช้เข้าใจสถานการณ์และคำถามได้ง่ายเช่นกัน 

        4. การประชุม (Facilitated Meeting) เป็นการเรียกกลุ่มบุคคลที่เกี่ยวข้องเข้าร่วมประชุมเพื่อขอความคิด และความต้องการ เพื่อให้เกิดความเข้าใจในความต้องการอย่างถ่องแท้มากกว่าการทำงานเพียงลำพัง

        5. การสังเกต (Observation) ใช้ตรวจสอบสภาพแวดล้อมการทำงานของผู้ใช้ซอฟต์แวร์ในระบบเดิม เพื่อพบกับปัญหาและวิธีการแก้ไขของผู้ใช้ที่เกี่ยวข้องอย่างแท้จริง

6.4 การวิเคราะห์ความต้องการ 

        การวิเคราะห์ความต้องการ (Requirement Analysis) เป็นการนำข้อมูลความต้องการที่รวบรวมได้มาวิเคราะห์ ประเมินเพื่อจำแนกกลุ่มความต้องการ จากนั้นนำมาจัดลำดับความสำคัญ ดูความสอดคล้อง ขจัดความขัดแย้ง นำไปสร้างเป็นแบบจำลอง และออกแบบสถาปัตยกรรมซอฟต์แวร์เบื้องต้น เพื่อนำไปทดสอบการยอมรับกับลูกค้า เมื่อลูกค้ายอมรับจะได้เอกสารความต้องการทั้งหมด (ฉบับร่าง) 

        การวิเคราะห์ความต้องการมีกิจกรรมย่อยดังนี้ 

แสดงกิจกรรมย่อยของการวิเคราะห์ความต้องการ

        6.4.1 การแบ่งกลุ่มความต้องการ (Requirement Classification) 

                1. ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) และไม่ใช่หน้าที่หลัก Non-Functional Requirement)

                2. แบ่งความต้องการที่เกี่ยวข้องกับผลิตภัณฑ์ และกระบวนการ 

                3. แบ่งกลุ่มตามลำดับความสำคัญของความต้องการ (จำเป็น (Mandatory) ปรารถนาสูง (Highly Desirable) ปานกลาง (Desirable) และละเว้นได้ (Optional))

                4. แบ่งกลุ่มตามขอบเขตความต้องการ โดยให้ความสำคัญต่อความต้องการที่มีขอบเขตกว้าง ซึ่งส่งผลกระทบต่อการพัฒนาซอฟต์แวร์

                5. แบ่งกลุ่มตามความต้องการเปลี่ยนแปลงของความต้องการ ได้แก่ ความต้องการที่เปลี่ยนแปลงได้ (Volatility) และความต้องการที่ไม่สามารถเปลี่ยนแปลงได้ (Stability)

        6.4.2 การสร้างแบบจำลองของความต้องการ (Requirement Modeling) 

                แบบจะลองความต้องการ (Requirement Model) หรือ แบบจำลองแนวคิด (Conceptual Model) ใช้เพื่อจำลองความต้องการที่รวบรวมมาได้ ทำให้ผู้ใช้และบุคคลอื่นๆ ที่เกี่ยวข้องเห็นภาพรวมของความต้องการ เข้าใจความต้องการได้ตรงกับทีมงาน 

                ชนิดและแบบจำลองจะแตกต่างกันออกไปตามแนวทางของการวิเคราะห์ เช่น แนวทางเชิงโครงสร้าง (SSAD ) จะใช้ DFD และ ERD ซึ่งเป็นแบบจำลองกระบวนการ ส่วนแนวทางเชิงวัตถุ (OOSAD) จะใช้แบบจำลอง Use Case เพื่อให้เห็นหน้าที่การทำงานของซอฟต์แวร์ 

                เพื่อประโยชน์ในการออกแบบการทำงานของซอฟต์แวร์ สิ่งสำคัญต่อการสร้างแบบจำลองคือ ระเบียบวิธีปฏิบัติที่ใช้สร้างแบบจำลอง ซึ่งปัจจุบันนิยมใช้ระเบียบวิธีตามภาษาการสร้างต้นแบบจำลองที่เรียกว่า UML (Unified Modeling Language) และ Formal Modeling ที่ใช้สมาการทางคณิตศาสตร์เข้ามาอธิบาย  

                IEEE ได้กำหนดสัญลักษณ์ที่เป็นประโยชน์ในการสร้างแบบจำลองหลายชนิด เช่น IEEE 1320.1, IDEF0 (ใช้สร้างแบบจำลองเชิงฟังก์ชัน) และ IEEE 1320.2, IDEF1X97 (เพื่อสร้างแบบจำลองข้อมูลเป็นต้น)

        6.4.3 การออกแบบสถาปัตยกรรมและการจัดสรรความต้องการ (Architectural Design and Requirement Allocation)

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

                   6.4.4 การเจรจาต่อรองความต้องการ (Requirement Negotiation)

                การเจรจาต่อรองความต้องการเรียกอีกอย่างหนึ่งว่า ?การแก้ไขความขัดแย้งระหว่างความต้องการ (Confict Resolution)? เกิดขึ้นเมื่อการนำเสนอแบบจำลองความต้องการต่อลูกค้าเพื่อรับทราบละยอมรับ หากลูกค้าพบข้อผิดพลาดในข้อกำหนดความต้องการ หรือไม่พอใจในข้อกำหนดความต้องการ หรืออาจต้องการเปลี่ยนแปลง จะเกิดการเจรจาต่อรองความต้องการขึ้น 

                เมื่อผ่านขั้นตอนการวิเคราะห์ความต้องการแล้ว รายการความต้องการต่างๆ ที่ร่างไว้จะมีความถูกต้อง (Validity) สอดคล้อง (Consistence) และความเป็นไปได้ (Feasibility) มากขึ้น พร้อมที่จะนำไปจัดทำข้อกำหนดความต้องการในเอกสารต่อไป

6.5 การกำหนดความต้องการ 

        ข้อกำหนดความต้องการด้านซอฟต์แวร์ส่วนใหญ่จะบ่งบอกถึงคุณลักษณะของซอฟต์แวร์  ซึ่งหมายถึง การสร้างเอกสารความต้องการแสดงรายละเอียดทางด้านซอฟต์แวร์ ที่สามารถตรวจสอบ ประเมินค่า และยอมรับได้ โดยเฉพาะอย่างยิ่งในระบบที่มีความซับซ้อนสูง โดยจะต้องประกอบด้วยรายละเอียดอื่นที่ไม่ใช่คอมโพเน้นท์ซอฟต์แวร์เพียงอย่างเดียว ได้แก่ การนิยามระบบ (System Definition) ความต้องการด้านระบบ (System Requirement) และความต้องการด้านซอฟต์แวร์ (Software Requirement) 

        เอกสารนิยามระบบ (System Definition Document)

                เป็นบันทึกความต้องการด้านระบบของผู้ใช้ เป็นการกำหนดมุมมองในระดับสูงจากมุมมองของผู้ใช้ 

        เอกสารข้อกำหนดความต้องการด้านระบบ (System Requirement Specification) 

                เอกสารความต้องการด้านระบบจะถูกกำหนดขึ้นมาก่อนเพื่อนำไปกำหนดความต้องการด้านซอฟต์แวร์ภายหลัง 

        เอกสารข้อกำหนดความต้องการด้านซอฟต์แวร์ (Software Requirement Specification SRS) 

                เอกสารข้อกำหนดทางด้านซอฟต์แวร์หรือ SRS เปรียบเสมือนข้อตกลงพื้นฐานระหว่างลูกค้ากับผู้ผลิต เพื่อให้เข้าใจตรงกันว่าสิ่งใดที่ซอฟต์แวร์ต้องทำ และสิ่งใดที่เป็นเงื่อนไขหรือข้อห้าม 

6.6 การตรวจสอบความต้องการ 

        เมื่อจัดทำเอกสารข้อกำหนดความต้องการ ขั้นตอนสุดท้ายก่อนนำไปสู่การออกแบบคือการตรวจสอบความต้องการอีกครั้ง เป็นการวิเคราะห์และตรวจสอบข้อผิดพลาดหรือปัญหาที่อาจเกิดขึ้นจากความทับซ้อนของความต้องการ  ซึ่งควรจรวจสอบตามลักษณะดังนี้

        1. ความเที่ยงตรง (Validity) จะต้องตรวจสอบความต้องการของผู้ใช้ทุกๆ กลุ่มอย่างเท่าเทียมกัน

        2. ความสอดคล้อง (Consistency) ความต้องการในเอกสารจะต้องไม่ทับซ้อนกัน ไม่ขัดแย้งกัน

        3. ความครบถ้วนสมบูรณ์ (Completeness) ต้องระบุรายละเอียดฟังก์ชันและบริการครบถ้วน ครอบคลุมความต้องการของผู้ใช่

        4. ความเป็นไปได้ (Feasibility) ตรวจสอบความต้องการด้วยองค์ความรู้เกี่ยวกับเทคโนโลยีที่องค์กรมีอยู่เพื่อให้มั่นใจว่าสามารถนำความต้องการที่ระบุในเอกสารไปพัฒนาระบบได้จริง

        5. สามารถพิสูจน์ได้ (Verifiability) ความต้องการนั้นจำต้องสามารถพิสูจน์เพื่อหาความจริงได้ คือต้องทดสอบและทดลองให้ลูกค้าเห็นถึงการทำงานจรองของระบบที่จะตอบสนองต่อความต้องการที่ระบุในเอกสารได้

        เทคนิคในการตรวจสอบความต้องการ

        1. การทบทวนความต้องการ (Requirement Review) เป็นการตรวจสอบเอกสารความต้องการอย่างละเอียด เพื่อตรวจหาความต้องการ หรือข้อสมมติฐานที่ผิดพลาด หรือถูกละเลย ไม่ชัดเจน ไม่ตรงตามมาตรฐานที่กำหนด โดยตรวจสอบตามลักษณะต่อไปนี้

         - สามารถพิสูจน์ได้ (Verification)

         - สามารถเข้าใจได้ (Comprehensibility)

         - สามารถย้อนกลับไปตรวจสิบได้ (Traceability)

         - สามารถดัดแปลงได้ (Adaptability)

        2. การจัดทำต้นแบบ (Prototyping) เป็นการสร้างต้นแบบของระบบ ขั้นมาเพื่อสาธิตให้ลูกค้าหรือผู้ใช้ระบบดู หรือทดลองใช้ด้วยตนเอง ก็จะทราบว่าตรงตามความต้องการหรือไม่ 

        3. การสร้างแบบทดสอบ (Test-Case Generation) ความต้องการที่ดีจะต้องสามารถทดสอบได้ ถ้าหาดจัดทำแบบทดสอบยางก็แสดงว่าระบบที่จะนำไปพัฒนานั้นยากด้วย

6.7 การจัดการความต้องการ 

        การจัดการความต้องการ ( Requirement Management) คือ กระบวนการทำความเข้าใจและควบคุมการเปลี่ยนแปลงความต้องการที่อาจจะเกิดขึ้นได้ตลอดเวลา ทั้งในช่วงการพัฒนาและระหว่างการใช้งาน 

        การเปลี่ยนแปลงความต้องการอาจเกิดได้จากหลายสาเหตุ ดังนี้

        1. สาเหตุจากมีผู้ใช้หลายกลุ่ม 

        2. สาเหตุจากเงินทุน ข้อจำกัดด้านค่าใช้จ่าย

        3. สาเหตุจากสภาพแวดล้อมและเทคโนโลยีเปลี่ยนแปลง

        6.7.1 ความต้องการที่เปลี่ยนแปลงและไม่เปลี่ยนแปลง 

         1. ความต้องการที่ไม่เปลี่ยนแปลง (Enduring Requirement) เป็นความต้องการแบบคงที่ไม่เปลี่ยนแปลงได้ง่าย เป็นความต้องการจากการทำงานหลักของธุรกิจในแต่ละวัน 

                 2. ความต้องการที่เปลี่ยนแปลง (Volatile Requirement) เป็นความต้องการที่มีการเปลี่ยนแปลงอยู่เสมอ ในระหว่างการพัฒนาหรือติดตั้งระบบเพื่อใช้งานไปแล้ว 

        6.7.2 การวางแผนการจัดการความต้องการ 

                เนื่องจากการจัดการความต้องการเป็นกระบวนการที่ต้องใช้งบประมาณค่อนข้างสูง ดังนั้น จึงต้องมีการวางแผนก่อนเริ่มดำเนินงาน ตามกิจกรรมต่อไปนี้

               1.จำแนกความต้องการ (Requirement Identification) ทีมงานต้องทำการระบุความเป็นเอกลักษณ์ให้กับทุกความต้องการเพื่อไม่ให้ความต้องการซ้ำซ้อนกัน และเพื่อการอ้างอิงถึง 

                 2.กระบวนการจัดการความเปลี่ยนแปลง (Change Management Process) ทีมงานจะต้องกำหนดกิจกรรมในการประเมินผลกระทบและต้นทุนที่เกิดจากการเปลี่ยนแปลง

           3.นโยบายการสืบหา (Traceability Policy) เป็นการกำหนดความสัมพันธ์ระหว่างความต้องการแต่ละรายการ และระหว่างความต้องการกับการออกแบบระบบ แล้วเก็บบันทึกไว้เพื่อประโยชน์ในการบำรุงรักษาต่อไป 

           4. CASE Tool ทีมงานต้องสรรหาเครื่องมือเข้ามาสนับสนุนกระบวนการจัดการความต้องการแต่ละรายการ เนื่องจากเป็นกระบวนการที่ต้องเกี่ยวข้องกับข้อมูลจำนวนมาก เครื่องมือเหล่านี้จะช่วยจัดการข้อมูลได้ง่ายขึ้น 

                การสืบหาส่วนที่ได้รับผลกระทบกระเทือนหรือแหล่งที่มาของความต้องการจึงมีความจำเป็น โดยสามารถสืบหาได้จากรายละเอียดในเอกสารข้อกำหนดความต้องการ สามารถแบ่งได้ 3 ชนิด

                 1. การสืบหาแหล่งที่มา (Source Traceability) เป็นการสืบหาแหล่งที่มาของการเปลี่ยนแปลง เพื่อสอบถามถึงเหตุผลและช่วงเวลาในการเสนอให้เปลี่ยน เพื่อนำเข้าสู่ที่ประชุม

                  2. การสืบหาความต้องการ (Requirement Traceability) เป็นการสืบหาจำนวนความต้องการที่ได้รับผลกระทบจากการเปลี่ยนแปลง เพื่อขยายผลไปยังการสืบหาความต้องการเมื่อเปลี่ยนแปลงไป

                3. การสืบหาในส่วนการออกแบบ (Design Traceability) เป็นการสืบหาส่วนการออกแบบจากความต้องการที่อาจมีการเปลี่ยนแปลงไป เพื่อทำการแก้ไขให้ถูกต้อง

        6.7.3 การจัดการกับการเปลี่ยนแปลงความต้องการ 

                เมื่อมีการยื่นข้อเสนอให้มีการเปลี่ยนแปลงความต้องการเกิดขึ้น  ต้องวิเคราะห์ถึงความคุ้มค่าเมื่อต้องเปลี่ยนแปลงตามข้อเสนอหากมีความคุ้มค่าจะอนุมัติให้ดำเนินการเปลี่ยนแปลงได้ แต่หากพบว่าไม่ได้รับผลตอบแทนที่คุ้มค่าก็จะยกเลิกข้อเสนอนั้นไป

Chapter 5 Software Requirements

บทที่ 5  ความต้องการด้านซอฟต์แวร์

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

5.1 ทำความรู้จักกับความต้องการด้านซอฟต์แวร์ 
     ความต้องการของลูกค้าหรือผู้ใช้เป็นตัวกำหนดฟังก์ชันการทำงาน รูปลักษณ์ ความสามารถ และรายละเอียดอื่นๆ ของระบบหรือซอฟต์แวร์ ความต้องการในแวดวงซอฟต์แวร์จำแนกเป็น 2 ระดับดังนี้ 
           1. ความต้องการของลูกค้า (User Requirement) เป็นความต้องการของลูกค้า หรือผู้ที่เกี่ยวข้องกับระบบ โดยแสดงออกมาในรูปแบบของภาษาธรรมชาติ ที่แสดงถึงความคาดหวังในการบริการ หรือการทำงานที่จะได้รับจากระบบและเงื่อนไขที่ต้องทำตาม
         2. ความต้องการด้านระบบ (System Requirement) เป็นการกำหนดความต้องการของการทำงาน ฟังก์ชันและบริการต่างๆ ของระบบในระดับรายละเอียด เรียกว่าข้อกำหนดของระบบ (Functional Specification)

     นอกจากความต้องการทั้ง 2 ระดับข้างต้นแล้ว ยังมีความต้องการอีกระดับหนึ่งที่คุ้นเคยกันดี นั่นคือ ความต้องการด้านซอฟต์แวร์ (Software Requirement) ซึ่งมีความสัมพันธ์อย่างมากกับความต้องการด้านระบบ เนื่องจากซอฟต์แวร์ก็เป็นความต้องการหนึ่งของระบบเช่นกัน 

5.2 ประเภทความต้องการด้านซอฟต์แวร์ 
        ความต้องการด้านซอฟต์แวร์ แบ่งออกเป็น 3 ประเภท คือ
           1. ความต้องการที่เป็นหน้าที่หลัก (Functional Requirement) คือความต้องการให้ซอฟต์แวร์ทำหน้าที่ใดๆ ตามที่กำหนดไว้      ได้ ซึ่งเป็นสิ่งที่ซอฟต์แวร์ควรจะทำเป็นหน้าที่หลักในการทำงาน หรือเป็นบริการที่ซอฟต์แวร์ควรมี ยกตัวอย่างเช่นระบบทะเบียน

- นักศึกษาสามารถตรวจสอบผลการเรียนและสภาพนักศึกษาได้
- นักศึกษาสามารถลงทะเบียนและทำการเพิกถอนรายวิชาได้ 
         - อาจารย์สามารถตรวจสอลกลุ่มนักศึกษาในรายวิชาที่เป็นผู้สอนได้ 
         - อาจารย์สามารถตรวจสอบผลการเรียนของนักศึกษาในรายวิชาของตน หลังจากส่งผลการเรียนไป
   ยังผ่ายทะเบียนแล้ว เพื่อดูความถูกต้อง 
         - อาจารย์และนักศึกษาสามารถติดตามเอกสารคำร้องต่างๆ ที่ยื่นต่อฝ่ายทะเบียนได้
         - เจ้าหน้าที่ฝ่ายทะเบียนสามารถ เพิ่ม ลบ และแก้ไข ข้อมูลต่างๆ ในระบบตามหน้าที่ได้
        2. ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-Functional Requirement) เป็นความต้องการที่ไม่เกี่ยวข้องโดยตรงกับฟังก์ชันหลักของระบบ แต่เกี่ยวข้องทางอ้อมในลักษณะที่เป็นเงื่อนไขการทำงานหรือฟังก์ชันหรือบริการ 
        ความต้องการที่ไม่ใช่หน้าที่หลักของระบบ อาจมาจากความต้องการของผู้ใช้หลายๆ ด้านที่ไม่เกี่ยวข้องกับซอฟต์แวร์เพียงอย่างเดียว ดังนี้
           1. ความต้องการด้านผลิตภัณฑ์ (Product Requirement) แบ่งออกเป็น 3 ส่วน ได้แก่
          - ความต้องการด้านประสิทธิภาพของผลิตภัณฑ์ (Performance Requirement)
          - ความต้องการด้านความน่าเชื่อถือ (Reliability Requirement)
          - ความต้องการด้านการทำงานข้ามแพลตฟอร์มได้ (Portability Requirement) และใช้งานง่าย 
            (Usability Requirement)
        2. ความต้องการขององค์กร (Organizational Requirement) เป็นความต้องการที่มาจากนโยบายและระเบียบปฏิบัติของลูกค้า และผู้พัฒนา โดยกำหนดข้อตกลงระหว่างองค์กร ไว้เพื่อเป็นแนวทางในการพัฒนาที่ตรงตามความต้องการของทั่งสองฝ่าย 
      3. ความต้องการจากปัจจัยภายนอก (External Requirement) เป็นความต้องการที่เกิดจากปัจจัยภายนอก ซึ่งส่งผลต่อซอฟต์แวร์และกระบวนการพัฒนา แบ่งเป็น 3 ส่วน ดังนี้ 
         - ความต้องการการทำงานร่วมกัน (Interoperability Requirement)
         - ความต้องการในทางกฎหมาย (Legislative Requirement) 
         - ความต้องการในด้านหลักจริยธรรม (Ethical Requirement)
        3. ความต้องการทางด้านงานธุรกิจ (Domain Requirement) เป็นความต้องการที่เกี่ยวข้องกับงานหลักของระบบที่ต้องการซอฟต์แวร์มาสนับสนุนโดยเฉพาะ ส่วนใหญ่ก็จะเป็นศัพท์เฉพาะงานธุรกิจด้านนั้น 

5.3 ความต้องการของผู้ใช้ 
        ความต้องการของผู้ใช้ (User Requirement) เป็นความต้องการที่มีต่อระบบซึ่งระบุโดยผู้ใช้ระบบ โดยจะอธิบายทั้งส่วนที่เป็นหน้าที่หลัก และส่วนที่ไม่ใช้หน้าที่หลักของระบบ ด้วยภาษาที่ผู้ใช้อ่านแล้วเข้าใจง่าย ไม่ควรใช้คำศัพท์เทคนิคมากเกินไป ดังนั้น การเขียนข้อกำหนดความต้องการของผู้ใช้ จะต้องใช้ภาษาที่เข้าใจง่าย อาจใช้แผนภาพเพื่อแสดงรายละเอียด ในระดับที่ผู้ใช้พอจะเข้าใจได้ หรืออธิบายในลักษณะของตารางหรือแบบฟอร์มง่ายๆ อย่างไรก็ตามอาจเกิดปัญหาดังนี้ 
        1. ขาดความชัดเจน
        2. ไม่สามารถจำแนกประเภทของความต้องการได้อย่างชัดเจน
        3. บางครั้งความต้องการมีจุดประสงค์เดียวกัน แต่เขียนออกมาในประโยคที่ต่างกัน
        จากปัญหาที่เกิดขึ้น การจัดทำเอกสารความต้องการต้องมีการแยกรายละเอียด ความต้องการของระบบออกจากผู้ใช้ เพื่อหลีกเลี่ยงความรู้สึกต่อต้าน ควรมีหลักปฏิบัติดังนี้
        1. กำหนดมาตรฐานของรูปแบบเอกสาร 
        2. จำแนกความจำเป็นของความต้องการ โดยจำแนกเป็น ความต้องการที่จำเป็น (Mandatory Requirement)  (ต้อง) และความต้องการที่ปรารถนา (Desirable Requirement) (ควร)

5.4 ความต้องการด้านระบบ 
        ความต้องการด้านระบบ (System Requirement) เป็นการกำหนดความต้องการการทำงาน ฟังก์ชัน และบริการต่างๆ ที่ระบบจะต้องมีเพื่อตอบสนองความต้องการของผู้ใช้ ความต้องการด้านระบบเป็นความต้องการที่ได้จากการวิเคราะห์ข้อมูลความต้องการของผู้ใช้มาแล้ว เป็นข้อมูลที่มีความสำคัญ การเขียนข้อกำหนดความต้องการด้านระบบ (System Requirement Specification) ควรภาษาธรรมชาติหรือภาษาที่เข้าใจง่าย โดยกำหนดมาตรฐานในการใช้ภาษาธรรมชาติมาอธิบายถึงความต้องการด้านระบบใบรูปแบบต่างๆ ดังนี้ 
ข้อกำหนดการใช้ภาษาโครงสร้าง (Structure Language Specification)
        1. From-Base Specification เป็นการสร้างฟอร์มมาตรฐานเพื่อใช้เป็นรูปแบบในการกำหนดความต้องการ ของระบบ โดยสามารถกำหนดได้ว่าต้องการรายละเอียดใดบ้าง เช่น 

        2. Tabular Specification กรณีต้องการคำนวณหาค่าต่างๆ สามารถใช้ตารางการคำนวณแสดงการตัดสินใจและทางเลือกต่างๆ ในการทำงานของระบบได้ด้วย เช่น 


เงื่อนไข        การกระทำ

Member=yes        Discount=5% then

Net price = total price-(total price*discount)

Member=no        Discount=0% then

Net price = total 

        3. Graphical Model เป็นการนำภาพหรือแบบจำลอง มาใช้อธิบายข้อมูลหรือความต้องการเพิ่มเติมจากการอธิบายด้วยรูปอื่น เนื่องจากรูปภาพช่วยลดความกำกวมและแสดงแทนข้อความจำนวนมากได้ เช่น

5.5 เอกสารความต้องการด้านซอฟต์แวร์ 

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

        เอกสารความต้องการด้านซอฟต์แวร์นั้นจะต้องเป็นรูปแบบที่มีมาตรฐานและเป็นทางการ เพื่อให้ผู้ที่เกี่ยวข้องกับการใช้เอกสารเข้าใจตรงกัน IEEE จึงกำหนดโครงสร้างของเอกสารความต้องการด้านซอฟต์แวร์ไว้ ดังนี้ 

        1. บทนำ (Introducation)

                1. 1 วัตถุประสงค์ของเอกสาร

                1.2 ขอบเขตของผลิตภัณฑ์
                1.3 นิยาม คำย่อ และตัวอักษรย่อต่างๆ 
                1.4 เอกสารอ้างอิง
                1.5 สรุปส่วนอื่นๆ ของเอกสาร        
        2. รายละเอียดทั่วไป (General Description)
                2.1 มุมมองเกี่ยวกับผลิตภัณฑ์
                2.2 ฟังก์ชันของผลิตภัณฑ์
                2.3 คุณสมบัติของผู้ใช้
                2.4 ข้อบังคับทั่วไป 
                2.5 สมมติฐานและส่วนเพิ่มเติม
        3. ข้อกำหนดความต้องการ (Specification Requirement) 
        4. ภาคผนวก (Appendices)
        5. ดัชนี (Index)

ที่มา www.softwaresiam.com

บทที่ 4 การบริหารโครงการผลิตซอฟต์แวร์

บทที่ 4การบริหารโครงการผลิตซอฟต์แวร์

4.1 การบริหารโครงการผลิตซอฟต์แวร์
        โครงการ (Project) หมายถึง การดำเนินกิจกรรมตามแผนงานที่ได้จัดทำขึ้น โดยแต่ละกิจกรรมมีวันที่เริ่มต้นและวันสิ้นสุด เพื่อบรรลุวัตถุประสงค์หรือเป้ามายที่ได้กำหนดไว้ ภายใต้ระยะเวลา ทรัพยากร และงบประมาณที่ได้กำหนดไว้
        การบริหารโครงการ (Project Management) หมายถึง การประยุกต์ใช้องค์ความรู้ ทักษะ เครื่องมือ และเทคนิค เพื่อดำเนินกิจกรรมตามความต้องการของโครงการให้บรรลุวัตถุประสงค์ที่กำหนดไว้
        4.1.1 จงจรชีวิตของซอฟแวร์
                โครงการทุกประเภท เป็นสิ่งที่จัดตั้งขึ้นเพียงชั่วคราวเท่านั้น ตลอดช่วงอายุของโครงการจะมี 4 ระยะ ได้แก่ 
                1. ระยะเริ่มโครงการ (Project Initiation)
                หลังจากที่องค์กรได้คัดเลือกโครงการที่เหมาะสมที่สุดแล้ว ทีมงานที่รับผิดชอบต้องเริ่มต้นโครงการด้วยการกำหนดขอบเขต ขนาด รวมทั้งกำหนดกิจกรรม แต่ละขั้นตอนด้วย
                2. ระยะวางแผนโครงการ (Project Planning)
                ผู้บริหารโครงการต้องกำหนดกิจกรรมในแต่ละขั้นตอนอย่างชัดเจน รวมถึงการใช้ทรัพยากรต่างๆ และต้องประเมินความเสี่ยงด้วย
3. ระยะดำเนินโครงการ (Project Execution) 
ทีมงานต้องดำเนินกิจกรรมผลิตซอฟต์แวร์ตาม Schedule ที่จัดไว้ โดยผู้บริหารต้องติดตามการทำงาน ดูแล สั่งการ และควบคุมการทำงาน ของลูกทีมให้ดำเนินตามแผนที่กำหนดไว้ 
4. ระยะปิดโครงการ (Project Closing) 
เป็นการดำเนินงานหลังจากติดตั้งซอฟต์แวร์เพื่อใช้งานเสร็จสิ้นแล้ว การปิดโครงการมี 2 ลักษณะคือ การปิดโครงการด้วยความสำเร็จ และการปิดโครงการเนื่องจากความล้มเหลว

        4.1. ความยากของการบริหารโครงการผลิตซอฟต์แวร์
               โครงการผลิตซอฟแวร์จะเป็นงานที่ยากกว่าการบริหารโครงการประเภทอื่น เนื่องจากสาเหตุต่างๆ ดังนี้
        1. ซอฟต์แวร์เป็นผลิตภัณฑ์ที่จับต้องไม่ได้         เนื่องจากไม่สามารถเห็นผลลัพธ์ที่ชัดเจน
        2. กระบวนการผลิตซอฟต์แวร์ไม่มีมาตรฐานที่แน่นอน ขึ้นอยู่กับสภาพแวดล้อมในการพัฒนา
        3. โครงการผลิตซอฟต์แวร์ขนาดใหญ่ย่อมมีลักษณะพิเศษแตกต่างกัน ขึ้นอยู่กับเทคโนโลยีใน
ขณะนั้น 
4.2 ความต้องการในการผลิตซอฟแวร์เป็นวัตถุดิบที่ไม่สามารถจัดต้องได้ และความต้องการของลูกค้ามักเปลี่ยนแปลงอยู่เสมอ
4.3 กิจกรรมในการบริหารโครงการ
        1. การเขียนข้อเสนอโครงการ (Proposal Writing) ยื่นต่อเจ้าของโครงการเพื่อขออนุมัติดำเนินโครงการ เป็นขั้นตอนที่ค่อนข้างสำคัญ ซึ่งจะอนุมัติหรือไม่ก็ขึ้นอยู่กับขั้นตอนนี้ โดยประกอบไปด้วยวัตถุประสงค์ การประมาณการต้นทุนและตารางงาน วิธีการดำเนินงาน และประโยชน์ที่จะได้รับจากโครงการ
        2. การวางแผนและจัดตารางงานโครงการ (Project Planning and Scheduling) เป็นการกำหนดกิจกรรมหลัก กิจกรรมย่อย และเป้าหมายของแต่ละกิจกรรม (Milestone) การส่งมอบงาน และจัดตารางงาน โดยกำหนดเวลาเริ่มต้นและส่งมอบงาน 
        3. งบประมาณการต้นทุนโครงการ (Cost Estimation) การประมาณการต้นทุน จะเกี่ยวข้องกับการประมาณการทรัพยากรส่วนอื่นร่วมด้วย
        4. การติดตามและทบทวนโครงการ (Project Monitoring and Review) ผู้บริหารโครงการจะติดตามความคืบหน้าของงาน พร้อมกับพิจารณาระยะเวลาและต้นทุนที่ใช้จริงเปรียบเทียบกับแผนที่วางไว้ ทบทวนการทำงานและปัญหาที่เกิดขึ้น 
        5. การคัดเลือกและประเมินบุคลากร ผู้บริหารจะต้องคัดเลือกบุคลากรเพื่อเข้าไปทำหน้าที่ต่างๆ ซึ่งบุคลากรจะต้องมีความสามารถที่พอจะรับผิดชอบงานที่ได้รับมอบหมายได้ 
        6. การเขียนและนำเสนอรายงาน การเขียนและนำเสนอรายงานเป็นอีกหน้าที่หนึ่งของผู้บริหารโครงการ เพื่อนำเสนอต่อลูกค้าและผู้รับเหมาช่วง (ถ้ามี) การเขียนรายงานจะต้องใช้ข้อความที่กระชับ เข้าใจง่าย และสอดคล้องกัน
4.4 การวางแผนโครงการ
        การบริหารโครงการจะมีประสิทธิภาพหรือไม่ขึ้นอยู่กับการวางแผนของผู้บริหารโครงการ ซึ่งไม่ใช่เพียงการวางแผนการดำเนินงานต่างๆ ให้มีความคืบหน้าเท่านั้น แต่ยังรวมถึงการวางแผนรับมือและป้องกันปัญหา ที่จะเกิดขึ้นอีกด้วย จึงทำให้ผู้บริหารโครงการต้องจัดทำแผนงานชนิดอื่นที่เกี่ยวข้องด้วย เช่น 
       1. แผนงานคุณภาพ (Quality Plan) แสดงรายละเอียดกระบวนการจัดการคุณภาพและมาตรฐานคุณภาพที่เลือกใช้
       2. แผนงานการทวนสอบ (Validation Plan) แสดงแนวทาง ทรัพยากรที่ต้องใช้ และตารางการทวนสอบระบบ
     3. แผนการจัดการโครงแบบระบบ (Configuration Management Plan) แสดงกระบวนการจัดการโครงแบบของระบบและโครงสร้างที่ใช้
       4. แผนงานบำรุงรักษาระบบ (Maintenance Plan) คาดการความต้องการบำรุงรักษาระบบในอนาคต พร้อมทั้งประมาณการด้นทุนและแรงงานที่ต้องใช้
       5. แผนงานพัฒนาบุคลากร (Staff Development) แสดงรายละเอียดทักษะ และประสบการณ์ที่ทีมงานต้องปรับปรุง 


สิ่งที่ได้จากกาวางแผนโครงการคือ แผนงานโครงการ ซึ่งส่วนใหญ่จะประกอบไปด้วย
        1. บทนำ (Instruction)
        2. โครงสร้างของโครงการ (Project Organization)
        3. การวิเคราะห์ความเสี่ยง (Risk Analysis)
        4. ความต้องการฮาร์ดแวร์และซอฟต์แวร์ (Hardware and Software Resource)
        5. โครงสร้างงาน (Work Breakdown) 
        6. ตารางงาน (Project Schedule) 
        7. การติดตามผลและรายงานผล (Monitoring and Reporting)
        เป้าหมายของกิจกรรมและส่งมอบงาน  (Milestone and Deliverable)
        Milestone คือ เป้าหมาย หรือหลักชัยของกิจกรรม มีระโยชน์ต่อการติดตามความคืบหน้าของงานที่ทำ เมื่อดำเนินกิจกรรมเสร็จสิ้นตามเป้าหมาย 

        Deliverable คือ ผลลัพธ์ที่จะส่งมอบให้แก่ลูกค้าซึ่งได้จาการดำเนินโครงการ โดยทั่วไปจะส่งมอบงานเมื่อเสร็จสิ้นงานในแต่ละระยะของโครงการ
        สิ่งที่เหมือนกันของ Milestone กับ Deliverable คือ ได้เมื่อเสร็จสิ้นกิจกรรม ที่ต่างกันคือ Milestone ได้จากการดำเนินกิจกรรมที่ดำเนินภายในโครงการ และต้องทำรายงานเสนอผู้บังคับบัญชา ส่วน Deliverable ได้จากการดำเนินกิจกรรมซึ่งต้องส่งมอบให้ลูกค้า 
4.4 การจัดตารางงานโครงการ
        เป็นกิจกรรมที่ผู้บริหารโครงการต้องเริ่มจากการนำกิกรรมมาแบ่งเป็นกิจกรรมย่อย แล้วกำหนดเวลาแล้วเสร็จให้แต่ละกิจกรรม โดยจะต้องทราบว่ากรรมใดมาก่อนมาหลัง โดยต้องสรรหาบุคลากรให้เหมาะสมกับกิจกรรมเหล่านี้ โดยไม่ทำให้กิจกรรมล่าช้า หรือใช้งบประมาณเกินจากที่กำหนด ซึ่งจะทำให้กิจกรรมกลายเป็น กิจกรรมวิกฤติ (Critical Task) ได้
        4.4.1 Gantt Chart
        ใช้จัดตารางการทำงานในโครงการ เป็นกราฟแท่งในแนวนอน แสดงระยะเวลาของกิจกรรมแต่ละขั้นตอน ชื่อจะถูกแสดงทางด้านซ้ายมือ ระยะเวลาจะถูกแสดงในแนวนอนของแผนภาพ
จึงทำให้เห็นลำดับของแต่ละกิจกรรมที่ต่อเนื่องกัน ทำให้ทราบว่ากิจกรรมใดมาก่อนมาหลัง หรือต้องดำเนินไปพร้อมๆ กัน

        4.2.2 PERT/CPM
PERT (Project Evaluation Review Technique)
แสดงเป็นแผนภาพกิจกรรมของโครงการที่เชื่อมต่อกันในลักษณะเครือข่าย ทำให้ทราบว่าจะต้องดำเนินกิจกรรมใดให้เสร็จสิ้นก่อนกิจกรรมถัดไป ตลอกจนกิจกรรมวิกฤติ โดยแต่ละกิจกรรมแทนด้วยเส้นลูกศร ที่เชื่อมโยงกันด้วยวงกลม หรือ Node
        CPM (Critical Path Method) เป็นเทคนิคในการวิเคราะห์เส้นทางหรือกิจกรรมวิกฤติ โดยแสดงเป็นแผนภาพเครือข่ายเหมือน PERT 


4.5 กุญแจสู่ความสำเร็จในการบริหารโครงการ
        สถาบัน PMI (Project Management Institute: PMI) ได้กำหนดงานบริหารที่จะนำไปสู่ความสำเร็จของโครงการไว้ทั้งหมด 9 ส่วนโดยอาศัยเครื่องมือและเทคนิคต่างๆ เป็นตัวสนับสนุน ดังนี้
   1. การบริหารโครงการโดยรวม (Project Integration Management) เป็นงานบริหารที่ทำให้มั่นใจว่าการประสานงานการทำงานกันของทุกๆ ฝ่ายมีความเหมาะสมและเป็นที่พอใจของทุกฝ่าย โดยผู้บริหารโครงการมีหน้าที่ในการระบุข้อดีข้อเสีย ของวัตถุประสงค์ต่างๆ เพื่อเลือกเฉพาะวัตถุประสงค์ที่ตอบสนองความต้องการของผู้บริหารระดับสูงสุดได้อย่างแท้จริง
    2. การบริหารขอบเขตของโครงการ (Project Scope Management) เป็นงานบริหารเพื่อให้ขอบเขตุของงานทั้งหมดในโครงการมีเฉพาะงานที่จำเป็นต่อการดำเนินโครงการให้สำเร็จลุล่วงเท่านั้น
    3. การบริหารโครงการเวลา (Project Time Management) เป็นงานบริหารเพื่อปิดโครงการใช้ทันเวลาที่กำหนดไว้ในแผนงาน
   4. การบริหารต้นทุนโครงการ (Project Cost Management) เป็นงานบริหารเพื่อให้โครงการใช้ต้นทุนไม่เกินงบประมาณที่ได้รับอนุมัติ 
  5. การบริหารคุณภาพโครงการ (Project Quality Management) เป็นงานบริหารเพื่อให้ทุกๆ กิจกรรม ที่ดำเนินในโครงการมีคุณภาพที่สุด ผู้บริหารจะต้องจัดทำระบบคุณภาพ ซึ่งประกอบด้วย 4 ประการคือ การวางแผนคุณภาพ (Quality Planning) การรับประกันคุณภาพ (Quality Assurance) การควบคุมคุณภาพ (Quality Control) และการปรับปรุงคุณภาพ  (Quality Improvement)
   6. การบริหารทรัพยากรบุคลากรของโครงการ (Project Human Resource Management) เป็นงานบริหารการใช้ทรัพยากรบุคคลของโครงการให้มีประสิทธิภาพและคุ้มค่ามากที่สุด
    7. การบริหารการสื่อสารภายในโครงการ (Project Communication Management) เป็นงานบริหารที่มีวัตถุประสงค์เพื่อให้การจัดทำรายงาน การเก็บรวบรวมข้อมูล การเผยแพร่ การจัดเก็บ และการส่งข้อมูลข่าวสารไปยังปลายทางถูกต้อง แม่นยำ และเหมาะสม 
    8. การบริหารความเสี่ยงของโครงการ (Project Risk Management) เป็นงานที่เกี่ยวกับการกำหนดปัจจัยเสี่ยง การวิเคราะห์ความเสี่ยง การวางแผนความเสี่ยง การติดตามความเสี่ยง และการแก้ปัญหาความเสี่ยง 
    9. การบริหารการจัดซื้อของโครงการ (Project Procurement Management) การบริหารการจัดซื้อจัดจ้าง เป็นกระบวนการจัดซื้อฮาร์ดแวร์ ซอฟต์แวร์ และว่าจ้างให้บุคคลภายนอกผลิตซอฟต์แวร์ให้ กระบวนการจัดซื้อแบ่งออกเป็น 4 ขั้นตอน ได้แก่ การวางแผนจัดซื้อจัดจ้าง (Procurement Planning) การดำเนินการจัดซื้อจัดจ้าง (Procurement Execution) การทำสัญญา (Contracting Procurement) การยุติสัญญา (Closing Contract) 

แบบฝึกหัดท้ายบท บทที่ 3-4

แบบฝึกหัดท้ายบท บทที่ 3-4

Gantt Chart

1. จงสร้างแผนภูมิ (Gantt chart)

ตอบ

2. จงสร้างเครือข่าย PERT

ตอบ

3. โครงการนี้ใช้ระยะเวลาดำเนินงานกี่วัน

 ตอบ พิจารณาเครือข่าย PERT ในข้อที่ 2 สามารถนำมาคำนวณเป็นสายงานได้ 3 สายดังนี้

 สายงานที่ 1 คือ P-Q-R-S = 31 วัน
 สายงานที่ 2 คือ P-T-Z-S = 32 วัน
 สายงานที่ 3 คือ X-Y-Z-S = 34 วัน

4. จงหาเส้นทางวิกฤตพร้อมระบุกิจกรรมวิกฤต

 ตอบ จากข้อที่ 3 Cretical path คือ สายงานที่ 3 ซึ่งใช้ระยะเวลาดำเนินงานสูงสุด 34 วัน 

Chapter 3 Systems Engineering

บทที่ 3  วิศวกรรมระบบ

3.1 ระบบ
        ระบบ ( System) หมายถึง กลุ่มขององค์ประกอบต่างๆ ที่สัมพันธ์กัน พึ่งพาอาศัยกัน และต้องปฏิสัมพันธ์กันเพื่อให้บรรลุวัตถุประสงค์ร่วมกัน
        ระบบในแวดวงพัฒนาสสารสนเทศเป็นระบบที่ประกอบไปด้วยฮาร์ดแวร์ ซอฟต์แวร์ และบุคลากร เพื่อประมวลผลข้อมูลให้ได้เป็นสารสนเทศที่ต้องการ ซึ่งก็คือ ระบบที่นำคอมพิวเตอร์มาสนับสนุนการทำงาน หรือ Computer-base System มีส่วนประกอบหลักๆ ดังนี้
1. ซอฟต์แวร์ (Software) คือโปรแกรมคอมพิวเตอร์
2. ฮาร์ดแวร์ (Hardware) ได้แก่ อุปกรณ์อิเล็กทรอนิกส์ที่ใช้ประมวลผล อุปกรณ์เชื่อมต่อ
3. บุคลากร (People) ได้แก่ ผู้ใช้ และผู้ควบคุมการทดงาน ของฮาร์ดแวร์และซอฟต์แวร์
4. ฐานข้อมูล (Database) คือส่วนจัดเก็บข้อมูลและสารสมเทศของระบบ
5. เอกสาร (Documentation) คือ เอกสารรายละเอียดทั้งหมดของระบบ
6. กระบวนการ (Procedure) ได้แก่ขั้นตอนการทำงานของระบบ
นอกจากองค์ประกอบข้างต้นและวัตถุประสงค์หลักขององค์กรแล้ว Computer-base System ยังต้องใช้องค์ความรู้อีกหลายด้านเพิ่มเติม เพื่อกำหนดวิธีการทำงานของระบบให้สามารถบรรลุวัตถุประสงค์อื่นๆ อีกด้วย บางครั้งจึงเรียกระบบลักษณะดังกล่าวว่า Socio-technical System ซึ่งมีคุณสมบัติ 3 ประการได้แก่
1.เป็นระบบที่มีคุณลักษณะ Emergent Properties คือ คุณลักษณะที่ไม่สามารถวัดได้จากระบบย่อยใดระบบหนึ่ง แต่จะต้องวัดจากการทำงานโดยรวมของระบบ
2.พฤติกรรมของระบบไม่แน่นอน บางครั้งระบบอาจแสดงผลลัพธ์ที่แตกต่างออกไปจากเดิม เนื่องจากข้อมูลนำเข้าที่มีลักษณะเฉพาะ หรือบางครั้งระบบอาจมีการตอบสนองในลักษณะอื่นขึ้นอยู่กับผู้ใช้ระบบ
3.เป็นระบบที่ถูกเพิ่มความสามารถให้บรรลุวัตถุประสงค์อื่นๆ นอกเหนือจากวัตถุประสงค์หลัก ทำให้ต้องมีการปรับปรุงระบบให้เข้ากับวัตถุประสงค์อื่นๆ เหล่านั้น ซึ่งอาจส่งผลให้การทำงานของระบบเกิดล้มเหลวได้

3.2 วิศวกรรมระบบ
        โดยส่วนใหญ่ เมื่อระบบทำงานผิดพลาดและไม่สามารถแก้ไขที่กระบวนการของระบบได้โดยตรง จึงต้องแก้ไขที่ซอฟต์แวร์ด้วยการเพิ่มประสิทธิภาพ หรือดัดแปลงการทำงานให้เข้ากับสภาพแวดล้อมที่เป็นสาเหตุในขณะนั้น บางครั้งอาจทำให้ประสิทธิภาพของซอฟต์แวร์ลดลง และส่งผลให้ลูกค้าไม่พอใจในที่สุด ในสถานการณ์ดังกล่าวอาจมองว่าปัญหาเกิดจากซอฟต์แวร์ไม่มีประสิทธิภาพ แต่แท้จริงแล้ว ปัญหาเกิดจากการออกแบบระบบ ที่ไม่ได้คำนึงถึงส่วนประกอบอื่นของระบบโดยเฉพาะสภาพแวดล้อมที่มีอิทธิพลต่อระบบ
        วิศวกรมระบบ (System Engineering) หมายถึง กระบวนการศึกษาและวิเคราะห์ของระบบที่มีความสลับซับซ้อน เพื่อสนับสนุนการทำงานในส่วนของวิศวกรรซอฟต์แวร์ กิจกรรมของวิศวกรรมระบบ จะถูกดำเนินไปพร้อมๆ กัน มีดังนี้
        1. กำหนดวัตถุประสงค์ของระบบ
        2. กำหนดขอบเขตระบบ
        3. แบ่งระบบออกเป็นส่วนๆ ตามฟังก์ชันการทำงานหรือคุณสมบัติของระบบ
        4. พิจารณาความสัมพันธ์ของส่วนประกอบต่างๆ ที่เกี่ยวข้องทั้งหมด
        5. กำหนดความสัมพันธ์ของปัจจัยนำเข้า ประมวลผล และผลลัพธ์
        6. พิจารณาปัจจัยที่มีส่วนเกี่ยวข้องในระบบ ไม่ว่าจะเป็นฮาร์ดแวร์ ซอฟต์แวร์ ฐานข้อมูล หรือแม้แต่ผลิตภัณฑ์ซอฟต์แวร์อื่นๆ เป็นต้อ
        7. กำหนดความต้องการในส่วนของการดำเนินการและฟังก์ชันทั้งระบบ
        8. สร้างแบบจำลองระบบ เพื่อใช้วิเคราะห์และพัฒนาให้สอดคล้องกับแบบจำลองซอฟต์แวร์ที่สร้างขึ้น
        9. นำเสนอและแลกเปลี่ยนข้อคิดเห็นกับผู้ที่เกี่ยวข้องกับระบบ ไม่ว่าจะเป็นผู้ใช้ระบบ เจ้าของระบบ หรือแม้แต่ผู้ที่เกี่ยวข้องกับผลประโยชน์ที่มีต่อระบบ

3.3 กระบวนการวิศวกรรมระบบ

          1. การกำหนดความต้องการ (Requirement Definition)
กระบวนการของวิศวกรรมระบบ เริ่มต้นด้วยการวิเคราะห์ภาพรวมของทั้งองค์กร เพื่อกำหนดนิยามความต้องการของระบบให้ชัดเจน ด้วยการกำหนดหน้าที่ว่าระบบควรทำอะไรได้บ้าง
          2. การออกแบบระบบ (System Design)
เป็นการกำหนดรายละเอียดของฟังก์ชั่นในแต่ละส่วนประกอบของระบบ โดยมีกระบวนการย่อยดังนี้
          3. แบ่งส่วนความต้องการ (Partition Requirement) วิเคราะห์ความต้องการและจัดโครงสร้างด้วยการแบ่งกลุ่มความต้องการด้วยวิธีที่เหมาะสม
           4. กำหนดระบบย่อย (Identify Sub-System) นำระบบใหญ่มาแบ่งส่วนออกเป็นระบบย่อย ด้วยวิธีการหรือแนวทางที่เหมาะสม
       5.กำหนดความต้องการในแต่ละระบบย่อย (Assign Requirement) กำหนดความต้องการของแต่ละระบบย่อย ซึ่งต้องสอดคล้องกับความต้องการทั้งหมดของระบบ และจะซับซ้อนขึ้นเมื่อความต้องการมีการเปลี่ยนแปลง
         6.กำหนดฟังก์ชันของแต่ละระบบย่อย (Specify Sub-system Functionality) ซึ่งต้องสอดคล้องกับความต้องการของแต่ละระบบย่อยด้วย
    7.กำหนดส่วนประสานของระบบย่อย แต่ละระบบย่อยจะต้องเตรียมส่วนประสานไว้บริการระบบย่อยอื่นๆ เพื่อการผนวกรวมระบบ


        3. การพัฒนาระบบย่อย (Sub-system Development)
เป็นการนำระบบย่อยที่ถูกกำหนดรายละเอียดไว้แล้วในระยะการออกแบบ มาสร้างตามรายละเอียดที่กำหนดไว้ ตามกระบวนการที่เหมาะสม การพัฒนาระบบย่อยโดยทั่วไปจะดำเนินการแบบขนาน เมื่อพบปัญหาจะต้องย้อนกลับไปแก้ไขทันที เนื่องจากการแก้ไขระบบหลังจากการผลิตเสร็จเรียบร้อยแล้วนั้น จะทำให้เกิดต้นทุนที่สูงมาก จึงต้องหันมาแก้ไขที่ซอฟต์แวร์เอง ซึ่งความซับซ้อนของซอฟต์แวร์นั้นมีลักษณะเป็นลูกโซ่ คือ ต้องเริ่มแก้ตั้งแต่ข้อกำหนดความต้องการ งานออกแบบ มาจนถึงโค้ดโปรแกรม จึงทำให้การแก้ไขซอฟต์แวร์นั้นเป็นเรื่องยาก

        4. การผนวกรวมระบบ (System Integration)
ระบบย่อยใดที่พัฒนาเสร็จสิ้นแล้ว จะถูกผนวกรวมเข้าด้วยกันจนกลายเป็นระบบที่เสร็จสิ้นสมบูรณ์ โดยใช้แนวทางที่เรียกว่า Big Bang ซึ่งเป็นการผนวกรวมระบบย่อยทั้งหมดในคราวเดียวกัน ซึ่งมองเห็นข้อผิดพลาดได้ยาก Incremental Integration Process เป็นการผนวกรวมระบบย่อยที่ละระบบ ทำให้มองเห็นความผิดพลาดของระบบได้ง่าย เมื่อผนวกรวมระบบแล้วต้องมีการทดสอบระบบอีกครั้ง
      
        5. การติดตั้งระบบ (System Installation)
เมื่อตรวจสอบประสิทธิภาพของระบบจนมั่นใจว่าระบบสมารถติดตั้งได้แล้ว ก็ทำการติดตั้งระบบให้ผู้ใช้ ใช้งาน และต้องทำการติดตามประสิทธิภาพการทำงานของระบบหลังการติดตั้งด้วย เมื่อพบข้อผิดพลาดก็ดำเนินการแก้ไขให้ถูกต้อง

        6. การเปลี่ยนแปลงระบบ (System Evolution)
ในช่วงระยะเวลาของการใช้งานระบบ  อาจเกิดการเปลี่ยนแปลงของสิ่งต่างๆ ทั้งในส่วนของระบบเองและสิ่งแวดล้อมระบบ โดยเจ้าระบบอาจต้องการแก้ไขข้อผิดพลาด รวมทั้งแก้ไขความต้องการของระบบเดิมให้เป็นไปตามความต้องการใหม่ เมื่อทุกฝ่ายที่เกี่ยวข้องกันตัดสินใจเปลี่ยนแปลงระบบ จะต้องวางแผนอย่างรอบคอบ เนื่องจาการเปลี่ยนแปลงระบบต้องใช้ต้นทุนค่อนข้างสูง
      
        7. การปลดระวางระบบ (System Decommission)
การปลดระวางระวางระบบ หมายถึง การเลิกใช้ระบบหลังพบว่าระบบไม่สามารถใช้งานได้อีกต่อไป
ข้อแตกต่างและความสัมพันธ์ระหว่างกระบวนการวิศวกรรมระบบกับกระบวนการวิศวกรรมซอฟต์แวร์ มีดังนี้
        1. ขอบเขตของการแก้ไขงานในระหว่างการพัฒนาระบบ
        เมื่อทีมงานสามารถกำหนดระบบที่จะพัฒนาได้แล้วหากในระหว่างการดำเนินงานอยู่นั้นมีการเปลี่ยนแปลงความต้องการบางอย่างละการเปลี่ยนแปลงได้รับการอนุมัติการแก้ไขจึงเป็นเรื่องยาก จึงต้องแก้ไขที่ตัวซอฟต์แวร์ของระบบซึ่งง่ายกว่า
        2. ความสัมพันธ์ของงานด้านวิศวกรรม
        ระบบหนึ่งระบบอาจต้องประยุกต์ใช้งานวิศวกรรมลายด้าน ทั้งนี้เพื่อให้ส่วนประกอบต่างๆของระบบ ทั้งฮาร์ดแวร์ ซอฟต์แวร์ บุคลากร และข้อมูลส่วนอื่นๆ มีความสัมพันธ์สอดคล้องกันเป็นอย่างดี เพื่อป้องกันการเกิดข้อผิดพลาดที่ไม่อาจคาดการณ์ได้ จึงต้องอาศัยวิศวกรหลายคนเพื่อรับผิดชอบงานแต่ละด้าน
3.4 ระบบกับองค์กร
        หากต้องการพัฒนาระบบงานใดระบบงานหนึ่งให้มีประสิทธิภาพและประสิทธิผล ทีมงานจะต้องทำความเข้าใจในองค์กรที่เป็นเจ้าของระบบนั้นด้วย
        วิธีที่จะทราบว่า เทคโนโลยีที่จะนำมาใช้ในองค์กรจะส่งผลกระทบต่อส่วนอื่นขององค์กรอย่างไร ทำได้โดยการศึกษาถึงความสัมพันธ์ระว่างองค์ประกอบทั้ง 5 ส่วนได้แก่


         1.บุคลากร (People) ศึกษาคุณสมบัติด้านกำลังความสามารถ และวุฒิภาวะ
         2.วัฒนธรรม (Culture) ศึกษาคุณสมบัติด้านทัศนคติ พฤติกรรม ทักษะการปรับตัว และการเรียนรู้
    3.เทคโนโลยี (Technology) ศึกษาเทคโนโลยีปัจจุบันและผลกระทบที่เกี่ยวข้องกับเทคโนโลยีใหม่ ระดับการใช้งานเครื่องมือ มาตรฐาน และระเบียบวิธีปฏิบัติ
         4. โครงสร้าง (Structure) ศึกษาโครงสร้างบุคลากร โครงสร้างองค์กร
       5. ภาระหน้าที่ (Task) ศึกษาด้านภาระหน้าที่ปัจจุบัน ความซับซ้อนของงานที่ได้รับมอบหมาย และวิธีการทำงาน