ระบบสนับสนุนการตัดสินใจ (Decision Support System)cs.udru.ac.th/~phanarut/Teach_22010/SE/Slides/Chap4-Software Requirements.pdfความต้องการด้านซอฟต์แวร์

บทท 4 ความตองการดานซอฟตแวร (Software Requirements)

สาขาวชาวทยาการคอมพวเตอรและเทคโนโลยสารสนเทศ

คณะวทยาศาสตร มหาวทยาลยราชภฏอดรธาน

สอนโดย อ.พนารตน ศรเชษฐา

1

วตถประสงคการเรยนร

เพออธบายความตองการดานซอฟตแวร ระดบและประเภทของความตองการดานซอฟตแวร

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

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

2

4123902 วศวกรรมซอฟตแวร (Software Engineering) อ.พนารตน ศรเชษฐา

เนอหาการเรยนร

ความตองการดานซอฟตแวร เอกสารขอก าหนดความตองการทางดานซอฟตแวร กระบวนการวศวกรรมความตองการ (Requirements Engineering) การบรหารความตองการ (Requirements Management)

3


ความตองการดานซอฟตแวร (Software Requirements)

ความตองการ (Requirements) ส าหรบระบบ คอการอธบายถงบรการทลกคาจะไดรบจากระบบ รวมถงขอจ ากดในการท างานของระบบนน

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

กระบวนการทใชในการคนหา การวเคราะห การจดท าเอกสาร และการตรวจสอบบรการและขอจ ากดเหลานน เรยกวา

วศวกรรมความตองการ (Requirements Engineering)

4



ระดบ (Level) ของความตองการดานซอฟตแวร: แบงได 2 ระดบ

1. ความตองการของผใช (User requirements) เปนความตองการทมตอระบบซงระบโดยผใชระบบ โดยจะอธบายทงสวนทเปนหนาทหลก และสวนทไมใชหนาทหลกของระบบ โดยแสดงออกมาในรปแบบเอกสารทใชภาษาธรรมชาตทเขาใจงาย ทแสดงถงความคาดหวงในการบรการ หรอการท างานทจะไดรบจากระบบและเงอนไขทตองท าตาม

2. ความตองการของระบบ (System requirements) เปนการก าหนดความตองการการท างาน ฟงกชน และบรการตางๆ ทระบบจะตองม ความตองการดานระบบเปนความตองการทไดจากการวเคราะหขอมลความตองการของผใชมาแลว เปนขอมลทมความส าคญ การเขยนขอก าหนดความตองการดานระบบ ควรใชภาษาธรรมชาตหรอภาษาทเขาใจงาย

5


ความตองการทางดานซอฟตแวร (Software Requirements)

นยามความตองการของผใช (User requirements definition)

6

1.1 ควรมการอ านวนความสะดวกในการก าหนดประเภทของแฟมขอมลภายนอกใหแกลกคา 1.2 แฟมขอมลภายนอกแตละประเภทอาจมเครองมอทเกยวของซงอาจถกประยกตใชกบแฟมขอมลได 1.3 แฟมขอมลภายนอกแตละประเภทอาจถกน าเสนอเปนรปไอคอนเฉพาะบนสวนแสดงผลของผใช 1.4 การอ านวนความสะดวกควรถกจดเตรยมเอาไวเปนไอคอนการน าเสนอประเภทแฟมขอมลภายนอก

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

ประเภทของแฟมขอมล

1. ระบบตองเตรยมวธการน าเสนอและการเขาถงแฟมขอมลภายนอกทสรางโดยเครองมออนๆ

ขอก าหนดความตองการของระบบ (System requirements specification)

ตวอยาง: ระบบหองสมดมหาวทยาลย (LIBSYS)


ความตองการดานซอฟตแวร (Software Requirements) 7

• ท าไมตองมการแยกระดบของความตองการ? เนองจากมผเกยวของหลายประเภท ทจะตองอานเอกสารความตองการ • เอกสารระบความตองการจ าเปนตองท าหนาท 2 อยาง

ใชเปนฐานอางองในการเปดประมล – ดงนน จ าเปนตองเปดเผยตอผตความสญญา ใชเปนฐานอางองถงการท าสญญา – ดงนน จงจ าเปนตองก าหนดรายละเอยด



