System Specification in Automotive SPICE® ASQF Meeting of Section “Automotive”, Berlin, June 8th 2017

Short introduction of Neusoft Initial situation System Processes

Profile Volker Lehmann Company & Role Head of Quality at Neusoft Technology Solutions GmbH Key Experience Member of intacs™ Advisory Board Leading intacs™ working groups Coaching for project and process managers Trainings and workshops for SPICE assessor certifications and introductions Software-/System Process Improvement Quality Assurance & Management Requirements Engineering & Management Certifications intacs™ certified Principal Assessor intacs™ certified Instructor for Provisional and Competent Level IPMA Level C (project manager) IREB® Certified Professional for Requirements Engineering ITIL® Foundation Level

NEUSOFT at a glance Privately founded in 1991 at Northeastern University(NEU) in Shenyang, China Corporation headquarters in Shenyang, China The first listed software corporation in China and traded on the Shanghai Stock Exchange(1996) Year-on-year growth of > 20% More than 20,000 expert employees for different fields of business 3 Universities in China with more than 36,000 students 29 software development & technical support centers and a comprehensive marketing & service network in over 40 cities across China. Global footprint, Subsidiaries in Europe, Israel, Middle-East, USA and Japan Shenyang Park Dalian Park Shanghai Park

Neusoft Automotives - Hamburg NTS (Neusoft Technology Solutions GmbH) Location: Hamburg, Germany Employees (2016): ~210 Established June, 2010 Global technology solution & service provider Provides navigational competence (internal and customer) Off-shore development bridge Research & Development: Navigation & Location Based Services Generation and processing of digital road maps & geographic information 3D city models Hamburg Headquarter

Short introduction of Neusoft Initial situation System Processes

Customer Requirements Common situation Customer Project SW Req CReq 4 CReq 1 CReq 2 CReq 5 CReq n CReq 3 Customer Requirements HW Req MEC Req Requirements from Customer are handed over to sales or project team Project defines requirements for domains SW, HW, MEC directly

Most important problems Customer Project SW Req Customer Requirements CReq 1 CReq 4 HW Req CReq 2 CReq 5 CReq 3 CReq n MEC Req Separate specifications are not synchronized Requirements got lost on system level Architecture on system level is not taken into account

A recommended approach SYS.1 Requirements Elicitation SYS.2 System Requirements Analysis SYS.3 System Architectural Design Establish a system level in projects for system requirements and system architectural design Establish the role of system engineer with system responsibility for the whole development lifecycle

Short introduction of Neusoft Initial situation System Processes

Customer Requirements Customer Requirements Idea of system processes in Automotive SPICE®: SYS.1 Requirements Elicitation Customer Project CReq 4 CReq 1 CReq 2 CReq 5 CReq n CReq 3 Customer Requirements ? CReq 4 CReq 1 CReq 2 CReq 5 CReq n CReq 3 Customer Requirements ! SYS.1 Requirements Elicitation Performed at the interface between customer and supplier Goal is to ensure a common understanding about customer requirements on BOTH sides

Implementation and challenges of SYS.1 Requirements Elicitation Usually not explicitly assessed by customers Partly performed intuitively during SYS.2 System requirements analysis Recommended participants: system engineer, system architect, domain architects, requirements engineers, tester Challenges: Resources need to be provided Customers need to be involved Commitment for baselined customer requirements is hardly to receive from customer

Customer Requirements Idea of system processes in Automotive SPICE®: SYS.2 System Requirements Analysis Customer Project ! CReq 4 CReq 1 CReq 2 CReq 5 CReq n CReq 3 Customer Requirements SysReq 5 SysReq 1 SysReq 2 SysReq 6 SysReq 7 SysReq 3 System Requirements SysReq n SysReq 4 SYS.2 System Requirements Analysis Analyze Customer Requirements and translate them into local technical language, detailing them out Ensure feasibility and testability

Implementation and challenges of SYS Implementation and challenges of SYS.2 System Requirements Analysis (1/3) Derive system requirements from: Internal requirements (e.g. quality, logistic, etc.) Cross-cutting technical requirements (“Querschnittslastenhefte”) Legal requirements Engineering standards Recommended participants: system engineer, system tester, requirements engineer, domain experts Ensure complete coverage of customer requirements

Implementation and challenges of SYS Implementation and challenges of SYS.2 System Requirements Analysis (2/3) Identify “non-requirements” in customer specification: Information for understanding of requirements Requirements for architectural design decisions Tag and map them appropriately (for traceability reasons) Identify concrete requirements for HW-/SW-/MEC in customer requirements Analyze impact on system and other domains Derive system and other domain requirements for them Will be focus of system qualification test stage (SYS.5)

Implementation and challenges of SYS Implementation and challenges of SYS.2 System Requirements Analysis (3/3) Challenges: System engineers with experience and overview on system level are often not available Customer requirements often are not stable while change request management is not implemented yet Internal requirements are not taken into account for system requirements analysis Traceability is implemented but consistency is not ensured Domain specific requirements on system level need to be managed in an appropriate way (see above) System requirements specification is not updated after changes in later project phases

SYS.3 System Architectural Design Idea of system processes in Automotive SPICE®: SYS.3 System Architectural Design Project Project SysReq 5 SysReq 1 SysReq 2 SysReq 6 SysReq 7 SysReq 3 System Requirements SysReq n SysReq 4 SYS.3 System Architectural Design Transform system requirements into architectural solution Make decisions about distribution of architecture elements and requirements

Implementation and challenges of SYS Implementation and challenges of SYS.3 System Architectural Design (1/3) Map system requirements to architecture elements Identify decisions for architectural design in customer requirements and map them to system architecture These decisions will not be part of system requirements Define interfaces of the system (internal as well as external) Define dynamic behavior Ensure complete coverage of system requirements

Implementation and challenges of SYS Implementation and challenges of SYS.3 System Architectural Design (2/3) Architecture sometimes is already predefined (e.g. for platform development) Structure system requirements according to existing architecture Existing platform has strong influence on extension of architecture Definition of architecture may be started in parallel of system requirements analysis Mind the different approaches (requirements vs. solution) Is the basis for different domain specifications (SW, HW, MEC) Will be focus for system integration test stage (SYS.4)

Implementation and challenges of SYS Implementation and challenges of SYS.3 System Architectural Design (3/3) Challenges: System engineers with experience and overview on system level are often not available Sometimes architecture needs to be shown to customer in proposal phase Predefined architecture might limit the margin for decisions Traceability is implemented but consistency is not ensured

谢谢！ Thank you very much for your attention!