1. CC20O7N - Software Engineering 1 CC2007N Software Engineering 1 Requirements Engineering Practices with Techniques

2. CC20O7N - Software Engineering 1 AGENDA WHAT Requirements Management (RM)? WHY Requirements Management (RM)? HOW Requirements Management (RM)? – Requirements Planning – Requirements Elicitation – Requirements Analysis – Requirements Development – Requirements Validation – Requirements Acceptance – Requirements Administration Requirements Engineering Best Practices 2

3. CC20O7N - Software Engineering 1 Software Requirements Definition Requirements are the basis for design and the whole product development process. IEEE Standard Definition –A condition or capability needed by user to solve a problem to achieve an objective. –Condition or capability that must be met or processed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. –A document representation of a condition or capability as in 1 or 2. WHAT Requirements Management (RM) ? 3

4. CC20O7N - Software Engineering 1 Levels of Requirements WHAT Requirements Management (RM) ? BUSINESS USER FUNCTIONAL Functional Non-Functional Business Req. Statement Of Work (SOW), RFP Vision & scope document Project charter Market Req. Doc. Functional Req. User Req. Use cases Scenario descriptions. Software Requirements Specs ( the system shall ……. ) Business Rules Quality Attributes External Interfaces Constraints System Req. 4

5. CC20O7N - Software Engineering 1 Example: Levels of Requirements BUSINESS USER FUNCTIONAL 5 In a word processing program: –Find spelling errors. –Add word to global dictionary. –The spell checker shall find & highlight misspelled words. –The spell checker shall display a dialog box with suggested replacements. –The Spell checker shall have the capability to replace the misspelled word globally. –The word processor includes a “Spell Checker”. – The program will allow users to correct spelling in document efficiently

6. CC20O7N - Software Engineering 1 Implications of Bad Requirements Rework.. Rework.. Rework - Cost of rework: 30% to 50% of development cost - 70% to 85% of rework cost come from requirements errors - 80-80 syndrome: the project is 80% complete 80% of the time WHY Requirements Management (RM) ? 6

7. CC20O7N - Software Engineering 1 Characteristics of Good Requirements Complete - Each requirement must fully describe the functionality to be delivered Correct - Each requirement must accurately describe the functionality to be built Feasible - It must be possible to implement the functionality Necessary - Each requirement should document a capability that is really needed Prioritized - Assign priorities to respond to budget cuts, time, … Unambiguous - All readers must arrive to the same understanding Verifiable - Can be tested, inspected, reviewed, … WHY Requirements Management (RM) ? 7

8. CC20O7N - Software Engineering 1 Risks Associated with Requirements 8 Requirements gathering and elicitation are not planned Suitable stakeholders are not involved in the elicitation phase Requirements are not documented or well analyzed Inexperience, lack of training of the requirements engineering team Difficulty in defining requirements. Requirements specifications are not well defined and not well validated Requirements and their changes are not accepted by customer and senior management WHY Requirements Management (RM) ?

9. CC20O7N - Software Engineering 1 Analyst Role & Stakeholders HOW Requirements Management (RM)? 9 Req. Producers Req. Consumers Project Sponsor (Customer)Project Management User Representative Development Testing Other Stakeholders Size and complexity Business Requirements User Requirements Exceptions and constraints Functional and non functional requirements Functional and non functional requirements

10. CC20O7N - Software Engineering 1 The Analyst Tasks & Skills HOW Requirements Management (RM)? 10 SOFTWARE REQUIRMENTS TASKS Define Identify stakeholders and user classes Elicit Analyze Write SRS Model Validate Prioritize Manage & Administrate SKILLS Listening Interview and questioning Analytical Facilitation Observation Writing Organization Modeling Interpersonal Creativity

11. CC20O7N - Software Engineering 1 Requirements Planning Procedure Objective - Guide the enactment of the requirements elicitation process -Establishing an agreement among project stakeholders:  Roles and responsibilities.  Deployment Schedule HOW Requirements Management (RM)? [Planning] 11 Requirements Administration PlanningElicitation Analysis Development Validation Acceptance InitialPlanningMonitoring & Control

