requirement phase - paijit.lpru.ac.thpaijit.lpru.ac.th/cgi-bin/s5672601/softeng7.pdf(negotiation is...

Asst.Prof.Paijit Suksomboon SoftwareEngineer 7 / LPRU 1

Requirement Phase

ความตองการ (Requirement)

“วตถดบทส าคญในการพฒนาระบบหรอการผลตซอฟตแวร เพอใชเปน

ขอก าหนดถงหนาทและรายละเอยดอน ๆ ทระบบหรอซอฟตแวรจะตองม”

ในการพฒนาระบบหรอการผลตซอฟตแวร ตองอาศยขอมลความตองการ

ของลกคาหรอผใช เปนตวก าหนด ฟงกชน รปลกษณ ความสามารถ และ

รายละเอยด แตเนองจากการพฒนามหลายแนวทางเชน พฒนาเอง จาง

เหมา หรอใชซอฟตแวรส าเรจรป หรอผลตเพอจ าหนาย จงท าให

ขอก าหนดความตองการมหลายระดบ หากจ าแนกระดบความตองการไม

ถกตอง จะสงผลใหซอฟตแวรไมตรงกบความตองการทแทจรง


Requirement Phase

ในแวดวงการผลตซอฟตแวร สามารถจดความตองการได 2 ระดบ

1. ความตองการของผใช (User Requirement) เปนความตองการของลกคาหรอผทเกยวของกบระบบ โดยแสดงออกมาในรป

ภาษาธรรมชาต ทแสดงถงการคาดหวงในบรการหรอการท างานทไดรบจากระบบ

2. ความตองการดานระบบ (System Requirement)

เปนการก าหนดความตองการของ

การท างาน ฟงกชน และบรการตาง

ๆ ของระบบในระดบรายละเอยดท

เรยกวา

“Functional Specification”


Requirement Phase

ประเภทความตองการดานซอฟตแวร

1. ความตองการทเปนหนาทหลก (Functional Requirement) คอความตองการใหซอฟตแวรท าหนาทใด ๆ ตามทก าหนดไว ซงกคอสงท

ซอฟตแวรควรท าเปนหลกในการท างานหรอเปนบรการทซอฟตแวรตองม เชน

- นกศกษาสามารถตรวจสอบผลการเรยนได และการลงทะเบยนเรยนได

- นกศกษาสามารถตรวจสอบตารางเรยนของตนเองได หรอตารางสอนอาจารยได

- นกศกษาสามารถเพมรายวชาเรยนหรอเพกถอนรายวชาเรยนได

Functional Requirement -> Complete & Consistency หมายเหต : ในทางปฏบตเปนไปไดยาก โดยเฉพาะระบบทมความซบซอนสง

เนองจากความตองการของเจาของหรอผใชแตละคนแตกตางกน

อกท งการใหขอมลอาจก ากวมไมชดเจน ท าใหเกดปญหาความ

เขาใจทไมตรงกนได


Requirement Phase

ประเภทความตองการดานซอฟตแวร

2. ความตองการทไมใชหนาทหลก (non-Functional Requirement) คอความตองการทไมไดเกยวของกบหนาทหรอฟงกชนหลกของระบบ แต

เกยวของทางออมในลกษณะทเปนเงอนไขของฟงกชนหรอบรการ และอาจไมได

เกยวของกบซอฟตแวรเพยงอยางเดยว ไดแก

(1) ความตองการดานผลตภณฑ (Product Requirement)

ไดแก ความตองการดานประสทธภาพ , ความนาเชอถอ และใชงานงาย

(2) ความตองการขององคกร (Organizational Requirement)

ไดแก ความตองการเชงนโยบายและระเบยบปฏบตของลกคาและผพฒนา เชน

มาตรฐานการผลต ภาษา เมธอดทใช หรอก าหนดเวลาสงมอบ

(3) ความตองการจากปจจยภายนอก (External Requirement)

ไดแก ความตองการการท างานรวมกน , ดานกฎหมาย และจรยธรรม

หมายเหต : ความตองการดงกลาวตองใชความรอบคอบเปนพเศษ เนองจากม

อทธพลตอการตดสนใจยอมรบซอฟตแวรหรอระบบของผใชอยางมาก


Requirement Phase

ประเภทความตองการดานซอฟตแวร ตวอยางคณลกษณะของระบบทใชก าหนดความตองการทไมใชหนาทหลก

คณลกษณะ หนวยวด

ความเรว - การประมวลผลรายการขอมล (หนวยเปนวนาท)

- ระยะเวลาตอบสนองตอการใชงาน

- เวลาในการเปลยนขอมลบนจอภาพ

ขนาด - กกะไบต (Gbytes)

- ขนาดของหนวยความจ าแรม

ใชงานงาย - ระยะเวลาทใชในการอบรมการใชงาน

- จ านวนของสวนชวยเหลอ (Help)

ความนาเชอถอ - คาเฉลยของขอผดพลาดทเกดขน

- ความนาจะเปนของระบบทไมสามารถใชงานได

- อตราของการเกดขอผดพลาด

ความสามารถในการท างานขามระบบได - จ านวนของระบบอนทใชงานได


Requirement Phase

ความตองการของผใช ความตองการของผใช (User Requirement)

: คอความตองการทมตอระบบของผใช โดยจะอธบายท งสวนทเปนหนาทหลกและ

สวนทไมใชหนาทหลกของระบบ ดวยภาษาทผใชเขาใจ ไมควรใชศพทเทคนคมาก

จนเกนไป เนองจากผใชจะเขาใจพฤตกรรมของระบบของตนเทานน ส าหรบสวนท

เกยวของกบการออกแบบ สถาปตยกรรม หรอคณลกษณะของระบบ ผใชจะ

หลกเลยงและไมสนใจ

ปญหาทมกเกดขนจากการเกบความตองการ

1. ขาดความชดเจน เนองจากบางคร งการเขยนค าอธบายความตองการใหกระชบ ไม

ก ากวม โดยใชภาษาทไมใชเชงเทคนค

2. ไมสามารถจ าแนกประเภทของความตองการไดอยางชดเจน

3. บางคร งความตองการของผใชอาจมจดประสงคเดยวกน แตเขยนออกมาใน

ประโยคแตกตางกน ดงนนควรจดกลมความตองการของผใชทเหมอนกนเขาไว

ดวยกน


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)

