The document discusses requirements management (RM) best practices. It describes the goals of RM as eliciting stakeholder needs to develop clear requirements and administrating requirements tracking. It then outlines the key stages of RM - planning, elicitation, analysis, development, validation, acceptance, and administration. For each stage, it describes objectives, entry/exit criteria, activities, and techniques used. It emphasizes the importance of RM for reducing costs and defects.

1. SPIG-PD: PRODUCT DEVELOPMENT PROCESS Software Requirements Procedures I ntegrated S olutions F or P orts Mohamed M. Mobarak Business Integration Analyst Alexandria Port Automation

2. 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

3. 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

4. Software Requirements SPIG 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) ?

5. 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.

6. Example: Levels of Requirements WHAT Requirements Management (RM) ? BUSINESS USER FUNCTIONAL 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

7. RM Process Goals Goal 1: Project stakeholders’ needs, expectations, constraints, and interfaces are elicited, analyzed, and stated as clear requirements, which are refined and elaborated to develop validated SRS WHAT Requirements Management (RM) ? Goal 2: Requirements are administrated and tracked to all product components during project phases

8. WHAT Requirements Management (RM) ?

9. 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

10. 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) ?

11. 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) ?

12. Risks Associated with Requirements 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) ?

13. Why Should I care? Fewer requirements defects Reduce development rework Fewer unnecessary features Lower enhancement costs Faster development Fewer miscommunications Reduced scope creep Reduced project Chaos More accurate system testing estimates High customer and team members satisfaction WHY Requirements Management (RM) ? Project Closure تسليم المشروع & Customer Satisfaction

14. 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

15. Analyst Role & Stakeholders HOW Requirements Management (RM)? 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

16. The Analyst Tasks & Skills HOW Requirements Management (RM)? 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

17. 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

18. 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] Requirements Administration Planning Elicitation Analysis Development Validation Acceptance Initial Planning Monitoring & Control

19. Entry & Exit Criteria HOW Requirements Management (RM)? [Planning] 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

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

21. Process Activities (Cont.) Risks to the project development should be identified and assessed Market Competition/ Timing/ User Acceptance/ Implementation Issue Review the plan to reach consensus on its contents. Communicate the plan to the customer and make needed updates. Review the elicitation plan. Add output to the CM repository. Monitor the progress. Approve the outputs of the procedure Funding Resource for the plan deployment HOW Requirements Management (RM)? [Planning]

22. 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

23. 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] Requirements Administration Planning Elicitation Analysis Development Validation Acceptance Initial Planning Monitoring & Control

24. Entry & Exit Criteria HOW Requirements Management (RM)? [Elicitation] 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

25. Process Activities Acquire the application domain knowledge. Identify candidate functional and non-functional requirements with its rationale (if possible). Requirements may be arbitrary broken into sub-groups to facilitate collection. Record requirements in Req. DB and procedures to establish RTM (DOC: Requirements Management ). Review the documented requirements. Monitor the progress. Approve the outputs of the procedure HOW Requirements Management (RM)? [Elicitation]

26. 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]

27. Are we done yet? Perhaps we are done if: The user can’t think of any more use cases. Users proposed new use cases you have already covered by other use case. User repeat issues covered in previous discussions Suggested new features, functions, requirements are all out of scope. Proposed new requirements are all low priority. HOW Requirements Management (RM)? [Elicitation]

28. 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

29. 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] Requirements Administration Planning Elicitation Analysis Development Validation Acceptance Initial Planning Monitoring & Control

30. Entry & Exit Criteria HOW Requirements Management (RM)? [Analysis] 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

31. Process Activities Examine requirements to classify the difficulties and risks. Assess risks and prioritize requirements. Review and identify traceability Negotiate conflicts with stakeholders. Communicate with customer and solve any issue Conduct peer review Conduct QA audit and CM activities Monitor the progress. Approve the outputs of the procedure HOW Requirements Management (RM)? [Analysis]

