Transcript วิชา ITSC2301 วิศวกรรมซอฟต์แวร์

ความต้องการด้านซอฟต์แวร์
ความต้องการ (Requirement)
วิศวกรรมความต้องการ (Requirement Engineering)
แบบจาลองการวิเคราะห์ (Analysis Model)
ความต้องการ (Requirement)

ความต้องการ ถือเป็ นวัตถุดบิ สาคัญในการผลิตซอฟต์แวร์ เพือ่ สร้างข้อกาหนด
ความต้องการของลูกค้า เพือ่ ให้ซอฟต์แวร์ทถ่ี กู พัฒนาขึน้ ตรงกับความต้องการ
ทีแ่ ท้จริง
จาแนกความต้องการด้านซอฟต์แวร์ได้เป็ น 2 ระดับ คือ
1. ความต้องการของผูใ้ ช้ (User Requirement)
แสดงถึงความคาดหวัง ในบริการ หรือการทางานทีไ่ ด้จากระบบและเงือ่ นไขที่
ระบบจะต้องทาตาม ถือเป็ นความต้องการในระดับสูงสุด
ความต้องการ (Requirement)
2. ความต้องการด้านระบบ (System Requirement)
เป็ นการกาหนดการทางาน ฟงั ก์ชนั และบริการต่างๆ ของระบบในระดับ
รายละเอียด และจัดทาเป็ นข้อกาหนดหน้าทีข่ องระบบ (Functional
Specification)
ความต้องการด้านซอฟต์แวร์ มีความสัมพันธ์อย่างมากกับความต้องการ
ของระบบ เพราะเป็ นการรวบรวมคุณสมบัติ ด้านเทคนิคของซอฟต์แวร์
ทีแ่ สดงถึงคาสังและบริ
่
การทีซ่ อฟต์แวร์สามารถทาได้ภายใต้ระบบหนึ่งๆ
ประเภทของความต้องการด้านซอฟต์แวร์

ความต้องการด้านซอฟต์แวร์ แบ่งออกเป็ น 3 ประเภท ได้แก่
 ความต้องการทีเ่ ป็ นหน้าทีห
่ ลัก
(Functional Requirement)
 ความต้องการทีไ่ ม่ใช่หน้าทีห
่ ลัก (Non- Functional Requirement)
 ความต้องการด้านธุรกิจ (Domain Requirement)
ประเภทของความต้องการด้านซอฟต์แวร์
1. Functional Requirement
เป็ นความต้องการทีเ่ ป็ นหน้าทีห่ ลัก ซึง่ ทาหน้าทีใ่ ดๆ ตามทีก่ าหนดไว้ในส่วน
การทางานหรือบริการทีซ่ อฟต์แวร์นนั ้ ควรมี
2. Non-Functional Requirement
เป็ นความต้องการทีไ่ ม่เกีย่ วข้องโดยตรงกับหน้าที่ หรือฟงั ก์ชนั หลักของ
ระบบ เช่น ความต้องการด้านผลิตภัณฑ์ ความต้องการขององค์กร และ
ความต้องการจากปจั จัยภายนอก เช่น การทางานร่วมกัน ด้านกฎหมาย และ
ด้านจริยธรรม
ประเภทของความต้องการด้านซอฟต์แวร์
3. Domain Requirement
เป็ นความต้องการทีเ่ กีย่ วข้องกับงานหลักของระบบธุรกิจ ทีต่ อ้ งการ
ซอฟต์แวร์มาสนับสนุนโดยเฉพาะ ซึง่ อาจเป็ นเงือ่ นไขของฟงั ก์ชนั ใดๆ หรือ
เงือ่ นไขทีใ่ ช้คานวณหาผลลัพธ์ใดๆ ของระบบ
เอกสารความต้องการด้านซอฟต์แวร์

