1 / 16

Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering

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.

dorjan
Télécharger la présentation

Dr. Ralph R. Young Director of Software Engineering Systems and Process Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

  5. Developer and Customer Tasks Acceptance, integration & verification Informing the enterprise Provisional & final Detailed Storing and using acceptance design & knowledge from component previous projects development User requirements Developer work Architectural Amount of effort design System 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

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

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

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

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

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

  11. Types of Requirements Errors

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

  13. 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. Effective Requirements Practices

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

  15. Level Focus Process Areas Result 5 - Optimizing Continuous process improvement Causal Analysis & Resolution Organizational Innovation & Deployment Productivity & Quality 4 - Quantitatively Managed Product & process quality Quantitative Project Management Organizational Process Performance 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 2 - Managed Project management Configuration Management Requirements Mgmt Project Monitoring & Control Project Planning Supplier Agreement Management Measurement & Analysis Process & Product Quality Assurance 1 - Initial Heroes Risk The CMMI SE/SW High Level Summary

More Related