32. 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

33. 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] Requirements Administration Planning Elicitation Analysis Development Validation Acceptance Initial Planning Monitoring & Control

34. Entry & Exit Criteria HOW Requirements Management (RM)? [Development] Entry Criteria (OR): Clear Traceable Requirements Approval Rework from Requirements Validation Calling from Requirements Administration Exit Criteria: Clear Traceable Requirements Input: Approved Clear Traceable Requirements Output: Updated RTM Approved SRS Requirements Development Procedure

35. Process Activities Review the available traceable requirements to gain understanding of requirements. Develop and document precise (function/ non-functional) specification. Develop and document any further related customer specs. Develop and document precise (User interface/ SW and HW interface) Develop and document precise list of associated product documentation materials. Develop an document precise Acceptance criteria Develop and documents any other required information HOW Requirements Management (RM)? [Development]

36. Process Activities – (Cont.) Update the Traceability matrix Conduct peer review Conduct QA audit and CM activities Monitor the progress. Approve the outputs of the procedure (DOC: Software Requirements Specification - SRS ). HOW Requirements Management (RM)? [Development]

37. 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]

38. 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

39. 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] Requirements Administration Planning Elicitation Analysis Development Validation Acceptance Initial Planning Monitoring & Control

40. Entry & Exit Criteria HOW Requirements Management (RM)? [Validation] 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

41. Process Activities Assess SRS to ensure SRS meets its required qualities Confirm traceability Document findings in a deficiency report Assess the reported defect to classify and assign priorities. Delegate defects that have to be corrected Correct the delegated defects and report the type of the defect. Close the corrected defect Conduct peer review Conduct QA audit and CM activities Conduct functional/physical configuration audit Baseline all planning outputs HOW Requirements Management (RM)? [Validation]

42. Process Activities (Cont.) Monitor the progress. Approve the outputs of the procedure (DOC: Requirements Management ). (DOC: Software Requirements Specification - SRS ). HOW Requirements Management (RM)? [Validation]

43. Validation Techniques Peer Review Prototyping Model Validation HOW Requirements Management (RM)? [Validation]

44. 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

45. 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] Requirements Administration Planning Elicitation Analysis Development Validation Acceptance Initial Planning Monitoring & Control

46. Entry & Exit Criteria HOW Requirements Management (RM)? [Acceptance] 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

47. Process Activities Present baselined requirements, SRS and associated measurements to senior management. Obtain customer approval of the baselined requirements. Go through the formal change management process and requirements administration process id any modifications are needed. Monitor the progress HOW Requirements Management (RM)? [Acceptance]

48. 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

49. Requirements Administration Procedure Objective Ensure that all requirements are traceable and under control The procedure is needed when any changes to the approved SRS occur. HOW Requirements Management (RM)? [Admin.] Requirements Administration Planning Elicitation Analysis Development Validation Acceptance Initial Planning Monitoring & Control

50. Entry & Exit Criteria HOW Requirements Management (RM)? [Admin] Entry Criteria: Change Request Approval Exit Criteria: Close Change Request Approval Input: Approved Change Request Requirements Database Baselined RTM Approved baselined SRS Output: Approved Close Change Request Requirements Administration Procedure

51. Process Activities Use Requirements Planning Procedure Use Requirements Elicitation Procedure Use Requirements Analysis Procedure Use Requirements Development Procedure Use Requirements Validation Procedure Use Requirements Acceptance Procedure Close the change request Monitor the progress Approve the output of the procedure HOW Requirements Management (RM)? [Admin]

52. 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

53. Three Categories of Req. Best Practices Requirements Engineering Best Practices Knowledge The Requirements Process Project Management

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

55. Requirements Engineering Best Practices (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

56. (2) The Requirements Process (Cont.) Analyze feasibly Create data dictionary Create prototypes Define acceptance criteria Requirements Engineering Best Practices

57. (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

58. Thanks For Your Attention Any Questions ?