1 / 29

Requirements Development Process Training

Requirements Development Process Training. Process for identifying, developing, documenting, and verifying software requirements. Agenda. Software Processes. The SEPG has developed the following processes: GRC-SW-7150.3 - Software Project Planning

akridge
Download Presentation

Requirements Development Process Training

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 Development Process Training Process for identifying, developing, documenting, and verifying software requirements

  2. Agenda

  3. Software Processes • The SEPG has developed the following processes: • GRC-SW-7150.3 - Software Project Planning • GRC-SW-7150.4 - Software Project Monitoring and Control • GRC-SW-7150.5 - Requirements Development • GRC-SW-7150.6 - Requirements Management • GRC-SW-7150.8 – Software Measurement • GRC-SW-7150.9 - Software Configuration Management • GRC-SW-7150.10 - Transition SW to a Higher Class • GRC-SW-7150.12 - Formal Inspection and Peer Review • GRC-SW-7150.14 - Software Acquisition SOW Guideline (being updated) • GRC-SW-7150.15 - Software Acquisition Planning • GRC-SW-7150.16 - Software Estimating • GRC-SW-7150.17 - Software Safety Planning • These are available on Software@Glenn.

  4. Software Documentation Templates • The SEPG has developed the following document templates: • GRC-SW-TPLT-SMP - Software Management Plan Template • GRC-SW-TPLT-SRS - Software Requirements Specification Template • GRC-SW-TPLT-RTM - Requirements Traceability Matrix Template • GRC-SW-TPLT-SCMP - Software Configuration Management Plan Template • Software Change Request/Problem Report • GRC-SW-TPLT-MMS – Master Metrics Spreadsheet • GRC-SW-TPLT-SDD - Software Design Description Template • GRC-SW-TPLT-IDD - Interface Design Description Template • GRC-SW-TPLT-STP - Software Test Plan Template • GRC-SW-TPLT-STPr - Software Test Procedure Template • GRC-SW-TPLT-STR - Software Test Report Template • GRC-SW-TPLT-SVD - Software Version Description Template • GRC-SW-TPLT-SUM - Software Users Manual Template • GRC-SW-TPLT-SMntP - Software Maintenance Plan Template • GRC-SW-TPLT-SSP- Software Safety Plan Template • GRC-SW-TPLT-SSCA - Software Safety Criticality Assessment (new) • These are available on Software@Glenn. • They are Word documents except for the Master Metrics SS.

  5. Requirements Development • This process was developed to assist Software Project Leads in evaluating stakeholder expectations and transforming them into product requirements. • This process is used throughout the software development project, although its primary use is early in the project when requirements are being defined, usually during the project planning phase and just before baselining of the Software Requirements Specification (SRS). • Use this process for • Evaluating stakeholder expectations for the software products • Identifying, developing, logically decomposing, documenting, and verifying requirements necessary for the development of a quality product that meets customers’ needs • Developing the Requirements Traceability Matrix • Implements NPR 7150.2B SWE-034, SWE–050, SWE–051, SWE–052, SWE–055, SWE-087, SWE-147, SWE-149, SWE-155, SWE-157 • Implements CMMI’s Requirements Development Specific Practices: 1.1, 3.1, 3.3, 3.5 • Note that GRC-SW-7150.6 is the Requirements Management Process that can be used to manage the requirements developed with this process.

  6. Requirements Development

  7. Requirements Development Identify stakeholders(6.1) •  The Software Project Lead develops a list of stakeholders of the software, and documents the list in a project document such as the Software Management Plan.  • Stakeholders include, at a minimum, the ultimate users of the system, but generally also include developers, project/program managers, and support and maintenance personnel. These may also include vendors or related engineering groups (e.g., fabrication, testing, or aero), even if their roles in the software development will be limited. • The Project Planning process, GRC-SW-7150.3, has an example list of stakeholders and additional guidance regarding identifying relevant stakeholders. Also see the Software Management Plan template for a blank stakeholder matrix that may be useful.

  8. Requirements Development Identify high-level requirements(6.2) • The Software Project Lead determines the high-level software requirements by meeting with stakeholders  and by reviewing the project’s documents (Project Plan, Operational Concept Document,   and/or Science Requirements Document).  • Requirements at this point may be at a very high level and written from the customer’s point of view, but will be maintained as the initial requirements.

  9. Requirements Development Gather and document other requirements(6.3) •  The Software Project Lead gathers and documents other enabling and constraining requirements from many different sources that can be used to guide the software development effort . These may include:: • Engineering Requirements Document • NPR 7150.2B, NASA Software Engineering Requirements (consider additional requirements that may be imposed on your system as a result of SWE-134 if you are safety critical.) • GLPR 8739.1, Software Assurance • Software Reliability and Quality Assurance Requirements • Computing System Requirements • Modeling and Simulation Management Requirements • Problem Reporting, Analysis, and Corrective Action Requirements • System-Level Requirements • User/Customer Scenarios  • End-User Requirements • Other System Discipline Requirements • Interface Requirements  • Re-usability Requirements (consider not only what software is available for re-use on the current project, but also what portions of the code you would like to make available for others to re-use upon completion of the project) • Software Security Risk Mitigations from Project Protection Plan • Space communications security measures • Agency and/or environmental standards • Document key decisions, rationales, and assumptions.

  10. Requirements Development Develop operational scenarios(6.4) • The  Software Project Lead develops an initial set of operational scenarios describing how the envisioned system will operate in its intended environment. • Consider how each of the different users will need to interact with the system. • Save and Update scenarios throughout the project’s life cycle. • Use the scenarios to test assumptions, elicit new or unstated requirements, test designs, develop test cases, and facilitate communication with the customer. 

  11. Requirements Development Analyze requirements individually(6.5) • The Software Team analyzes the software requirements individually for safety, criticality, correctness, clarity, traceability, feasibility, verifiability, and maintainability. • The document “Writing a Software Requirements Specification” on the Software@Glenn Web site provides guidance on this.

  12. Requirements Development Analyze requirements as a set(6.6) • The Software Team analyzes the software requirements as an integrated set to ensure that they provide a complete, self-consistent solution to the customer’s software needs. Use operational scenarios to validate the requirements when appropriate. Develop new scenarios as needed. • The operational scenarios should evolve as the requirements and design are further developed and are updated and augmented as needed.  

  13. Requirements Development Review scenarios with stakeholders(6.7) • The Software Team runs through the operational scenarios with the identified stakeholders to secure their acceptance that the scenarios accurately meet the needs and expectations of the customer and reflect the users’ concepts of the system in its intended environment.

  14. Requirements Development Logical decomposition of the set of requirements(6.8) •  The software team decomposes the set of requirements to transform them into a set of derived technical requirements  for input to the technical solution process. • Theteam reviews the requirements that have been flowed down from the higher level requirements for consistency.

  15. Requirements Development Document the requirements(6.9) • The software team documents the software requirements.  These requirements shall be written in software terms to form a basis for software development work to proceed. Be sure to indicate those requirements that are being implemented by a COTS/GOTS/MOTS product to allow validation that the product meets those items. If the software is safety critical, NASA-STD-8719.13 requires those requirements that are Safety Critical be tagged as such to allow for the appropriate level of rigor. • It is recommended, but not required, that each requirement include: • A rationale statement to indicate why the requirement is needed. • Verification method to define how each requirement will be verified: Test, Demonstration, Inspection, or Analysis. • Verification statement to describe how that method of verification will be implemented. This provides a level of clarity for test planning and also final acceptance. • If an SRS is required by your project, use the SRS template, GRC–SW–TPLT–SRS, to ensure that all elements of an SRS are included. • Re-usability requirements may not belong within the SRS or requirements document. They may be written in the design document as rationale for the architecture of the software system.

  16. Requirements Development Develop Requirements for Bi-directional Traceability (6.10) •  Using the requirements, the software team develops and documents the bidirectional traceability  information for the requirements. • The information may be documented in the requirements traceability matrix (RTM) following the template, GRC–SW–TPLT–RTM or with the use of an electronic tool.  

  17. Requirements Development Conduct a review/inspection of the requirements(6.11) • The Software Project Lead conducts a formal inspection or peer review of the requirements document against predefined criteria following GRC–SW–7150.12, Formal Inspection and Peer Review. • The project size and resources should determine whether a formal inspection, or a peer review, is performed and who to include in the inspection or review. • Ensure that the software team is included in the review, at a minimum.

  18. Requirements Development Define and document acceptance criteria(6.12) • The Software Project Lead and the customer define and document the conditions for acceptance of the software.  • Describe the acceptance process, any tests or demonstrations that will be run, what physical property will be delivered to the customer, the environment in which the final acceptance testing will take place, and the participants in the acceptance testing. • Document in the Software Management Plan and/or in a Software Acceptance Plan.  

  19. Requirements Development Baseline requirements and scenarios(6.13) • Requirements and scenarios should be baselined by agreement between the customer/Project Manager and the software team  either when they have stabilized, or when the project schedule demands a baseline. • The risk of baselining too soon is that the Software Development Team may proceed to design and build software that will not meet the customer’s needs. The risk of waiting too long is that the Software Development Team may jeopardize the schedule and budget by not allowing sufficient time or resources.

  20. Using the Software Requirements Specification (SRS) Template • The SRS template has been developed for use in the Flight Software Branch. • Projects outside the branch are welcome to use it. • The template covers all requirements associated with a Class A Safety Critical software development effort. • All projects should tailor the SRS template to the classification of their software and the needs of the project. • Designed to cover NPR 7150.2B requirements and CMMI’s Requirements Development process area. • The SRS is intended for documenting all software requirements and is used as the baseline by which the software will be written. • Once the SRS is baselined, the project should follow the appropriate requirements management and change request process for making modifications to the requirements and this document.

  21. Using the Requirements Traceability Matrix (RTM) Template • The RTM template has been developed for use in the Flight Software Branch. • Projects outside the branch are welcome to use it. • The template covers all software development efforts and includes all pertinent information for tracing a requirement from its parent through its verification. • All projects should tailor the RTM template based on the needs of the project. • The template describes each field and the data that is needed for each requirement. • Designed to cover NPR 7150.2B requirements for traceability. • This document can be a stand alone document or an appendix to the Software Requirements document. For small projects, this matrix may double as the software requirements specification.

  22. Software Measurement ProcessResources, Tools, and Templates • Available from Software@Glenn: • http://software.grc.nasa.gov • GRC-SW-7150.4: Software Development Process • NPR 7150.2B: NASA Software Engineering Requirements • GRC-SW-TPLT-SRS: Software Requirements Specification Template • GRC-SW-TPLT-RTM: Requirements Traceability Matrix Template • Available from the Agency • NASA Engineering Network: Software Engineering Community of Practice • https://nen.nasa.gov/web/nen/home: Click on Communities->Software Engineering • NASA Software Engineering Handbook • https://swehb.nasa.gov/

  23. Feedback on the Requirements Development • Processes, checklists, templates and forms available at Software@Glenn: http://software.grc.nasa.gov • To ask questions • Lisa Lambert, x3994 • grc-sepg-lead@lists.nasa.gov • We value your feedback • The feedback form is on the Feedback page of Software@Glenn. • Send the feedback form to grc-sepg-lead@lists.nasa.gov. • Group feedback sessions available upon request. • Based on feedback, the process will be updated. • The updated process will be made available on Software@Glenn. • Share your products as examples for future projects!

  24. Questions?

  25. Backup

  26. CMMI v1.3 Requirements Development • Specific Goals and Practices • SG 1 – Develop customer requirements • SP 1.1 – Elicit needs • SP 1.2 – Transform stakeholder needs into customer requirements • SG 2 – Develop product requirements • SP 2.1 – Establish product and product component requirements • SP 2.2 – Allocate product component requirements • SP 2.3 – Identify interface requirements • SG 3 – Analyze and validate requirements • SP 3.1 – Establish operational concepts and scenarios • SP 3.2 – Establish a definition of required functionality and quality attributes • SP 3.3 – Analyze requirements • SP 3.4 – Analyze requirements to achieve balance • SP 3-5 – Validate requirements

  27. CMMI v1.3 Generic Goal 2 • Generic Goal 2 and Practices • Goal 2 – Institutionalize a managed process • GP 2.1 – Establish an organizational policy • GP 2.2 – Plan the process • GP 2.3 – Provide resources • GP 2.4 – Assign responsibility • GP 2.5 – Train people • GP 2.6 – Control work products • GP 2.7 – Identify and involve relevant stakeholders • GP 2.8 – Monitor and control the process • GP 2.9 – Objectively evaluate adherence • GP 2.10 – Review status with higher level management • 27

  28. NPR 7150.2B RequirementsSWEs: 034, 050, 051, 052, 055, 087 • SWE-034: The project manager shall define and document the acceptance criteria and conditions for the software. • SWE-050: The project manager shall establish, capture, record, approve, and maintain software requirements, including the software quality requirements, as part of the technical specification. • SWE-051: The project manager shall perform software requirements analysis based on flowed down and derived requirements from the top-level systems engineering requirements and the hardware specifications and design. • SWE-052: The project manager shall perform, record, and maintain bidirectional traceability between the software requirement and the higher-level requirement. • SWE-055: The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment. • SWE-087: The project manager shall perform and report the results of software peer reviews or • software inspections for: • a. Software requirements. • b. Software plans. • c. Any design items that the project identified for software peer review or software inspections according to the software development plans. • d. Software code as defined in the software and or project plans. • e. Software test procedures.

  29. NPR 7150.2B Requirements(cont.)SWEs: 147, 149, 155, 157 • SWE-147: The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including models used to generate the software. • SWE-149: The project manager shall ensure that when an OSS component is acquired or used, the following conditions are satisfied: • A. The requirements that are to be met by the software component are identified. • b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions). • c. Proprietary, usage, ownership, warranty, licensing rights, and transfer rights have been addressed. • d. Future support for the software product is planned and adequate for project needs. • e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use. • SWE-155: The project manager shall implement the identified software security risk mitigations addressed in the Project Protection Plan. • SWE-157: The project manager shall ensure that software systems with space communications capabilities are protected against un-authorized access.

More Related