เอกสารความต้องการด้านซอฟต์แวร์ (Software Requirement
Document) เรียกได้อีกอย่างหนึ่ งว่า “ข้อกาหนดความต้องการ
ซอฟต์แวร์” (Software Requirement Specification : SRS) เป็ นเอกสาร
ข้อกาหนดความต้องการอย่างเป็ นทางการ ทีจ่ ะบอกให้ทมี พัฒนาซอฟต์แวร์
ทราบว่าต้องพัฒนาอะไรบ้าง
รายละเอียดในเอกสารนัน้ ขึน้ อยูก่ บั ชนิดของระบบทีจ่ ะทาการพัฒนา
และกระบวนการทีใ่ ช้ เพือ่ ความเข้าใจตรงกันของผูท้ เ่ี กีย่ วข้อง IEEE ได้
กาหนดโครงสร้างของเอกสารไว้
เอกสารความต้องการด้านซอฟต์แวร์
IEEE ได้กาหนดโครงสร้างของเอกสาร ดังนี้
1.บทนา –วัตถุประสงค์ ,ขอบเขต,นิยาม,สรุป
2. รายละเอียดทัวไป
่ –มุมมอง, ฟงั ก์ชนั , คุณสมบัติ
3.ข้อกาหนดความต้องการ –หน้าทีห่ ลัก ไม่ใช่หน้าทีห่ ลัก
4.ภาคผนวก
5.ดัชนี
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
1
1.1
1.2
1.3
1.4
1.5
Topic
Introduction
บทคัดย่อ
วัตถุประสงค์ของเอกสาร
โครงสร้างของเอกสาร
นิยามศัพท์
อื่น ๆ ที่ตอ้ งการอ้างอิงถึง
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
2
2.1
2.2
2.3
2.4
2.5
2.6
Topic
System Description
ภาพรวมของระบบในปัจจุบนั
ปัญหาที่พบในระบบปัจจุบนั
เป้ าหมายของระบบที่พึงประสงค์
ภาพรวมของระบบที่พึงประสงค์
คุณลักษณะของผูใ้ ช้ระบบ
ข้อสมมุติฐาน
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
3
3.1
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
Topic
Functional Requirements
ฟังก์ชนั หลักของระบบทั้งหมด
ฟังก์ชนั /โมดูล 1
รายละเอียด (สร้างแผนผังประกอบ)
การบรรลุเป้ าหมายที่ตอ้ งการ
ตัวอย่างความต้องการ
ฟังก์ชนั /โมดูล 2
...
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Secti
on
4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Topic
Non-Functional Requirements
ประสิ ทธิภาพ
ประโยชน์
ระบบรักษาความปลอดภัยของระบบ
ความปลอดภัยในการใช้งาน
สมรรถภาพ
ส่วนประสานกับผูใ้ ช้
ความน่าเชื่อถือ
ข้อกาหนดความเป็ นส่วนตัว
ความสามารถในการดูแลรักษา
Chapter/Secti
on
4.10
4.11
4.12
…
Topic
ความสามารถในการตรวจสอบ
การขยายระบบในอนาคต
การนากลับมาใช้งานได้อีก
...
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
5
6
6.1
6.2
6.3
6.4
6.5
6.6
Topic
Design Constraint
Project Requirement (Optional)
การประมาณการขนาดของซอฟต์แวร์
การประมาณการแรงงานในการผลิต
การประมาณการต้นทุน
ตารางการทางาน
Platform ที่ใช้ในการพัฒนา
เงื่อนไขการยอมรับ
เอกสาร SRS ที่ดดั แปลงมาจาก
IEEE830,1993[Javadekar,2005]
Chapter/Section
A
B
...
Topic
Appendices
ประเด็นที่อยูร่ ะหว่างศึกษา
แบบสารวจความต้องการ
...
วิศวกรรมความต้องการ

วิศวกรรมความต้องการ (Requirement Engineering) หมายถึง
กระบวนการทีจ่ ะทาให้วศิ วกรรมซอฟต์แวร์ เข้าใจและเข้าถึงความต้องการของ
ลูกค้าได้อย่างแท้จริง ด้วยการสกัดความต้องการ ตรวจสอบ และนิยามความ
ต้องการ เพือ่ นาไปสร้างเป็ นข้อกาหนดความต้องการด้านระบบหรือซอฟต์แวร์ ที่
จะใช้เป็ นจุดเริม่ ต้นในการพัฒนาระบบในขัน้ ตอนต่อไป [Jawadekar, 2004]
นอกจากนี้ วิศวกรรมความต้องการยังรวมไปถึงกระบวนการควบคุมการ
เปลีย่ นแปลงของความต้องการทีจ่ ะเกิดขึน้ ด้วย เรียกว่า “การจัดการความต้องการ
(Requirement Management)” ดังนัน้ การวิศวกรรมความต้องการจึงช่วยให้
ซอฟต์แวร์ทผ่ี ลิตออกมา สามารถแก้ปญั หาหรือช่วยสนับสนุนการทางานของ
ลูกค้าได้อย่างถูกต้องตรงตามความต้องการทีแ่ ท้จริง
วิศวกรรมความต้องการ

