Analysis Package Development Process

This is written for system SEIT level Systems Engineering, but is applicable when tailored (i.e., identify appropriate participants) for use in the segment level SE process also.

Analysis

1. Assign Use Case to engineer for elaboration and analysis

2. Specify Source (driving) requirement(s) for Use Case (A-Spec)

3. Develop Data Flow Diagram (functional context diagram)

4. Develop Scenario Sequence Diagram (SSD) and associated Event Flow Table

5. Identify source requirements for each transaction (row) of EFT

6. Identify where derived (B-Spec) requirements are needed

7. Identify design assumptions, as required, for each transaction (row) of EFT

8. Include comments/concerns as required, for each transaction (row) of EFT

9. Schedule community review

10. Hold community review

(Note; this is a non-trivial activity which should be allocated at least I day per use case)

a. System Architect

b. Use Case Model Owner

c. System Model Owner

d. System SEIT Conops team

e. System SEIT I&T

f. System SEll Requirements

g. Segment representation

11. Make updates to analysis packages as required

12. Perform requirements audit (AP identified Use Case to B-Spec requirement)

13. Generate new derived requirements, as needed

14. Link requirement to AP in DOORS (create an A attribute in DOORS)

15. Prep for SFR

a. Focus on High Risk requirements (requirements that are vague and have high potential for malicious interpretation with cost/schedule impact)

b. Make and capture clarifying assumptions for each of above

c. Insure APs are available in read file

Post SFR System Engineering Design Document (SEDD) development

16. Merge approved/reviewed scenario into System model

17. Support configuration change process, as required, based on review

The Analysis Package

The Analysis Package is a structured engineering artifact that captures architecture and behavior and validates design against requirements.  The typical structure of an Analysis Package is,…

 

<Scenario Name>

 

Summary/Overview

<Summarize the purpose/goal of the thread, including the driving system level requirement fulfilled by the Thread.  This should be one or two paragraphs >

 

Preconditions

<Describe the required state of the system before the thread can begin including data required and other threads that this one is dependent upon.  A thread dependency diagram may be useful.>

 

Actors:

<List of Operators or Nodes involved in the Thread.  Time is often used as an actor. >

 

Context Diagram:

<Graphic depiction of interfaces between actors. >

 

Scenario Sequence Diagram (SSD):

<Graphic depiction of sequential interactions between actors.  The message sequence chart illustrates the source and receiving actors (operators or nodes), the interface message from the source to the receiver, and the processing by the receiver.   See Example in Appendix>

 

Event Flow Table

<The Event Flow Table describes the details of the MSC capturing for each event in the operation sequence the requirement it satisfies.  The Event Flow Table includes (where applicable) derived requirements, requirements clarifications, assumptions and other awareness derived from the Thread exercise. >

 

Post-Conditions

<Describe the state of the system or product when the thread ends successfully>

 

Blog

Steve’s Home Page