SWE.1 Software Requirements Analysis

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
SWE.1 Software Requirements Analysis por Mind Map: SWE.1 Software Requirements Analysis

1. Purpose: The purpose of the Software Requirements Analysis Process is to transform the software related parts of the system requirements into a set of software requirements.

1.1. SWE.1.BP1: Specify software requirements

1.1.1. Agree on the attributes required for capturing the Software Requirement specification

1.1.2. Derive Software Requirements (Software Functions) from System Requirements Specification, Software Architecture Design and Customer Requirements as input

1.1.3. Derive Application Parameters values that contributes to the vehicle performance by fine tuning the values (Variant Management)

1.1.4. Document the Software Requirements in SRS

1.1.5. Outcomes: Traceability record, Change control record, Analysis report, Interface Requirements Specification, Software Requirements Specification

1.2. SWE.1.BP2: Structure software requirements

1.2.1. Grouping of Software Requirements into different clusters - for ex: the requirements can be grouped by features - Lane Keep Assist, Adaptive Cruise Control, Forward collision warning etc..

1.2.2. Categorize the Requirements as Functional and Non-Functional (Performance and Standard) for ex: Resource utilization or Compliance to ISO 26262 - ASIL D requirements

1.2.3. Prioritize the Requirements - Follow MOSCOW (Must have, Should Have, Could Have or Would Have) or ideal will be assign it to release milestone Sample A1, B1, C, D etc..

1.2.4. Outcomes: Analysis report, Verification criteria

1.3. SWE.1.BP3: Analyze software requirements

1.3.1. Analyze the Requirements - Identified dependencies or interrelated requirements , Technical feasibility , verifiability, risks, cost and schedule

1.3.2. Outcomes: Analysis report, Change Control Record, Verification criteria

1.4. SWE.1.BP4: Analyze the impact on the operating environment.

1.4.1. Analyze the Impact of Requirements on Boot loader or the Micro controller

1.4.2. Outcomes: Change Control Record, Analysis report, Interface requirements specification

1.5. SWE.1.BP5: Develop verification criteria

1.5.1. Identify Verification criteria for all Requirements - Pre-conditions, inputs, outputs , use cases , post conditions etc

1.5.2. Outcomes: Change Control Record, Analysis record, Verification criteria

1.6. SWE.1.BP6: Establish bidirectional traceability

1.6.1. Establish Traceability - System and Software Requirements and System architecture and software requirements

1.6.2. Outcomes: Traceability record

1.7. SWE.1.BP7: Ensure consistency.

1.7.1. Establish Traceability - System and Software Requirements and System architecture and software requirements

1.7.2. Review the Software Requirements and Traceability

1.7.3. Outcomes: Traceability record, Review record

1.8. SWE.1.BP8: Communicate agreed software requirements.

1.8.1. Communication the Software Requirements as per Communication Plan

1.8.2. Outcomes: Communication Record

1.9. Sample Work Products

1.9.1. Software Requirements Specification

1.9.2. Feasibility Analysis Process

1.9.3. Verification Criteria