เป้าหมายของวิศวกรรมความต้องการ ก็คอื การสร้างและบารุงเอกสาร
ข้อกาหนดความต้องการ ทัง้ ทางด้านระบบและด้านซอฟต์แวร์ ให้เป็ น
เอกสารทีม่ คี ุณภาพทีส่ ดุ
งานย่อยของงานวิศวกรรมความต้องการ


งานย่อยในกระบวนการด้านวิศวกรรมความต้องการ แบ่งเป็ น 7 ด้าน
ได้แก่ การเริม่ ต้นวิเคราะห์ (Inception) การเจาะลึกความต้องการ
(Elicitation) การขยายรายละเอียด (Elaboration) การเจรจาต่อรอง
(Negotiation) การจัดทาข้อกาหนด (Specification) การตรวจรับ
(Validation) และการจัดการความต้องการ (Requirement Management)
งานบางอย่างสามารถทาไปพร้อมๆ กันแบบขนานได้ และทุกงานต้องปรับให้
เข้ากับความจาเป็ นของโครงการ เพือ่ ให้บรรลุถงึ สิง่ ทีล่ กู ค้าต้องการอย่าง
แท้จริง
งานย่อยของงานวิศวกรรมความต้องการ

การเริ่มต้นวิเคราะห์ (Inception)
วิศวกรซอฟต์แวร์จะตัง้ คาถามเปิด เพือ่ ทาความเข้าใจพืน้ ฐานในปญั หา และ
ทางแก้ปญั หา รวมถึงการจัดสร้างการสือ่ สารทีม่ ปี ระสิทธิภาพกับบุคลากรที่
ต้องการทางแก้ปญั หา และสร้างความร่วมมือระหว่างลูกค้ากับผูพ้ ฒ
ั นาระบบ
งานย่อยของงานวิศวกรรมความต้องการ

การเจาะลึกความต้องการ (Elicitation)
ถามความต้องการของลูกค้า และผูใ้ ช้งานระบบ ว่าต้องการอะไร เป้าหมาย
ของระบบคืออะไร ปญั หาทีพ่ บในการทางานนี้คอื
- ปญั หาของการหาขอบเขตระบบ (Problem of Scope)
- ปญั หาของการทาความเข้าใจ (Problem of Understanding)
- ปญั หาการไม่คงทน (Problem of volatility)
เทคนิ คการเก็บรวบรวมความต้องการ
เทคนิคที่ใช้
1. การสัมภาษณ์ (Interview) นิยมใช้มากทีส่ ดุ
2. การแสดงลาดับเหตุการณ์ (Scenario) เตรียมคาถามตามลาดับงานของผูใ้ ช้
3. สร้างต้นแบบ (Prototype) เช่น ออกแบบจอภาพบนกระดาษ เพือ่ ทดสอบการ
ยอมรับความต้องการในเบือ้ งต้น
4. การประชุม (Meeting) เป็ นการเรียกกลุ่มบุคคลทีเ่ กีย่ วข้องมาประชุม เพือ่ ขอ
ความคิดเห็นและความต้องการ
5. การสังเกต (Observation) โดยตรวจสอบสภาพแวดล้อมการทางานของผูใ้ ช้
เป็ นวิธที ด่ี แี ต่ค่าใช้จา่ ยสูง
งานย่อยของงานวิศวกรรมความต้องการ