ประเภท (Category) ของความตองการดานซอฟตแวร: แบงได 3 ประเภท

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

ตวอยางเชน ระบบทะเบยน - นกศกษาสามารถตรวจสอบผลการเรยนและสภาพนกศกษาได - นกศกษาสามารถลงทะเบยนและท าการเพกถอนรายวชาได - อาจารยสามารถตรวจสอบกลมนกศกษาในรายวชาทเปนผสอนได - อาจารยสามารถตรวจสอบผลการเรยนของนกศกษาในรายวชาของตน - เจาหนาทฝายทะเบยนสามารถ เพม ลบ และแกไข ขอมลตางๆ ในระบบตามหนาทได

8



ประเภท (Category) ของความตองการดานซอฟตแวร: แบงได 3 ประเภท

2. ความตองการทไมเปนหนาทหลก (Non-functional requirements) เปนความตองการทไมเกยวของโดยตรงกบฟงกชนหลกของระบบ แตเกยวของทางออมในลกษณะทเปนเงอนไขหรอขอจ ากดของบรการหรอการท างานของระบบ ไดแก ขอจ ากดดานเวลา ขอจ ากดดานกระบวนการและมาตรฐานการพฒนา เปนตน ความตองการประเภทนอาจมาจากความตองการของผใชหลายๆ ดานทไมเกยวของกบซอฟตแวรเพยงอยางเดยว

3. ความตองการทางดานงานธรกจ (Domain requirements) เปนความตองการทมาจากงานธรกจของระบบ และความตองการเหลานสะทอนถงคณลกษณะและขอจ ากดตางๆ ของธรกจ ซงความตองการประเภทนเปนไดทง functional หรอ non-functional

9



1. ความตองการทเปนหนาทหลก (Functional Requirements)

บงบอกวาระบบควรท าอะไร ขนอยชนดของซอฟตแวรทก าลงพฒนา, ผใชเปาหมาย, และวธการทองคกรใช

ในการเขยนเอกสารความตองการนน ถาเปน user requirements ความตองการทเปนหนาทหลก จะเขยนใน

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

ฟงกชนโดยรายละเอยด ขอมลน าเขามอะไรบาง ขอมลออกมอะไรบาง สงทคาดวาจะไดรบ และอนๆ

10



1. ผใชจะสามารถคนหาขอมลหนงสอหรอเอกสารไดจากทงฐานขอมล หรอจากสวนยอยของฐานขอมล 2. ระบบควรมสวนมมมองทเหมาะสม ทใหผใช อานหรอตรวจดเอกสารทคนหาได 3. ทกๆ การสงหนงสอหรอเอกสารจากหองสมดอน ควรมการระบหมายเลขการสง (order_id) เพอใหผใชสามารถท าส าเนาเกบไวในสวนเกบเอกสารถาวรได

ความตองการเชงฟงกชน (Functional Requirements for a university library system)

ตวอยาง: ระบบหองสมดมหาวทยาลย (LIBSYS) ซงม interface เดยว ตอไปยงหลายฐานขอมลทรวบรวมบทความตางๆ ไว ผใชสามารถดาวนโหลดบทความทตพมพในนตยสาร หนงสอพมพ และวารสาร ได

ผใช: นกเรยน และคณะ เปาหมาย: เพอสงหนงสอและเอกสารจากหองสมดอน



2. ความตองการทไมเปนหนาทหลก (Non-functional Requirements)

เปนความตองการทไมไดเกยวของโดยตรงกบฟงกชนของระบบ มกเกยวของกบคณสมบตทเกดขนในระบบ เชน ความนาเชอถอ, เวลาในการ

ตอบสนอง, เนอทจดเกบขอมล นอกจากน มกใชบอกถงขอจ ากดของระบบ ไดแก ความสามารถของอปกรณ

I/O, และวธการน าเสนอขอมลในสวน user interface ความตองการนอาจรวมถง ประสทธภาพ, ความปลอดภย, ความสามารถใน

การท างาน, และคณสมบตอนๆ ทเกดขนมาของระบบ

12



ประเภทของความตองการทไมเปนหนาทหลก: แบงได 3 ประเภทหลก

