Requirements Management Made Simple - 5 Easy Steps

Transcription

1 w i t h Requirements Management Made Simple - 5 Easy Steps Jiri Walek VP Product Management 1

2 Poor Requirements Management 2 nd main cause for project failures. PMI: Pulse of Profession % Overall 24% Small projects 90% Large projects 2

3 2004 Founded with Disruptive Vision 2005 First Unified, 100% Browser-Based ALM 10 Years Focus on Unlocking Synergies: Full Traceability, Real-Time Collaboration, Intuitive UI 10 Years Customer Satisfaction & Growth 2016 Acquired by Siemens 250+ Fortune 1000 Deployments 2.5+M Users 200+ Extensions 15K Registered Community Members 3

4 REQUIREMENTS 1. Why do we NOT write them? 2. How can they become invisible? 3. How can they be visible but ignored? 4. Can we stop whining about cost? 5. OK, we're Agile. Now what? 4

5 REQUIREMENTS 1. Why do we NOT write them? 2. How can they become invisible? 3. How can they be visible but ignored? 4. Can we stop whining about cost? 5. OK, we're Agile. Now what? 5

6 Software Requirement A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. The IEEE Standard Glossary of Software Engineering Technology 6

7 #1 - MS Word Documents 50% - plain text specifications 7

8 8

9 9

10 User Acceptance Takeaway: Focus on user acceptance? Why are MS Word Documents not enough? Invisible requirements Ignored requirements 10

11 REQUIREMENTS 1. Why do we NOT write them? 2. How can they become invisible? 3. How can they be visible but ignored? 4. Can we stop whining about cost? 5. OK, we're Agile. Now what? 11

12 Invisible? Developers not aware of requirements Many requirements not tested I was not aware of this requirement specification No one told me about this requirement 12

13 Why? Search for specification documents Search for relevant requirements What to search for? Is this list complete? 13

14 Unified ALM Mission: Make relevant requirements available in one click Unified ALM to cover all disciplines of SW Lifecycle Full exposure of Requirements to all the other departments Access on all the devices End-to-end traceability across all the artifacts, projects and process steps 14

15 15

16 16

17 Traceability Takeaway: Focus on traceability Traceability is about data structure and exposure, it does not ensure application of requirement. 17

18 REQUIREMENTS 1. Why do we NOT write them? 2. How can they become invisible? 3. How can they be visible but ignored? 4. Can we stop whining about cost? 5. OK, we're Agile. Now what? 18

19 Not Applied? The test specification is not aligned with requirements The outcome does not match the contracts. This is outdated, We discussed it and we agreed to implement it differently Requirements are wishes, check tasks to see what we have implemented We did not have time to update the specification 19

20 Not reliable Not up-to-date Changed without notification/approval Change not propagated / analyzed 20

21 Secure collaboration Online collaboration Version management Permissions to control access rights Lifecycle definition Control who can change what and WHEN Impact propagation through suspect links Workflow Automation: enforcement of SOP 21

22 Impact Analysis Functional Design Large Data Scale 50k Requirements 20mil LoC 22

23 23

24 No time! It slows down our productivity, we have no time for managing requirements properly. 24

25 REQUIREMENTS 1. Why do we NOT write them? 2. How can they become invisible? 3. How can they be visible but ignored? 4. Can we stop whining about cost? 5. OK, we're Agile. Now what? 25

26 60% of requirements are being reused 26

27 Needs for Reuse Distribute Regulatory Requirements New Versions of your projects Variants / Product Lines 27

28 Derived Documents Derived Documents Share the regulatory requirements across the projects Distribute the updates as necessary Track additional properties with each individual copy Derive Product A Safety Req Spec Safety Req Spec Safety Ver. 3.4 ReqVer. Spec 3.3 Ver. 1.8 Update from 3.3 to 3.4 Product B The biggest benefit for WaveLight is the ease of reuse (of artifacts such as Requirements) across different projects. - Werner Motzet, WaveLight 28

29 Branching Live Branches Publish the approved versions for production Changes are instantly propagated (Live Branch) or on demand (Frozen Branch) Eliminate the risk of un-synched changes caused by copypaste duplication "Visual Diff": Compare documents via change highlights 29

30 Evolution of Variant Management Polarion Polarion VARIANTS Add-on 30

31 WASTE 31

32 REQUIREMENTS 1. Why do we NOT write them? 2. How can they become invisible? 3. How can they be visible but ignored? 4. Can we stop whining about cost? 5. OK, we're Agile. Now what? 32

33 Agile / Traditional - WHEN Specifications (Static) Written up-front User Stories (Dynamic) Written shortly before sprint 33

34 Agile / Traditional - HOW Specifications (Static) Written upfront The system shall.. User Stories (Dynamic) Written shortly before sprint I as a user want.. because.. 34

35 Agile / Traditional - LIFESPAN Specifications (Static) Written upfront The system shall.. Maintained User Stories (Dynamic) Written shortly before sprint I as a user want.. because.. Discarded when done 35

36 Traditional Command & Control Agile Commend & Support 36

37 User Story Focused Flat structure Describes increments Feasible to implement Estimation Ready Requirements Structured Specification Not ordered Overlapping Easy to write 37

38 Progressive Requirement Specification Requirements Epics Backlog User Stories Product Documentation Component Specifications 38

39 39 39

40 REQUIREMENTS 1. Why do we NOT write them? 2. How can they become invisible? 3. How can they be visible but ignored? 4. Can we stop whining about cost? 5. OK, we're Agile. Now what? 40

41 REQUIREMENTS 1. Why do we NOT write them? Focus on usability 2. How can they become invisible? Focus on traceability 3. How can they be visible but ignored? Secure Collaboration 4. Can we stop whining about cost? Support Reuse 5. OK, we're Agile. Now what? Support Agility not Methodology 41

42 Thank you. 42