5. ข้อกำหนดความต้องการซอฟต์แวร์ (Software Requirements Specification) Requirements Model Requirements Workflow ความยุ่งยากของการหา Requirements Stakeholders เทคนิดในการรวบรวมความต้องการ (Techniques for Information Gathering) Activity Diagram สำหรับการโมเดลกระแสงาน

5.1 Software Requirements คืออะไร Merlin Dorfman and Richard H. Thayer ได้ให้นิยามของSoftware Requirements ไว้ว่า ความสามารถของซอฟต์แวร์ที่เป็นที่ต้องการของผู้ใช้เพื่อแก้ปัญหาหรือเพื่อให้ประสบผลสำเร็จตามเป้าหมาย ความสามารถของซอฟต์แวร์ที่ต้องพบในระบบหรือส่วนประกอบของระบบเพื่อให้เป็นไปตามสัญญา (Contract) ข้อกำหนด (Specification) หรือ มาตรฐาน (Standard) หรือตามที่กำหนดไว้อย่างเป็นทางการในเอกสารอื่นๆ

Requirements มีหลายระดับ อาจเป็นถ้อยความอธิบายกว้างๆ (high-level abstract statement) ถึงบริการและข้อจำกัดของระบบ จนถึงข้อกำหนดในรายละเอียด Requirement อาจถูกนำไปใช้ในหลายลักษณะ ใช้เพื่อการประกวดราคา (bid) ให้ผู้รับงานทำข้อเสนอ เป็นตัวสัญญาที่เป็นรายละเอียดของข้อเสนอ

Requirements มีความสำคัญอย่างไร [Standish Group’s CHAOS] Requirements ที่ไม่สมบูรณ์และการขาดความมีส่วนร่วมจากผู้ใช้เป็นสองประเด็นหลักของโครงการพัฒนาซอฟต์แวร์ที่ล้มเหลว 76% ของบริษัทพัฒนาซอฟต์แวร์ใน USA และ UK เคยประสบความล้มเหลวในโครงการ สาเหตุที่ถูกกล่าวถึงคือ ‘การเปลี่ยน Requirements’

5.2 Requirements Model ถ้อยความและ diagram ที่อธิบายความต้องการของผู้ใช้ที่มีต่อระบบ อธิบายว่าระบบจะต้องทำอะไร (What) Functional Requirements – สิ่งที่เป็นพฤติกรรมความสามารถของระบบ อธิบายถึงบริการที่มีในระบบ สิ่งที่ระบบตอบสนองเมื่อรับ input และพฤติกรรมที่ระบบตอบสนองต่อเหตุการณ์ใดๆ Non-functional Requirements – คุณสมบัติเฉพาะ (Specific properties) หรือข้อจำกัด (Constraints) ของระบบข้อจำกัดของการบริการหรือฟังก์ชันที่มีในระบบ เช่นข้อจำกัดด้านเวลา ด้านกรรมวิธีการพัฒนาระบบ มาตรฐาน และอื่นๆ

รูปแบบของการเขียน Requirement ที่ดี ใน UML ใช้ Use case model แสดง Requirement ทั้ง Functional และ nonfunctional รูปแบบของการเขียน Requirement ที่ดี <id> The <system> shall <function> Functional requirement 1. The ATM system shall check the validity of the inserted ATM card 1. The ATM system shall validate an ATM card in three seconds or less

5.3 Requirements Workflow โดยทั่วไป Gather information Define system requirement Build prototypes for discovery of requirements Prioritize requirements Review recommendations with management Requirements workflow ของ UP Find actors and use cases Prioritize use cases Detail a use case Structure the use case model Prototype user interface ความเชียวชาญที่ต้องนำมาใช้ Fact-finding และ Modeling

Gather Information Analyst ต้องเรียนรู้กิจกรรมทางธุรกิจ (Business process) และการดำเนินงานในแต่ละวัน (Daily operation) เพื่อให้เป็น expert ในธุรกิจที่ระบบสนับสนุน จากบุคคลที่เป็นผู้ใช้ระบบ จากเอกสารนโยบาย/แผนงาน จากเอกสารระบบปัจจุบัน ศึกษาจากบริษัทอื่นๆ รวบรวม Technical info ศึกษากิจกรรมที่ user ทำ ระบุสถานที่ที่ทำกิจกรรม ระบุ interface กับระบบอื่น พูดกับทุกคนที่เกี่ยวข้อง อ่านจากเอกสารทุกอย่างที่มี

Define System Requirements จัดทำเอกสารอธิบาย Requirements ทั้ง Functional และ Technical requirements รวมทั้งสร้าง models Logical model - แสดงสิ่งที่ระบบต้องทำโดยไม่ผูกกับ Technology ใดๆ Physical model - แสดงให้เห็นว่าระบบจะถูก implement อย่างไร การสร้าง Models ทำให้ Analyst ได้เรียนรู้และเข้าใจระบบงานมากขึ้น

Prototype for Feasibility and Discovery เพื่อให้มั่นใจว่า Technology ที่นำเสนอสามารถทำได้อย่างที่ต้องการ เพื่อมั่นใจว่า users เข้าใจในสิ่งที่จะได้รับ ทำความเข้าใจในความต้องการของ Users ได้ดีขึ้น Prioritize Requirements จัดลำดับความสำคัญ เพราะทรัพยากรในการพัฒนาระบบมีจำกัด

5.4 ความยุ่งยากของการหา Requirements Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

