small software project management plan · web viewwbs templates. decomposition. outputs. project...

Travel’s Center Requirement Management PlanTLGTravel’s CenterNoppanan Chatasuk29-May-2010Version 01

______________________________ ( )

[Project Lead]

______________________________ ( )

[Project Manager]Table of Contents

Travel’s Center Software Project Plan 29-May-2010

1 INTRODUCTION.................................................................................................. 5

1.1 PURPOSE........................................................................................................... 51.2 SCOPE............................................................................................................... 51.3 COLLABORATORS.............................................................................................. 61.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS...............................................61.5 REFERENCES..................................................................................................... 71.6 TLG DOCUMENTS............................................................................................. 8

2 ROLES AND RESPONSIBILLITIES...................................................................8

2.1 ROLES AND RESPONSIBILITIES...........................................................................8

3 REQUIREMENTS PROCESS.............................................................................16

3.1 REQUIREMENTS DEFINITION WITH SCOPE BEING AN INPUT...............................163.2 REQUIREMENTS DEVELOPMENT WITHIN INFORMATION MODEL........................19

4 CONCEPT EXPLORATION PHASE REQUIREMENTS MANAGEMENT..20

4.1 CONCEPT EXPLORATION PHASE REQUIREMENTS MANAGEMENT.....................204.1.1 Vision Development....................................................................................204.1.2 Concept Development.................................................................................204.1.3 Requirements Integrated Product Team......................................................204.1.4 Use Case Development...............................................................................204.1.5 Requirement Document.................................................................................. 20

5 CONCEPT DEVELOPMENT REQUIREMENTS MANAGEMENT PROCESS..................................................................................................................... 21

5.1 PROVIDE BASELINED REQUIREMENTS TO DEVELOPMENT CONTRACTORS........215.2 CONTRACTOR REQUIREMENT ANALYSIS.........................................................215.3 SYSTEM REQUIREMENTS REVIEW (SRR).........................................................215.4 REVIEWS REQUIREMENTS AND PROVIDES FEEDBACK......................................215.5 DEVELOPMENT CONTRACTORS PRODUCE SYSTEM DESIGN DOCUMENTS.........215.6 SYSTEM DESIGN REVIEWS (SDRS)..................................................................225.7 DEVELOPMENT CONTRACTOR SELECTED.........................................................225.8 NEW REQUIREMENTS BASELINE......................................................................22

6 REQUIREMENTS TOOLS AND TECHNIQUES.............................................22

6.1 RATIONAL REQUISITEPRO...............................................................................226.2 DOCUMENT TEMPLATES AND SPREADSHEETS..................................................226.3 INTERVIEWS.................................................................................................... 226.4 SURVEY QUESTIONNAIRE................................................................................22

7 REQUIREMENTS DOCUMENTATION AND ORGANIZATION.................23

7.1 REQUIREMENTS DOCUMENTATION..................................................................237.2 ORGANIZATION...............................................................................................24

7.2.1 Traceability Strategy...................................................................................... 24

8 REQUIREMENTS ACCEPTANCE CRITERIA...............................................24

ii Version 01

Travel’s Center Requirement Management Plan 29-May-2010

A. DEFINITIONS, ACRONYMS, ABBREVIATIONS...........................................25

B. FORMS................................................................................................................. 26

C. REQUIREMENTS EVALUATION CHECKLISTS..........................................27

D. REQUIREMENT REPORT EXAMPLES..........................................................29

E. Quality Standards.................................................................................................. 30

iii Version 01

Travel’s Center Software Project Plan 29-May-2010

Revision Sheet

Revision Number

Date Brief Summary of Changes

01 29-May-2010

Initial Version

iv


1 Introduction

1.1 Purposeเอกสารฉบบนจดทำาขนเพอกำาหนดใหความตองการจะตองถกจดการ และความขดแยง

ตางๆ ระหวางความตองการและแผนการดำาเนนโครงการและผลตภณฑจะตองถกระบ1.2 Scope

1. ทำาความเขาใจกบบคคลผใหความตองการเพอใหไดความตองการทแทจรง (Obtain an Understanding of Requirements) โดยสรางเกณฑเพอระบแหลงของความตองการ และเกณฑการยอมรบความตองการ มการวเคราะหความตองการกบบคคลทใหความตองการเพอจะไดเขาใจในความ ตองการอยางถองแทตรงกน ผานเกณฑการยอมรบความตองการ สดทายจะทำาใหไดความตองการทสมบรณพรอมทงขอตกลงในความตองการ

2. การไดมาซงพนธะสญญาบนความตองการรวมกนโดยผรวมโครงการทกคน (Obtain Commitment to Requirements) กระท ำาการสรางและบนท กพนธะสญญาระหวางผมสวนเกยวของในโครงการทกคน และจะตองกระทำาตามพนธะสญญาดงทไดตกลงไวในความตองการ รวมทงการเปลยนแปลงจากแผนการดำาเนนโครงการ กจกรรม และผลตภณฑทจะเกดขนภายหลงดวย

3. จดการกบการเปลยนแปลงความตองการทเกดขนไดตลอดระยะเวลาของโครงการ (Manage Requirements Changes) ระหวางการดำาเนนโครงการนน มกจะมการเปลยนแปลงความตองการเกดขนเสมอดวยเหตผลตางๆ การจดการกบการเปลยนแปลงจงเปนสงจำาเปนทจะตองการทำา โดยการทำาการวเคราะหถงผลกระทบของการเปลยนแปลง มการจดบนทกถงเหตท ต องท ำาใหเก ดการเปลยนแปลงรวมทงผ เรยกรองใน การเปลยนแปลงนน

4. บำารงรกษาการตามรอยไปกลบระหวางความตองการกบแผนโครงการและผลตภณฑงาน (Maintain Bidirectional Traceability of Requirements) เมอความตองการไดถกกำาหนดแลวการสรางการตามรอยไปกลบสามารถสรางจาก แหลงความตองการไปสความตองการขนพนฐาน และจากความตองการขนพนฐานกลบมาสแหลงความตองการ จะชวยใหพจารณาไดวาแหลงความตองการไดถกระบเปนทเรยบรอยและความ ตองการขนพนฐานนนตามรอยไปถกแหลงความตองการ ผลลพธสามารถสรางเปนเมทรกซตดตาม (Traceability matrix) ของความตองการได

