requirement phase - paijit.lpru.ac.thpaijit.lpru.ac.th/cgi-bin/s5672601/softeng7.pdf(negotiation is...
TRANSCRIPT
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 1
Requirement Phase
ความตองการ (Requirement)
“วตถดบทส าคญในการพฒนาระบบหรอการผลตซอฟตแวร เพอใชเปน
ขอก าหนดถงหนาทและรายละเอยดอน ๆ ทระบบหรอซอฟตแวรจะตองม”
ในการพฒนาระบบหรอการผลตซอฟตแวร ตองอาศยขอมลความตองการ
ของลกคาหรอผใช เปนตวก าหนด ฟงกชน รปลกษณ ความสามารถ และ
รายละเอยด แตเนองจากการพฒนามหลายแนวทางเชน พฒนาเอง จาง
เหมา หรอใชซอฟตแวรส าเรจรป หรอผลตเพอจ าหนาย จงท าให
ขอก าหนดความตองการมหลายระดบ หากจ าแนกระดบความตองการไม
ถกตอง จะสงผลใหซอฟตแวรไมตรงกบความตองการทแทจรง
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 2
Requirement Phase
ในแวดวงการผลตซอฟตแวร สามารถจดความตองการได 2 ระดบ
1. ความตองการของผใช (User Requirement) เปนความตองการของลกคาหรอผทเกยวของกบระบบ โดยแสดงออกมาในรป
ภาษาธรรมชาต ทแสดงถงการคาดหวงในบรการหรอการท างานทไดรบจากระบบ
2. ความตองการดานระบบ (System Requirement)
เปนการก าหนดความตองการของ
การท างาน ฟงกชน และบรการตาง
ๆ ของระบบในระดบรายละเอยดท
เรยกวา
“Functional Specification”
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 3
Requirement Phase
ประเภทความตองการดานซอฟตแวร
1. ความตองการทเปนหนาทหลก (Functional Requirement) คอความตองการใหซอฟตแวรท าหนาทใด ๆ ตามทก าหนดไว ซงกคอสงท
ซอฟตแวรควรท าเปนหลกในการท างานหรอเปนบรการทซอฟตแวรตองม เชน
- นกศกษาสามารถตรวจสอบผลการเรยนได และการลงทะเบยนเรยนได
- นกศกษาสามารถตรวจสอบตารางเรยนของตนเองได หรอตารางสอนอาจารยได
- นกศกษาสามารถเพมรายวชาเรยนหรอเพกถอนรายวชาเรยนได
Functional Requirement -> Complete & Consistency หมายเหต : ในทางปฏบตเปนไปไดยาก โดยเฉพาะระบบทมความซบซอนสง
เนองจากความตองการของเจาของหรอผใชแตละคนแตกตางกน
อกท งการใหขอมลอาจก ากวมไมชดเจน ท าใหเกดปญหาความ
เขาใจทไมตรงกนได
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 4
Requirement Phase
ประเภทความตองการดานซอฟตแวร
2. ความตองการทไมใชหนาทหลก (non-Functional Requirement) คอความตองการทไมไดเกยวของกบหนาทหรอฟงกชนหลกของระบบ แต
เกยวของทางออมในลกษณะทเปนเงอนไขของฟงกชนหรอบรการ และอาจไมได
เกยวของกบซอฟตแวรเพยงอยางเดยว ไดแก
(1) ความตองการดานผลตภณฑ (Product Requirement)
ไดแก ความตองการดานประสทธภาพ , ความนาเชอถอ และใชงานงาย
(2) ความตองการขององคกร (Organizational Requirement)
ไดแก ความตองการเชงนโยบายและระเบยบปฏบตของลกคาและผพฒนา เชน
มาตรฐานการผลต ภาษา เมธอดทใช หรอก าหนดเวลาสงมอบ
(3) ความตองการจากปจจยภายนอก (External Requirement)
ไดแก ความตองการการท างานรวมกน , ดานกฎหมาย และจรยธรรม
หมายเหต : ความตองการดงกลาวตองใชความรอบคอบเปนพเศษ เนองจากม
อทธพลตอการตดสนใจยอมรบซอฟตแวรหรอระบบของผใชอยางมาก
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 5
Requirement Phase
ประเภทความตองการดานซอฟตแวร ตวอยางคณลกษณะของระบบทใชก าหนดความตองการทไมใชหนาทหลก
คณลกษณะ หนวยวด
ความเรว - การประมวลผลรายการขอมล (หนวยเปนวนาท)
- ระยะเวลาตอบสนองตอการใชงาน
- เวลาในการเปลยนขอมลบนจอภาพ
ขนาด - กกะไบต (Gbytes)
- ขนาดของหนวยความจ าแรม
ใชงานงาย - ระยะเวลาทใชในการอบรมการใชงาน
- จ านวนของสวนชวยเหลอ (Help)
ความนาเชอถอ - คาเฉลยของขอผดพลาดทเกดขน
- ความนาจะเปนของระบบทไมสามารถใชงานได
- อตราของการเกดขอผดพลาด
ความสามารถในการท างานขามระบบได - จ านวนของระบบอนทใชงานได
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 6
Requirement Phase
ความตองการของผใช ความตองการของผใช (User Requirement)
: คอความตองการทมตอระบบของผใช โดยจะอธบายท งสวนทเปนหนาทหลกและ
สวนทไมใชหนาทหลกของระบบ ดวยภาษาทผใชเขาใจ ไมควรใชศพทเทคนคมาก
จนเกนไป เนองจากผใชจะเขาใจพฤตกรรมของระบบของตนเทานน ส าหรบสวนท
เกยวของกบการออกแบบ สถาปตยกรรม หรอคณลกษณะของระบบ ผใชจะ
หลกเลยงและไมสนใจ
ปญหาทมกเกดขนจากการเกบความตองการ
1. ขาดความชดเจน เนองจากบางคร งการเขยนค าอธบายความตองการใหกระชบ ไม
ก ากวม โดยใชภาษาทไมใชเชงเทคนค
2. ไมสามารถจ าแนกประเภทของความตองการไดอยางชดเจน
3. บางคร งความตองการของผใชอาจมจดประสงคเดยวกน แตเขยนออกมาใน
ประโยคแตกตางกน ดงนนควรจดกลมความตองการของผใชทเหมอนกนเขาไว
ดวยกน
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)
โดยเฉพาะถามการเตรยมเอกสารประกอบอยางด เชน โครงรางของเรองทจะพด
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)
ไมวาจะไดขอสรปหรอไม หรอวามบางเรองทยงขาดความชดเจน กใหการสอสาร
เดนหนาไปกอน อยาพดซ าไปซ ามากหาขอยตไมไดใหเปลองเวลา
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)
มหลาย ๆ เรองทนกวศวกรซอฟตแวรตองตอรองกบลกคา เชน งานทซอฟตแวร
ท าได ล าดบงานกอนหลง ก าหนดวนสงมอบ ท งน จะตองมการรวมมอรวมใจ
สรางเปาหมายรวมกน การตอรองตองอาศยการประนประนอมจากท งสองฝาย
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 10
Requirement Phase
ความตองการของผใช
การเขยนเอกสารความตองการของผใชควรจะมหลกปฏบต
1. ก าหนดมาตรฐานของรปแบบเอกสาร เชน รปแบบการใชตวอกษร ขนาด ส และ
เนนขอความ การขดเสน ตวเอง ควรใชกบขอความสวนใด
(อยาลม!! ก าหนดแหลงทมาของความตองการ ผจดท า และวนทจดท าดวย)
2. จ าแนกความจ าเปนของความตองการ โดยแบงออกเปน “ความตองการทจ าเปน
(Mandatory Requirement)” และ “ความตองการทเปนความปรารถนา
(Desirable Requirement)” โดยใชค าน าหนาความตองการของท ง 2 ลกษณะ
คอ น าหนาวา “ตอง” ส าหรบความตองการทจ าเปน และ “ควร” ส าหรบความ
ตองการทปรารถนา
3. ในเอกสารควรเนนขอความทเปนประเดนส าคญของความตองการใหเหนเดนชด
เพอใหผใชมงความสนใจอยภายในขอบเขตของประเดนนน
4. หลกเลยงการใชค าศ พทหรอรปทางเทคนคในเอกสารใหมากทสดเทาทจะท าได
หากหลกเลยงไมได ควรหาศพททเหมาะสมกบผใชมากทสด
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 11
Requirement Phase
ความตองการของระบบ
ความตองการของระบบ (System Requirement) เปนการก าหนดความตองการ
ท างาน ฟงกชน และการบรการตาง ๆ ทระบบจะตองมเพอตอบสนองความตองการของ
ผใช (หมายเหต : เกดจากการวเคราะหขอมลความตองการของผใชมาแลว)
เหตผลทตองระบรายละเอยดขนการออกแบบไวในความตองการของระบบ เพราะ
1. เพอชวยใหการก าหนดโครงการของเอกสารความตองการงายขน เชน ถาตองการ
ใชกระบวนการพฒนาแบบ Component Reuse ตองออกแบบสถาปตยกรรม
ของระบบกอน เพอก าหนดคอมโพเนนทยอย
2. ระบบจะตองท างานรวมกบระบบอนทมอยแลว ตองอาศยรายละเอยดการออกแบบ
เขามาชวยก าหนดความตองการ
3. เพอใหสามารถตอบสนองความนาเชอถอได บางคร งจ าเปนตองออกแบบ
สถาปตยกรรมเฉพาะขนมากอนเพอใชเปนกรอบการท างานตอไป
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
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
จดวางรายละเอยดอยางเปนระเบยบ
แตยงไมสามารถลดความก ากวมได
อยางสมบรณ เนองจากความตองการ
หากเปนการค านวณคาตาง ๆ จะท า
ใหอานยาก
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
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
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., คณลกษณะใหมทควรน าเสนอใน
ระบบเมอไมพบในระบบอนทเกยวขอ
คณลกษณะส าคญอน ๆ
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) ส าหรบผใช:
- ระดบทกษะการใชงาน
- การเขาถงระดบพเศษ
- การฝกอบรม
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 18
Requirement Engineer
การจดท าขอก าหนดความตองการ ตองมคณสมบตส าคญ คอ
“สามารถตรวจสอบ พสจน และวเคราะหคณภาพได”
ดงนนจงตองมกระบวนการบางอยางทท าใหก าหนดความตองการถกตองและตรงกบท
ตองการอยางแทจรง เรยกวา วศวกรรมความตองการ
“กระบวนการทท าใหวศวกรซอฟตแวร
เขาใจและเขาถงความตองการของลกคาไดอยางแทจรง”
เปาหมายของวศวกรรมซอฟตแวร
คอ การสรางและบ ารงรกษาเอกสารขอก าหนดความตองการ ท งในดานระบบ และ
ซอฟตแวร ใหเปนเอกสารทมคณภาพมากทสด
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 19
Requirement Engineer
กระบวนการวศวกรรมความตองการ
กจกรรมของวศวกรรมความตองการ
อยระยะการวเคราะหความตองการของกระบวนการผลตซอฟตแวร ตองด าเนนงานอยาง
เปนข นตอน มกระบวนการและทมงานเฉพาะ ประกอบไปดวยกจกรรมยอยดงน
1. สกดความตองการ
2. วเคราะหความตองการ
3. ก าหนดความตองการ
4. ตรวจสอบความตองการ
สกดความตองการ
(Requirement Elicitation)
วเคราะหความตองการ
(Requirement Analysis)
ก าหนดความตองการ
(Requirement Spec.)
ตรวจสอบความตองการ
(Requirement Validation)
ความตองการประเภทตาง ๆ
แบบจ าลองความตองการ
ขอก าหนดความตองการ
เอกสารขอก าหนดความตองการ
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 20
Requirement Engineer
กระบวนการวศวกรรมความตองการ
1. สกดความตองการ (Requirement Elicitation) สกดความตองการ คอ การรวบรวมหรอคนหาความตองการ เปนข นตอนการท า
ความเขาใจปญหาทเกดขนทตองการแกไขดวยซอฟตแวร (ความจ าเปนของการ
น าซอฟตแวรมาใช) โดยเรมตนจากก าหนดกลมบคคลทเกยวของซงเปน
แหลงทมาของความตองการ จากนนรวบรวมความตองการดวยเทคนคตาง ๆ
- สมภาษณ (Interview)
เปนวธด งเดมและนยมใชมากทสด วศวกรซอฟตแวรควรทราบถงขอด-
ขอเสยของวธการสมภาษณ รวมท งวธการโนมนาวผถกสมภาษณดวย
- การแสดงล าดบเหตการณ (Scenario)
เปนการเตรยมค าถามตามล าดบงานของผใช ในแตละงานมการต งค าถามวา
“จะเกดอะไรขน ถา...” และ “จะตองท าอยางไร” การรวบรวมความตองการ
ดวยเทคนคนจะเชอมโยงไปยงการสรางแบบจ าลอง Use Case ไดงาย และ
Use Case เปนลกษณะหนงของ Scenario ผใชจงเขาใจค าถามไดงาย ท า
ใหการตอบค าถามไดชดเจนขน
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 21
Requirement Engineer
กระบวนการวศวกรรมความตองการ
1. สกดความตองการ (Requirement Elicitation) ตอ - ตนแบบ (Prototype)
เปนเทคนคทท าใหผเขาใจในสถานการณและค าถามไดงายเชนกน การท า
ตนแบบมหลายชนด เชน การออกแบบจอภาพบนกระดาษ เพอทดสอบการ
ยอมรบความตองการในเบองตน ซงอาจเปนเทคนคซ ากบการตรวจสอบ
ความตองการ
- การประชม (Facilitated Meeting)
เปนการเรยกกลมบคคลทเกยวของเขารวมประชมเพอขอความคดเหนและ
ความตองการ เพอใหเกดความเขาใจในความตองการอยางถองแทมากกวา
การท างานเพยงล าพง เปนการระดมความคดเพอแกไขปญหาเมอพบขอ
ขดแยงในความตองการ อยางไรกตาม ตองระมดระวงเรองความขดแยง
ระหวางกลมบคคลทอาจเกดขนไดในทกองคกร
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 22
Requirement Engineer
กระบวนการวศวกรรมความตองการ
2. วเคราะหความตองการ (Requirement Analysis)
ประเมนความตองการทรวบรวมมาได เพอจดกลมความตองการ จดล าดบความส าคญ แกไขความขดแยงระหวางความตองการเพอใหเกดความสอดคลอง
กน จากนนสรางแบบจ าลองทเปน Conceptual Model และน าเสนอผเกยวของ
ท งหมดใหยอมรบในความตองการทได หากไมยอมรบตองแกไข เจรจาตอรอง
และน าเสนอจนกวาจะไดรบการยอมรบในทสด
3. ก าหนดความตองการ (Requirement Specification) หลงจากแบบจ าลองความตองการไดรบการยอมรบแลว จะน ามาจดท าเอกสาร
ความตองการ โดยเรมจากการนยามความตองการ และจดท าเปนขอก าหนดของ
ระบบ เพอแจกแจงเปนขอก าหนดความตองการของซอฟตแวร โดยเอกสาร
ท งหมด ตองตรวจสอบและวดคณภาพได
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 23
Requirement Engineer
กระบวนการวศวกรรมความตองการ
4. ตรวจสอบความตองการ (Requirement Validation) เปนการทบทวนและตรวจสอบขอก าหนดความตองการในเอกสารท งหมด เพอให
เกดความเทยงตรง สอดคลอง ครบถวนสมบรณ มความเปนไปได และสามารถ
พสจนไดตามเปาหมายของกระบวนการวศวกรรมซอฟตแวร จากนนจะน าไป
ทดสอบเพอใหเกดการยอมรบจากบคคลทกฝายทเกยวของ
- ความเทยงตรง (Validity)
นอกจากฟงกชนพนฐานทผใชสวนใหญตองการแลว อาจมฟงกชนบางอยางท
ผใชกลมอนตองการ ดงนนทมงานควรใหความส าคญ เนองจากผใชแตละ
กลมมความตองการแตกตางกน ดงนนการก าหนดความตองการจะ
ตอบสนองกบผใชทกกลมอยางเทาเทยมกน
- ความสอดคลอง (Consistency)
ความตองการในเอกสารจะตองไมมการทบซอนกน ไมมความขดแยงกน
หากพบความตองการไมเปนแนวทางเดยวกน ตองตรวจสอบและแกไขให
สอดคลองกนทนท
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 24
Requirement Engineer
กระบวนการวศวกรรมความตองการ
4. ตรวจสอบความตองการ (Requirement Validation) - ความครบถวนสมบรณ (Completeness)
เอกสารตองระบรายละเอยดฟงกชนและการบรการอยางครบถวน และ
ครอบคลมความตองการของผใช จะตองไมมฟงกชนใดทผใชตองการขาด
หายไป
- ความเปนไปได (Feasibility)
เปนการตรวจสอบความตองการดวยองคความรเกยวกบเทคโนโลยทองคกรม
อย เพอใหม นใจวาสามารถน าความตองการทระบในเอกสารไปพฒนาระบบ
ไดจรง ซงนอกจากความเปนไปไดทางเทคโนโลยแลว ยงตองพจารณาถง
ความเปนไปไดดานงบประมาณและระยะเวลาในการพฒนาดวย หากใช
งบประมาณหรอเวลาในการพฒนามากกวาทมอย ถอวาความเปนไปไดนอย
มาก
- สามารถพสจนได (Verifiability)
ความตองการนนตองพสจนหาความจรงได คอ ตองทดสอบและทดลองให
ลกคาเหนถงการท างานจรงของระบบตามทระบไวในเอกสารได
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 25
Requirement Engineer
กระบวนการวศวกรรมความตองการ
4. ตรวจสอบความตองการ (Requirement Validation) เทคนคของการตรวจสอบความตองการ
- การทบทวนความตองการ (Requirement Review)
เปนการตรวจสอบเอกสารความตองการอยางละเอยด เพอตรวจหาความ
ตองการหรอขอสมมตฐานทผดพลาด ถกละเลย ไมชดเจน และไมตรงกบ
มาตรฐานทก าหนด
(1) ทบทวนแบบไมเปนทางการ (Informal Review) ทมทบทวนจะน า
เอกสารความตองการมาพจารณาหาขอผดพลาดรวมกบผมสวนไดสวน
เสยและผรบเหมาชวง
(2) ทบทวนแบบเปนทางการ (Formal Review) ทมทบทวนจะตอง
พจารณาความตองการรวมกบผใชทละรายการ เพอตรวจสอบความ
สอดคลองและความครบถวนสมบรณตามลกษณะดงตอไปน
- สามารถพสจนได - สามารถเขาใจได
- สามารถยอนกลบไปตรวจสอบได
- สามารถดดแปลงได (โดยไมสงผลกระทบตอระบบ)
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 26
Requirement Engineer
กระบวนการวศวกรรมความตองการ
4. ตรวจสอบความตองการ (Requirement Validation) เทคนคของการตรวจสอบความตองการ
- การจดท าตนแบบ (Prototyping)
เปนการสรางตนแบบของระบบ (Executable Model) เพอสาธตใหลกคา
หรอผใชระบบด หรอทดลองใชดวยตนเอง นอกจากนยงเปนวธทรวบรวม
ความตองการทเกดขนใหมไดดวย อยางไรกตาม การสรางตนแบบตองใช
เงนทนสง แตเมอเปรยบเทยบกบผลทไดรบนบวาคมคามาก จดเปนวธทด
ทสดอยางหนง
- การสรางแบบทดสอบ (Test-Case Generation)
ความตองการทดตองสามารถทดสอบได และถาทดสอบนนท าไดยากหรอ
ออกแบบยาก แสดงวาการน าความตองการดงกลาวไปพฒนาจากตามไปดวย
จงความน าความตองการนนกลบไปพจารณาใหม
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 27
Requirement Engineer
กระบวนการวศวกรรมความตองการ
การจดการความตองการ (Requirement Management) จดเปน
สวนหนงของกระบวนการวศวกรรมความตองการ
“ กระบวนการท าความเขาใจและควบคมการเปลยนแปลง
ความตองการของระบบ ”
โดยสามารถเรมด าเนนการไดทนททจดท าเอกสารขอก าหนดความตองการฉบบราง
เสรจเรยบรอย (ข นท 4) แตการวางแผนการจดการความตองการนน ควรเรมต งแต
ข นตอนการสกดความตองการเรมขน (ข นท 1) สาเหตของการเปลยนแปลง :
1. ผใชมหลายกลม ความตองการแตกตางกนออกแบบ อาจเกดการขดแยง จง
หลกเลยงไมไดทจะตองปรบความสมดลของความตองการใหม
2. โดยท วไป ผใชซงเปนผจายเงนลงทน กบผใชระบบโดยตรงไมใชผใชกลม
เดยวกน
3. ภายหลงการตดต งระบบเพอใชงาน สภาพแวดลอมทางธรกจ และเทคโนโลยท
เปลยนแปลงไป มผลท าใหระบบตองเปลยนแปลงตามไปดวย
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 28
Requirement Engineer
กระบวนการวศวกรรมความตองการ
มมมองของววฒนาการของความตองการ แบงความตองการออกเปน 2
ประเภท ไดแก
1. ความตองการทไมเปลยนแปลง (Enduring Requirement)
เปนความตองการแบบคงท ไมเปลยนแปลงไดงาย เปนความ
ตองการทเกดจากการท างานหลกของธรกจในแตละวน เชน ระบบ
ลงทะเบยน วชาเรยน คาลงทะเบยน เปนตน
2. ความตองการทเปลยนแปลง (Volatile Requirement)
เปนความตองการทเปลยนแปลงอยเสมอในระหวางการพฒนา
ระบบหรอหลงจากการตดต งระบบ เชน นโยบายการลงทะเบยน
เปนตน
Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 29
Requirement Engineer
กระบวนการวศวกรรมความตองการ
การจดการกบการเปลยนแปลงความตองการ
เมอมการยนขอเสนอใหมการเปลยนแปลงความตองการใด ๆ
เกดขน ทมงานหรอองคกรตองมกระบวนการจดการกบการเปลยนแปลง
(Requirement Change Management) ดงกลาว เพอใหการ
เปลยนแปลงทเกดขนมความสอดคลองกบสวนอนทสมพนธกน และอย
ภายใตการควบคมอยางเปนทางการ
กระบวนการจดการการแปลงเปลยนจะเกยวของกบการ
วเคราะหถงความคมคาเมอตองการเปลยนแปลงตามขอเสนอ หากม
ความคมคาจะอนมตใหด าเนนการเปลยนแปลงได แตหากพบวาไมได
รบผลตอบแทนทคมคากจะยกเลกขอเสนอนนไป