The Value of an Organizational Requirements Working Group

1. The Value of an Organizational Requirements Working Group Dr. Ralph R. Young Director, Systems and Software Process Engineering Litton PRC young_ralph@prc.com Third International Conference on Practical Software Quality Techniques (PSQT ‘98) October, 1998

2. Briefing Agenda • Background: Software at PRC • Key Elements of the PRC SPI Program • PRC Requirements Working Group (RWG) • Formation • Goals, Strategies, and Early Activities • Evolving Role of the RWG • PRC Requirements (RE) Process • Deployment/Implementation/Institutionalization • FY98 RWG Mission & Goals • The Value of an Organizational Working Group • Lessons Learned

3. Background: Software at PRC • Customers and Primary Markets: • Criminal Justice, Defense, Document Management, Education, Electronic Commerce, Command and Control, Health, Intelligence, Legacy Systems, Transportation, and Weather • Staff: 2889 computer/engineering, approx. 5500 total • Core competencies: • Systems Integration, System/Software Engineering, Complex Document Imaging, Computer Aided Dispatch, Enterprise Implementation, SETA Support and Life Cycle Support

4. Reusable Corp/Sector Processes (PRC PAL) Input Defect Prevention (action on the process) Processes are: • Desktop accessible • Supported with tools • Bid with proposal Process Output SPI Mission and Vision Mission: To reduce the life-cycle costs of PRC software development, while increasing software quality and programmer productivity Management Guidance – “Software Processes shall be: Defined ...Documented ...Trained ...Implemented ...Measured ...Refined.”

5. Customers & Markets Products & Services SW Engineering Methods & Tools Related Core Competencies Diverse & Dynamic HW, OS, Compilers, DBMS, Etc Project Size SW Life Cycle Stages Repeatable and Defined Organizational SW Processes Management Engineering Organizational Challenge!Diversity of Software Engineering Activities vs. Need for Repeatable, Defined Processes

6. Key Elements of the PRC SPI Program • Industry Standard Models • Institutionalized TQM Method • Organizational EPG Infrastructure • Continuous Investment in SPI since 1993 • SEI Level 3 Maturity Rating Strong Management Commitment

7. Optimized - Level 5 Continuously Process Change Management Improving Technology Change Management Process Defect Prevention Managed - Level 4 Predictable Software Quality Management Quantitative Process Management Process Defined - Level 3 Peer Reviews Intergroup Coordination Standard Software Product Engineering Integrated Software Management Consistent Training Program Organizational Process Definition Practice Organizational Process Focus Repeatable - Level 2 Disciplined Software Configuration Management Process Software Quality Assurance Software Subcontract Management Software Project Tracking and Oversight Software Project Planning Requirements Management Initial - Level 1 The Capability Maturity Model (CMM) Provides a Standard

8. Quality Improvement Provides a Method QI Teams follow the 7-step problem solving process called the QI Story QIDW incorporates Process Management - Statistical Process Control Priority Management QI Quality Quality These principles support the necessary cultural change In Teams Daily Work Customer Satisfaction P-D-C-A Management By Fact Respect for People Plan-Do-Check-Act

9. Organization and Infrastructure for SPI PRC QMB Technology EPG Working Group Leaders Full-Time Staff Support Metrics, RWG, others PRC EPG At-Large Membership QITs Project Representation Phoenix I, II, III, N Sector EPGs Core Competency Representation Systems Services IIS SW, PM Site/Dept/Project EPGs

10. PRC’s SPI Investment • Approximately $1 million per year since 1993 • Full-time SEPG support for process definition, etc. • Phoenix teams, Metrics Lead team, working groups (e.g., RWG) • SEPG Infrastructure (Systems) • Development, acquisition, and support of SPI tools (including the Web-based Process Asset Library [PAL]) • SPI training development, seminars and symposia, handbooks, and assessments • $470 per software engineer vs. industry median at $1375 (per SEI)

11. Requirements Working Group (RWG) Formation • A Requirements Management (RM) Process was defined in 1994 • Compliant with the CMM for Software (SW-CMM) • PRC desired to have its process reflect a full life cycle approach and be compliant with the Systems Engineering CMM (SE-CMM) • PRC Systems Engineering Lead Team (SELT) evolving SE Maturity • The organizational culture suggested use of a QI Team composed of project requirements engineers to update the RM Process • Lead Team Authority: PRC EPG • Team Leader: a PRC Process Engineer and member of the SELT • First meeting: March, 1997