1. ความตองการดานผลตภณฑ (Product requirements) เปนการระบพฤตกรรมของผลตภณฑ เชน ความตองการในแงประสทธภาพ - ระบบประมวลผลไดเรวแคไหน, หนวยความจ าทตองการม

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

2. ความตองการองคกร (Organizational requirements) เปนความตองการทมาจากนโยบายและระเบยบปฏบตของลกคาและผพฒนา โดยก าหนดขอตกลงระหวางองคกรไวเพอเปนแนวทางในการพฒนาทตรงตามความตองการของทงสองฝาย

3. ความตองการภายนอก (External requirements) เปนความตองการทเกดจากปจจยภายนอก ซงสงผลตอซอฟตแวรและกระบวนการพฒนา

13


14




ความตองการดานผลตภณฑ 8.1 สวนตดตอผใชของระบบ LIBSYS ควรเขยนในรปแบบ HTML แบบงายๆ โดยไมตองท าเปนเฟรม หรอเปนแบบ Java applets

ความตองการดานองคกร 9.3.2 กระบวนการพฒนาระบบและเอกสารทจะสงมอบ ควรมความสอดคลองกบ กระบวนการและเอกสารการสงมอบ ทก าหนดไวในมาตรฐานของ XYZCo-SP-STAN-95.

ความตองการดานปจจยภายนอก

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

ความตองการทไมเปนเชงฟงกชน (Non-functional Requirements)




3. ความตองการทางดานงานธรกต (Domain Requirements) เปนความตองการทไดมาจาก application domain ของระบบมากกวาทจะไดมาจาก

ความตองการเฉพาะของผใชระบบ โดยทวไป มนประกอบดวยศพทเฉพาะทางของโดเมนนนๆ หรอการอางองไปยง

แนวคดของโดเมนนนๆ มนอาจเปน functional requirements แบบใหม, เปนเงอนไขทมใน functional

requirements หรอเปนการก าหนดวธการค านวณตามโดเมน

16



1. จะมสวนตดตอผใชทเปนมาตรฐานเชอมไปยงฐานขอมลทงหมดทอาศยมาตรฐาน Z39.50

2. เนองจากขอจ ากดทางดานลขสทธ เอกสารบางอยางตองถกลบออกทนททสงไปถงปลายทาง ซงจะขนอยกบความตองการของผใชดวยวา จะใหพมพทฝงระบบเซฟเวอรดวยมอแบบ Local หรอจะพมพทเครองพมพผานเครอขาย

ความตองการเชงโดเมน (Domain Requirements)



ขอก าหนดความตองการดานซอฟตแวร (Software Requirements Specification หรอ SRS)

เอกสารความตองการดานซอฟตแวร (Software Requirements Document) เรยกไดอกอยางหนงวา ขอก าหนดความตองการดานซอฟตแวร (Software Requirements Specification: SRS)

SRS เปนเอกสารแสดงความตองการซอฟตแวรอยางเปนทางการ ทผพฒนาจะตองน าไปใชปฏบตในการพฒนาซอฟตแวร

ใน SRS ตองประกอบดวย (1) User Requirements - จะเขยนไวในสวนบทน าของ SRS

(2) System Requirements - ถามความตองการหลายประเดน สวนของ System Requirements อาจเขยนเปนเอกสารแยกออกไปตางหาก

18



กลมผใชเอกสาร

ขอก าหนดความ

ตองการทางดาน

ซอฟตแวร - SRS

19



หนวยงานทก าหนดมาตรฐานการเขยน SRS 1. US Department of Defense 2. IEEE

มาตรฐาน SRS ทเปนทรจกกน คอ IEEE/ANSI 830-1998 ซงมโครงสรางของเอกสาร ทสามารถน าไปปรบใชในองคกร ไดดงน 1. บทน า (Introduction)

1.1 เปาหมายของเอกสารความตองการ (Purpose of the Requirements document) 1.2 ขอบเขตของผลตภณฑ (Scope of the product) 1.3 นยาม (Definitions), (Acronyms), (Abbreviations) 1.4 บทอางอง (References) 1.5 ภาพรวมของสวนทเหลอของเอกสาร (Overview of the remainder of the document)

20



