Requirements Analysis INCOSE Systems Engineering Boot Camp Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering Defense Enterprise Solutions Northrop Grumman Information Technology ralph.young@northropgrumman.com (703) 556-1030

INCOSE Systems Engineering Boot Camp Things I’ve Noticed From My Requirements Engineering Experience Information and guidance concerning effective requirements practices is available but is not applied by most Project Managers. Although the requirements engineering process is a full system life cycle process, a lot of the issues and problems are created in the requirements gathering activities. Therefore, in my opinion, we can save a lot of time by addressing this area more effectively. Industry data supports this view. Further, doing a better job in requirements elicitation reduces rework downstream. Rework = 45% of total project effort industry wide. The requirements are often unknowable at the inception of many systems and projects. We need to recognize this and deal with it. Tools don’t obviate the need for people, a requirements process (in all situations), effective practices, and formal training. Customer involvement throughout the project is essential. An incremental development approach works best when the requirements are evolving and changing.

Practices, Methods, Techniques, and Tools That May Be New, Different, and Especially Important Create or tailor a requirements process. Use effective requirements practices, tailored as needed to the size and scope of the project, e.g.,: a “joint team;” defining the “real requirements;” iterating the requirements and architecture repeatedly; achieving effective communication; and use your requirements process and practice continuous improvement. Consider having an organizational requirements working group. Consider time-boxes to set limits on prototype iterations. Consider Requirements Based Product Development (RBPD) utilizing an effective automated requirements tool. Have an organizational center of excellence to enable and empower your organization, e.g.: requirements and architecture working groups a process improvement group organizational “process owners” an electronic process asset library to share and reuse artifacts

Establishing the partnership: User / Establishing the Partnership: User/Customer Responsibilities Know what is needed Know why it is needed Provide information to help others know what you know Document your assumptions Prioritize requirements Be reasonable Be timely

Developer and Customer Tasks Provisional & final acceptance Acceptance, integration & verification Informing the enterprise Detailed design & component development Storing and using knowledge from previous projects Developer work Architectural System design Amount of effort User requirements requirements Customer work Defining Defining what Optimizing Deciding Linking Qualifying Verifying results the system the cost- on potential deliverables the & validating for users must do benefits changes to requirements design the product

Goals of Good Requirements Practitioners Identify incorrect assumptions Ensure consistency Increase compliance Reduce misunderstandings between organizations and individuals Improve the responsiveness of suppliers Improve the satisfaction of all customers Write good requirements

Characteristics of Effective Requirements Analysts An attitude of continuous improvement and commitment to meet customers real needs. Good listener, communicator, and writer. Commitment to learning, applying, and using improved practices and methods, and to project success. Proactive in engaging co-workers, project management, customers, and users. Expert knowledge of requirements engineering and requirements practices. Ability to estimate the resources and time required to accomplish technical work. Takes responsibility for her/his views, attitudes, relationships, and actions. Maintains focus on keeping the main thing the main thing. Persevering. Maintains a good knowledge of evolving technology and how it can be applied to meet customer needs. Sets achievable goals and meets them. Desires to "make a difference" in his/her professional work. Good facilitation skills. Ability to "think outside the box" to provide creative approaches that might not occur to people who are close to the problem and the legacy system.

What Drives Requirements Regulations Higher Level Specifications Standards What Drives Requirements Customer & User needs & expectations Constraints costs schedules technical viability Existing systems & processes

Before You Write Requirements You Write Requirements Perform the up-front process Assemble and educate the team Define documents Define outline (checklist) Plan for change

Up-front Process Determine drivers Understand customer needs and environment Understand and document the scope of your project Define external interfaces Define system components Define specifications outline

Types of Requirements Errors

Criteria for a Good Requirement Each individual requirement should be: Correct – Technically and legally possible Complete – Express a whole idea or statement Clear – Unambiguous and not confusing Consistent – Not in conflict with other requirements Verifiable – Can be determined to meet the requirement Traceable – Uniquely identified and can be tracked Feasible – Accomplished within cost and schedule Modular – Can be changed without excessive impact Design independent – Does not pose a specific implementation solution

Effective Requirements Practices Commit to the approach. Establish and utilize a Joint Team to be responsible for the requirements. Define the real customer needs. Use a requirements process and continually improve it. Iterate the system requirements and the system architecture repeatedly. Use a mechanism to maintain project communication between and among all engineering groups throughout the development effort. Select familiar methods and maintain a set of work products that collectively comprise the current requirements specification. Perform requirements verification and validation. Provide an effective mechanism to accommodate changes in requirements during system life cycle development. Perform the development effort using known familiar proven industry, organizational, and project best practices.

The Value of an Organizational Requirements 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 (such as transition packages, AKA “Jump Start Kits” Consider initiating one in your organization

The CMMI SE/SW High Level Summary 1 - Initial Heroes 2 - Managed Project management Configuration Management Requirements Mgmt Project Monitoring & Control Project Planning Supplier Agreement Management Measurement & Analysis Process & Product Quality Assurance 3 - Defined Engineering process Decision Analysis & Resolution Risk Management Integrated Project Management Validation Organizational Training Verification Organizational Process Definition Product Integration Organizational Process Focus Technical Solution Requirements Development 4 - Quantitatively Managed Product & process quality Quantitative Project Management Organizational Process Performance 5 - Optimizing Continuous process improvement Causal Analysis & Resolution Organizational Innovation & Deployment Level Focus Process Areas Result Productivity & Quality Risk