12. CC20O7N - Software Engineering 1 Entry & Exit Criteria HOW Requirements Management (RM)? [Planning] 12 Entry Criteria (OR): Partial PMP Approval Rework from Requirements Elicitation Procedure Exit Criteria: Requirements Elicitation Plan Approval Input: Request for proposal (RFP) Proposal (and Pre-Sales Documents) Statement of Work (SOW) (Project initiation documents) Approved partial PMP Historical Database Output: Approved Requirements Elicitation Plan Requirements Planning Procedure

13. CC20O7N - Software Engineering 1 Process Activities 1.Assign a person to engineer and manage requirements for the project. 2.Review the given “Problem Description” to gain understanding of the required product. 3.Identifies the individuals and/or groups with a stake in the success of the project  Favored/ Un-favored/ Ignored User Classes 4.Identify acceptance criteria and document acceptance criteria for requirements elicitation procedures. 5.Develop a plan for requirements elicitation and document it (DOC: Requirements Elicitation Plan)Requirements Elicitation Plan HOW Requirements Management (RM)? [Planning] 13

14. CC20O7N - Software Engineering 1 Requirements Elicitation Procedure Objective - Discover and capture candidate software requirements (both functional and non-functional) by communicating with the customer and/or end users and others who have stake in the system development HOW Requirements Management (RM)? [Elicitation] 14 Requirements Administration PlanningElicitation Analysis Development Validation Acceptance InitialPlanningMonitoring & Control

15. CC20O7N - Software Engineering 1 Entry & Exit Criteria HOW Requirements Management (RM)? [Elicitation] 15 Entry Criteria: Requirements Elicitation Plan Approval Exit Criteria: Approved Candidate Requirements Input: Approved Requirements Elicitation Plan Output: Candidate Requirements Approval Requirements Planning Requirements Elicitation Procedure

16. CC20O7N - Software Engineering 1 Elicitation Techniques  Interactive –Interviews –Elicitation workshops (Facilitated meetings)  Tips: Establish ground rules/ Stay in Scope/ Time-box discussion/ Keep team small and include right participants/ Keep everyone engaged/ Talk Once Comment Once Technique. –Focus Groups  Passive –Prototypes –Scenarios –Observations HOW Requirements Management (RM)? [Elicitation] 16

17. CC20O7N - Software Engineering 1 Requirements Analysis Procedure Objective -Further understand the requirements to solve conflicts and inconsistencies and to ensure that they meet the required quality attributes and reflect the customer needs. -Repeated procedure until an agreement is reached HOW Requirements Management (RM)? [Analysis] 17 Requirements Administration PlanningElicitation Analysis Development Validation Acceptance InitialPlanningMonitoring & Control

18. CC20O7N - Software Engineering 1 Entry & Exit Criteria HOW Requirements Management (RM)? [Analysis] 18 Entry Criteria (OR): Baselined Project Management Plan Rework From Requirements Development Rework from Requirements Validation Calling from Requirements Administration Exit Criteria: Clear Traceable Requirements Input: Approved Candidate Requirements Output: Approved Clear Traceable Requirements Requirements Analysis Procedure

19. CC20O7N - Software Engineering 1 Process Activities 1.Examine requirements to classify the difficulties and risks. 2.Assess risks and prioritize requirements. 3.Review and identify traceability 4.Negotiate conflicts with stakeholders. 5.Communicate with customer and solve any issue 6.Conduct peer review 7.Conduct QA 8.Monitor the progress. 9.Approve the outputs of the procedure HOW Requirements Management (RM)? [Analysis] 19

20. CC20O7N - Software Engineering 1 Requirements Development Procedure Objective -Transform identified requirements into a formal software requirement specification (SRS), which is used to communicate requirements among all stakeholders. HOW Requirements Management (RM)? [Development] 20 Requirements Administration PlanningElicitation Analysis Development Validation Acceptance InitialPlanningMonitoring & Control