2. ค าอธบายทวไป (General Description) 2.1 มมมองของผลตภณฑ (Product perspective) 2.2 ฟงกชนการท างานของผลตภณฑ (Product functions) 2.3 คณลกษณะของผใชงาน (User characteristics) 2.4 ขอจ ากดโดยทวไป (General constraints) 2.5 ขอสมมตฐาน (Assumptions) และการขนอยตอกน (Dependencies)

3. ความตองการเฉพาะ (Specific Requirements) ซงสวนนเปนสวนทส าคญมากทสดของเอกสาร แตเนองจากแตละองคกรมแนวทางการปฏบตแตกตางกน ดงนนในสวนนจะไมมโครงสรางทเปนมาตรฐาน ความตองการในสวนนเปนการท าเอกสารสวนตดตอกบภายนอก, บรรยายหนาทและการท างานของระบบ, ขอจ ากดในสวนของการออกแบบ, คณสมบตทเกดขนในระบบ และคณลกษณะเชงคณภาพ

4. ภาคผนวก (Appendices) 5. ดชน (Index)

21



ตวอยางโครงสรางการเขยน SRS ทดดแปลงมาจากการใช IEEE/ANSI 830-1998

22

บท ค าอธบาย 1. ค าน า - เปนการก าหนดวาผทควรอานเอกสารเปนใคร

- มกบรรยายถงประวตเวอรชนตางๆ ของซอฟตแวร รวมถงค าชแจงของการสรางเวอรชนใหม และสวนทเปลยนแปลงไปในเวอรชนปจจบน

2. บทน า - บรรยายความจ าเปนของระบบ - อธบายฟงกชนการท างานของระบบอยางกวางๆ และอธบายวามนจะท างานรวมกบระบบอนอยางไร - บรรยายวาระบบจะตอบสนองกบวตถประสงคและกลยทธทงหมดขององคกรทรบผดชอบงานทางดานซอฟตแวร ไดอยางไร

3. ค าแปลศพท - ก าหนดค าศพทเชงเทคนคทใชในเอกสาร 4. ค าจ ากดความของความตองการของผใช

- อธบายบรการตางๆ ทมไวส าหรบ user requirements และ system requirements - ใชภาษาธรรมชาต แผนภาพ หรอเครองหมายสญลกษณ ทลกคาสามารถเขาใจได เปนตวอธบาย - ควรระบดวยวาใชใชมาตรฐานผลตภณฑและมาตรฐานกระบวนการใดในการเขยน




23

บท ค าอธบาย 5. สถาปตยกรรมระบบ - น าเสนอภาพรวมของสถาปตยกรรมของระบบทคาดหวง เพอแสดงถงการกระจาย

ของฟงกชนตางๆ ขามโมดลของระบบ - องคประกอบเชงสถาปตยกรรมใดทน ากลบมาใช ควรมการเนนใหชดเจน

6. ขอก าหนดความตองการของระบบ

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

7. แบบจ าลองระบบ - ก าหนดแบบจ าลองระบบ 1 อนหรอมากกวานน เพอแสดงถงความสมพนธระหวางองคประกอบของระบบและระบบและสงแวดลอมของระบบ - แบบจ าลองเหลาน อาจเปนแบบจ าลองเชงวตถ (object), แบบจ าลองการไหลของขอมล (data-flow), และแบบจ าลองเชงขอมลทมความหมาย (semantic data)

8. ววฒนาการของระบบ - บรรยายขอสมมตฐานเบองตนเกยวกบระบบ วาจะมการเปลยนแปลงทคาดหวงอยางไร หากเกดการเปลยนแปลงในดานฮารดแวร การเปลยนแปลงความตองการผใช เปนตน




24

บท ค าอธบาย 9. ภาคผนวก - เตรยมขอมลโดยละเอยด หรอขอมลเฉพาะซงสมพนธกบโปรแกรมประยกตทได

พฒนา - ตวอยางของภาคผนวก ไดแก การอธบายเรองฮารดแวรหรอฐานขอมล - ความตองการทางดานฮารดแวร จะเปนการก าหนดองคประกอบทต าทสดหรอทเหมาะสมทสด ทระบบจะท างานได - ความตองการทางดานฐานขอมล จะเปนการก าหนดการจดการขอมลเชงตรรกะทใชโดยระบบ และความสมพนธระหวางขอมล