5. ระบสงทไมสอดคลองกนระหวางความตองการกบแผนโครงการและผลตภณฑงาน (Identify Inconsistencies Between Project Work and Requirements) โดยการหาความขดแยงกนระหวางความตองการและแผนการดำาเนนโครงการและ ผลตภณฑ พรอมทงหาวธแกไขความขดแยงนน

5 Version 01


1.3 Collaborators1. นายจกรกฤช นนทนชา2. นายฉลองรตน เสนยวงศ ณ อยธยา3. นางสาวณฐยา อมรนพวงศ4. นายนพนนต ชาตาสข5. นางสาวนฤมล ชนชจตร6. นายสรอรรถ บญเตม7. นายธวชชย เยนยบ8. นางสาวศรกญญา ยมเกด9. นายธชชย รศมโรจน10. นายสราวธ โสธร11. นายคำานง พทกษกรณ

1.4 Definitions, Acronyms and Abbreviations- Baseline

A reviewed and approved release of artifacts that constitutes an agreed basis for further evolution or development and that can be changed only through a formal procedure, such as change management and configuration control.

- Business RuleA formal regulation or bylaw imposed by an organization

or simply the standard practices of users governing the way the organization conducts its business. Business rules may be classified as Definitions, Facts (Relationships, Connections), Constraints ('must have' versus 'must not have') and Derivation Rules (inferring new facts from existing ones).

- Cyclomatic Complexity

6 Version 01


The most widely used member of a class of static software metrics. It may be considered a broad measure of soundness and confidence for a program. Cyclomatic Complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.

- Engineering TimeA measurement unit describing engineering effort.

Usually expressed in units of weeks or months. The move away from terms like man-months, or person-months is deliberate. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. In most uses, engineering time is used to understand the relative size of something, not as an advertised elapsed time to complete a task.

- Pareto Chartเปนแผนภมทใชสำาหรบแสดงปญหาตางๆ ทเกดขน โดยเรยงลำาดบปญหาเหลา

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

- Product FeatureA capability or characteristic of a system that directly

fulfills a Stakeholder Need. Often thought of as the "advertised benefits" of the system.

- Stakeholder กลมคนหรอองคกร ทมสวนเกยวของกบโปรเจคหรอมความสนใจในตวโปร

เจค โดยอาจจะมทงผลในดานลบและดานบวกตอตว Stakeholder โดยมากมกจะเปนผท

7 Version 01


มอทธพลตอ Project ตวอยางของ Stakeholder เชน customer, sponsor, performing organisation

- Stakeholder NeedThe business or operational problem (opportunity) that

must be fulfilled in order to justify purchase or use. Also known as goal or objective.

- Vision DocumentA general vision of the core project's requirements it

provides the contractual basis for the more detailed technical requirements. This is a project management document owned by the IT Project Manager. A System Analyst authors it with primary input educed from the Customer.

1.5 References•IEEE/EIA 12207.0 Standard for Information Technology -

Software life cycle processes – Life cycle data• IEEE Std 1233 - 1998, IEEE Guide for Developing System

Requirements Specifications• Spence, I. And L. Probasco, Tracability Strategies for Managing

Requirements with Use-Cases, Cupertino, CA: Rational Software Corporation, 1998

• Mc McCabe, T. & A. Watson, "Software Complexity," Crosstalk, Journal of Defense Software Engineering 7, 12 (December 1994): pp. 5-9.

• Issues Template, V 0.1, Draft, 2010• Test Plan Template, V 0.1, Draft, 2010• Assumptions Template, V 0.1, Draft, 2010

1.6 TLG Documents • เอกสาร Project Management Plan (TLG-CTL-PMP)

• เอกสาร Configuration Management Plan (TLG-CTL-CMP)• เอกสาร Quality Management Plan (TLG-CTL-QMP)• เอกสาร Project Schedule (TLG-CTL-Project Schedule)• เอกสาร Metrics Plan (TLG-CTL-MP)• เอกสาร Training Needs Assessment (TLG-CTL-TRA)• เอกสาร Technical Review Process (TLG-CTL-TEP)

8 Version 01


2 Roles and Responsibillities

2.1 Roles and Responsibilities

No.

Role Responsibility Report To

1 Planning Manager (PM)

ดแลและจดการโครงการ CEO

2 Team Leader (TL)

ดแล ควบคมและดำาเนนกจกรรมของ Project ในสวนการควบคมทม

PM

3 Quality/ Process Manager (QM)

รบผดชอบโครงการในสวนการเขาตรวจสอบคณภาพของกระบวนการและชนงาน

PM, CEO

4 Support Management (SM)

รบผดชอบโครงการในสวนการเขาตรวจสอบมาตรฐานและการเกบชน

งานเขาส Folder มาตรฐาน

PM, CEO

5 Development Manager (DM)

ดแล ควบคมและดำาเนนกจกรรมของ Project ในสวนการเกบ Requirement, สวนการวเคราะหและออกแบบระบบ, สวนการเขยนโปรแกรม, สวนการทดสอบโปรแกรม, สวนการตดตงโปรแกรม

TL, PM

6 Business Analyst (BA)

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

DM

7 System Analyst (SA)

รบผดชอบโครงการในสวนการวเคราะหและออกแบบระบบ

DM

8 Developer (DV)

รบผดชอบโครงการในสวนการเขยนโปรแกรม

DM

9 Tester (TT) รบผดชอบโครงการในสวนการทดสอบโปรแกรม

DM

10

System Engineer (SE)

รบผดชอบโครงการในสวนการตดตงระบบกอนนำาชนงานขนทดสอบ

DM

2.1.1 Planning Manager (PM) บทบาทของ PM

9 Version 01


มบทบาทในทกสวนของการพฒนาโปรแกรมตงแตเรมตนจนจบ Project หนาทของ PM

1.เปนผนำาในการเจรจาตอรองเกยวกบขอบเขตงานเพอใหอยในกรอบทไดมการตกลงในเบองตน พรอมทงรกษาความสมพนธอนด และควบคมใหระบบพฒนาตอบสนองไดตามความตองการ

2.เปนผนำา ใหแตละฝาย (DM, BA, SA, Tester, Developer) ทำางานรวมกนอยางมประสทธภาพ

3. เปนผนำาในเรองการแกไขปญหาเฉพาะหนากรณทโครงการเกดปญหา ( โดยใหใช DAR ชวย กรณทปญหาอยในขอบขายการพจารณาของ DAR)

4.ทำาหนาทในการบรหารโครงการ โดยตองควบคมดแลในเรอง คณภาพ บคลากร และระยะเวลา รวมทงแผนการสงงานใหเปนไปตามแผนทวางไว

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

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