การขยายความรายละเอียด (Elaboration)
งานขัน้ นี้คอื การนาสารสนเทศทีไ่ ด้จากลูกค้า มาขยายและแจกแจง
รายละเอียดเพิม่ เติม กิจกรรมนี้มงุ่ จะพัฒนาแบบจาลองทางเทคนิคทีล่ ะเอียด
ของหน้าทีก่ ารทางาน รวมถึงลักษณะและข้อจากัดของซอฟต์แวร์
การขยายความรายละเอียด (Elaboration)
กระบวนการ
 การแบ่งกลุ่มความต้องการ (Requirement Classification) เป็ น functional ,
non-functional , product & process หรืออาจแบ่งกลุ่มตามลาดับความสาคัญ
ตามขอบเขต หรือตามการเปลีย่ นแปลงความต้องการ
 การสร้างแบบจาลองความต้องการ (Requirement Modeling) เป็ นแบบจาลอง
แนวคิด เพือ่ จาลองความต้องการ ให้เห็นภาพรวมความต้องการทีมงานเข้า
ใจความต้องการได้ตรงกัน ชีใ้ ห้เห็นข้อผิดพลาดและแก้ไขข้อผิดพลาดนัน้
การขยายความรายละเอียด (Elaboration)


การออกแบบสถาปตั ยกรรม (Architectural Design) แสดงให้ผใู้ ช้มองเห็น
ถึง คอมโพเน้นท์ ทีใ่ ช้สนับสนุน และรองรับความต้องการส่วนใดของผูใ้ ช้
การจัดสรรความต้องการ (Requirement Allocation)จัดสรรความต้องการ
ให้เข้ากับองค์ประกอบแต่ละส่วนของซอฟต์แวร์ เพือ่ นาไปวิเคราะห์ ในระดับ
รายละเอียดเพิม่ มากขึน้
งานย่อยของงานวิศวกรรมความต้องการ

การเจรจาต่อรอง (Negotiation)
ลูกค้ามักต่อรองขอมากกว่าทีร่ ะบบจะทาสาเร็จ นักวิศวกรความต้องการต้อง
ประสานความขัดแย้งเหล่านี้ผา่ นกระบวนการเจรจาต่อรองกับลูกค้า และ
ปรับเปลีย่ นความต้องการบางส่วน เพือ่ ให้ทกุ ฝา่ ยบรรลุความพอใจ
งานย่อยของงานวิศวกรรมความต้องการ

การจัดทาข้อกาหนด (Specification)
จัดทาเอกสาร เป็ นการรวบรวมข้อกาหนด เป็ นต้นแบบของโปรแกรม การ
จัดทาข้อกาหนด ทีบ่ ่งบอกถึงคุณลักษณะของซอฟต์แวร์ โดยเอกสารเหล่านี้
จะต้องสามารถตรวจสอบ ประเมินค่า และยอมรับได้ จาเป็ นต้องมีความ
ยืดหยุน่ โดยเฉพาะสาหรับระบบขนาดใหญ่
การจัดทาข้อกาหนด (Specification)
เอกสารที่เกี่ยวข้อง
1. เอกสารนิยามระบบ เป็ นเอกสารทีถ่ กู จัดทาขึน้ จากมุมมองของผูใ้ ช้ โดยแสดง
ถึงรายการความต้องการด้านระบบ
2. เอกสารข้อกาหนดความต้องการด้านระบบ ดาเนินงานโดยวิศวกรระบบ มัก
ถูกจัดทาก่อนข้อ 3
3. เอกสารข้อกาหนดความต้องการด้านซอฟต์แวร์ ระบุถงึ หน้าทีข่ องซอฟต์แวร์
ซึง่ เป็ นข้อตกลงขัน้ พืน้ ฐานของทีมงานกับผูใ้ ช้
งานย่อยของงานวิศวกรรมความต้องการ

