Defining the Requirements Tawatchai Iempairote September 9, 2014.

งานนำเสนอเรื่อง: "Defining the Requirements Tawatchai Iempairote September 9, 2014."— ใบสำเนางานนำเสนอ:

1 Defining the Requirements Tawatchai Iempairote September 9, 2014

2 เราจะได้รู้จัก “REQUIREMENTs” คืออะไร ทำไมเราต้องการ “REQUIREMENTs” The SRS ทำไม SRS สำคัญ กระบวนการการได้มาของ “REQUIREMENTs”

3 What Are Requirements? (1/2) ทีมสร้าง software requirements specification (SRS) ( ข้อกำหนดความต้องการซอฟต์แวร์ ) SRS ต้องชัดเจน และไม่กำกวมว่า product จะเป็นอะไร มีลักษณะอย่างไร SRS จะรวมเกณฑ์ที่ชัดเจนสำหรับการประเมิน product ที่ พัฒนาเสร็จแล้วว่าตรงตามที่ควรจะเป็นหรือไม่

4 What Are Requirements? (2/2) จะเป็นคำตอบว่าผู้ใช้ต้องการ product แบบนั้น จริงๆ (No Assumptions, No Guesses) ให้เขียนความต้องการนั้นด้วยคำที่คุณเข้าใจและ สอบทานกลับกับ user อีกครั้งว่าตรงตามที่ ต้องการหรือไม่ 1 week for cycle 1, Half a week for cycle 2 - 3

5 ข้อกำหนดความต้องการด้านซอฟต์แวร์ ( SRS ) ไม่ใช่เอกสารประกอบการออกแบบ ไม่บรรยายว่าจะสร้าง product นั้น อย่างไร แต่เป็นเอกสารของกลุ่ม ความต้องการ ที่กล่าวว่าระบบควร ต้องทำอะไรได้บ้าง เป็นเสมือน สัญญาหรือข้อตกลงระหว่างผู้พัฒนา กับผู้ว่าจ้าง เพื่อให้ทราบถึงขอบเขตใน การพัฒนา

6 Why we need Requirements? Top 2 factors in the failure of system development contracts to meet schedule or budget [SEI] –Inadequate requirements specification –Changes in requirements Top 3 causes of quality and delivery problems [Standish Group] –Lack of user input –Incomplete requirements –Changing requirements From ENFOCUS Solution 1/2

7 Why we need Requirements? Requirement development process is more important Through requirements development, your team gains a common understanding and agreement on what to build. เพื่อที่สามารถพัฒนา product ได้ถูก เสียเวลาทำ ดีกว่าพัฒนาผิดทาง 2/2

8 The SRS Focus the SRS on what the product is to do and avoid specifying how it will be designed and built. For TSPi, you will concentrate on the functional and operational requirements. –Functional requirements –External interface requirements –Design constraints –Attributes –Other requirements

9 Requirements Changes Users generally cannot know precisely what they need until they try to use the finished product. Thus the requirements almost always change, and they keep on changing until they are frozen in a product. Learn & Help the users define their needs in term of useful product function Agree on SRS that represents your common best understanding of what they needs.

10 Requirements Changes No free requirements change !!! (cost time and money) The SRS helps you to manage changes. After the customers have read the SRS and agreed with its contents, you can argue that any changes will cost time and/or money. SRS

11 Requirement Engineering Process From Aj.Amphol Kongkeaw

12 Requirements Elicitation From Aj.Amphol Kongkeaw

13 Requirements Elicitation Techniques One - on - one interview Group interview Facilitated session Joint application development (JAD) Questionnaire Prototype Use case Following people around Request for proposals (RFPs) Brainstorming

14 The principal steps of Requirements Elicitation Assess system feasibility Understand organization issues Identify system stakeholder Record requirement sources Assess business issues Define domain constraints Record requirement rationale Prototype poorly understood requirements Define usage scenarios Define operation processes

15 The Software Requirements Specification for TSPi Functional requirements Operational requirement To document the team’s agreement on the functions (inputs, output, calculations, use cases) and external interfaces (user, hardware, software, communications) requirements.

16 The Software Requirements Specification for TSPi Requirements Traceability Balance Workload

17 TSPi Requirements Scripts Entry Criteria Need Statement Review Need Statement Clarification Requirements Task Allocation Requirements Documentation System Test Plan Requirements and System Test Plan Inspection (INS) Requirements Update User SRS Review Requirement Baseline (CCR) Exit Criteria

18 Requirements Development Script TSPi Cycle 1 : Table 6.2 TSPi Cycle n: Table 6.3

19 Entry Criteria Development strategy Development plan

20 Need Statement Review The development manager leads the team in reviewing the product need statement and ensures that all questions are clarified among the team members or noted for discussion with the customer. (function & used)

21 Need Statement Clarification The development manager reviews the list of questions and the team’s clarification notes with the customer.

22 Requirements Task Allocation The development manager leads the team through outlining the SRS document and the work to produce it ； The team leader allocates the tasks among the team members and obtains commitments for when they will complete these tasks.

23 Requirements Documentation Each team member –Produces and reviews his or her portions of SRS document; –Provides these to the development manager. The development manager produces the SRS draft.

24 System Test Plan The development manager leads the team in producing and reviewing the system test plan. (The system testing is aimed at ensuring that the system does what you and the users agree it is supposed to do.)

25 Requirements and System Test Plan Inspection The quality/process manager leads the team through –Inspecting the SRS draft and system test plan –Identifying questions and problems –Defining who will resolve each question and problem and when –Documenting the inspection in form INS.INS

26 Requirements Update The development manager obtains the updated SRS and system test plan sections and -Combines them into a final SRS and system test plan ； -Verifies traceability to the need statement or other sources.

27 User SRS Review Have the end users read the SRS and agree that it describes what they want.

28 Requirements Baseline The support manager baselines an official SRS copy, which the team can now change only by using the change control procedure (form CCR).CCR

29 Exit Criteria The completed, inspected and updated SRS and system test plan under configuration control ； All personal time, defect and size data entered in the TSPi forms and support system (LOGT, LOGD, SUMS, TASK, SCHEDULE, SUMP, SUMQ) ； The completed inspection form (INS) from the requirements inspection ； Updated project notebook.

30 Requirement Phase Output SRS ที่สมบูรณ์ ผ่านการตรวจสอบ และ system test plan ภายใต้ configuration control ข้อมูลทั้งหมดที่เกี่ยวกับ personal time, defect และ size data ใน TSPi forms แบบฟอร์มรายงานผลการตรวจสอบที่สมบูรณ์จาก requirement inspection สำเนาของทุกๆ forms, SRS และ system test plan ใน project notebook