รายงานการตดตามดงกลาวให อาจารย พจารณาทกสปดาห8.ปฏบตงานสอดคลองตาม วงจรการพฒนาซอฟตแวรตามกฎระเบยบททมไดกำาหนดรวม

กน (รบผดชอบในการเตรยมเอกสารทสำาคญทรองรบ CMMI)9.รบผดชอบตอคณภาพงานทจะสงมอบ

ลำาดบการทำางานของ PM ในการพฒนา Software อางอง Phase ตาม Project Plan แสดงกระบวนการทงหมดทเกดขน1. Initiation Phase : 1.1 พจารณาเงอนไขเบองตนในการทำางานโดยใชเอกสาร DAR1.2 จดการประชม Assign Key Person ใหสมาชกในทม และจดทำาเอกสารสรปการ

ประชม (MOM)1.3 รบผดชอบในการจดเตรยมเอกสาร Risk Management, Estimation Sheet

เพอใชประกอบในการสรางแผนโครงการ1.4 กำาหนดแผนการพฒนาระบบโดยจดเตรยมเอกสาร Project Plan ซงครอบคลม

งานทง 6 Phase แต ใหลงรายละเอยดในระดบ Task งานของ Phase ตงแต Initiation Phase ถง Requirement Document Phase เพอพจารณารวมกนกบ Project Team

10 Version 01


1.5 รบผดชอบในการจดเตรยมการประชมเพอลงมตรวมกนสำาหรบแผนพฒนาระบบฉบบดงกลาว

1.6 เสนอแผนการพฒนาระบบและนำาแผนทผานการพจารณาแลวมาเปนตนแบบในการพฒนา ระบบตอไป

1.7 ประชมตดตามสถานะเปนระยะๆ และสงรายงานใหทาง Senior Management2. Requirement Document Phase :3.2 รบผดชอบในการนำาทม BA,SA ประชมเกบขอมลความตองการของระบบ3.3 พจารณาเอกสารททาง BA,SA จดทำากอนการสงให CEO3.4 รบผดชอบในการเซนรบมอบเอกสารการพฒนาและประสานงานตางๆ เชน SRS,

Functional Specification เปนตน3.5 หากปรมาณงานมการเปลยนแปลงเนองจากความตองการของอาจารยหรอในทม

ตองทำาการเตรยม Estimation Sheet ใหม3.6 เตรยมเอกสาร Software Development Plan ซงคลอบคลมรายละเอยดงาน

ตงแต Analysis and Design Document Phase ถง Deployment and Service Phase เพอพจารณารวมกนกบ Project Team

3.7 รบผดชอบในการจดเตรยมการประชมเพอลงมตรวมกนสำาหรบแผนพฒนาระบบฉบบดงกลาว

3.8 ประชมตดตามสถานะทกสปดาห และสงรายงานใหทาง CEO และทมรบทราบ3. Analysis and Design Document Phase :3.1 รบผดชอบในการนำาทม SA ประชมรวมกนกบทมเพอพจารณาเอกสารการออกแบบ3.2 พจารณาเอกสารททาง SA จดทำากอนการสงให CEO3.3 รบผดชอบในการเซนรบมอบเอกสารการพฒนาและประสานงานตางๆ เชน Screen

Prototype, Program Specification เปนตน3.4 ประชมตดตามสถานะทกสปดาห และสงรายงานใหทาง CEO และทมรบทราบ4 Software Product Phase :4.1 ดำาเนนการเรองการสงมอบเอกสารการออกแบบพรอมทงตรวจสอบความถกตอง

และครบถวนของ ขอมลกอนการ Coding4.2 ตรวจสอบงานทมการพฒนาแลวเสรจเปนระยะๆ 4.3 ประชมตดตามสถานะทกสปดาห และสงรายงานใหทาง CEO และทมรบทราบ5 Testing Document Phase :5.1 ควบคมตดตามการทดสอบระบบเปนระยะๆ

11 Version 01


5.2 ประชมตดตามสถานะทกสปดาห และสงรายงานใหทาง CEO และทมรบทราบ5.3 รวมประชมเพอจดการอบรมการใชงานระบบทพฒนาแลวเสรจ6 Deployment and Service Phase :6.1 รบผดชอบคณภาพของงาน และดำาเนนการเรองสงมอบระบบพรอมประสานงาน

ตางๆ6.2 ประชมปดโครงการ, เกบ Feedback จากสมาชกในทม, จดเตรยมเอกสาร

Project Closure Report และรวบรวมเอกสารทเกยวของกบ ระบบและหารอปญหาและแนวทางแกไขเกบเปน สวนหนงของ Historical data

หมายเหต1.PM ตองทำารายงานสรปสถานะของโครงการ (Project Status Report) ทก 1

อาทตย ( อางองเอกสาร MOM)2.ในกรณอาจารย ตอง Review งาน PM จะทำาการ Update งานขนเวบบลอก และรอ

ผล Review จาก CEO

2.1.2 Team Leader (TL)

บทบาทของ TL มบทบาทในทกสวนของการพฒนาโปรแกรมตงแตเรมตนจนจบ Project

หนาทของ TL 1. เปนผนำาใหแตละฝาย (DM, BA, SA, Tester, Developer) ทำางานรวมกนอยาง

มประสทธภาพ โดยดแล ควบคมและดำาเนนกจกรรมของ Project รองจาก PM2. เปนผนำาในเรองการแกไขปญหาเฉพาะหนาใหกบทมกรณทเกดปญหาขน แลวทำาการ

แจงให PM รบทราบ

3. ปฏบตงานสอดคลองตาม วงจรการพฒนาซอฟตแวรตามกฎระเบยบททมไดกำาหนดรวมกน

ลำาดบการทำางานของ TL ในการพฒนา Software 1. ไดรบ Assign งานในสวนทตองรบผดชอบในการควบคม ดแลทม2. นำาทมดำาเนนกจกรรมของ Project ใหเปนไปตามแผนท PM กำาหนด3. กรณเกดปญหา TL จะตองหาแนวทางในการแกปญหาและคอยเปนทปรกษาใหกบทม 4. TL จะตองแจงปญหาตางๆ และสถานะของโครงการให PM รบทราบเปนระยะหมายเหต1. กรณท PM ไมสามารถปฏบตงานได TL จะตองทำาหนาทแทน PM และตองรายงานให PM รบทราบดวยทกครง

12 Version 01


2.1.3 Quality/ Process Manager (QM)