การตรวจรับ (Validation)
ผลิตผลงานทีเ่ ป็ นผลลัพธ์ของวิศวกรรมความต้องการ จะถูกประเมินในแง่
คุณภาพระหว่างขัน้ ตอนการตรวจรับ เป็ นการทบทวนข้อกาหนด เพือ่ ให้
มันใจว่
่ าทุกๆ ความต้องการได้ระบุไว้อย่างไม่คลุมเครือ
โดยทีมทบทวนประกอบด้วย นักวิศวกรซอฟต์แวร์ ลูกค้าผูใ้ ช้งาน และผูม้ ี
ส่วนได้สว่ นเสียในธุรกิจอื่นๆ ทาหน้าทีต่ รวจสอบข้อกาหนด เพือ่ มองหา
ข้อผิดพลาดในเนื้อหาหรือการตีความ
การตรวจรับ (Validation)
ลักษณะที่ดีของความต้องการ
1. มีความเทีย่ งตรง (validity)
2. มีความสอดคล้อง (consistency)
3. มีความครบถ้วนสมบูรณ์ (completeness)
4. มีความเป็ นไปได้ (feasibility)
5. สามารถพิสจู น์ได้ ( verifiability)
การตรวจรับ (Validation)
เทคนิคการตรวจสอบ
1. การทบทวนความต้องการ (requirement review) โดยมีการตรวจสอบ
เอกสารอย่างละเอียด เพือ่ หาข้อผิดพลาดตามลักษณะต่างๆ
2. การจัดทาต้นแบบ (prototyping) ของระบบและสาธิตให้ผใู้ ช้ดู เป็ นเทคนิคที่
ใช้เงินทุนสูง แต่ได้ผลลัพธ์ทด่ี ี
3. การสร้างแบบทดสอบ (test-case generation) โดยนาแบบทดสอบนัน้ ไป
ออกแบบหรือพัฒนาระบบขึน้ ใช้ ถ้าทาได้ยาก ควรพิจารณาความต้องการนัน้
ใหม่ มักใช้กบั การพัฒนาซอฟต์แวร์แบบ Extreme Programming
งานย่อยของงานวิศวกรรมความต้องการ

การจัดการความต้องการ (Requirement Management)
ความต้องการในระบบมักเปลีย่ นแปลงไปตลอดช่วงชีวติ ของระบบ การ
จัดการความต้องการเป็ นชุดของกิจกรรมทีช่ ่วยให้ทมี งานกาหนดกลไกใน
การควบคุมและติดตามความสาเร็จและการเปลีย่ นแปลงความต้องการ ณ
เวลาใดเวลาหนึ่งขณะทีโ่ ครงการดาเนินไป
การจัดการความต้องการ (Requirement Management)
สาเหตุของการเปลี่ยนแปลงความต้องการ
1. มีผใู้ ช้หลายกลุ่มซึง่ มีความต้องการต่างกัน จึงมีความขัดแย้งกัน จาเป็ นต้องมี
การปรับสมดุลความต้องการใหม่
2. เกิดความขัดแย้งระหว่างผูใ้ ช้ทจ่ี า่ ยเงินลงทุน กับผูใ้ ช้ทเ่ี ป็ นผูใ้ ช้ระบบโดยตรง
3. มีการเปลีย่ นสภาพแวดล้อมทางธุรกิจและเทคโนโลยีภายหลังมีการติดตัง้ ใช้
ระบบงาน
การจัดการความต้องการ (Requirement Management)

กระบวนการ
1. จาแนกความต้องการทีเ่ ปลีย่ นแปลงและความต้องการทีไ่ ม่เปลีย่ นแปลง
2. วางแผนการจัดการความต้องการ โดยระบุความเป็ นเอกลักษณ์ให้กบั ทุก
ความต้องการ กาหนดกิจกรรมการประเมินผล กาหนดความสัมพันธ์ของ
ความต้องการแต่ละรายการและใช้ Case Tool เข้าช่วยจัดการความต้องการ
3. จัดการกับการเปลีย่ นแปลงความต้องการ เพือ่ ให้การเปลีย่ นแปลงทัง้ หมด
ทีเ่ กิดขึน้ มีความสอดคล้องกัน โดยอาศัยหลักการจัดการโครงแบบของระบบ
แบบจาลองการวิเคราะห์ (Analysis Model)
แบบจาลอง คือ สัญลักษณ์ทใ่ี ช้จาลองข้อเท็จจริงต่างๆ ที่
เกิดขึน้ ในระบบ เป็ นแผนภาพทีแ่ สดงให้เห็นในแต่ละมุมมอง
แบบจาลองการวิเคราะห์ คือ แบบจาลองทีเ่ ขียนขึน้ จากข้อกาหนด
ความต้องการของระบบ สะท้อนให้เห็นถึงหน้าทีก่ ารทางานของ
ระบบด้านต่างๆ และจะถูกนาไปใช้ในระยะการออกแบบต่อไป
แบบจาลองการวิเคราะห์ (Analysis Model)
ประเภท
 แบบจาลองตามแนวทางเชิงโครงสร้าง (Structured Analysis) – Process