โดยเฉพาะถามการเตรยมเอกสารประกอบอยางด เชน โครงรางของเรองทจะพด


Requirement Phase


เนนหลกการส าคญ (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)

ไมวาจะไดขอสรปหรอไม หรอวามบางเรองทยงขาดความชดเจน กใหการสอสาร

เดนหนาไปกอน อยาพดซ าไปซ ามากหาขอยตไมไดใหเปลองเวลา


Requirement Phase


เนนหลกการส าคญ (Core Principles) ในการสอสารกบลกคา (ตอ)

หลกท 10 การตอรองไมใชการแขงขนหรอเกม จะเปนการดทสด หากท งสองฝายเปนผชนะ

(Negotiation is not a contest or a game, It works best when both

parties win)

มหลาย ๆ เรองทนกวศวกรซอฟตแวรตองตอรองกบลกคา เชน งานทซอฟตแวร

ท าได ล าดบงานกอนหลง ก าหนดวนสงมอบ ท งน จะตองมการรวมมอรวมใจ

สรางเปาหมายรวมกน การตอรองตองอาศยการประนประนอมจากท งสองฝาย


Requirement Phase

ความตองการของผใช

การเขยนเอกสารความตองการของผใชควรจะมหลกปฏบต

1. ก าหนดมาตรฐานของรปแบบเอกสาร เชน รปแบบการใชตวอกษร ขนาด ส และ

เนนขอความ การขดเสน ตวเอง ควรใชกบขอความสวนใด

(อยาลม!! ก าหนดแหลงทมาของความตองการ ผจดท า และวนทจดท าดวย)

2. จ าแนกความจ าเปนของความตองการ โดยแบงออกเปน “ความตองการทจ าเปน