บทบาทของ QM มบทบาทในทกสวนของการพฒนาโปรแกรมตงแตเรมตนจนจบ Project

หนาทของ QM ทำาหนาทตรวจสอบวากระบวนการทเกดขนในระหวางการทำา Project ตงแตเรมตนจนจบ

ถกตองตรงตามกระบวนการทไดรบการอนมตจากสมาชกทกคนในทมหรอไม ลำาดบการทำางานของ QM ในการพฒนา Software

1. ไดรบ Assign งานในสวนทตองรบผดชอบในการตรวจสอบ2. ทำา QA Plan หลงจาก Project Plan ออกแลว3. แจงผทจะถกเขาตรวจใหทราบลวงหนา กอนเขาตรวจจรง4. ตรวจกระบวนการตามทระบใน QA Plan เมอถงวนเวลาทกำาหนด5. ในกรณทพบวาเกด Non-Compliance ขน QM จะปฏบตตามคมอวธการจดการNon-Compliance6. ทำารายงานผลการตรวจสอบ และสงรายงานใหสมาชกทกคนในทมรบทราบ หลงเขาตรวจ

2.1.4 Support Management (SM)

บทบาทของ SM มบทบาทในทกสวนของการพฒนาโปรแกรมตงแตเรมตนจนจบ Project

หนาทของ SM ทำาหนาทตรวจสอบวาชนงานทเกดขนในระหวางการทำา Project ตงแตเรมตนจนจบ ถก

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

ลำาดบการทำางานของ SM ในการพฒนา Software 1. ไดรบ Assign งานในสวนทตองรบผดชอบในการตรวจสอบ2. ทำา CM Plan หลงจาก Project Plan ออกแลว3. ตรวจกระบวนการตามทระบใน CM Plan เมอถงวนเวลาทกำาหนด โดยตรวจสอบการตง

ชอและการกำาหนด Version ใหเปนไปตามมาตรฐานในคมอการตงชอและกำาหนดVersion (File Naming)

4. ในกรณทพบวาเกดปญหาหรอเกดการขอแกไขชนงาน CM จะปฏบตตามคมอวธการ จดการปญหาหรอการขอแกไข ชนงาน

5. ทำาการจดเกบชนงาน โดยจดเกบตามมาตรฐานทกำาหนดไวในคมอการจดเกบชนงาน(File Repository Location)

6. ทำารายงานผลการนำาชนงานขน Baseline (CM Baseline Report) และสงรายงาน ใหสมาชกทกคนในทมและผบรหารรบทราบภายใน 2 วนหลงเขาตรวจ

7. ทำารายงานสถานะของ CI Item (CM Report) และสงรายงานใหสมาชกทกคนในทมและผบรหารรบทราบสปดาหละครง

13 Version 01


2.1.5 Development Manager (DM)

บทบาทของ DM มบทบาทในทกสวนของการพฒนาโปรแกรมตงแต Phase Requirement Document

จนถง Phase Deployment and Service หนาทของ DM

1. เปนผนำาใหแตละฝาย (BA, SA, Tester, Developer) ทำางานรวมกนอยางมประสทธภาพ โดยดแล ควบคมและดำาเนนกจกรรมของ Project ในสวนของการเกบ Requirement, สวนการวเคราะหและออกแบบระบบ, สวนการเขยนโปรแกรม, สวนการทดสอบโปรแกรม และสวนของการตดตงโปรแกรม รองจาก TL

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

3. ปฏบตงานสอดคลองตาม วงจรการพฒนาซอฟตแวรตามกฎระเบยบททมไดกำาหนดรวมกน

ลำาดบการทำางานของ DM ในการพฒนา Software 1. ไดรบ Assign งานในสวนทตองรบผดชอบในการควบคม ดแลทมในเชงเทคนคตางๆ2. นำาทมดำาเนนกจกรรมของ Project ใน สวนของการเกบ Requirement, สวนการ

วเคราะหและออกแบบระบบ, สวนการเขยนโปรแกรม, สวนการทดสอบโปรแกรม และสวนของการตดตงโปรแกรม ใหเปนไปตามแผนท PM กำาหนด

3. กรณเกดปญหา DM จะตองหาแนวทางในการแกปญหาและคอยเปนทปรกษาใหกบทม

4. DM จะตองแจงปญหาตางๆ และสถานะของโครงการให TL, PM รบทราบเปนระยะหมายเหต1. กรณท TL, PM ไมสามารถปฏบตงานได DM จะตองทำาหนาทแทน TL, PM และ

ตองรายงานให TL, PM รบทราบดวยทกครง

2.1.6 Business Analyst (BA)

บทบาทของ BA มบทบาทหลกในสวนงานเกบขอมลความตองการของระบบ (Requirement Document Phase)

หนาทของ BA

14 Version 01


ทำาการเกบความขอมลความตองการของระบบ และสรปเปนเอกสารเกบขอมลความตองการของระบบ (Requirement Documents) ไดแก Software Requirements Specifications (SRS) และ แผนผงทางธรกจ (Business Flow)

ลำาดบการทำางานของ BA ในการพฒนา Software 1. ไดรบ Assign งานในสวนทตองรบผดชอบในการเกบความตองการของลกคา2. ศกษาและทำาความเขาใจผลตภณฑและความตองการของระบบเบองตนและเตรยมสรป

คำาถามกอนเขาประชมในการเกบ Requirement3. นดหมายและเขาพบบคคลทเกยวของทสามารถให Requirement ได เพอทำาการเกบความตองการของระบบ4. วเคราะหความตองการของระบบ จากขอมลทเกบมา5. ทำาเอกสารสรปรายละเอยดความตองการของระบบ (SRS) โดยอางองกบหวขอทวเคราะหไวกอนหนาน6. ทำาเอกสารแสดงแผนผงทางธรกจ (Business Flow)7. ทำาการแกไขเอกสารสรปความตองการของระบบ หากมการขอใหแกไข หลงจาก

Review โดยสมาชกในทมหรอ บคคลตางๆ ทเกยวของ8. จดทำาการอบรมและเอกสารประกอบการอบรม เมอทำาการพฒนาโปรแกรมเสรจเรยบรอย

แลวหมายเหต1. ในการเกบ Requirement จากการประชมตองจดบนทกเปนลายลกษณอกษร และ

เอกสารทไดรบทงหมดทไดจากการประชมแตละครง จะนำาสงลกคาเพอยนยนความถกตอง แลวทำาเอกสารเพอเกบขอมลความตองการของระบบ (Requirement Documents)

