Zusammenarbeit der Teams im Anforderungsmanagement

Transcription

1 Zusammenarbeit der Teams im Anforderungsmanagement 2. Berliner Requirements Engineering Symposium 27. September 2012, Berlin Volker Stephan Dr. Klaus Paul Sara Vetter Rolls-Royce Deutschland 2012 Rolls-Royce Deutschland Ltd & Co KG The information in this document is the property of Rolls-Royce Deutschland Ltd & Co KG and may not be copied or communicated to a third party, or used for any purpose other than that for which it is supplied without the express written consent of Rolls-Royce Deutschland Ltd & Co KG. This information is given in good faith based upon the latest information available to Rolls-Royce Deutschland Ltd & Co KG, no warranty or representation is given concerning such information, which must not be taken as establishing any contractual or other commitment binding upon Rolls-Royce Deutschland Ltd & Co KG or any of its subsidiary or associated companies.

2 Overview RR The company and the market Collaboration in the tender phase reply to a Request for Proposal (RFP) Collaboration in the development interface management

3 RR The company and the market

4 Rolls-Royce - The Company Around people In more than 50 countries Markets ( integrated power systems ) Civil Aerospace Defence Aerospace Marine Energy German sites are located in Dahlewitz, Oberursel and Hamburg.

5 The Civil Aerospace Market Narrow market Few (potential) customers (Airbus, Boeing, Embraer, Gulfstream, Bombardier ) Few engine suppliers (RR, GE, P&W ) Long periods between new developments A320 in service since 1988, replacement 202? B737 in service since 1967, replacement 202? Products long time in service Dart since 1952

6 The General Aerospace Market Different lead times for new projects A400M - December 1982 creation of Future International Military/Civil Airlifter-Consortium (FIMA) - December 2001 contract - Service 2013 Business Aircraft - Quick reaction on competition Different offering periods Many months or 6 weeks response time (during summer holiday)

7 The General Aerospace Market, cont. Very specific (technical) requirements 800 to 5000 Up to 7 levels in document hierarchy SOFTWARE CHANGE CONTROL Contradicting (technical) requirements Fuel consumption Weight Cost (purchase, operation)

8 Collaboration in the tender phase reply to a Request for Proposal (RFP)

9 Process Description Get RFP (CRD) (any format) The customer sends a set of RFP documents containing the technical Customer Requirements Document (CRD). Map RFP into DOORS The documents need to be reformatted and transferred into the company s RM database (DOORS). Map RFP onto copy of Generic PRD Map the CRD onto a copy of a generic Product Requirements Document (PRD) and add own requirements. Allocate teams to requirements Every single statement is allocated to one or several expert teams for familiarisation and assessment. Teams assess requirements Parallel work possible: Expert teams assess the requirements, the CE team deals with the (critical) requirements and provides a final assessment based on the expert teams input. A CRD up-issue is possible, starting the process again for the delta RFP. CE compiles answer for customer within CRD

10 Working View for Stakeholders PRD text - neutral RFP text - original Object-Type Responsible Teams PRD or Gen. Spec. Questions for Customer All available information has been compiled for the teams to provide a full overview. The teams can tailor the view (remove and rearrange columns). Unique ID Engine variant Comments - internal

11 Working View for Stakeholders, cont. Acceptance from Performance

12 Working View for Stakeholders, cont. PRD created from customer specification To add own requirements To provide some interpretation To remove source information (secrecy is a requirement) Overview with all available information provided to users for tailoring. PRD Columns relevant for review Earlier statements of same project Comparable other projects and related comments

13 Working View for Stakeholders, cont. Applicability of requirement for aircraft/engine variants shown. Customer specific or generic requirement. Stakeholders allocated to each requirement. Stakeholders have to state yes/no (acceptable or not) for each requirement. If the requirement is not acceptable a comment (internal) or a question (external) shall be provided.

14 Team Allocation All involved teams are listed and can be selected. Every requirement gets at least one team allocated to make sure that all requirements are addressed. Note: Definitions instead of real requirements are used to demonstrate the principle.

15 For every requirement (and some information) at least one team has been allocated. First allocation has been done top-down during set-up of the document. Teams have been asked to check allocation as well (bottom-up) and to correct accordingly. DXL script to allow check for healthy allocation Allocation is used for Team Allocation Check that stakeholders have assessed the requirement Providing high level requirements for sub-systems.

16 Concentrating on Critical Requirements HPT team does not agree Missing vote from LPT team Filtering for rejected requirements ( problem = not empty ) allows to concentrate early on critical requirements. Requirements assessed by several teams without indicating a problem can get priority 2. Unassessed requirements can be easily discovered. Optimum use of (limited) resource in time critical environment.