(Mandatory Requirement)” และ “ความตองการทเปนความปรารถนา

(Desirable Requirement)” โดยใชค าน าหนาความตองการของท ง 2 ลกษณะ

คอ น าหนาวา “ตอง” ส าหรบความตองการทจ าเปน และ “ควร” ส าหรบความ

ตองการทปรารถนา

3. ในเอกสารควรเนนขอความทเปนประเดนส าคญของความตองการใหเหนเดนชด

เพอใหผใชมงความสนใจอยภายในขอบเขตของประเดนนน

4. หลกเลยงการใชค าศ พทหรอรปทางเทคนคในเอกสารใหมากทสดเทาทจะท าได

หากหลกเลยงไมได ควรหาศพททเหมาะสมกบผใชมากทสด


Requirement Phase

ความตองการของระบบ

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

ท างาน ฟงกชน และการบรการตาง ๆ ทระบบจะตองมเพอตอบสนองความตองการของ

ผใช (หมายเหต : เกดจากการวเคราะหขอมลความตองการของผใชมาแลว)

เหตผลทตองระบรายละเอยดขนการออกแบบไวในความตองการของระบบ เพราะ

1. เพอชวยใหการก าหนดโครงการของเอกสารความตองการงายขน เชน ถาตองการ

ใชกระบวนการพฒนาแบบ Component Reuse ตองออกแบบสถาปตยกรรม

ของระบบกอน เพอก าหนดคอมโพเนนทยอย

2. ระบบจะตองท างานรวมกบระบบอนทมอยแลว ตองอาศยรายละเอยดการออกแบบ

เขามาชวยก าหนดความตองการ

3. เพอใหสามารถตอบสนองความนาเชอถอได บางคร งจ าเปนตองออกแบบ

สถาปตยกรรมเฉพาะขนมากอนเพอใชเปนกรอบการท างานตอไป


Requirement Phase


การเขยนขอก าหนดความตองการดานระบบ (System Requirement

Specification) ควรใชภาษาธรรมชาตหรอภาษาทเขาใจงายเชนเดยวกบขอก าหนด

ความตองการของผใช (User Requirement Specification) แตอยางไรกตามความ

ตองการของระบบนนมรายละเอยดทางเทคนคมากกวา ภาษาทใชอาจก ากวม ท าให

เขาใจผดได จงมการก าหนดมาตรฐานในการใชภาษาธรรมชาตมาอธบายดงน

1. Form-Based Specification

2. Tubular Specification

3. Graphic Model


Requirement Phase


1. Form-Based Specification

แหลงเอกสาร

Function

Description

Inputs

Outputs

Source

Destination

Action

Pre-Condition

Post-Condition

จดวางรายละเอยดอยางเปนระเบยบ

แตยงไมสามารถลดความก ากวมได

อยางสมบรณ เนองจากความตองการ

หากเปนการค านวณคาตาง ๆ จะท า

ใหอานยาก


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


Requirement Phase


3. Graphic Model

เปนการน าแผนภาพหรอแบบจ าลองมาใชอธบายขอมลความตองการเพมเตม

เนองจากรปภาพลดความก ากวมหรอแทนค าอธบายไดมากกวา ชวยใหเขาใจมาก

ยงขน แตอยางไรกตามการใชแผนภาพจ าเปนตองมความรและความเขาใจใน

สญลกษณทปรากฏในแผนภาพดงกลาวดวย

: order : Customer : Product

Officer

getOrderInfo()

getCustInfo()

getProdInfo()

CalTotal() displayResult()

Ex. Sequence Diagram


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., คณลกษณะใหมทควรน าเสนอใน

ระบบเมอไมพบในระบบอนทเกยวขอ

คณลกษณะส าคญอน ๆ


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) ส าหรบผใช:

- ระดบทกษะการใชงาน

- การเขาถงระดบพเศษ

- การฝกอบรม


Requirement Engineer

การจดท าขอก าหนดความตองการ ตองมคณสมบตส าคญ คอ

“สามารถตรวจสอบ พสจน และวเคราะหคณภาพได”