10. ดชน - ในเอกสารอาจมดชนอยหลายแบบ คลายๆ กบดชนแบบตวอกษรทวไป ในเอกสาร SRS อาจเปนดชนของแผนภาพ ดชนของฟงกชน เปนตน


กระบวนการวศวกรรมความตองการ (Requirements Engineering Processes)



วตถประสงค เพอสรางและบ ารงรกษาเอกสารความตองการของระบบ กระบวนการวศวกรรมความตองการมหลากหลายวธ ขนอยกบโดเมนของระบบงาน,

ผเกยวของและองคกรทหาความตองการ

กระบวนการวศวกรรมความตองการ ประกอบดวย 4 ขนตอน (1) การศกษาความเปนไปได (Feasibility Studies) (2) การลวงหาและการวเคราะหความตองการ (Requirements Elicitation and Analysis) (3) การตรวจทานความตองการ (Requirements Validation) (4) การบรหารความตองการ (Requirements Management)

26



27

Requirements engineering process



28

Requirements Engineering Process ใน Spiral Model


1. การศกษาความเปนไปได (Feasibility Studies)

Input: เซตของความตองการทางธรกจเบองตน, การอธบายภาพรวมของระบบ, และการบอกวาระบบจะสนบสนนกระบวนการทางธรกจอยางไร

Output: รายงานทบอกวามนจะมความเปนไปไดหรอไม Process: ท าการศกษาโดยมเปาหมายวาจะตอบค าถามตอไปน

(1) ระบบจะบรรลวตถประสงคขององคกรหรอไม*** (2) ระบบสามารถสรางไดโดยใชเทคโนโลยปจจบน ภายใตขอจ ากดดานงบประมาณและเวลา

หรอไม (3) ระบบสามารถน าไปใชรวมกบระบบอนๆ ทใชอยปจจบน ไดหรอไม

ขนตอน (1) การประเมนขอมล (2) การรวบรวมขอมล (3) การเขยนรายงาน

29


1. การศกษาความเปนไปได (Feasibility Studies)

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

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

2.การเกบรวบรวมขอมล ขอมลทรวบรวมสามารถหาไดจากการพบปะพดคยกบแหลงขอมล อนไดแก ผจดการ นกวศวกรซอฟตแวร ผเชยวชาญทางเทคนค และผใชระบบ

3.การเขยนรายงาน เขยนรายงานการศกษาความเปนไปไดทไดท าการรวบรวมและท าการประเมนขอมล โดยควรเขยนขอเสนอแนะดวยวา ควรด าเนนการพฒนาระบบตอไปนหรอไม, ควรเปลยนขอบเขตงาน งบประมาณ ตารางเวลาการท างานของระบบหรอไม อยางไร

30


2. การลวงหาและวเคราะหความตองการ (Requirements Elicitation and Analysis)

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

กจกรรมนเขาไปเกยวของกบคนในองคกรหลากหลายประเภท ซงอาจเรยกไดวาเปน ผมสวนไดสวนเสย (stakeholders) กบระบบ ไดแก ผใชระบบ, วศวกรทพฒนาและบ ารงรกษาระบบ, ผเชยวชาญโดเมน, ฯลฯ

ตวอยาง stakeholders ของระบบ ATM ลกคาธนาคาร, ตวแทนจากตางธนาคาร, ผจดการธนาคาร, เจาหนาททเคานเตอร, ผบรหารฐานขอมล, ผจดการดานความปลอดภย, ฝายการตลาดของธนาคาร, วศวกรผดแลฮารดแวรและซอฟตแวร และผออกกฏหมายควบคมธนาคาร

31



32

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

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

การแยกประเภทและจดโครงสรางความตองการ การจดล าดบความส าคญความตองการ

การจดท าเอกสารความตองการ



การคนหาความตองการ (Requirements discovery)*** พดคยสอบถามผมสวนไดเสย เพอคนหาวาเขาตองการอะไรบาง ความตองการหลกๆ กจะ

พบไดจากการพดคยน