17 Concentrating on Critical Requirements, cont. The customer requirements are mapped onto a generic PRD and flagged Proj.-spec. = true. Using a filter provides an overview on Customer specific requirements, Generic requirements, Requirements potentially forgotten by the customer. Fulfil only the necessary requirements. Consider to discuss missing requirements with the customer. Consider potential requirements in the concepts.

18 Dealing with the Customer Filtered for Airframer HPC has an issue Comments / Questions Comments from Airframer Feedback from discussion with Airframer

19 Dealing with the Customer, cont. A DXL script does analyse requirements for Teams voting no (column Problem ), Teams not voted yet (column Not Worked ). Requirements with problems, questions and comments have been filtered. A subset has been selected for discussion with the customer. Notes from discussion with customer have been fed into Feedback, official customer response into Airframer- Comments. Updated customer documents show influence of discussion.

20 Easy Compliance Reporting Team votes only shown for relevant variant CDE decides based on proposal CDE vote fills boxes at once, if applicable for all variants Team votes summarized: Yes all allocated teams voted yes Yes, incompl. only yes votes, but some votes missing No at least one team voted no

21 Easy Compliance Reporting, cont. Comments and questions from the teams Comment for customer

22 Easy Compliance Reporting, cont. The team votes within the PRD provide the basis for the final compliance statement with the specification to the customer (proposed by CDE). All information from the PRD is compiled and mapped into the customer specification Summarised team proposal for applicable variant, Background information to explain the proposal. CDE can make final decision and comment based on condensed input

23 Management of Outdated Team Votes Critical change of requirement evaluation Due to the time stamps linked to the information, it can be evaluated if there is a (last minute) change of the specialist team assessment after the final vote by the CE team had been done. Consistent and parallel work possible until last minute.

24 Summary RFP phase Every customer is different Every campaign is different Flexibility is needed, based on common approach Pre-work helpful (e.g. Generic PRD) The chosen approach has increased efficiency. Requirements management starts where the biggest levers are requirements negotiation and concept phase.

25 Collaboration in the development interface management

26 Interface Management - Process Description Identify interface Agree partnership for interface vectors In the ideal world done with the support of a Functional-Flow-Model. The stakeholders agree, that there is an interface to which they all contribute. Group interface vectors into interface E. g. all the pins of a socket, the housing (physical), the signals (functional) and the Keep-Out-Zone (KOZ). Assign interfaces to Engines Mature interfaces Different Engines may have different interfaces between components (test builds, production modifications). Information is agreed in logical steps, e.g. to allow casting order whilst not all details are agreed. Sign off Interface Agreement All stakeholders sign off the interface information which has been compiled during the process.

27 Interface Management System The Goal The IFMS does currently only manage the administration of the interfaces Information about physical interfaces is held in Teamcenter Information about functional interfaces is stored in Word, later potentially in DOORS Have prototype Long term implementation within Teamcenter (TC) considered Improve process Create complete set of information for TC implementation: - Requirements - Flow charts - Use cases

28 Interface Management System The Goal Force people to agree interfaces Plus electronic agreement instead paper signature Reduce administration effort Replace Excel by DOORS - The involved parties agree the interface and enter the data directly in the database - Up-to-date reporting of existing interfaces Worldwide access to the database Reduce bugs DOORS User interface Input checks (restricted entries and combinations) Help function Treat interfaces as requirements Administration in the requirements database (DOORS) Allow later direct access to requirements

29 The Development of the IFMS < / ? DOORS (RM) DOORS (RM) DOORS (RM) DOORS (RM) Roadmap DOORS (IFMS) DOORS (IFMS) TeamCenter (IFMS) Paper (functional) Paper (functional) DOORS (functional) DOORS (functional) TeamCenter (physical) TeamCenter (physical) TeamCenter (physical) TeamCenter (physical)

30 The Set-Up of the IFMS The following subjects are grouped: People within teams (action on behalf of teams) Teams with each other, which are stakeholder at an interface Teams within a realm Interface types (physical, functional, KOZ ) Engine builds An Interface Definition Document covers the whole set of information for a specific interface.

31 Interface Definition Document (IDD) - Cover Sheet List of all IF vectors No physical interface without functional interface Applicability of interface definition Agreement of all stakeholders

32 Definition of Interface vector The current user and his role Definition of interface vector Available interface vectors for TeamA

33 Grouping of Interface Vectors Selected interface vectors Available interface vectors for TeamA

34 Maturity Steps Activities grouped by interface type Activities for next maturity step Activities for following maturity step

35 Summary Interface Management Proven process has been further improved by the exchange of Excel against DOORS. New interface management tool now applied to two projects. First steps done to integrate different tools.