12. RWG Goals and Strategy • Initial Objective: Update the RM Process • Strategy: • RWG membership open to anyone who wanted to participate • Participation from known project requirements engineers was encouraged • Participants provide the guidance; Team Leader does the legwork • Meetings held weekly • Lunchtime “Brown Bags” (i.e., an overhead charge number was not provided) • Utilize actual project experience to improve the process

13. RWG Goals and Strategy(continued) • Goal: Satisfy SE-CMM requirements for: • PA06 Understand Customer Needs and Expectations • PA02 Derive and Allocate Requirements • Project focus • Provide an updated process by end of FY97 (7/31/97) to support SELT FY97 objectives • RWG members available to assist other projects

14. RWG: Initial Activities • High level of interest on the part of several project requirements engineers: wanted to lend their experience and expertise to improve PRC’s process • Good participation in weekly meetings • Individual participation varied depending upon project priorities • Team Leader provided: • Familiarization with the existing RM Process • Familiarization with SE-CMM PA06 and PA02 requirements • Copies of articles reflecting industry best practices • Agendas, motivation, e-mail reminders of meetings, encouragement, nagging, coordination with PRC EPG, SELT, PM EPG, Sector EPGs

15. Maintaining Momentum • Because of a high level of project responsibilities, some RWG participants experienced conflicts in making time for RWG Meetings. Solution: drive on with whoever can make the meeting -- keep going! • Team Leader: • Stressed the importance of the RWG effort to PRC’s business objectives • Emphasized an awareness of the importance of requirements to project success (based on a review of industry literature) • Worked between meetings to develop RWG products • Kept PRC EPG infrastructure aware of RWG efforts and products • Arranged for formal recognition of RWG members • The RWG effort helped evolve our KPA/PA “Process Owner Responsibilities”

16. Evolving Role of the RWG • Recommended an updated (and expanded) PRC Policy concerning requirements • Process and other artifacts/assets • Maintained the Web pages for the RM KPA • Created Web pages for the related SE-CMM PAs • Recommended methods for each part of the process • Invited vendors to provide demos, resulting in suggested tools • Suggested metrics (quality indicators for the products; process indicators for the processes) • Collaboration with the SEI’s “Transistion Packages Initiative:” • Provided PRC artifacts to the SEI for links on its Web site • Joint meetings to help the SEI develop a prototype

17. Evolving Role of the RWG(continued) • Developed training materials for the “PRC Requirements Course” (10 hours) • Provided tailoring guidance • Comparison of the old process with the new • Draft template for a Project Requirements Policy • Identify industry best practices and best of breed methods • Acronyms • References • Proposal support materials • Web-based transition package at PRC including all of the above, plus links to project deployments of the “PRC RE Process” (currently 8 project links are active)

18. The PRC Requirements Process • Defined in a process flow chart and a Process Description (a completed or filled-in DID) for: • Macro: REOOO PRC Requirements (RE) Process • Full life cycle requirements activities • Micros: • RE100 Assess new/changed requirements and control changes • RE200 Understand customer needs and expectations (PA06) • RE300 Derive and allocate requirements (PA01) • With lots of attention to: • Who are the customers of this process? • What are their “Customer Valid Requirements?” • Mechanisms to facilitate effective implementation • Narrative to describe the purpose, intent, entrance criteria, inputs, outputs, exit criteria, responsibilities, tasks

19. Key (Essential) Products for Definition of a PRC Process • Organizational policy • Process (flow chart) • Process description (narrative per DID) • Recommended methods • Suggested tools • Tailoring guidance • Training

20. Consideration of Tools • Our experience is that development of a process is facilitated by implementation of an effective automated tool. • Provide formal vendor training so that the tool can be used effectively • Facilitate relationships with vendors so that brown bags, demos, and evaluation copies are provided as needed

21. Deployment/Implementation/Institutionalization • Work with Proposal Managers, Project Managers, and engineers to encourage use of the process (deployment) • Consider a Web-based corporate process asset library with links to project instantiations (and peer pressure!) • Proposals are a great place to start! • Brief the Process Improvement (PI) infrastructure concerning the availability of artifacts • Members of the RWG can lend their experiences to assist and advise concerning implementation • Capture success stories (where the process and the tool have helped a project) and publicize • Advocates and sponsors are very helpful in achieving institutionalization

22. Gaining Buy-in • How many times we have learned: • Involve early those we need to make it happen! • Identify management advocates and supporters and enlist their help • Utilize RWG members to help educate and inform

23. Results • Artifacts are available on the Web • Process has been used on 8 projects to date • Achieving repeatable processes • Saves time and money • Gets the job done in an improved manner • Allows continuous improvement (feedback from projects to further strengthen and improve the process) • Engineers familiar when they move to new projects • Increase in use of automated requirements tools (4 projects) • RWG desires to further facilitate PRC business objectives