ดงนนจงตองมกระบวนการบางอยางทท าใหก าหนดความตองการถกตองและตรงกบท

ตองการอยางแทจรง เรยกวา วศวกรรมความตองการ

“กระบวนการทท าใหวศวกรซอฟตแวร

เขาใจและเขาถงความตองการของลกคาไดอยางแทจรง”

เปาหมายของวศวกรรมซอฟตแวร

คอ การสรางและบ ารงรกษาเอกสารขอก าหนดความตองการ ท งในดานระบบ และ

ซอฟตแวร ใหเปนเอกสารทมคณภาพมากทสด



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

กจกรรมของวศวกรรมความตองการ

อยระยะการวเคราะหความตองการของกระบวนการผลตซอฟตแวร ตองด าเนนงานอยาง

เปนข นตอน มกระบวนการและทมงานเฉพาะ ประกอบไปดวยกจกรรมยอยดงน

1. สกดความตองการ

2. วเคราะหความตองการ

3. ก าหนดความตองการ

4. ตรวจสอบความตองการ

สกดความตองการ

(Requirement Elicitation)

วเคราะหความตองการ

(Requirement Analysis)

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

(Requirement Spec.)

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

(Requirement Validation)

ความตองการประเภทตาง ๆ

แบบจ าลองความตองการ

ขอก าหนดความตองการ

เอกสารขอก าหนดความตองการ




1. สกดความตองการ (Requirement Elicitation) สกดความตองการ คอ การรวบรวมหรอคนหาความตองการ เปนข นตอนการท า

ความเขาใจปญหาทเกดขนทตองการแกไขดวยซอฟตแวร (ความจ าเปนของการ

น าซอฟตแวรมาใช) โดยเรมตนจากก าหนดกลมบคคลทเกยวของซงเปน

แหลงทมาของความตองการ จากนนรวบรวมความตองการดวยเทคนคตาง ๆ

- สมภาษณ (Interview)

เปนวธด งเดมและนยมใชมากทสด วศวกรซอฟตแวรควรทราบถงขอด-

ขอเสยของวธการสมภาษณ รวมท งวธการโนมนาวผถกสมภาษณดวย

- การแสดงล าดบเหตการณ (Scenario)

เปนการเตรยมค าถามตามล าดบงานของผใช ในแตละงานมการต งค าถามวา

“จะเกดอะไรขน ถา...” และ “จะตองท าอยางไร” การรวบรวมความตองการ

ดวยเทคนคนจะเชอมโยงไปยงการสรางแบบจ าลอง Use Case ไดงาย และ

Use Case เปนลกษณะหนงของ Scenario ผใชจงเขาใจค าถามไดงาย ท า

ใหการตอบค าถามไดชดเจนขน




1. สกดความตองการ (Requirement Elicitation) ตอ - ตนแบบ (Prototype)

เปนเทคนคทท าใหผเขาใจในสถานการณและค าถามไดงายเชนกน การท า

ตนแบบมหลายชนด เชน การออกแบบจอภาพบนกระดาษ เพอทดสอบการ

ยอมรบความตองการในเบองตน ซงอาจเปนเทคนคซ ากบการตรวจสอบ

ความตองการ

- การประชม (Facilitated Meeting)

เปนการเรยกกลมบคคลทเกยวของเขารวมประชมเพอขอความคดเหนและ

ความตองการ เพอใหเกดความเขาใจในความตองการอยางถองแทมากกวา

การท างานเพยงล าพง เปนการระดมความคดเพอแกไขปญหาเมอพบขอ

ขดแยงในความตองการ อยางไรกตาม ตองระมดระวงเรองความขดแยง

ระหวางกลมบคคลทอาจเกดขนไดในทกองคกร




2. วเคราะหความตองการ (Requirement Analysis)

ประเมนความตองการทรวบรวมมาได เพอจดกลมความตองการ จดล าดบความส าคญ แกไขความขดแยงระหวางความตองการเพอใหเกดความสอดคลอง

