Use of Requirements in Model-Based Systems Engineering for a Legacy Design. Philip Simpkins KIHOMAC Sr. Systems Engineer

Size: px
Start display at page:

Download "Use of Requirements in Model-Based Systems Engineering for a Legacy Design. Philip Simpkins KIHOMAC Sr. Systems Engineer"

Transcription

1 Use of Requirements in Model-Based Systems Engineering for a Legacy Design Philip Simpkins KIHOMAC Sr. Systems Engineer

2 Abstract Requirements are known as one of the pillars of the systems engineers repertoire, but sometimes they are either overlooked or under emphasized in Model-Based Systems Engineering (MBSE). For instance, Department of Defense Architecture Framework (DoDAF) 2.0 does not currently have requirements represented in any of its 52 views. Systems Modeling Language (SysML) utilizes requirements, but they are not prevalent in many of the diagrams within SysML. Requirements are impacted, and can be influenced, by many stakeholders. Stakeholders, themselves, can affect the intent of a requirement by how they define, constrain, or propose to implement a requirement. If the stakeholders do not fully explain their desired need, the requirement can be misinterpreted, thus impacting full and correct implementation. Thus, it is critical for all stakeholders to understand the ramifications of poorly documented requirements and to directly participate in the requirements development process. Requirements identification/definition plays a vital role in the initial creation of a project, but are sometimes put on the shelf until the final verification and validation stage of the design. Requirements should be checked and verified throughout the development of a product or project and a baseline developed and approved to eliminate scope creep and to verify the direction of the design. By reviewing the design progression against the approved requirements set, the tendency for a design drifting away from the stakeholder s operational capabilities can be minimized. This also assists the correction/elimination of obsolete requirements before they can adversely impact future enhancements. The requirements should be linked and traceable from start to finish of a design. The evolution of new system requirements can take place over several years, even 40 years after the original design. This traceability helps assess the original intent and the users needs versus what we think the stakeholders initially wanted or needed. A requirements management plan approach as part of an MBSE design program has been successfully used for the sustainment of US Air Force assets KIHOMAC Inc. 2

3 Requirements Management Plan 2012 KIHOMAC Inc. 3

4 Process Stakeholders Configuration Control Engineering Configuration Baseline Review Requirements Development Requirement Review Approved by the CC Verification and Validation Reports Developmental Forms 2012 KIHOMAC Inc. 4

5 Stakeholders The User Community The Stakeholders that will actually be utilizing the product. Configuration Control Board (CCB) Provides final approval of any system modifications Requirements Owner Develops and establishes the Engineering Configuration Baseline Implementers of the Modification Entities that develop work packages Develop system physical requirements 2012 KIHOMAC Inc. 5

6 Establish Configuration Control (CC) The User Community Documents/databases defining the operational requirements Documents/databases describing capabilities Configuration Control Board Configuration Management Plan Requirements Owner Engineering Configuration Baseline Design Requirements database / document establishing the minimum set of requirements Requirements Management Plan Implementers of the Modification Work Packages Test Plans 2012 KIHOMAC Inc. 6

7 Engineering Configuration Baseline Development 2012 KIHOMAC Inc. 7

8 Configuration Management Establish Engineering Controlled Baseline (ECB) Define configuration management guidelines Configuration Management Plan CCB 2012 KIHOMAC Inc. 8

9 Requirement Development Process Gather Stakeholder Requirements Develop Key Performance Parameters Requirements Analysis Establish set of Impacted Requirements Maybe all the requirements as in a new Design Defined set of requirements for a redesign or modification Reviewed against the Engineering Controlled Baseline (ECB) Operational Assessment Track impacted Requirements Trace the requirements to functions Trace the requirements to components 2012 KIHOMAC Inc. 9

10 Requirement Review and Acceptance Requirements Reviewed by the CCB and Requirements Owner CCB coordinates with the requirements owner Verification Use a Verification Matrix Review the ECB to verify if/how the ECB has evolved from the origin of the Impacted Requirements» System Requirements Review (SRR),» Preliminary Design Review (PDR),» Critical Design Review (CDR) Notify owner of any discrepancy Validation by the User Community 2012 KIHOMAC Inc. 10

11 Technical Requirements 2012 KIHOMAC Inc. 11

12 Technical Requirement Analysis 2012 KIHOMAC Inc. 12

13 Communicated, Traced, and Verified Commercially available software package. Capability to verify the requirements. The verification table should at least have these minimum values Requirement Impacted Function Solution Component Drawing # Requirement # and description of the requirement impacted by the upgrade. Function # and description of function or functions that specify the requirement Component # and description of component which is allocated to the function. Drawing # or numbers and titles where solution is displayed KIHOMAC Inc. 13

14 Reports Verification Table Status Table Verification Report Custom Reports 2012 KIHOMAC Inc. 14

15 Status Table Number Requirement Type Status Number of the Requirement Description of the Requirement impacted by the Modification. The attribute in the database that describes that type of requirement that is listed. They can be : 1. Capability 2. Composite 3. Constraint 4. Functional 5. Non-Functional 6. Operational 7. Performance 8. Program 9. Test 10.Verification The defined Status of the requirement: 1. Proposed 2. Approved 3. Implemented 2012 KIHOMAC Inc. 15

16 Verification Report Verification Requirement Req # and description of the Verification Requirement Verification article (Document or Drawing) Comp # and Description of component which is allocated to the function. Type of Verification (Review, Test, or Analysis) Drawing # or numbers and Titles where solution is displayed KIHOMAC Inc. 16

17 Requirements Evaluation Checklist Evaluation Criteria - All Requirements Yes No IDs Remarks A test case is associated with the requirement. The requirement can be understood by affected parties (e.g., SME, developers, testers ). Unacceptable words and phrases are absent (e.g., adverbs, adjectives, as appropriate, at a minimum). Adheres to defined terms in the requirements glossary. Requirement conforms to standard format. Requirement is at the appropriate level of detail for its position in the hierarchy. Requirement has the associated information required by the RMP KIHOMAC Inc. 17

18 Questions? 2012 KIHOMAC Inc. 18

19 Thank You! 2012 KIHOMAC Inc. 19

20 Contact Philip Simpkins Senior Systems Engineer KIHOMAC, Inc. 334 N. Marshall Way, Suite J Layton, UT (210) Philip.simpkins@kihomac.com 2012 KIHOMAC Inc. 20

21 Biography Philip J. Simpkins is a Senior Systems Engineer at KIHOMAC Inc. He has over 20 years of collective experience in aerospace requirements development, systems engineering, nuclear operations, and nuclear safety analysis. Mr. Simpkins has extensive knowledge in systems engineering, functions and requirements analysis, risk management, interface management, and analytical software He has delivered presentations to various professional societies, and user group events. He remains active in the International Council on Systems Engineering (INCOSE) and served as Region V Member Board Representative, in 2011 he was the Director-at-Large for the Alamo Chapter in Texas, and has been Past President of Alamo and the Central Savannah River chapters. Mr. Simpkins also participates on several INCOSE international committees. Mr. Simpkins is a Certified System Engineering Professional (CSEP) and holds a Bachelor of Science degree in Electrical Engineering and a Master s degree in Engineering Management from the Missouri University of Science and Technology KIHOMAC Inc. 21