การแยกประเภทและจดโครงสรางความตองการ (Requirements classification and organization) รวบรวมความตองการทไมมโครงสราง แลวจดกลมความตองการทเกยวของกนไวในกลม

เดยวกน

การจดล าดบความส าคญความตองการ (Requirements prioritization and negotiation) จดล าดบความส าคญ อะไรมความส าคญตองการท ากอน อะไรทขดแยงกนตองขจดออกไป

การจดท าเอกสารความตองการ (Requirements documentation) บนทกความตองการเปนลายลกษณอกษร และใชเปนขอมลในการ ลวงหาและวเคราะหความ

ตองการในรอบถดไป โดยอาจท าเปนเอกสารแบบ formal หรอ informal

33



เทคนคการรวบรวมความตองการ: การสมภาษณ (Interview) เปนวธทนยมใชมากทสดวธหนง

การแสดงล าดบเหตการณ (Scenario) เปนการเตรยมค าถามตามล าดบงานของผใช ในแตละงานจะมการตงค าถาม

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

การประชม (Facilitated Meeting) เปนการเรยกกลมบคคลทเกยวของเขารวมประชมเพอขอความคด และความตองการ เพอใหเกดความเขาใจในความตองการอยางถองแทมากกวาการท างานเพยงล าพง

การสงเกต (Observation) ใชตรวจสอบสภาพแวดลอมการท างานของผใชซอฟตแวรในระบบเดม เพอพบกบปญหาและวธการแกไขของผใชทเกยวของอยางแท

34



การวเคราะหความตองการ: เปนการน าขอมลความตองการทรวบรวมไดมาวเคราะห ประเมนเพอจ าแนกกลมความตองการ จากนนน ามาจดล าดบความส าคญ ดความสอดคลอง ขจดความขดแยง น าไปสรางเปนแบบจ าลอง และออกแบบสถาปตยกรรมซอฟตแวรเบองตน เพอน าไปทดสอบการยอมรบกบลกคา เมอลกคายอมรบจะไดเอกสารความตองการทงหมด (ฉบบราง) การแบงกลมความตองการ (Requirement Classification) การสรางแบบจ าลองของความตองการ (Requirement Modeling) การออกแบบสถาปตยกรรมและการจดสรรความตองการ (Architectural Design

and Requirement Allocation) การเจรจาตอรองความตองการ (Requirement Negotiation) การก าหนดความตองการ

35



การแบงกลมความตองการ (Requirement Classification) ความตองการทเปนหนาทหลก (Functional Requirement) และไมใชหนาทหลก Non-

Functional Requirement) แบงความตองการทเกยวของกบผลตภณฑ และกระบวนการ แบงกลมตามล าดบความส าคญของความตองการ (จ าเปน (Mandatory) ปรารถนาสง

(Highly Desirable) ปานกลาง (Desirable) และละเวนได (Optional)) แบงกลมตามขอบเขตความตองการ โดยใหความส าคญตอความตองการทมขอบเขตกวาง

ซงสงผลกระทบตอการพฒนาซอฟตแวร แบงกลมตามความตองการเปลยนแปลงของความตองการ ไดแก ความตองการท

เปลยนแปลงได (Volatility) และความตองการทไมสามารถเปลยนแปลงได (Stability)

36



การสรางแบบจ าลองของความตองการ (Requirements Modeling) แบบจ าลองความตองการ ใชเพอจ าลองความตองการทรวบรวมมาได ท าใหภาพรวมของ

ความตองการ เขาใจความตองการไดตรงกบทมงาน ชนดและแบบจ าลองจะแตกตางกนออกไปตามแนวทางของการวเคราะห เชน แนวทางเชงโครงสราง (SSAD ) จะใช DFD และ ERD แนวทางเชงวตถ (OOSAD) จะใชแบบจ าลอง Use Case

ระเบยบวธปฏบตทใชสรางแบบจ าลอง ปจจบนนยมใช UML (Unified Modeling Language) และ Formal Modeling ทใชสมการทางคณตศาสตรเขามาอธบาย

IEEE ไดก าหนดสญลกษณทเปนประโยชนในการสรางแบบจ าลองหลายชนด เชน IEEE 1320.1, IDEF0 (ใชสรางแบบจ าลองเชงฟงกชน) และ IEEE 1320.2, IDEF1X97 (เพอสรางแบบจ าลองขอมลเปนตน)