2. เอกสาร Requirement ทกฉบบและ Business Flow ทงหมดตองไดรบการอนมต(Approve) จากลกคากอนสงตอใหกบ SA

3. กรณมขอมลเพมเตมจากลกคา ไมวาจะเปน Requirement เพมหรอปรบแกไข จะตอง มาจาก PM และทำาการประชมภายในทมรวมกน เทานน ถงจะมการปรบแกไขได

2.1.7 System Analyst (SA)

บทบาทของ SA มบทบาทหลกในสวนงานวเคราะหและออกแบบระบบ (Analysis and Design

Document Phase) หนาทของ SA

ทำาหนาทในการวเคราะหและออกแบบระบบ (Analysis and Design) จากเอกสารเกบขอมลความตองการของระบบ (Requirement Documents)

ลำาดบการทำางานของ SA ในการพฒนา Software 1. ไดรบ Assign งานในสวนทตองรบผดชอบในการวเคราะหระบบ

15 Version 01


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

3. ทำาเอกสารประกอบการวเคราะหระบบ ประกอบดวย Data Dictionary เพอสอสารกน ระหวาง SA กบผพฒนา

ระบบและเจาของระบบ4.วเคราะหระบบวาระบบจะตองประกอบดวยเรองหรอโมดลอะไรบาง5. ออกแบบลกษณะการตดตอของโปรแกรมกบผใชงาน (User Interface หรอ

Prototype)6. นำาเสนอ Prototype ทออกแบบนำาเสนอในทประชมรวมกบผทเกยวของ ผานขนตอน

การ Review ในทมพฒนา กอนทจะนำาเสนอลกคา เพอใหลกคา Review วาตรงกบความตองการหรอไม

7. ออกแบบ Dataflow Diagram เพอกำาหนดทศทางการไหลของขอมล8. ออกแบบขอมล Input , Output ของระบบ9. ออกแบบ Database เพอรองรบการจดเกบขอมล Input , Output10. นำา Screen Prototype ทไดรบการตกลงรวมกนกบผทเกยวของ มาทำา

Program Specification หรอ เอกสาร ในรปแบบทสอสารกบ Developer ให สามารถนำาไปพฒนาเปนระบบงาน หรอ Program ใหตรงตาม Requirement ได

11. จดทำาคมอในการใชงานระบบ (User Manual)12. จดทำาการอบรมและเอกสารประกอบการอบรม เมอทำาการพฒนาโปรแกรมเสรจ

เรยบรอยแลว13. บำารงรกษาและประเมนผลการทำางานของระบบหมายเหต1.SA จะตองเขารวมตงแตกระบวนการของการเกบ Requirement และประชมรวมกบ

ลกคาและผเกยวของรวมกบ BA ดวย รวมถงการบนทก Requirement และ ขอมล ตางๆ ทไดจากการเขารวมในการเกบ Requirement ดวย

2.1.8 Developer (DV)

บทบาทของ DV มบทบาทหลกในสวนงานเขยนโปรแกรม (Software Product Phase)

หนาทของ DV ทำาหนาทเขยนโปรแกรม ตามเอกสารวเคราะหและออกแบบระบบ (Design Documents)

และ Program Specification ลำาดบการทำางานของ DV ในการพฒนา Software

1. ไดรบ Assign งานในสวนทตองรบผดชอบในการเขยนโปรแกรม2. ศกษาและทำาความเขาใจเอกสารทไดจากการวเคราะหและออกแบบระบบ (Program

Specification)3. เขยนโปรแกรมโดยอางองตาม Program Specification

16 Version 01


4. ทำาการทดสอบหนาทการทำางานเบองตนของโปรแกรมทเขยน (Unit Test) และทำา รายงานสรปผลการทดสอบ (Unit Test Report) และสงรายงานททำา ใหผทเปน

หวหนา (Team Lead) ตรวจดความถกตองของรายงาน5. ทำาการตดตงโปรแกรมทผานการทำา Unit Test นลงระบบ เพอให Tester ได

ทำาการทดสอบตอไป6. จดทำาคมอสำาหรบการตดตง (System Manual)หมายเหต1. DV สามารถชวยทำาหนาทในการวเคราะหระบบดวยได ( ดรายละเอยดหนาทของ SA

จากสรปหนาทของ SA ดานบน)

2.1.9 Tester (TT)

บทบาทของ TT มบทบาทหลกในสวนงานทดสอบโปรแกรม (Testing Document Phase)

หนาทของ TT ทำาหนาทเขยนขนตอนการทดสอบโปรแกรม (Test Case) และทำาการทดสอบตามขนตอน

นนๆ ลำาดบการทำางานของ TT ในการพฒนา Software

1. ไดรบ Assign งานในสวนทตองรบผดชอบในการออกแบบขนตอนการทดสอบ (Test Case) 2. ศกษาและทำาความเขาใจเอกสารบนทก Requirement3. เขยนขนตอนการทดสอบโปรแกรม (Test Case) โดยอางองกบเอกสารบนทกRequirement4. นำาเสนอ Test Case ทเขยนขนนำาเสนอในทประชมรวมกบผทเกยวของ ผานขนตอน

การ Review ในทมพฒนา เพอใหทมงาน Review วาตรงกบความตองการหรอไม และทำาการปรบแก Test Case

ตามทไดรบ comment จากทม5. ทดสอบโปรแกรมตามการทดสอบทออกแบบไว (Integrate Test)6. ทำารายงานผลการทดสอบ (Test Case Report) และสงให PM ทำาการตรวจสอบความถกตอง

2.1.10 System Engineer (SE)

บทบาทของ SE มบทบาทหลกในสวนงานตดตงโปรแกรม (Deployment Phase)

หนาทของ SE ทำาหนาทกำาหนดคาเบองตนและตดตงโปรแกรมท Site ลกคา

ลำาดบการทำางานของ SE ในการพฒนา Software 1. ไดรบ Assign งานในสวนทตองรบผดชอบในการตดตงโปรแกรมท Site งานลกคา2. ศกษาและทำาความเขาใจคมอ System Manual ของโปรแกรม

17 Version 01


3. ทำาการกำาหนดคาเบองตนและตดตงโปรแกรมท Site ลกคา โดยอางองตามคมอSystem Manual ของโปรแกรม4. ทำาการแจงผลการตดตงให PM รบทราบ

3 Requirements Process

3.1 Requirements definition with scope being an input

Figure 3.1 Requirements definition with scope being an input