24. FY98 RWG: Mission and Objectives Mission: To lead efforts to institutionalize the PRC Requirements Process. Objectives: 1. Encourage deployment and implementation of the PRC RE Process, and achieve active participation and use of the process by PRC Projects. 2. Maintain involvement and feedback from projects using the RE Process. 3. Determine a way to measure the benefits of using the process. 4. Provide an explanatory document describing the benefits of using the process. 5. Update the process based on inputs, suggestions, and project tailoring (continuous improvement). 6. Provide the capability for proposals to utilize/propose the process (provide sample write-ups, presentation slides, etc.).

25. FY98 RWG: Mission and Objectives Objectives (continued): 7. Prepare a "Work Plan" to facilitate project use of the Requirements Process artifacts, in particular, to help projects just starting with how to proceed (what to do first, then next…etc.) and how to utilize the artifacts which are provided in the RE Process Transition Package. 8. Sponsor Brown Bags on methods, tools, and technologies. Consider sponsoring training as needed. 9. Provide instructional sessions concerning methods that are recommended to support the process. 10. Review, study, and make available for PRC exceptional materials from the requirements literature. 11. Participate in learning sessions with industry experts.

26. The Value of an Organizational Working Group • Allows the organization to benefit from the experience of its projects and the expertise of key staff members • Seeds the organization with persons who share a common body of knowledge and who have come into consensus on key topics • Members provide a resource to the remainder of the organization • Facilitates use of the developed knowledge and artifacts for use in winning new business (proposals, lead marketing briefings, etc.) • Encourages a common way of doing things; supports repeatability and reuse • Encourages and facilitates selection of appropriate methods and tools as well as their deployment and implementation • Encourages us to measure the effectiveness of the process and the benefits of institutionalization • Allows participation in industry leading-edge efforts (transition packages)

27. Lessons Learned-Organizational • Involvement of Project Personnel and Management is critical • Establish an organization-wide approach and infrastructure for process, QI, and customer satisfaction • Build a Knowledge-Sharing Environment • Maintain and Demonstrate Management Commitment • Continuous Improvement • Both an act and an attitude • An environment of trust and openness

28. Lessons Learned-RWG Specific • Need for committed, ongoing staff support • Maintain momentum • Provide acknowledgement and recognition • Be proactive in deployment • Be available to help/advise/sympathize • Benefit from industry experience (read and synthesize) • Be persistent • Share information learned at conferences • Keep the PI infrastructure informed and updated • Provide training--on the process and for tools

29. References Sommerville, Ian and Sawyer, Pete, Requirements Engineering: A Good Practice Guide. Wiley & Sons, 1997. IEEE Software, March/April 1998, focus on requirements engineering. McCarthy, Jim, Dynamics of Software Development. Microsoft Press, 1995. Kar, Pradip and Bailey, Michelle, “Characteristics of Good Requirements. INCOSE. Stevens, Richard and Putlock, Gary, “Improving Requirements Management.” INCOSE INSIGHT, Summer, 1997. Quality Systems & Software Web site http://www.qssinc.com/ has various articles on the subject of requirements. Pressman, Roger S., Software Engineering: A Practitioners Approach (Fourth Edition), McGraw-Hill, 1997. See also the R.S. Pressman & Associates, Inc. Web site http://www.rspa.com/ McConnell, Steve, Software Project Survival Guide. Microsoft Press, 1998. See also his Web site http://www.construx.com/ and another book, Rapid Development: T Wild Software Schedulers. Microsoft Press, 1996.

30. References (continued) Gilb, Tom (authoring on Evolutionary Development (EVO), Requirements-Driven Management, and Inspections), Principles of Software Engineering Management. Addison Wesley, 1988. See also http://ourworld.compuserve.com/homepages/KaiGilb/. Rechtin, Eberhardt and Maiev, Mark W., The Art of Systems Architecting. CRC Press, 1997. Grady, Jeffrey O., System Requirements Analysis. McGraw Hill, Inc., 1993. Litton PRC, Phoenix Software Process Improvement Reference Guide (Fourth Edition), April, 1996. Hooks, Ivy, “Guide for Managing and Writing Requirements.” 1994. Software Engineering Institute (SEI) Capability Maturity Model for Software(SW-CMM), Version 1.1. Carnegie Mellon University, February, 1993. Litton PRC Requirements Process, 1997. Systems Engineering Capability Maturity Model (SE-CMM), Version 1.1. Enterprise Process Improvement Collaboration (EPIC), November, 1995.