5.5 Stakeholders Stakeholders – บุคคลที่มีความสนใจในความสำเร็จของระบบ Users ผู้ใช้ระบบ Business users ให้ข้อมูลเกี่ยวกับ daily operation และแนวทางที่ระบบจะต้องสนับสนุน Information users ให้ข้อมูลความต้องการ information เช่น information ชนิดใดที่ควรมีเป็นรายวัน รายสัปดาห์ รายเดือน รายปี รูปแบบที่นำเสนอ Management users ผู้ซึ่งบริหารจัดการให้การทำงานขององค์กรเป็นไปอย่างมีประสิทธิภาพ ต้องการข้อมูลทางสถิติ ให้ข้อมูลชนิด report ที่ต้องมี performance ของระบบ จำนวน transaction ที่มี Executive users สนใจ strategic issues เปรียบเทียบ improvement การใช้ทรัพยากร

External entity ลูกค้าของบริษัท/องค์กร External users ลูกค้าของบริษัท ที่เป็นผู้ใช้ระบบ Clients ผู้ออกค่าใช้จ่าย ผู้เป็นเจ้าของระบบ Analyst ต้องรายงานความก้าวหน้าของโครงการเป็นระยะ Technical staff ผู้ที่ทำให้ระบบปฏิบัติงานได้ภายใต้ environment ขององค์กร ให้ข้อเสนอแนะเช่น programming languages, computer platform External entity ลูกค้าของบริษัท/องค์กร

5.6 Techniques for Information Gathering สิ่งที่ต้องค้นหา มี Business Processes อะไรบ้าง แต่ละ Business Process ทำงานอย่างไร มี Information อะไรที่จำเป็นต่อการทำงาน คุณค่าของ Analyst อยู่ที่จะวิเคราะห์ปัญหา และเสนอ solution ให้เป็นที่ยอมรับได้ดีเพียงใด

Techniques Distribute questionnaires Understand new system constraints Interview Users Review existing documentation Understand new system procedures Develop requirements and models for new system Observe business procedures Understand new system functions Research vendor solution

Techniques ทบทวนจากรายงาน แบบฟอร์ม คู่มือการปฏิบัติงาน สัมภาษณ์ สนทนากับ users สังเกตการปฏิบัติงาน สร้าง Prototype ทำแบบสอบถาม JAD

ทบทวนจากรายงาน แบบฟอร์ม คู่มือการปฏิบัติงาน ควรจะเป็นกิจกรรมแรกของ fact-finding activities ศึกษาจากแหล่งข้อมูล ภายนอกองค์กร องค์กรอื่นที่ทำธุรกิจเดียวกัน ภายในองค์กร ขอให้ users สำเนาเอกสาร ฟอร์มที่ใช้ในปัจจุบัน นำมาศึกษา ใช้ฟอร์ม เอกสารเป็นสื่อในการสัมภาษณ์ การทบทวนเอกสารอาจค้นพบ business rules

สัมภาษณ์ (Interview) Before Establish the objective for the interview Determine the correct user(s) to be involved Determine project team members to participate Build a list of questions and issues to be discussed Review related documents and materials Set the time and location Inform all participants of objective, time, and locations During Dress appropriately Arrive on time Look for exception and error conditions Probe for details

Take thorough notes Identify and document unanswered items or open questions After Review notes for accuracy, completeness, and understanding Transfer information to appropriate models and documents Identify areas needing further clarification Send thank-you notes if appropriate

Observe and Document Business Process Observing เตรียมการ ระบุขั้นตอนที่ต้องการสังเกต เตรียมคำถาม 1. ตั้งคำถามที่เหมาะ 2. สังเกตทุกขั้นตอน 3. ตรวจสอบฟอร์ม เรคคอร์ด รายงาน 4. พิจารณางานของแต่ละบุคคล 5. ปรึกษาผู้ใช้รายงาน (สมบูรณ์ ถูกต้อง ทันเวลา)

Documenting Business Process Documenting with Workflow diagrams (Activity Diagram)

Build Prototypes A prototype is an initial, working model of a larger, more complex entity. Prototype ที่ดีควรจะ 1. Operative แสดงขั้นตอนการทำงาน 2. Focused มีจุดมุ่งหมายที่ชัดเจน 3. Quick ใช้เครื่องมือที่ทำได้เร็ว

แบบสอบถาม (Questionnaires) 1. สั้น ง่ายที่จะตอบ 2. จัดเรียงในลักษณะ Logical Order 3. ไม่ใช้คำ วลี ที่จะทำให้เข้าใจผิด 4. เลี่ยงคำถามที่ต้องการคำตอบที่ยาว หรือสั้น 5. ใช้คำถามที่จะได้คำตอบที่ต้องการ 6. ทดสอบแบบสอบถามก่อน

Conduct Joint Application Design (JAD) ประชุมระดมความคิด โดยมี stakeholders ที่สำคัญ เข้าร่วม ผู้เข้าร่วมประกอบด้วย 1. The JAD session leader 2. Users 3. Technical staff 4. Project team members

5.7 Activity Diagram สำหรับแสดงกระแสงาน กระแสงาน (Workflow) - เป็นชุดของขั้นตอนการทำงานที่ทำให้งานทางธุรกิจหนึ่ง (Business Transaction) เสร็จสมบูรณ์ใช้อธิบายได้ทั้งการทำงานของระบบเก่าและระบบใหม่ Activity Diagram - เป็นไดอะแกรมกระแสงาน (Workflow Diagram) ชนิดหนึ่ง อธิบายกิจกรรมการทำงานของคน (หรือระบบ) บุคคลที่เป็นผู้ทำกิจกรรม และลำดับของกิจกรรมเหล่านั้น

สัญลักษณ์พื้นฐานใน Activity Diagram Control Flow Initial State Decision Final State Action State Swimlane Transition (Fork) Note Transition (Join)

A Simple Activity Diagram to Demonstrate a Workflow Figure 4-14 A Simple Activity Diagram to Demonstrate a Workflow

An Activity Diagram Showing Concurrent Paths Figure 4-15 An Activity Diagram Showing Concurrent Paths