21. CC20O7N - Software Engineering 1 The SRS Audience –Customers –Project Managers –Software development team –The testing group –Maintenance ad support staff, –Documentation writers –Training personnel –Legal staff ensure –Subcontractor HOW Requirements Management (RM)? [Elicitation] 21

22. CC20O7N - Software Engineering 1 Requirements Validation Procedure Objective -Ensure that the developed SRS reflects the customer requirements. -Process involves communicating the SRS to all stakeholders and facilitating agreement among them HOW Requirements Management (RM)? [Validation] 22 Requirements Administration PlanningElicitation Analysis Development Validation Acceptance InitialPlanningMonitoring & Control

23. CC20O7N - Software Engineering 1 Entry & Exit Criteria HOW Requirements Management (RM)? [Validation] 23 Entry Criteria (OR): SRS Approval Calling from Requirements Administration Exit Criteria: Requirements Baselined Requirements Development Rework Requirements Analysis Rework Input: Updated RTM Approved SRS Output: Baselined SRS & RTM Requirements Validation Procedure

24. CC20O7N - Software Engineering 1 Process Activities 1.Assess SRS to ensure SRS meets its required qualities 2.Confirm traceability 3.Document findings in a deficiency report 4.Assess the reported defect to classify and assign priorities. 5.Delegate defects that have to be corrected 6.Correct the delegated defects and report the type of the defect. 7.Close the corrected defect 8.Conduct peer review 9.Conduct QA audit and CM activities 10.Conduct functional/physical configuration audit 11.Baseline all planning outputs HOW Requirements Management (RM)? [Validation] 24

25. CC20O7N - Software Engineering 1 Process Activities (Cont.) 12.Monitor the progress. 13.Approve the outputs of the procedure (DOC: Requirements Management).Requirements Management (DOC: Software Requirements Specification - SRS).Software Requirements Specification - SRS HOW Requirements Management (RM)? [Validation] 25

26. CC20O7N - Software Engineering 1 Validation Techniques  Peer Review  Prototyping  Model Validation HOW Requirements Management (RM)? [Validation] 26

27. CC20O7N - Software Engineering 1 Requirements Acceptance Procedure Objective -Confirm that the baseline requirements reflect the project’s acceptance criteria -This process can be used as a milestone to report progress to the customer and senior management HOW Requirements Management (RM)? [Acceptance] 27 Requirements Administration PlanningElicitation Analysis Development Validation Acceptance InitialPlanningMonitoring & Control

28. CC20O7N - Software Engineering 1 Entry & Exit Criteria HOW Requirements Management (RM)? [Acceptance] 28 Entry Criteria (OR): Requirements Baselined Calling from Requirements Administration Exit Criteria: Customer and Senior Management Acceptance Input: Baselined SRS and RTM Measurement Data Output: Accepted Baselined Requirements Requirements Acceptance Procedure

29. CC20O7N - Software Engineering 1 Three Categories of Req. Best Practices Requirements Engineering Best Practices 29 Knowledge The Requirements Process Project Management

30. CC20O7N - Software Engineering 1 (1) Knowledge - Train requirements analysts. - Educate user representatives and managers about requirements. - Create a glossary Requirements Engineering Best Practices 30

31. CC20O7N - Software Engineering 1 Requirements Engineering Best Practices 31 (2) The Requirements Process - Define a requirements process -Adopt Software Requirements Specs (SRS) template -Create requirements traceability matrix (RTM) -Validate Requirements -Baseline and manage version of requirements -Measure requirements and track its status -Establish change control board (CCB) with a defined process -Identify user classes -Hold facilitated elicitation workshops -Observer users performing their jobs -Reuse requirements

32. CC20O7N - Software Engineering 1 (2) The Requirements Process (Cont.) -Analyze feasibly -Create data dictionary -Create prototypes -Define acceptance criteria Requirements Engineering Best Practices 32

33. CC20O7N - Software Engineering 1 (3) Project Management - Select appropriate life cycle -Best plans on requirements -Renegotiate commitments -Manage requirements risks -Track requirements effort -Review past lessons learned Requirements Engineering Best Practices 33