bannerd


UNDER CONSTRUCTION

03. Software Requirements Activity Overview

03. Software Requirements Activity Overview

Requirements are the basis for a software product.They identify the needs to be addressed, the behavior of the system, the desired quality of the software, and the constraints under which the problem is to be solved. They specify the product the provider is to deliver to a customer.  Requirements serve as the basis for verification activities allowing the developing organization and the customer to judge the completeness of the product.

Analyzing software requirements allows a team to ensure that they are properly formed and accurately and clearly describe the software system to be built.  The analysis provides a structured method of reviewing requirements to identify any issues with them individually or as a collected set.  The team can address identified issues before using the requirements for further project work.  This reduces the need for future rework, not only of the requirements but also of any work based on those requirements.

Any inconsistencies among these three - requirements, project plans, and software products – will most likely result in a product that does not meet its requirements. Corrective actions address not only new or changed requirements, but also failures and defects in the work products (requirements, project plans, and software products). Corrective actions need to be analyzed to determine the impact that the change will have on the work product, related work products, budget, and schedule. Corrective actions need to be tracked until closure to ensure decisions regarding the closure of those actions are followed through and to prevent the problems described in those corrective actions from propagating through the project or recurring.

Validation is one way to ensure the requirements define the need completely, clearly, correctly, and consistently to give the software engineers the best chance to build the correct product. Validation is a process of evaluating artifacts to ensure that the right behaviors have been defined in the artifacts. The right behaviors adequately describe what the system is supposed to do, what the system is not supposed to do, and what the system is supposed to do under adverse conditions.  

Acceptance criteria synchronize the visions of the client and the development team. They ensure that everyone has a common understanding of the requirements: Developers know exactly what kind of behavior the feature must demonstrate, while stakeholders and the client understand what's expected from the feature.

Bidirectional traceability matrices help ensure that all the required software requirements (only what is required is developed) are addressed in software design and tested in the software testing activities. Bidirectional traceability matrices also make it less likely that requirements are misinterpreted as they are refined.

Frequency Of This Activity

Requirements change management helps ensure alignment between the software requirements and the project’s software plans and software work products. Collecting, analyzing, and managing requirements changes allow a project to control those changes and measure their impact. Requirements change management can also provide early insights into the impact of those changes to the overall project's budget and schedule, including the ability to plan how to address changes rather than simply reacting when a change is made.

03.1 Related SWEs

  • SWE-034 - Acceptance Criteria - 3.1.5 The project manager shall define and document the acceptance criteria for the software. 
  • SWE-050 - Software Requirements - 4.1.2 The project manager shall establish, capture, record, approve, and maintain software requirements, including requirements for COTS, GOTS, MOTS, OSS, or reused software components, as part of the technical specification. 
  • SWE-051 - Software Requirements Analysis - 4.1.3 The project manager shall perform software requirements analysis based on flowed down and derived requirements from the top-level systems engineering requirements, safety and reliability analyses, and the hardware specifications and design. 
  • SWE-052 - Bidirectional Traceability - 3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: 

    Bi-directional Traceability

    Class A, B, and C

    Class D

    Class F

    Higher-level requirements to the software requirements

    X


    X

    Software requirements to the system hazards

    X

    X


    Software requirements to the software design components

    X



    Software design components to the software code

    X



    Software requirements to the software verification(s)

    X

    X

    X

    Software requirements to the software non-conformances

    X

    X

    X

  • SWE-053 - Manage Requirements Changes - 4.1.5 The project manager shall track and manage changes to the software requirements. 
  • SWE-054 - Corrective Action for Inconsistencies - 4.1.6 The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products. 
  • SWE-055 - Requirements Validation - 4.1.7 The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment. 
  • SWE-184 - Software-related Constraints and Assumptions - 4.1.4 The project manager shall include software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software in the software requirements documentation.

03.2 Related Work Products

03.2.1 Related Process Asset Templates


03.3 Related Topics

  • 6.2 - Checklist for General Software Safety Requirements Provides a list of many of the requirements that should be included in a safety-critical software system.
  • 8.01 - Off Nominal TestingGuidance focusing on out of bounds parameters, failure scenarios, unexpected conditions, and capabilities that are typically considered as "must not work" functions.
  • 8.02 - Software ReliabilityThe goal of SW reliability and maintainability is to assure that SW performs consistently as desired, when operating within specified conditions. This topic covers additional basic information on software reliability.
  • 8.07 - Software Fault Tree AnalysisA top-down analysis method to help identify the causes of presupposed hazards.
  • 8.54 - Software Requirements Analysis - The Software Requirements Analysis product focuses on analyzing the software requirements that have been developed from the system requirements. 

Editors only

A.03.01 Software Requirements

Analysis of SWEs and SM

A.03.01 Software Requirements

  • FTA should point to some SWEs and maybe some topics where it is mentioned
SWE or Topic

Related SWEs 

Related SM

Related Activity

5.01 - CR-PR - Software Change Request - Problem Report
5.07 - SDD - Software Data Dictionary
5.09 - SRS - Software Requirements Specification
6.2 - Checklist for General Software Safety Requirements
7.08 - Maturity of Life Cycle Products at Milestone Reviews
7.09 - Entrance and Exit Criteria

7.19 - Software Risk Management Checklists
8.01 - Off Nominal Testing
8.02 - Software Reliability
8.07 - Software Fault Tree Analysis
8.54 - Software Requirements Analysis

PAT-003 - Functional Requirements Checklist

PAT-004 - Safety Requirements Analysis Checklist

PAT-007 - Checklist for General Software Safety Requirements

PAT-013 - Software Requirements Checklist

PAT-033 - TASKS NEEDING OBJECTIVE EVIDENCE

PAT-034 - SAANALYSIS Checklist




  • No labels