Model(DFD) + Data Model (ER)
 แบบจาลองตามแนวทางเชิงวัตถุ (Object Oriented Analysis) – UML
(Unified Modeling Language)
แบบจาลองเชิงโครงสร้าง (Structured Analysis)


พิจารณาข้อมูล (Data) และกระบวนการ (Process) ทีเ่ ปลีย่ นรูปข้อมูล วัตถุ
ข้อมูลถูกจาลองในลักษณะทีก่ าหนด แอตทริบวิ ส์และความสัมพันธ์ กระบวนการ
ทีจ่ ดั การกับข้อมูลถูกจาลองในลักษณะทีแ่ สดงว่าสามารถเปลีย่ นข้อมูลทีเ่ ป็ นเป็น
วัตถุขอ้ มูลผ่านระบบได้อย่างไร
แบ่งออกเป็ น 2 ชนิด คือ
Model) จาลองขัน้ ตอนการทางานของระบบ - DFD
 แบบจาลองข้อมูล (Data Model) จาลองโครงสร้างข้อมูลทัง้ หมดในระบบ - ERD
 แบบจาลองกระบวนการ (Process
แบบจาลองกระบวนการ (Process Model)


แผนภาพกระแสข้อมูล (Data Flow Diagram)
แผนภาพทีแ่ สดงถึงทิศทางการไหลของข้อมูลทีม่ อี ยูใ่ นระบบ จากกระบวนการทางาน
หนึ่งไปอีกกระบวนการหนึ่ง หรือไปยังส่วนอื่นทีเ่ กีย่ วข้อง เช่น แหล่งจัดเก็บข้อมูล (Data
Store) ผูท้ เ่ี กีย่ วข้องทีอ่ ยูน่ อกระบบ (External Agent)
ประเภทของแผนภาพกระแสข้อมูล
- แผนภาพกระแสข้อมูล เชิงตรรกะ (Logical DFD) – แสดงกระบวนการของระบบใน
ระดับแนวคิด (Conceptual) เท่านัน้
- แผนภาพกระแสข้อมูล เชิงกายภาพ (Physical DFD) – แสดงรายละเอียดภายใน
กระบวนการ เช่น ชือ่ กระบวนการ วิธกี ารทางาน แหล่งกาเนิด และปลายทาง เป็ นต้น
Context Diagram

แผนภาพกระแสข้อมูล
ระดับบนสุดทีแ่ สดง
ภาพรวมการทางานของ
ระบบทีม่ คี วามสัมพันธ์กบั
สภาพแวดล้อมนอกระบบ
ตัวอย่าง DFD
ตัวอย่าง DFD
แผนภาพกระแสข้อมูล (Data Flow Diagram)


DFD คือ เป็ นแผนภาพที่บอกถึงรายละเอียดของระบบ โดยเฉพาะข้อมูล
และผังการไหลของข้อมูล
สิ่ งที่ DFD บอกเรา
 ข้อมูลมาจากไหน
 ข้อมูลไปที่ใด
 ข้อมูลเก็บที่ใด
 เกิดเหตุการณ์ใดกับข้อมูลบ้าง
แบบจำลองกระบวนกำร (Process Model)

แผนภำพกระแสข้ อมูล (Data Flow Diagram)
แผนภาพที่แสดงถึงทิศทางการไหลของข้อมูลที่มีอยูใ่ นระบบ จาก
กระบวนการทางานหนึ่งไปอีกกระบวนการหนึ่ง หรื อไปยังส่ วนอื่นที่เกี่ยวข้อง เช่น
แหล่งจัดเก็บข้อมูล (Data Store) ผูท้ ี่เกี่ยวข้องที่อยูน่ อกระบบ (External Agent)
วัตถุประสงค์ ของ DFD





เป็ นแผนภาพสรุ ปรวมข้อมูลทั้งหมดที่ได้จากการวิเคราะห์
เป็ นข้อตกลงร่ วมกันระหว่าง SA และ User
เป็ นแผนภาพที่ใช้ในการพัฒนาต่อในขั้นตอนออกแบบ
เป็ นแผนภาพที่ใช้ในการอ้างอิง หรื อเพือ่ ใช้พฒั นาต่อ
ทราบที่มาที่ไปของกระบวนการต่าง ๆ
ดังนัน้ DFD จึงมีความสาคัญมากต่อการพัฒนาระบบ
ซึ่ง SA หรือ Programmer ไม่สามารถมองข้ามได้
ขั้นตอนการวิเคราะห์เพื่อไปสูก่ ารออกแบบ
แบบจาลองข้อมูล (Data Model)

แผนภาพแสดงความสัมพันธ์ของข้อมูล (Entity Relationship Diagram :
ERD)
เป็ นแผนภาพสาหรับจาลองข้อมูล ซึง่ จะประกอบด้วย Entity และ
ความสัมพันธ์ของข้อมูล (Relationship) ทีเ่ กิดขึน้ ทัง้ หมดในระบบ
แบบจาลองเชิงวัตถุ (Object Oriented Analysis)


มุง่ ทีน่ ิยามของคลาสและลักษณะทีค่ ลาสทางานร่วมกัน แทนทีเ่ ราจะมอง
ปญั หาในลักษณะอินพุต โพรเซส เอาท์พตุ แบบดัง้ เดิม ซึง่ เป็ นลักษณะของ
กระแสข้อมูล เราจะมองปญั หาในแง่ของโครงสร้างข้อมูลตามลาดับชัน้
แบบจาลองเชิงวัตถุ UML (Unified Modeling Language) มี 9 แผนภาพ
Class Diagram
EXAMPLE ประเภทความต้องการด้านซอฟต์แวร์

1. ความต้องการที่เป็ นหน้าที่หลัก (Functional Requirement)
คือความต้องการให้ซอฟต์แวร์ทาหน้าที่ใดๆ ตามที่กาหนดไว้ได้ ซึ่งเป็ นสิ่งที่
ซอฟต์แวร์ควรจะทาเป็ นหน้าที่หลักในการทางาน หรือเป็ นบริการที่
ซอฟต์แวร์ควรมี ยกตัวอย่างเช่น ระบบทะเบียนนักศึกษา
- นักศึกษาสามารถตรวจสอบผลการเรียนและสภาพนักศึกษาได้
- นักศึกษาสามารถลงทะเบียนและทาการเพิกถอนรายวิชาได้
- อาจารย์สามารถตรวจสอบกลุ่มนักศึกษาในรายวิชาที่เป็ นผูส้ อนได้
EXAMPLE

- อาจารย์สามารถตรวจสอบผลการเรียนของนักศึกษาในรายวิชาของตน
หลังจากส่งผลการเรียนไปยังฝ่ ายทะเบียนแล้ว เพื่อดูความถูกต้อง
- อาจารย์และนักศึกษาสามารถติดตามเอกสารคาร้องต่างๆ ที่ยนื่ ต่อฝ่ าย
ทะเบียนได้
- เจ้าหน้าที่ฝ่ายทะเบียนสามารถ เพิ่ม ลบ และแก้ไข ข้อมูลต่างๆ ในระบบ
ตามหน้าที่ได้
EXAMPLE

2. ความต้องการที่ไม่ใช่หน้าที่หลัก (Non-Functional
Requirement) เป็ นความต้องการที่ไม่เกี่ยวข้องโดยตรงกับฟั งก์ชนั หลัก
ของระบบ แต่เกี่ยวข้องทางอ้อมในลักษณะที่เป็ นเงื่อนไขการทางานหรือ
ฟั งก์ชนั หรือบริการ
ความต้องการที่ไม่ใช่หน้าที่หลักของระบบ อาจมาจากความต้องการ
ของผูใ้ ช้หลายๆ ด้านที่ไม่เกี่ยวข้องกับซอฟต์แวร์เพียงอย่างเดียว ดังนี้
EXAMPLE

2.1 ความต้องการด้านผลิตภัณฑ์ (Product Requirement) แบ่ง
ออกเป็ น 3 ส่วน ได้แก่
- ความต้องการด้านประสิทธิภาพของผลิตภัณฑ์ (Performance
Requirement)
- ความต้องการด้านความน่ าเชือ่ ถือ (Reliability Requirement)
- ความต้องการด้านการทางานข้ามแพลตฟอร์มได้ (Portability
Requirement) และใช้งานง่าย (Usability Requirement)
EXAMPLE

2.2 ความต้องการขององค์กร (Organizational Requirement)
เป็ นความต้องการที่มาจากนโยบายและระเบียบปฏิบตั ิของลูกค้า และ
ผูพ้ ฒ
ั นา โดยกาหนดข้อตกลงระหว่างองค์กร ไว้เพื่อเป็ นแนวทางในการ
พัฒนาที่ตรงตามความต้องการของทัง่ สองฝ่ าย
EXAMPLE

2.3 ความต้องการจากปั จจัยภายนอก (External Requirement)
เป็ นความต้องการที่เกิดจากปั จจัยภายนอก ซึ่งส่งผลต่อซอฟต์แวร์และ
กระบวนการพัฒนา แบ่งเป็ น 3 ส่วน ดังนี้
- ความต้องการการทางานร่วมกัน (Interoperability
Requirement)
- ความต้องการในทางกฎหมาย (Legislative Requirement)
- ความต้องการในด้านหลักจริยธรรม (Ethical Requirement)
EXAMPLE

3. ความต้องการทางด้านงานธุรกิจ (Domain Requirement) เป็ น
ความต้องการที่เกี่ยวข้องกับงานหลักของระบบที่ตอ้ งการซอฟต์แวร์มา
สนับสนุ นโดยเฉพาะ ส่วนใหญ่ก็จะเป็ นศัพท์เฉพาะงานธุรกิจด้านนั้ น
EXAMPLE เอกสารความต้องการด้านซอฟต์แวร์

เอกสารความต้องการด้านซอฟต์แวร์ (Software Requirement
Document) เรียกได้อีกอย่างหนึ่ งว่า ข้อกาหนดความต้องการด้าน
ซอฟต์แวร์ (Software Requirement Specification : SRS)
เป็ นเอกสารข้อกาหนดความต้องการอย่างเป็ นทางการ ที่จะบอกใช้ทีม
พัฒนาทราบว่าต้องพัฒนาอะไรบ้าง ควรมีขอ้ มูลความต้องการของผูใ้ ช้ และ
ความต้องการด้านระบบ
เอกสารความต้องการด้านซอฟต์แวร์น้ันจะต้องเป็ นรูปแบบที่มี
มาตรฐานและเป็ นทางการ เพื่อให้ผทู้ ี่เกี่ยวข้องกับการใช้เอกสารเข้าใจ
ตรงกัน IEEE จึงกาหนดโครงสร้างของเอกสารความต้องการด้านซอฟต์แวร์
ไว้ ดังนี้
EXAMPLE เอกสารความต้องการด้านซอฟต์แวร์

1. บทนำ (Introduction)
ยอต
่ ำงๆ
่
1.1 วัตถุประสงคของเอกสำร
์
1.2 ขอบเขตของผลิตภัณฑ ์
1.3 นิยำม คำยอ
่ และตัวอักษร
1.4 เอกสำรอำงอิ
ง
้
1.5 สรุปส่วนอืน
่ ๆ ของเอกสำร
EXAMPLE เอกสารความต้องการด้านซอฟต์แวร์

2. รำยละเอียดทัว่ ไป (General Description)
2.1 มุมมองเกีย
่ วกับผลิตภัณฑ ์
2.2 ฟังกชั
์ นของผลิตภัณฑ ์
2.3 คุณสมบัตข
ิ องผูใช
้ ้
2.4 ขอบั
้ งคับทัว่ ไป
2.5 สมมติฐำนและส่วนเพิม
่ เติม
EXAMPLE เอกสารความต้องการด้านซอฟต์แวร์

3. ข้อกำหนดควำมตองกำร
้
(Specification Requirement)
4. ภำคผนวก (Appendix)
5. ดัชนี (Index)