37



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

ซอฟตแวร ทเขามาสนบสนนและรองรบความตองการสวนใหญของผใช

การเจรจาตอรองความตองการ (Requirement Negotiation) เกดขนเมอ หากลกคาพบขอผดพลาดหรอไมพอใจในขอก าหนดความตองการ หรออาจ

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

การก าหนดความตองการ เปนการเขยนขอก าหนดความตองการดานซอฟตแวร (Software Requirements

Specification: SRS) นนเอง

38


3. การก าหนดความตองการ (Requirements Specification)

ขอก าหนดความตองการดานซอฟตแวรสวนใหญจะบงบอกถงคณลกษณะของซอฟตแวร ซงหมายถง การสรางเอกสารความตองการแสดงรายละเอยดทางดานซอฟตแวร ทสามารถตรวจสอบ ประเมนคา และยอมรบได โดยเฉพาะอยางยงในระบบทมความซบซอนสง โดยจะตองประกอบดวยรายละเอยดอนทไมใชคอมโพเนนทซอฟตแวรเพยงอยางเดยว ไดแก การนยามระบบ (System Definition)

ความตองการดานระบบ (System Requirement) และ ความตองการดานซอฟตแวร (Software Requirement)

39


4. การตรวจทานความตองการ (Requirements Validation)

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

ไดมากกวาการมาพบเมอพฒนาและสงมอบงานไปแลว

เทคนคการตรวจสอบความตองการ การทบทวนความตองการ (Requirement Review) เปนการตรวจสอบเอกสารความตองการ

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

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

การสรางแบบทดสอบ (Test-Case Generation) ความตองการทดจะตองสามารถทดสอบได ถาหาดจดท าแบบทดสอบยางกแสดงวาระบบทจะน าไปพฒนานนยากดวย

40


การบรหารความตองการ (Requirements Management)

ระบบซอฟตแวรขนาดใหญมกมการเปลยนแปลงความตองการ อนเนองมาจากการทไมสามารถก าหนดปญหาออกมาไดครบถวนสมบรณ, เขาใจปญหาไมถกตอง ลกคาระบความตองการขดแยงกบผใชระบบ หรอเกดความตองการเพมขนมา

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

การวางแผนการบรหารความตองการ (Requirements Management Planning)

1. การวางแผนทจะระบความตองการออกมา 2. วางแผนบรหารการเปลยนแปลง 3. การก าหนดนโยบายการตดตามการเปลยนแปลง 4. การวางแผนการใชเครองมอสนบสนนทางดานวศวกรรมซอฟตแวร

41


4. การบรหารความตองการ (Requirements Management)

การก าหนดนโยบายการตดตามการเปลยนแปลง การตดตาม/สบหารองรอย (Traceability) คอความสามารถทจะสบหา

แหลงทมาของความตองการและรปแบบของระบบ สบหาแหลงทมา – เชอมโยงความตองการไปยงผลงทนทเสนอความ ตองการ สบหาความตองการ – เชอมโยงระหวางความตองการทพงพากน สบหารปแบบ - เชอมโยงระหวางความตองการและการออกแบบ

42



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

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

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

เปลยนแปลง

43



44

ตารางแสดงการตดตามการเปลยนแปลง (Traceability Matrix)

D: ความตองการทอยในแถว ขนอยความตองการทอยในคอลมน R: ความตองการทอยในแถว มสวนเกยวของกบความตองการทอยในคอลมน



การวางแผนการใชเครองมอสนบสนนทางดานวศวกรรมซอฟตแวร

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

บรหารการเปลยนแปลง กระบวนการบรหารการเปลยนแปลงเปนกระบวนการ Workflow ซง สามารถ

แสดงสถานภาพได และมขอมลวงไป-มาระหวางสถานภาพ เหลานนเปนแบบกงอตโนมต

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

โดยอตโนมต

45


Documents

ระบบสนับสนุนการตัดสินใจ (Decision Support System)cs.udru.ac.th/~phanarut/Teach_22010/SE/Slides/Chap4-Software Requirements.pdfความต้องการด้านซอฟต์แวร์