จากรปไดอะแกรมดานบนจะแสดงใหเหนกระบวนการทมองดแลวคลายกบเครองจกร เรมกระบวนการโดยการปอนวตถดบตาง ๆ (Input Requirements) เขาไป จากนนกระบวนการตางภายในกจะทำางานวนรอบหลายรอบจนไดผลลพธของความตองการทผานการกลนกรองแลว (Approved Requirements) กระบวนการทอยภายในประกอบดวย การ

18 Version 01


เกบรวบรวมความตองการ (Elicit) , การระบความตองการ (Specify), การวเคราะหความตองการ, การทบทวนความตองการ (Review) รปไดอะแกรมดานบนไมไดแสดงใหเหนวาจะตองเรมตนจากกระบวนการใดกอน และลำาดบตอไปตองเปนกระบวนการใดตอไป รวมทงไมไดแสดงจำานวนรอบของการทำางาน (Interations) เพอใหไดผลลพธของความตองการทผานการกลนกรองแลว รปไดอะแกรมแสดงใหเหนผลลพธทผานการกลนกรองจะดหรอไมขนกบขอมลความตองการทไดมาตงแตตน โดยปกตบางขนตอนของกระบวนการพฒนาความตองการทำาใหเขาใกลกระบวนการพฒนาโปรแกรมยงขน เขาใจวาระบบทตองพฒนาจะมหนาตาเปนอยางไร กระบวนการพฒนาความตองการไมสามารถทำาเปนระบบอตโนมตได ยงคงตองการคนตดสนใจในการวเคราะหความตองการ

- Elicit ในขนตอนนเราจะสามารถทราบความตองการตางๆ โดยผพฒนาระบบตองไปปรกษา

กบลกคา จากเอกสารของระบบ ความรตางๆ ในหวขอทเราจะศกษา การใหบรการของระบบ ทเราจะพฒนา ความตองการของประสทธภาพของระบบ ขอจำากดทางดานฮารดแวร เพอท

จะทราบถงแนวทางในการแกปญหา Requirements elicitation เปนสวนทสำาคญมาก หากเราไมสามารถทราบถงความตองการทแทจรงของลกคาแลว เมอเราพฒนาระบบออกมา

อาจทำาใหลกคาไมพอใจในตวระบบ- Specify

องคประกอบของ Requirements elicitation 1. ความเขาใจในขอบเขตของแอปพลเคชน (Application domain

understanding) เปนการทำาความเขาใจเกยวกบขอบเขตหวขอของระบบทเราจะพฒนา ตวอยางเชนถาเราจะพฒนาระบบ จะทำาอะไร มขอบเขตอะไรบาง

2. ความเขาใจในปญหา (Problem understanding) เราตองทำาความเขาใจใน รายละเอยดของปญหาของลกคาทเราตองใชระบบของเรามาจดการนน ตองเขาใจวาปญหา

หรออปสรรคใดๆ ในระบบธรกจหรองานทตองการนำาเอาระบบคอมพวเตอรไปแกไข คออะไร3. เขาใจในธรกจหรอระบบทศกษาอย (Business understanding) เราตอง เขาใจวา ระบบจะทำาการปฏสมพนธ และมผลตอระบบธรกจในแตละสวนอยางไร นอกจาก

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

(Understanding the needs and constraints of system stakeholders) ใน ระบบมผเกยวของหลายฝาย แตละฝายตองการอะไร มเงอนไขอะไร

Requirements elicitation process ประกอบไปดวยกจกรรมสำาคญ 4 อยางไดแก

1. การตองจดมงหมาย (Objective setting) วตถประสงคขององคกร ซง ประกอบไปดวย เปาหมายหลกของธรกจ และการบรรยายถงปญหาทตองการนำามาแกไข

และขอจำากดของระบบเชน งบประมาณ เวลา ควรจะถกกำาหนดออกมาในขนตอนน

19 Version 01


2. การรขอมลเบองหลงของระบบ (Background knowledge acquisition) นเปนขนตอนทสำาคญมากๆ ซงเปนขนตอนท Requirements engineering จะใช

รวบรวมและเขาใจในขอมลพนฐานตางๆ ของระบบ และสวนนยงใชบอกดวยวา สวนในขององคกรทระบบของเราจะถกนำาไปใช, ขอมล application domain ของระบบ และ ระบบทมอยแลวในองคกรซงกำาลงใชอยและระบบทจะเอาระบบทเราพฒนาเขาไปแทนท

3. การมความรเกยวกบภาพรวมขององคกร (Knowledge organization) ขอมลและองคความรทงหมดทถกเกบมาใน 2 สวนทแลวจะถกทำาใหเปนระบบและจดเรยง

ซงไดแก ผทมสวนเกยวของในระบบ และบทบาทของบคคลเหลานน เรยงลำาดบความสำาคญ เปาหมายขององคกร และตดdomain knowledge ทไมเกยวของโดยตรงกบความ

ตองการของระบบ4. การรวบรวมความตองการของผมสวนไดสวนเสยกบระบบ (Stakeholder

requirements collection) นเปนสวนทเรยกวาการดงขอมลออกมาจรงๆ ซงรวมไปทงการปรกษาผทเกยวของในระบบเกยวกบสงทบคคลเหลานนตองการและการไดมาซง

ความตองการตางๆ ทมาจาก application domain และจากองคกรทตองการระบบของเราไปใชงาน

- Specify จดทำาเอกสาร เปนการรวบรวมขอกำาหนด เปนตนแบบของโปรแกรม การจดทำาขอ

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

เอกสาร requirements document ไมไดเปนเอกสารทใชในการออกแบบระบบ ซอฟตแวร ดงนนจงไมมการระบรายละเอยดวธการออกแบบวาตองทำาอยางไร หากแตเปน

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

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

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

คอ1. ควรมพฤตกรรมภายนอกทเกยวของกบระบบ2. ควรมการระบเงอนไขหรอขอจำากดภายในระบบ3. ควรอยในรปแบบทงายสำาหรบการแกไข4. สามารถนำามาเปนเครองมออางองในระบบ5. ควรมการบนทกรายละเอยดขนตอนการทำางานทเกดขน รวมถงวฏจกรการพฒนา6. ควรมการระบวธการทำางานของระบบ เมอมเหตการณทไมตองการเกดขน

- Analyse เปาหมายของการวเคราะหความตองการของผใชกคอ เพอทจะคนหาปญหาใน

