Lesson 1 - Elements of the Software Requirements Analysis Phase

1. Module 6Application of Software Acquisition Management (SAM) Surveillance toSoftware Requirements Analysis (SRA) Lesson 1 - Elements of the Software Requirements Analysis Phase Lesson 2 - Surveillance During Software Requirements Analysis

2. Module Objective • Distinguish activities within the Software Requirements Analysis phase given Software Acquisition Management (SAM) guidelines

3. What Will You Learn in This Module? • How to recognize elements of the Software Requirements Analysis (SRA) phase • How to use and evaluate the supplier Requirements Analysis processand products, using: • Process Reviews • Product Examinations • Formal Reviews and Audits • Data Collection and Analysis • Take Action as Appropriate

4. Lesson 1Elements of the Software Requirements Analysis Phase Objective: Identify elements of the Software Requirement Analysis phase

5. Lesson Objective • Identify elements of the Software Requirement Analysis phase

6. Systems and Software Engineering • Systems are made up of: • Hardware • Software • People • Software Engineering Process • Users needs are TRANSLATED into requirements • Requirements are TRANSFORMED into design • Design is IMPLEMENTED into code • Code is VERIFIED in testing

7. Software Life-cycle - V Diagram - -

8. Requirements Traceability Preliminary Software Design Detailed Software Design Coding and Unit Testing Coding and Unit Testing

9. System/Software Requirements Analysis

10. Software Requirements Analysis • Problem-solving step used to allocate system requirements to the software component of the system (breaking down a problem to smaller pieces) • Determines WHAT the software needs to do versus HOW the software will do it • Establishes the boundaries of the contracted software development effort and prepares the developers to design a solution in the next phase accounting acquisition activities analysis assessment audits baseline baselines board breakdown capability characteristic CMM CMMI commitment common community configuration consequence continuous contract control COP cost data DCMA defined derived development developmental DFAR document engineering event FAR feature federal field FRP functional generic goals group guidebook handling IDD identification independent initial instructions integrity interface likelihood managed management maturity measurement metric metrics milestone model moderate monitoring monitor package peer plan planned planning PLAS practice practices preliminary prioritized process product quantitatively RAMP random regulation representation reviews risk schedule SDD security SEPG software specific SQA SQE SRS staged status STP structure sub test traceable transformation validation verification WBS work

11. Software Requirements Analysis, Cont. • Typically results in: • Software/Interface Requirements Specification (SRS/IRS) • Specifies WHAT the software must do to solve the problem • Provides more technical detail • Used by the technical team • Ensures that we are building the right system

12. Software Requirements Analysis, Cont. • How does the customer get insight during the development? • Reviews that occur during this phase are: • Program Management Reviews • Technical Integration Meetings (TIMs) • Software Specification Review (SSR) • What is Defense Contract Management Agency (DCMA’s) support during these reviews? • Ensure entrance criteria are satisfied prior to review • Participate in reviews • Exit criteria (ensure action items and issues are dispositioned)

13. Question and Answer What three things make up a system? • Process, software, hardware • Hardware, plans, people • People, requirements, software • Hardware, software, people

14. Lesson Summary • Identified elements of the Software Requirements Analysis phase

15. Lesson 2Surveillance During Software Requirements Analysis Objective: Identify surveillance activities performed during the Software Requirement Analysis phase

16. Lesson Objective • Identify surveillance activities performed during the Software Requirement Analysis phase

17. Software Requirements • Using these techniques, the DCMA SP can evaluate the supplier’s performance of an effective Software Requirements process. • Process Reviews • Product Examinations • Formal Reviews and Audits • Data Collection and Analysis • Accept product

18. Software Requirements Analysis • What products/processes could the DCMA SP examine or review to prepare for this phase?

19. Process Reviews Software Reqs Management Process Peer Reviews Inspections and Audits Configuration and Data Management Risk Management Project Planning and Tracking What SPs Do During the Software Requirements Phase • Product Examinations • System Segment Specification (SSS) update • SRS, IRS • Software Requirements Traceability • Software Plans (Software Development Plan (SDP), Software Quality Assurance Plan (SQAP), Software Configuration Management Plan (SCMP), etc.) • Other Reqs Mgmt/Dev work products

20. Data Collection and Analysis Reqs Management Progress Cost/Schedule Defect Results Peer Review Results Requirements Stability/Volatility/Creep Staffing Take Action as Appropriate Corrective Action Requests (CARs) Continuous Improvement Plans (CIOs) Report to Customer What SPs Do During the Software Requirements Phase, Cont. • Formal Reviews and Audits(SSR) • Track and verify entrance criteria • Participate in review • Ensure exit criteria is satisfied • Ensure Action Items are dispositioned

21. CMMI Process Areas and Life-cycle Phases

22. SAM Surveillance Steps Note: Documentation occurs at all steps of the Software Acquisition Management (SAM) Surveillance Process (i.e., SSR Log and Standalone Documentation).

23. Replanning Triggers • Changes in risk from data analysis results • Significant changes in schedule • Change in staffing • Requirements creep • Noncompliance defects • Threshold exceeded

24. Question and Answer Process reviews include: Risk Management, Peer Reviews, and project planning and tracking. • True • False

25. Lesson Summary • Identified surveillance activities performed during the Software Requirement Analysis phase

26. Workshop Outline • For each life-cycle phase workshop: • Scenario and Statement of Work (SOW) of supplier activities during this phase • Plan, identify, and prioritize the activities students will perform to evaluate the elements in the templates • Students to give status and insights into cost, schedule, and technical performance • Analyze data and document

27. Things to Think About During the Workshop • Phase • What Phase Dependent/Independent Processes should be considered? • What is your criteria? • Review the contractual requirements (SOW, Contract Data Requirements List (CDRL), etc.) • Review the supplier plans, process and procedures • Capability Maturity Model Integration (CMMI) Helper Guide • What are you going to do??? • Process Reviews, Product Exams, etc.

28. Workshop 3

29. Workshop 3 • Products from the workshop • Partial Software Surveillance Plan (SSP) • Complete a Data Measure/Analysis MAS • SSR Log

30. Module Summary • Distinguished activities within the Software Requirements Analysis phase given SAM guidelines

31. Questions or Comments?