Page 1
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 1
Requirement Phase
ความตองการ (Requirement)
“วตถดบทส าคญในการพฒนาระบบหรอการผลตซอฟตแวร เพอใชเปน
ขอก าหนดถงหนาทและรายละเอยดอน ๆ ทระบบหรอซอฟตแวรจะตองม”
ในการพฒนาระบบหรอการผลตซอฟตแวร ตองอาศยขอมลความตองการ
ของลกคาหรอผใช เปนตวก าหนด ฟงกชน รปลกษณ ความสามารถ และ
รายละเอยด แตเนองจากการพฒนามหลายแนวทางเชน พฒนาเอง จาง
เหมา หรอใชซอฟตแวรส าเรจรป หรอผลตเพอจ าหนาย จงท าให
ขอก าหนดความตองการมหลายระดบ หากจ าแนกระดบความตองการไม
ถกตอง จะสงผลใหซอฟตแวรไมตรงกบความตองการทแทจรง
Page 2
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 2
Requirement Phase
ในแวดวงการผลตซอฟตแวร สามารถจดความตองการได 2 ระดบ
1. ความตองการของผใช (User Requirement) เปนความตองการของลกคาหรอผทเกยวของกบระบบ โดยแสดงออกมาในรป
ภาษาธรรมชาต ทแสดงถงการคาดหวงในบรการหรอการท างานทไดรบจากระบบ
2. ความตองการดานระบบ (System Requirement)
เปนการก าหนดความตองการของ
การท างาน ฟงกชน และบรการตาง
ๆ ของระบบในระดบรายละเอยดท
เรยกวา
“Functional Specification”
Page 3
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 3
Requirement Phase
ประเภทความตองการดานซอฟตแวร
1. ความตองการทเปนหนาทหลก (Functional Requirement) คอความตองการใหซอฟตแวรท าหนาทใด ๆ ตามทก าหนดไว ซงกคอสงท
ซอฟตแวรควรท าเปนหลกในการท างานหรอเปนบรการทซอฟตแวรตองม เชน
- นกศกษาสามารถตรวจสอบผลการเรยนได และการลงทะเบยนเรยนได
- นกศกษาสามารถตรวจสอบตารางเรยนของตนเองได หรอตารางสอนอาจารยได
- นกศกษาสามารถเพมรายวชาเรยนหรอเพกถอนรายวชาเรยนได
Functional Requirement -> Complete & Consistency หมายเหต : ในทางปฏบตเปนไปไดยาก โดยเฉพาะระบบทมความซบซอนสง
เนองจากความตองการของเจาของหรอผใชแตละคนแตกตางกน
อกท งการใหขอมลอาจก ากวมไมชดเจน ท าใหเกดปญหาความ
เขาใจทไมตรงกนได
Page 4
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 4
Requirement Phase
ประเภทความตองการดานซอฟตแวร
2. ความตองการทไมใชหนาทหลก (non-Functional Requirement) คอความตองการทไมไดเกยวของกบหนาทหรอฟงกชนหลกของระบบ แต
เกยวของทางออมในลกษณะทเปนเงอนไขของฟงกชนหรอบรการ และอาจไมได
เกยวของกบซอฟตแวรเพยงอยางเดยว ไดแก
(1) ความตองการดานผลตภณฑ (Product Requirement)
ไดแก ความตองการดานประสทธภาพ , ความนาเชอถอ และใชงานงาย
(2) ความตองการขององคกร (Organizational Requirement)
ไดแก ความตองการเชงนโยบายและระเบยบปฏบตของลกคาและผพฒนา เชน
มาตรฐานการผลต ภาษา เมธอดทใช หรอก าหนดเวลาสงมอบ
(3) ความตองการจากปจจยภายนอก (External Requirement)
ไดแก ความตองการการท างานรวมกน , ดานกฎหมาย และจรยธรรม
หมายเหต : ความตองการดงกลาวตองใชความรอบคอบเปนพเศษ เนองจากม
อทธพลตอการตดสนใจยอมรบซอฟตแวรหรอระบบของผใชอยางมาก
Page 5
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 5
Requirement Phase
ประเภทความตองการดานซอฟตแวร ตวอยางคณลกษณะของระบบทใชก าหนดความตองการทไมใชหนาทหลก
คณลกษณะ หนวยวด
ความเรว - การประมวลผลรายการขอมล (หนวยเปนวนาท)
- ระยะเวลาตอบสนองตอการใชงาน
- เวลาในการเปลยนขอมลบนจอภาพ
ขนาด - กกะไบต (Gbytes)
- ขนาดของหนวยความจ าแรม
ใชงานงาย - ระยะเวลาทใชในการอบรมการใชงาน
- จ านวนของสวนชวยเหลอ (Help)
ความนาเชอถอ - คาเฉลยของขอผดพลาดทเกดขน
- ความนาจะเปนของระบบทไมสามารถใชงานได
- อตราของการเกดขอผดพลาด
ความสามารถในการท างานขามระบบได - จ านวนของระบบอนทใชงานได
Page 6
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 6
Requirement Phase
ความตองการของผใช ความตองการของผใช (User Requirement)
: คอความตองการทมตอระบบของผใช โดยจะอธบายท งสวนทเปนหนาทหลกและ
สวนทไมใชหนาทหลกของระบบ ดวยภาษาทผใชเขาใจ ไมควรใชศพทเทคนคมาก
จนเกนไป เนองจากผใชจะเขาใจพฤตกรรมของระบบของตนเทานน ส าหรบสวนท
เกยวของกบการออกแบบ สถาปตยกรรม หรอคณลกษณะของระบบ ผใชจะ
หลกเลยงและไมสนใจ
ปญหาทมกเกดขนจากการเกบความตองการ
1. ขาดความชดเจน เนองจากบางคร งการเขยนค าอธบายความตองการใหกระชบ ไม
ก ากวม โดยใชภาษาทไมใชเชงเทคนค
2. ไมสามารถจ าแนกประเภทของความตองการไดอยางชดเจน
3. บางคร งความตองการของผใชอาจมจดประสงคเดยวกน แตเขยนออกมาใน
ประโยคแตกตางกน ดงนนควรจดกลมความตองการของผใชทเหมอนกนเขาไว
ดวยกน
Page 7
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 7
Requirement Phase
วธปฏบตดานการสอสาร (Communication Practice)
กจกรรมการตดตอสอสารเปนสงทชวยใหการรวบรวมความตองการของลกคาเปนไปได การ
ตดตอสอสารทมประสทธภาพ นบเปนสงททาทายมากทสด
เนนหลกการส าคญ (Core Principles) ในการสอสารกบลกคา
หลกท 1 ฟง! (Listen!)
จงใหความส าคญกบทกค าของลกคา ถามขอสงสยใหสอบถามเพอความกระจาง
หลกท 2 เตรยมตวใหพรอมกอนเรมการตดตอสอสาร (Prepare before you
communicate)
พยายามทจะเขาใจปญหาดวยตนเองกอน โดยอาจตองมการหาขอมลเพมเตม
หลกท 3 ควรมผประสานงาน (Someone should facilitate the activity)
ในทก ๆ การตดตอสอสาร ควรจะมผน าทท าหนาทในการควบคมการสนทนาให
มงไปในทศทางทเกดผล และเปนผประนประนอมความขดแยงทอาจเกดขน
หลกท 4 การตดตอสอสารแบบพบหนากนดทสด (Face-to-face communication is
best)
โดยเฉพาะถามการเตรยมเอกสารประกอบอยางด เชน โครงรางของเรองทจะพด
Page 8
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 8
Requirement Phase
วธปฏบตดานการสอสาร (Communication Practice)
เนนหลกการส าคญ (Core Principles) ในการสอสารกบลกคา (ตอ)
หลกท 5 จดรายละเอยดการพดคยรวมถงขอตกลงในเรองตาง ๆ (Take notes and
document decision)
หลกท 6 พยายามใหเกดความรวมมอ (Strive for collaboration)
ความรวมมอกนระหวางสมาชกในทม เปนชวยกอใหเกดความไววางใจซงกน
และกน อนจะน าไปสเปาหมายรวมกนของทมได
หลกท 7 เนนหวขอ ไมแตกประเดน (Stay focused, modularize your discussion)
การตดตอสอสารใด ๆ กตาม ยงมผเกยวของมาก กยงมโอกาสขดแยงมากหรอวน
ไปวนมา ตองพยายามอยาใหการสนทนาออกนอกประเดน
หลกท 8 ถามอะไรไมชดเจน ใหวาดภาพประกอบ (If something is unclear, draw a
picture)
กรณทการสอสารดวยค าพดท าใหเกดความไมชดเจน การวาดภาพ ตาราง
หรอใชรปประกอบ อาจชวยได
หลกท 9 พยายามใหการตดตอสอสาร “เดนหนา” (Move on)
ไมวาจะไดขอสรปหรอไม หรอวามบางเรองทยงขาดความชดเจน กใหการสอสาร
เดนหนาไปกอน อยาพดซ าไปซ ามากหาขอยตไมไดใหเปลองเวลา
Page 9
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 9
Requirement Phase
วธปฏบตดานการสอสาร (Communication Practice)
เนนหลกการส าคญ (Core Principles) ในการสอสารกบลกคา (ตอ)
หลกท 10 การตอรองไมใชการแขงขนหรอเกม จะเปนการดทสด หากท งสองฝายเปนผชนะ
(Negotiation is not a contest or a game, It works best when both
parties win)
มหลาย ๆ เรองทนกวศวกรซอฟตแวรตองตอรองกบลกคา เชน งานทซอฟตแวร
ท าได ล าดบงานกอนหลง ก าหนดวนสงมอบ ท งน จะตองมการรวมมอรวมใจ
สรางเปาหมายรวมกน การตอรองตองอาศยการประนประนอมจากท งสองฝาย
Page 10
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 10
Requirement Phase
ความตองการของผใช
การเขยนเอกสารความตองการของผใชควรจะมหลกปฏบต
1. ก าหนดมาตรฐานของรปแบบเอกสาร เชน รปแบบการใชตวอกษร ขนาด ส และ
เนนขอความ การขดเสน ตวเอง ควรใชกบขอความสวนใด
(อยาลม!! ก าหนดแหลงทมาของความตองการ ผจดท า และวนทจดท าดวย)
2. จ าแนกความจ าเปนของความตองการ โดยแบงออกเปน “ความตองการทจ าเปน
(Mandatory Requirement)” และ “ความตองการทเปนความปรารถนา
(Desirable Requirement)” โดยใชค าน าหนาความตองการของท ง 2 ลกษณะ
คอ น าหนาวา “ตอง” ส าหรบความตองการทจ าเปน และ “ควร” ส าหรบความ
ตองการทปรารถนา
3. ในเอกสารควรเนนขอความทเปนประเดนส าคญของความตองการใหเหนเดนชด
เพอใหผใชมงความสนใจอยภายในขอบเขตของประเดนนน
4. หลกเลยงการใชค าศ พทหรอรปทางเทคนคในเอกสารใหมากทสดเทาทจะท าได
หากหลกเลยงไมได ควรหาศพททเหมาะสมกบผใชมากทสด
Page 11
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 11
Requirement Phase
ความตองการของระบบ
ความตองการของระบบ (System Requirement) เปนการก าหนดความตองการ
ท างาน ฟงกชน และการบรการตาง ๆ ทระบบจะตองมเพอตอบสนองความตองการของ
ผใช (หมายเหต : เกดจากการวเคราะหขอมลความตองการของผใชมาแลว)
เหตผลทตองระบรายละเอยดขนการออกแบบไวในความตองการของระบบ เพราะ
1. เพอชวยใหการก าหนดโครงการของเอกสารความตองการงายขน เชน ถาตองการ
ใชกระบวนการพฒนาแบบ Component Reuse ตองออกแบบสถาปตยกรรม
ของระบบกอน เพอก าหนดคอมโพเนนทยอย
2. ระบบจะตองท างานรวมกบระบบอนทมอยแลว ตองอาศยรายละเอยดการออกแบบ
เขามาชวยก าหนดความตองการ
3. เพอใหสามารถตอบสนองความนาเชอถอได บางคร งจ าเปนตองออกแบบ
สถาปตยกรรมเฉพาะขนมากอนเพอใชเปนกรอบการท างานตอไป
Page 12
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 12
Requirement Phase
ความตองการของระบบ
การเขยนขอก าหนดความตองการดานระบบ (System Requirement
Specification) ควรใชภาษาธรรมชาตหรอภาษาทเขาใจงายเชนเดยวกบขอก าหนด
ความตองการของผใช (User Requirement Specification) แตอยางไรกตามความ
ตองการของระบบนนมรายละเอยดทางเทคนคมากกวา ภาษาทใชอาจก ากวม ท าให
เขาใจผดได จงมการก าหนดมาตรฐานในการใชภาษาธรรมชาตมาอธบายดงน
1. Form-Based Specification
2. Tubular Specification
3. Graphic Model
Page 13
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 13
Requirement Phase
ความตองการของระบบ
1. Form-Based Specification
แหลงเอกสาร
Function
Description
Inputs
Outputs
Source
Destination
Action
Pre-Condition
Post-Condition
จดวางรายละเอยดอยางเปนระเบยบ
แตยงไมสามารถลดความก ากวมได
อยางสมบรณ เนองจากความตองการ
หากเปนการค านวณคาตาง ๆ จะท า
ใหอานยาก
Page 14
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 14
Requirement Phase
ความตองการของระบบ
2. Tubular Specification
กรณทตองการค านวณคาตาง ๆ อาจอธบายในรปของตารางเพมเตมจาก Form-Based ได
จะท าใหเขาใจงายขน นอกจากน ตารางยงสามารถใชแสดงการตดสนใจและทางเลอกตาง ๆ
ไดอกดวย
เงอนไข การกระท า
Member = Yes Discount = 5% Then
Net Price = Total Price – (Total Price * Discount)
Member = No Discount = 0% Then
Net Price = Total Price
Page 15
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 15
Requirement Phase
ความตองการของระบบ
3. Graphic Model
เปนการน าแผนภาพหรอแบบจ าลองมาใชอธบายขอมลความตองการเพมเตม
เนองจากรปภาพลดความก ากวมหรอแทนค าอธบายไดมากกวา ชวยใหเขาใจมาก
ยงขน แตอยางไรกตามการใชแผนภาพจ าเปนตองมความรและความเขาใจใน
สญลกษณทปรากฏในแผนภาพดงกลาวดวย
: order : Customer : Product
Officer
getOrderInfo()
getCustInfo()
getProdInfo()
CalTotal() displayResult()
Ex. Sequence Diagram
Page 16
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 16
Requirement Phase
ความตองการของซอฟตแวร
ความตองการของซอฟตแวร (Software Requirement) เปนเอกสารขอก าหนดความ
ตองการ (Software Requirement Specification) อยางเปนทางการ ทจะบอกทม
พฒนาใหทราบวาตองการพฒนาอะไรบาง โดยบรรจท ง User Requirement และ
System Requirement
ขอก าหนดความตองการของซอฟตแวร (Software Requirement Specification : SRS)
1. บทน า (Introduction)
เกรนทมาของการพฒนาระบบเบองตน
1.1 ปญหาทพบ (Problem Statement)
1.2 บคลากรทเกยวของกบระบบ (System Personal)
1.3 การปฏบต (Operational Setting)
(อธบายล าดบข นตอนการปฏบตงานกอนและหลงใชระบบใหม)
1.4 การวเคราะหผลกระทบ (Impact Analysis)
1.5 ระบบทเกยวของ (Related Systems)
อธบายถงปญหา หรอลกษณะ
ของปญหาทท าให เหนความ
จ าเปนทจะตองพฒนาระบบใหม
นขนมา
อธบายถงบคลากรทเกยวของกบ
ระบบ โดยจ าแนกตามหนาทของ
บคลากรอาท
system end users
paying customers
project managers
domain experts
system analysts
system developers
บคคลารบางกลมอาจท าหนาทท
ทบซอนกนกได
อ ธ บ า ย ก า ร ต ด ต ง ร ะ บ บ ท ถ ก ใ ช ใ น
สภาพแวดลอมหนง ๆ โดยการอภปรายให
เหนถงวธการด าเนนงานเปรยบเทยบกอน
และหลงทมระบบ เพอใหสามารถตอบ
ค าถามขอดของระบบได
การวเคราะหผลกระทบในการ
พฒนาระบบ โดยน าเสนอท ง
ผลกระทบเชงบวก (เชน การผลต
ทเพมขนและยอดขายผลตภณฑท
สงขน) และ ผลกระทบเชงลบ
(เชน แรงงาน ผลกระทบทาง
กฎหมายทอาจเกดขนในทางลบ)
เพอใหเกดการพจารณาตอไป
ระบบอนทเกยวของกบระบบคอมพวเตอรทใชงาน
อย โดยความเกยวพนนอาจเปนฟงกช นหนงท
ก าหนดใหมขน ซงโดยสวนใหญระบบในเชง
พานชย หรอระบบส าคญควรม
และสามารถชแจงใหเหนถงค าตอบหวขอตอไปน:
อะไรคอขอดในการเกยวของกบระบบอน
i.e., คณลกษณะทควรน าเสนอในระบบ
อะไรคอขอเสยในการเกยวของกบระบบอน
i.e., คณลกษณะทไมควรน ามาเสนอในระบบ
แตหาสงทแตกตางหรอหาหนทางอนทดกวา
แทน
อะไรคอขอผดพลาดหากเกยวของกบระบบ
อน i.e., คณลกษณะใหมทควรน าเสนอใน
ระบบเมอไมพบในระบบอนทเกยวขอ
คณลกษณะส าคญอน ๆ
Page 17
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 17
Requirement Phase
ความตองการของซอฟตแวร
ขอก าหนดความตองการของซอฟตแวร (Software Requirement Specification : SRS)
1. บทน า (Introduction)
2. ขอก าหนดความตองการ (Specification Requirement)
2.1 Functional Requirement
2.1.1 User Interface Overview
2.1.2 System Specific Overview
2.2 Non-Functional Requirement
2.2.1 System-Related Non-Functional Requirements
2.2.2 Process-Related Non-Functional Requirements
2.2.3 Personnel-Related Non-Functional Requirements
3. การวเคราะหและการออกแบบระบบ (System Analysis and Design)
4. ภาคผนวก (Appendices)
5. ดชน (Index)
Functional Requirement ภายใน
ระบบ ทตองแสดงใหเหนถงสถานะใช
งานเชงสถานการณ/เหตการณ เชงลก
น าเสนอภาพรวมในสวนประสานของ
ผ ใช โดยอธบ ายการท า ง านของ
ฟงกช นทผใชส งการ ตวอยางเชน ถา
ผใชคลกเมน 1 ระบบจะด าเนนการ
อะไร แสดงอะไร
Functional Requirement ก าหนด
ฟง กช น เฉพาะทระบบซอฟตแว ร
ด าเนนการ พรอมกบขอมลทฟงกชน
เหลานนตองด าเนนการ โดยอธบายให
เหนปฏส มพ นธระหวางระบบก บ
ผใชงาน
Non-functional requirements คอ
ความตองการทไมเปนฟงกช นหลก
ของระบบ ซงฟงกช นเหลานรวมถง
ประสทธภาพของระบบ / คาใชจาย
และลกษณะท วไปของระบบ / ความ
นาเชอถอการรกษาความปลอดภย
และความตองการทในแงมมของการ
พ ฒนาระบบ และบคลากรทร วม
ปฏบตงาน
Non-functional system require-
ments ประกอบดวย:
I. ประสทธภาพ
- time
- space
II. สภาพแวดลอมการปฏบตงาน
- hardware platform
- software platform
- external software
interoperability
III. มาตรฐานทสอดคลองกน
IV. คณสมบตท วไป
- reliability
- robustness
- accuracy of data
- correctness
- security
- privacy
- safety
- portability
- modifiability and
extensibility
- simplicity versus power .
Non-functional process require-
ments ประกอบดวย:
a) เวลาในการพฒนา
b) คาใชจายในการพฒนา
c) ขอจ ากดของ SDLC
d) การสงมอบระบบ
- extent of deliverables
- deliverable formats
e) การตดต งระบบ
- developer access to
installed environment
- phase-in procedures to
replace existing system
f) มาตรฐานทสอดคลองกน
g) การรายงาน
h) การตลาด
- pricing
- target customer base
i) สญญา (RSD) และกฏหมายทเกยวของ
Non-functional personnel require-
ments ประกอบดวย :
a) ส าหรบผพฒนา:
- หนงสอรบรอง/การการนตบคคล
- ประกาศนยบตร/ลขสทธการพฒนา
แอพพลเคช น
b) ส าหรบผใช:
- ระดบทกษะการใชงาน
- การเขาถงระดบพเศษ
- การฝกอบรม
Page 18
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 18
Requirement Engineer
การจดท าขอก าหนดความตองการ ตองมคณสมบตส าคญ คอ
“สามารถตรวจสอบ พสจน และวเคราะหคณภาพได”
ดงนนจงตองมกระบวนการบางอยางทท าใหก าหนดความตองการถกตองและตรงกบท
ตองการอยางแทจรง เรยกวา วศวกรรมความตองการ
“กระบวนการทท าใหวศวกรซอฟตแวร
เขาใจและเขาถงความตองการของลกคาไดอยางแทจรง”
เปาหมายของวศวกรรมซอฟตแวร
คอ การสรางและบ ารงรกษาเอกสารขอก าหนดความตองการ ท งในดานระบบ และ
ซอฟตแวร ใหเปนเอกสารทมคณภาพมากทสด
Page 19
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 19
Requirement Engineer
กระบวนการวศวกรรมความตองการ
กจกรรมของวศวกรรมความตองการ
อยระยะการวเคราะหความตองการของกระบวนการผลตซอฟตแวร ตองด าเนนงานอยาง
เปนข นตอน มกระบวนการและทมงานเฉพาะ ประกอบไปดวยกจกรรมยอยดงน
1. สกดความตองการ
2. วเคราะหความตองการ
3. ก าหนดความตองการ
4. ตรวจสอบความตองการ
สกดความตองการ
(Requirement Elicitation)
วเคราะหความตองการ
(Requirement Analysis)
ก าหนดความตองการ
(Requirement Spec.)
ตรวจสอบความตองการ
(Requirement Validation)
ความตองการประเภทตาง ๆ
แบบจ าลองความตองการ
ขอก าหนดความตองการ
เอกสารขอก าหนดความตองการ
Page 20
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 20
Requirement Engineer
กระบวนการวศวกรรมความตองการ
1. สกดความตองการ (Requirement Elicitation) สกดความตองการ คอ การรวบรวมหรอคนหาความตองการ เปนข นตอนการท า
ความเขาใจปญหาทเกดขนทตองการแกไขดวยซอฟตแวร (ความจ าเปนของการ
น าซอฟตแวรมาใช) โดยเรมตนจากก าหนดกลมบคคลทเกยวของซงเปน
แหลงทมาของความตองการ จากนนรวบรวมความตองการดวยเทคนคตาง ๆ
- สมภาษณ (Interview)
เปนวธด งเดมและนยมใชมากทสด วศวกรซอฟตแวรควรทราบถงขอด-
ขอเสยของวธการสมภาษณ รวมท งวธการโนมนาวผถกสมภาษณดวย
- การแสดงล าดบเหตการณ (Scenario)
เปนการเตรยมค าถามตามล าดบงานของผใช ในแตละงานมการต งค าถามวา
“จะเกดอะไรขน ถา...” และ “จะตองท าอยางไร” การรวบรวมความตองการ
ดวยเทคนคนจะเชอมโยงไปยงการสรางแบบจ าลอง Use Case ไดงาย และ
Use Case เปนลกษณะหนงของ Scenario ผใชจงเขาใจค าถามไดงาย ท า
ใหการตอบค าถามไดชดเจนขน
Page 21
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 21
Requirement Engineer
กระบวนการวศวกรรมความตองการ
1. สกดความตองการ (Requirement Elicitation) ตอ - ตนแบบ (Prototype)
เปนเทคนคทท าใหผเขาใจในสถานการณและค าถามไดงายเชนกน การท า
ตนแบบมหลายชนด เชน การออกแบบจอภาพบนกระดาษ เพอทดสอบการ
ยอมรบความตองการในเบองตน ซงอาจเปนเทคนคซ ากบการตรวจสอบ
ความตองการ
- การประชม (Facilitated Meeting)
เปนการเรยกกลมบคคลทเกยวของเขารวมประชมเพอขอความคดเหนและ
ความตองการ เพอใหเกดความเขาใจในความตองการอยางถองแทมากกวา
การท างานเพยงล าพง เปนการระดมความคดเพอแกไขปญหาเมอพบขอ
ขดแยงในความตองการ อยางไรกตาม ตองระมดระวงเรองความขดแยง
ระหวางกลมบคคลทอาจเกดขนไดในทกองคกร
Page 22
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 22
Requirement Engineer
กระบวนการวศวกรรมความตองการ
2. วเคราะหความตองการ (Requirement Analysis)
ประเมนความตองการทรวบรวมมาได เพอจดกลมความตองการ จดล าดบความส าคญ แกไขความขดแยงระหวางความตองการเพอใหเกดความสอดคลอง
กน จากนนสรางแบบจ าลองทเปน Conceptual Model และน าเสนอผเกยวของ
ท งหมดใหยอมรบในความตองการทได หากไมยอมรบตองแกไข เจรจาตอรอง
และน าเสนอจนกวาจะไดรบการยอมรบในทสด
3. ก าหนดความตองการ (Requirement Specification) หลงจากแบบจ าลองความตองการไดรบการยอมรบแลว จะน ามาจดท าเอกสาร
ความตองการ โดยเรมจากการนยามความตองการ และจดท าเปนขอก าหนดของ
ระบบ เพอแจกแจงเปนขอก าหนดความตองการของซอฟตแวร โดยเอกสาร
ท งหมด ตองตรวจสอบและวดคณภาพได
Page 23
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 23
Requirement Engineer
กระบวนการวศวกรรมความตองการ
4. ตรวจสอบความตองการ (Requirement Validation) เปนการทบทวนและตรวจสอบขอก าหนดความตองการในเอกสารท งหมด เพอให
เกดความเทยงตรง สอดคลอง ครบถวนสมบรณ มความเปนไปได และสามารถ
พสจนไดตามเปาหมายของกระบวนการวศวกรรมซอฟตแวร จากนนจะน าไป
ทดสอบเพอใหเกดการยอมรบจากบคคลทกฝายทเกยวของ
- ความเทยงตรง (Validity)
นอกจากฟงกชนพนฐานทผใชสวนใหญตองการแลว อาจมฟงกชนบางอยางท
ผใชกลมอนตองการ ดงนนทมงานควรใหความส าคญ เนองจากผใชแตละ
กลมมความตองการแตกตางกน ดงนนการก าหนดความตองการจะ
ตอบสนองกบผใชทกกลมอยางเทาเทยมกน
- ความสอดคลอง (Consistency)
ความตองการในเอกสารจะตองไมมการทบซอนกน ไมมความขดแยงกน
หากพบความตองการไมเปนแนวทางเดยวกน ตองตรวจสอบและแกไขให
สอดคลองกนทนท
Page 24
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 24
Requirement Engineer
กระบวนการวศวกรรมความตองการ
4. ตรวจสอบความตองการ (Requirement Validation) - ความครบถวนสมบรณ (Completeness)
เอกสารตองระบรายละเอยดฟงกชนและการบรการอยางครบถวน และ
ครอบคลมความตองการของผใช จะตองไมมฟงกชนใดทผใชตองการขาด
หายไป
- ความเปนไปได (Feasibility)
เปนการตรวจสอบความตองการดวยองคความรเกยวกบเทคโนโลยทองคกรม
อย เพอใหม นใจวาสามารถน าความตองการทระบในเอกสารไปพฒนาระบบ
ไดจรง ซงนอกจากความเปนไปไดทางเทคโนโลยแลว ยงตองพจารณาถง
ความเปนไปไดดานงบประมาณและระยะเวลาในการพฒนาดวย หากใช
งบประมาณหรอเวลาในการพฒนามากกวาทมอย ถอวาความเปนไปไดนอย
มาก
- สามารถพสจนได (Verifiability)
ความตองการนนตองพสจนหาความจรงได คอ ตองทดสอบและทดลองให
ลกคาเหนถงการท างานจรงของระบบตามทระบไวในเอกสารได
Page 25
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 25
Requirement Engineer
กระบวนการวศวกรรมความตองการ
4. ตรวจสอบความตองการ (Requirement Validation) เทคนคของการตรวจสอบความตองการ
- การทบทวนความตองการ (Requirement Review)
เปนการตรวจสอบเอกสารความตองการอยางละเอยด เพอตรวจหาความ
ตองการหรอขอสมมตฐานทผดพลาด ถกละเลย ไมชดเจน และไมตรงกบ
มาตรฐานทก าหนด
(1) ทบทวนแบบไมเปนทางการ (Informal Review) ทมทบทวนจะน า
เอกสารความตองการมาพจารณาหาขอผดพลาดรวมกบผมสวนไดสวน
เสยและผรบเหมาชวง
(2) ทบทวนแบบเปนทางการ (Formal Review) ทมทบทวนจะตอง
พจารณาความตองการรวมกบผใชทละรายการ เพอตรวจสอบความ
สอดคลองและความครบถวนสมบรณตามลกษณะดงตอไปน
- สามารถพสจนได - สามารถเขาใจได
- สามารถยอนกลบไปตรวจสอบได
- สามารถดดแปลงได (โดยไมสงผลกระทบตอระบบ)
Page 26
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 26
Requirement Engineer
กระบวนการวศวกรรมความตองการ
4. ตรวจสอบความตองการ (Requirement Validation) เทคนคของการตรวจสอบความตองการ
- การจดท าตนแบบ (Prototyping)
เปนการสรางตนแบบของระบบ (Executable Model) เพอสาธตใหลกคา
หรอผใชระบบด หรอทดลองใชดวยตนเอง นอกจากนยงเปนวธทรวบรวม
ความตองการทเกดขนใหมไดดวย อยางไรกตาม การสรางตนแบบตองใช
เงนทนสง แตเมอเปรยบเทยบกบผลทไดรบนบวาคมคามาก จดเปนวธทด
ทสดอยางหนง
- การสรางแบบทดสอบ (Test-Case Generation)
ความตองการทดตองสามารถทดสอบได และถาทดสอบนนท าไดยากหรอ
ออกแบบยาก แสดงวาการน าความตองการดงกลาวไปพฒนาจากตามไปดวย
จงความน าความตองการนนกลบไปพจารณาใหม
Page 27
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 27
Requirement Engineer
กระบวนการวศวกรรมความตองการ
การจดการความตองการ (Requirement Management) จดเปน
สวนหนงของกระบวนการวศวกรรมความตองการ
“ กระบวนการท าความเขาใจและควบคมการเปลยนแปลง
ความตองการของระบบ ”
โดยสามารถเรมด าเนนการไดทนททจดท าเอกสารขอก าหนดความตองการฉบบราง
เสรจเรยบรอย (ข นท 4) แตการวางแผนการจดการความตองการนน ควรเรมต งแต
ข นตอนการสกดความตองการเรมขน (ข นท 1) สาเหตของการเปลยนแปลง :
1. ผใชมหลายกลม ความตองการแตกตางกนออกแบบ อาจเกดการขดแยง จง
หลกเลยงไมไดทจะตองปรบความสมดลของความตองการใหม
2. โดยท วไป ผใชซงเปนผจายเงนลงทน กบผใชระบบโดยตรงไมใชผใชกลม
เดยวกน
3. ภายหลงการตดต งระบบเพอใชงาน สภาพแวดลอมทางธรกจ และเทคโนโลยท
เปลยนแปลงไป มผลท าใหระบบตองเปลยนแปลงตามไปดวย
Page 28
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 28
Requirement Engineer
กระบวนการวศวกรรมความตองการ
มมมองของววฒนาการของความตองการ แบงความตองการออกเปน 2
ประเภท ไดแก
1. ความตองการทไมเปลยนแปลง (Enduring Requirement)
เปนความตองการแบบคงท ไมเปลยนแปลงไดงาย เปนความ
ตองการทเกดจากการท างานหลกของธรกจในแตละวน เชน ระบบ
ลงทะเบยน วชาเรยน คาลงทะเบยน เปนตน
2. ความตองการทเปลยนแปลง (Volatile Requirement)
เปนความตองการทเปลยนแปลงอยเสมอในระหวางการพฒนา
ระบบหรอหลงจากการตดต งระบบ เชน นโยบายการลงทะเบยน
เปนตน
Page 29
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 29
Requirement Engineer
กระบวนการวศวกรรมความตองการ
การจดการกบการเปลยนแปลงความตองการ
เมอมการยนขอเสนอใหมการเปลยนแปลงความตองการใด ๆ
เกดขน ทมงานหรอองคกรตองมกระบวนการจดการกบการเปลยนแปลง
(Requirement Change Management) ดงกลาว เพอใหการ
เปลยนแปลงทเกดขนมความสอดคลองกบสวนอนทสมพนธกน และอย
ภายใตการควบคมอยางเปนทางการ
กระบวนการจดการการแปลงเปลยนจะเกยวของกบการ
วเคราะหถงความคมคาเมอตองการเปลยนแปลงตามขอเสนอ หากม
ความคมคาจะอนมตใหด าเนนการเปลยนแปลงได แตหากพบวาไมได
รบผลตอบแทนทคมคากจะยกเลกขอเสนอนนไป