เอกสารความตองการตนแบบ (draft requirements document) ขณะดำาเนนการ

20 Version 01


วเคราะหความตองการตางๆ นกวเคราะหตองพยายามทำาความเขาใจกบปญหาตางๆ ของ องคกร ขนตอนตางๆ ของ requirements analysis process จะมกจกรรมทตอง

ดำาเนนการซำาไปซำามาจนกระทงไดขอมลทถกตองและชดเจนทสด ซงขนตอนนมกจกรรม ตางๆ ดงน1. การตรวจสอบความตองการ (Necessity checking) สงทจำาเปนสำาหรบความ

ตองการตางๆ จะถกวเคราะห ซงในบางกรณ ความตองการบางอยางอาจจะไมไดเกยวของกบเปาหมายทางธรกจขององคกร

2. การตรวจสอบความสอดคลองและสมบรณของความตองการ (Consistency and completeness checking) ความตองการจะถก ตรวจสอบ(cross-checked)

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

ใดๆ ตกหลนหรอขาดหายไป3. การตรวจสอบความเปนไปได (Feasibility checking) ความตองการจะถก

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

- Review เปนขนตอนสดทายในกระบวนการ Requirements engineering ซงมเปาหมาย

คอ เพอทำาใหความตองการทเราเกบมาถกตอง โดย requirements validation จะมง เนนไปในทางการตรวจสอบ เอกสารความตองการ (requirements document) ซง

รวบรวมความตองการทกอยางของระบบและ ความไมสมบรณพรอมทงความซอนทบของ ความตองการถกกำาจดไปทงหมดแลว นอกจากนการทำา requirements validation

เราควรมคำาถามคำาถามหนงอยในใจเสมอ นนคอ เราไดความตองการทถกตองแลวหรอยง เกณฑการตรวจสอบความตองการม 4 ขนตอนคอ

1.ความถกตอง(Validity) ความตองการตาง ๆทลกคาระบในเอกสารตองตรงกบ สงทลกคาตองการจรงๆ

2. ความสอดคลอง (Consistency) ความตองการตางๆ จะตองไมขดแยงซงกนและกน

3. ความสมบรณ (Completeness) รายละเอยดตาง ๆทเปนความตองการและ เงอนไขกฎเกณฑทงหมด จะตองถกระบอยในเอกสาร

4. ความเปนจรง (Realism) ในทางปฏบตไมมทางใดทจะบอกไดวา ความตองการ ตางๆ ทระบในขอกำาหนดสามารถนำามาพฒนาระบบไดจรง

3.2 Requirements development within information model

21 Version 01


22 Version 01


4 Concept Exploration Phase Requirements Management

4.1 Concept Exploration Phase Requirements Management

4.1.1 Vision Development

เปนกระบวนการพฒนาความตองการโดยอาศยวสยทศตามขอบเขตของโปรเจค วสยทศคลมครอบวตถประสงคและเปาหมายของโปรเจค เปนขนตอนทอยในระดบสงอาศยวตถประสงคและเปาหมายของโปรเจค เพอใหสอดคลองความตองการและเปาหมายของลกคา ในขนตอนนจะพฒนาเปนสองเวอรชน คอเวอรชน Draft ทพฒนาตามความเขาใจระบบ ณเวลาขณะนน และเวอรชนทสองเปนเวอรชนทนำาเวอรชน Draft มาปรบปรงเปนเวอรชนทสมบรณมากขนโดย Team Leader

4.1.2 Concept Development

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

4.1.3 Requirements Integrated Product Team

เปนการขนตอนการเตรยมทำาการเกบรวบรวมความตองการ ซงประกอบดวยวงจรการพฒนาความตองการ ดงน• Prepare for cycle,

กำาหนดเปาหมายของการเกบรวบรวมขอมล กำาหนดเทคนคในการเกบรวบรวมขอมล กำาหนดตวของผทมสวนไดเสยกบผทมสวนรวมกบโครงการ

• Elicit requirements,

23 Version 01


ขนตอนการเกบรวบรวมขอมล หรอ ใชเทคนคในการเกบรวบรวมขอมล ทไดจากขนตอนการเตรยมความพรอมกอนทำาการเกบรวบรวมขอมล ผลรบไดจากขนตอนการเกบรวบขอมล จะเปนชดของขอมลทอาจนำาไปปรบปรงความตองการของโปรเจคกได ซงจะถกนำาไปคดเลอกในขนตอนตอไป• Analyze requirements,

ขนตอนการวเคราะหความตองการทไดมาจากขนตอนการเกบรวบรวมขอมล จดทำาเปนเปนเอกสารทเปนทางการ พจารณาวามขอมลทซบซอน หรอกลำากลวม ใหทำาการแกไข เรมตนทำาการจบคระหวางลำาดบของความตองการ ผลลพธทไดเปนชดของขอมลความตองการใหม หรอชดของขอมลความตองการเกาทมการปรบปรง• Formalize requirements

ขอมลความตองการจะอยในรปแบบทเปนทางการ นำาขอมลความตองการทไดจากขนตอน Analyze requirement มาใชกบเครองมอ Requirement Management Tool เพอจะไดผลลพธตารางทำาการตดตามได และมการอพเดดด• Validate and Verify requirements.

Requirement Development จะถกตรวจสอบวาถกตอง หรอ ตรงกบความตองการของผทมสวนไดเสยกบงาน โดยการทำาการทบทวน, สมภาษณ และตองมนใจวาตรงกบเปาหมายของโครงการ ถาผทมสวนไดเสยกบงานตกลงกบ Requirement Development เอกสารฉบบนจะตองมการควบคมเวอรชนของเอกสารดวย

4.1.4 Use Case Development

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

4.1.5 Requirement Document

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

24 Version 01


5 Concept Development Requirements Management Process

5.1 Provide Baselined Requirements to Development Contractorsจดเตรยมความตองการพนฐานเพอใชในการพฒนาและออกแบบ

5.2 Contractor Requirement Analysisวเคราะห กำาหนดวธการในการพฒนา โดยจะใชกระบวนการของ CM มาชวยในการ

ควบคม เพอใหอยในกรอบของเงอนไขทไดกำาหนดเอาไว โดยจะนำาขอมลทไดจากการวเคราะหมาจดทำา System Requirements Specification

5.3 System Requirements Review (SRR)เพอตรวจสอบวาความตองการนนไดรบการตอบสนองครบถวน ถกตองตามความ