กน จากนนสรางแบบจ าลองทเปน Conceptual Model และน าเสนอผเกยวของ

ท งหมดใหยอมรบในความตองการทได หากไมยอมรบตองแกไข เจรจาตอรอง

และน าเสนอจนกวาจะไดรบการยอมรบในทสด

3. ก าหนดความตองการ (Requirement Specification) หลงจากแบบจ าลองความตองการไดรบการยอมรบแลว จะน ามาจดท าเอกสาร

ความตองการ โดยเรมจากการนยามความตองการ และจดท าเปนขอก าหนดของ

ระบบ เพอแจกแจงเปนขอก าหนดความตองการของซอฟตแวร โดยเอกสาร

ท งหมด ตองตรวจสอบและวดคณภาพได




4. ตรวจสอบความตองการ (Requirement Validation) เปนการทบทวนและตรวจสอบขอก าหนดความตองการในเอกสารท งหมด เพอให

เกดความเทยงตรง สอดคลอง ครบถวนสมบรณ มความเปนไปได และสามารถ

พสจนไดตามเปาหมายของกระบวนการวศวกรรมซอฟตแวร จากนนจะน าไป

ทดสอบเพอใหเกดการยอมรบจากบคคลทกฝายทเกยวของ

- ความเทยงตรง (Validity)

นอกจากฟงกชนพนฐานทผใชสวนใหญตองการแลว อาจมฟงกชนบางอยางท

ผใชกลมอนตองการ ดงนนทมงานควรใหความส าคญ เนองจากผใชแตละ

กลมมความตองการแตกตางกน ดงนนการก าหนดความตองการจะ

ตอบสนองกบผใชทกกลมอยางเทาเทยมกน

- ความสอดคลอง (Consistency)

ความตองการในเอกสารจะตองไมมการทบซอนกน ไมมความขดแยงกน

หากพบความตองการไมเปนแนวทางเดยวกน ตองตรวจสอบและแกไขให

สอดคลองกนทนท




4. ตรวจสอบความตองการ (Requirement Validation) - ความครบถวนสมบรณ (Completeness)

เอกสารตองระบรายละเอยดฟงกชนและการบรการอยางครบถวน และ

ครอบคลมความตองการของผใช จะตองไมมฟงกชนใดทผใชตองการขาด

หายไป

- ความเปนไปได (Feasibility)

เปนการตรวจสอบความตองการดวยองคความรเกยวกบเทคโนโลยทองคกรม

อย เพอใหม นใจวาสามารถน าความตองการทระบในเอกสารไปพฒนาระบบ

ไดจรง ซงนอกจากความเปนไปไดทางเทคโนโลยแลว ยงตองพจารณาถง

ความเปนไปไดดานงบประมาณและระยะเวลาในการพฒนาดวย หากใช

งบประมาณหรอเวลาในการพฒนามากกวาทมอย ถอวาความเปนไปไดนอย

มาก

- สามารถพสจนได (Verifiability)

ความตองการนนตองพสจนหาความจรงได คอ ตองทดสอบและทดลองให

ลกคาเหนถงการท างานจรงของระบบตามทระบไวในเอกสารได




4. ตรวจสอบความตองการ (Requirement Validation) เทคนคของการตรวจสอบความตองการ

- การทบทวนความตองการ (Requirement Review)

เปนการตรวจสอบเอกสารความตองการอยางละเอยด เพอตรวจหาความ

ตองการหรอขอสมมตฐานทผดพลาด ถกละเลย ไมชดเจน และไมตรงกบ

มาตรฐานทก าหนด

(1) ทบทวนแบบไมเปนทางการ (Informal Review) ทมทบทวนจะน า

เอกสารความตองการมาพจารณาหาขอผดพลาดรวมกบผมสวนไดสวน

เสยและผรบเหมาชวง

(2) ทบทวนแบบเปนทางการ (Formal Review) ทมทบทวนจะตอง

พจารณาความตองการรวมกบผใชทละรายการ เพอตรวจสอบความ

สอดคลองและความครบถวนสมบรณตามลกษณะดงตอไปน

