Requirements Engineering for the Accelerator Eugene Tanke Systems Engineer Workshop on Requirements Conformance for SRF Cryomodules October 15, 2014

Outline Why work with requirements? Framework for ESS accelerator requirements DOORS requirements database Outlook

Why work with requirements in the Accelerator? (slide 1 of 2) Looking backwards in time from the “First beam on target” milestone:  Beam will need to be commissioned  Equipment (beam line and ancillary) will need to be tested  Equipment will need to be installed  Equipment may need to be tested at the “factory” prior to shipping  Equipment will need to be produced  Equipment will need to be designed

Why work with requirements in the Accelerator? (slide 2 of 2) Requirements aid in:  assuring that what is designed and built is what the user needs  providing a basis for testing (ensuring functionality)  and hence aid in reaching our milestone

V-model widely used in industry for requirements Within the ESS accelerator, elements of this model have been implemented

Product Breakdown Structure is the framework for te ESS accelerator requirements (slide 1 of 2) *PBS definition CM =CryoModule LWU=Linac Warm Unit Diciplines (L4) are matrixed to sections (L3)

Product Breakdown Structure is the framework for te ESS accelerator requirements (slide 2 of 2) *PBS definition CM =CryoModule HEBT=High Energy Beam Transport LWU=Linac Warm Unit Product Breakdown Structure forms the framework for the top-down and interface requirements

Accelerator interfaces tracked through an interface matrix “System” contacts have been established

Requirements development (L4,L5) is ongoing Top-down requirement examples in Excel Interface requirement examples in Excel

Reviewed requirements are uploaded into DOORS Requirements pass an ESS Lund internal review before upload to DOORS DOORS is a database that has been built for requirements management  Accelerator L1, L2 and L3 requirements are in DOORS  DOORS has a thin (web) client, accessible to the ESS partners  ESS partners can comment on requirements using the “Discussions” option in DOORS  ESS Lund engineers will then respond to these  DOORS has a thick client for database management

Thin client of DOORS allows for discussion threads

Reviewed requirements are uploaded into DOORS Requirements pass an ESS Lund internal review before upload to DOORS DOORS is a database that has been built for requirements management  Accelerator L1, L2 and L3 requirements are in DOORS  DOORS has a thin (web) client, accessible to the ESS partners  ESS partners can comment on requirements using the “Discussions” option in DOORS  ESS Lund engineers will then respond to these  DOORS has a thick client for database management

Requirements process: an outlook Starting from requirements in DOORS, the following process is proposed:  Review by ESS partner (where applicable)  Base-lining of requirements in DOORS with  Export (automated?) of base-lined requirements to document control center (CHESS)  Automatic to relevant parties to inform about new baseline  In the case of requirement changes:  Have change request approved at appropriate CCB (Change Control Board)  Export new baseline to CHESS & relevant parties