ตองการหรอไม อาจประเมนไดจากเกณฑดงน• Traceability to acquisition needs,• Consistency with acquisition needs,• Testability• Feasibility of system architectural design• Feasibility of operation and maintenance.

5.4 Reviews Requirements and Provides Feedbackเพอ review requirement และ feedback กลบไปยงผทจดทำา System Requirements

Specification ซงอาจมการปรบเปลยน Baseline หรอมขอเสนอแนะใหแกไขเพมเตม หากมการแกไข Baseline จะตองทำาภายใตกระบวนการของ CM

25 Version 01


5.5 Development Contractors Produce System Design Documentsออกแบบตาม Baseline ทไดวางไว โดยจะไดเปนเอกสาร System Design Documents

5.6 System Design Reviews (SDRs)ทำาการ review วาการออกแบบทไดทำาไว ตอบสนองความตองการไดอยางครบถวน

โดยจะตองไดรบการยอมรบจากคสญญา เพอทำาการอนมต

5.7 Development Contractor Selectedทำาการวเคราะหเอกสาร SDD เพอเลอกทางทเหมาะสมสำาหรบการพฒนาระบบ

5.8 New Requirements Baseline

6 Requirements Tools and Techniques

6.1 Rational RequisitePro

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

6.2 Document Templates and Spreadsheets

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

6.3 Interviews

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

26 Version 01


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

6.4 Survey Questionnaire การสำารวจแบบสอบถามเปนวธการทระบบเกบรวบรวมขอมลจากผมสวนไดเสย เกยว

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

7 Requirements Documentation and Organization

7.1 Requirements Documentation

7.1.1 Breakdown Structures

1. Inputs2. Organizational Process Assets3. Project Scope Statement4. Project Scope Management Plan5. Approved Change Requests6. Tools and Techniques7. WBS Templates8. Decomposition9. Outputs10. Project Scope Statement (Updates)11. Work Breakdown Structure12. Organizational Breakdown Structure13. Risk Breakdown Structure14. Resource Breakdown Structure

27 Version 01


15. WBS Dictionary16. Scope Baseline17. Project Scope Management Plan (Updates)18. Requested Changes

7.2 Organization

7.2.1 Traceability Strategy

- Forward traceability เพอตดตามความตองการใหกบองคประกอบในผลลพธ ของขนตอนตอมา

(ออกแบบ, การเขยนโปรแกรม) ในวงจรชวต- มนเปนสงจำาเปนเพอใหแนใจวาซอฟตแวรคณสมบตตรงตามขอกำาหนด

- Backward traceability เพอตดตามองคประกอบในผลลพธของแตละขนตอนยอนกลบไปทความ

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

7.2.2 Numbering Convention

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

8 Requirements Acceptance Criteria

มนถกตอง ? ความตองการสามารถแทนความตองการทจำาเปนและสามารถระบตวความตองการไดหรอไม ?มนตรวจสอบและทดสอบได ? ทกความตองการควรจะสามารถตรวจสอบดวยการทดสอบ หรอผานการวเคราะหมนสามารถตดตามได ? ทกความตองการควรจะสามารถตดตามความตองการอน ๆ ไดดวย

28 Version 01


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

29 Version 01


A. DEFINITIONS, ACRONYMS, ABBREVIATIONS

Associated information

Information associated with a requirement, including traceability information. If a requirements management tool is used, the requirements database or repository usually has more associated information than hardcopy documents such as the SRS.

Child Child requirements are decomposed from parent requirements. For example, A is the child of the requirement ABC.

Compliance matrix RTM

Constraint Boundary conditions on how the system must be constructed and implemented, for example, how a COTS package might be selected.

Derived New requirements identified during the development process that trace back to a driving requirement.

Goal States the desired result, not the way to reach it. For example, they system shall reduce operating costs by 10% of 2001 costs. All changes in requirements and design should be passed through stated goals. If they are outside the goals, they should be rejected.

Information Any communication or representation of knowledge such as facts, data, or opinions in any media or form.

Non-functional requirement

Relate to characteristics of a system such as performance, reliability, security, accuracy, and so forth.

Non-technical requirements

Agreements, conditions, or contractual terms that affect and determine the management activities of a project.

Parent Child requirements are decomposed from parent requirements. See child requirement.

PMO Project management office

Requirement A condition or capability that is wanted or needed.

Requirement repository

COTS providing a database or spreadsheet in which the requirements and associate information are stored.

RM Requirements management

RTM Requirements traceability matrix

SME Subject matter expert in one or more areas of the client’s business.

SRS System requirements specification.

System functional requirements

Include functional and non-functional requirements on the system.

30 Version 01


B. FORMSInclude forms that will be used.

31 Version 01


C. REQUIREMENTS EVALUATION CHECKLISTSEnter the unique ID of the problem requirement(s). Explain in Remarks the reason if “No” is checked. Attach additional sheets if needed.

Evaluation Criteria Yes No ID RemarksA test case is associated with the requirement.The requirement can be understood by affected parties (e.g., SME, developers, testers).Unacceptable words and phrases are absent (e.g., adverbs, adjectives, as appropriate, at a minimum).Adheres to defined terms in the requirements glossary.Requirement conforms to standard format.Requirement is at the appropriate level of detail for its position in the hierarchy.Requirement has the associated information required by the RM plan.Requirement is within scope.Requirement is terse.Requirement avoids specifying design.Requirement is feasible.Requirement is written in the imperative (shall).Cross-references are specific so the information can be easily located; the reference is located in the project document library if it is external to the requirement.Requirement can be traced to its parent or driver.Requirement is unrestrictive; it can be implemented by more than one solution or design.Requirement contains no TBD.

A. Checklist for Individual Requirements

32 Version 01


Evaluation Criteria - All Requirements Yes No IDs RemarksRequirements are consistent with each other.Requirements are complete: every case or scenario is addressed.Requirements address user interfaces.Non-functional requirements are addressed.Assumptions and dependencies for requirements are stated.Requirements address system and user error conditions.All requirements are traced to their parent or driver (no dropped traceability).Interfaces are specified (internal/external).Inputs and outputs are specified.

B. Checklist for All Requirements

33 Version 01


D. REQUIREMENT REPORT EXAMPLES Some requirement reports are listed below. Examples should be generated from the tool when possible.

Traceability Matrix Unallocated Requirements Requirements by Risk Requirements by Priority Requirements by Qualification Method Requirements Status Cumulative Changes Other Requirement Metrics Reports

34 Version 01


E. QUALITY STANDARDSDescribe the characteristics of requirements of good quality.

35 Version 01