- สามารถพสจนได - สามารถเขาใจได

- สามารถยอนกลบไปตรวจสอบได

- สามารถดดแปลงได (โดยไมสงผลกระทบตอระบบ)




4. ตรวจสอบความตองการ (Requirement Validation) เทคนคของการตรวจสอบความตองการ

- การจดท าตนแบบ (Prototyping)

เปนการสรางตนแบบของระบบ (Executable Model) เพอสาธตใหลกคา

หรอผใชระบบด หรอทดลองใชดวยตนเอง นอกจากนยงเปนวธทรวบรวม

ความตองการทเกดขนใหมไดดวย อยางไรกตาม การสรางตนแบบตองใช

เงนทนสง แตเมอเปรยบเทยบกบผลทไดรบนบวาคมคามาก จดเปนวธทด

ทสดอยางหนง

- การสรางแบบทดสอบ (Test-Case Generation)

ความตองการทดตองสามารถทดสอบได และถาทดสอบนนท าไดยากหรอ

ออกแบบยาก แสดงวาการน าความตองการดงกลาวไปพฒนาจากตามไปดวย

จงความน าความตองการนนกลบไปพจารณาใหม




การจดการความตองการ (Requirement Management) จดเปน

สวนหนงของกระบวนการวศวกรรมความตองการ

“ กระบวนการท าความเขาใจและควบคมการเปลยนแปลง

ความตองการของระบบ ”

โดยสามารถเรมด าเนนการไดทนททจดท าเอกสารขอก าหนดความตองการฉบบราง

เสรจเรยบรอย (ข นท 4) แตการวางแผนการจดการความตองการนน ควรเรมต งแต

ข นตอนการสกดความตองการเรมขน (ข นท 1) สาเหตของการเปลยนแปลง :

1. ผใชมหลายกลม ความตองการแตกตางกนออกแบบ อาจเกดการขดแยง จง

หลกเลยงไมไดทจะตองปรบความสมดลของความตองการใหม

2. โดยท วไป ผใชซงเปนผจายเงนลงทน กบผใชระบบโดยตรงไมใชผใชกลม

เดยวกน

3. ภายหลงการตดต งระบบเพอใชงาน สภาพแวดลอมทางธรกจ และเทคโนโลยท

เปลยนแปลงไป มผลท าใหระบบตองเปลยนแปลงตามไปดวย




มมมองของววฒนาการของความตองการ แบงความตองการออกเปน 2

ประเภท ไดแก

1. ความตองการทไมเปลยนแปลง (Enduring Requirement)

เปนความตองการแบบคงท ไมเปลยนแปลงไดงาย เปนความ

ตองการทเกดจากการท างานหลกของธรกจในแตละวน เชน ระบบ

ลงทะเบยน วชาเรยน คาลงทะเบยน เปนตน

2. ความตองการทเปลยนแปลง (Volatile Requirement)

เปนความตองการทเปลยนแปลงอยเสมอในระหวางการพฒนา

ระบบหรอหลงจากการตดต งระบบ เชน นโยบายการลงทะเบยน

เปนตน




การจดการกบการเปลยนแปลงความตองการ

เมอมการยนขอเสนอใหมการเปลยนแปลงความตองการใด ๆ

เกดขน ทมงานหรอองคกรตองมกระบวนการจดการกบการเปลยนแปลง

(Requirement Change Management) ดงกลาว เพอใหการ

เปลยนแปลงทเกดขนมความสอดคลองกบสวนอนทสมพนธกน และอย

ภายใตการควบคมอยางเปนทางการ

กระบวนการจดการการแปลงเปลยนจะเกยวของกบการ

วเคราะหถงความคมคาเมอตองการเปลยนแปลงตามขอเสนอ หากม

ความคมคาจะอนมตใหด าเนนการเปลยนแปลงได แตหากพบวาไมได

รบผลตอบแทนทคมคากจะยกเลกขอเสนอนนไป

requirement phase - paijit.lpru.ac.thpaijit.lpru.ac.th/cgi-bin/s5672601/softeng7.pdf(negotiation is...

Documents