Requirements Management Made Simple - 5 Easy Steps Jiri Walek VP - - PowerPoint PPT Presentation

▶
requirements management made simple 5 easy steps
SMART_READER_LITE
LIVE PREVIEW

Requirements Management Made Simple - 5 Easy Steps Jiri Walek VP - - PowerPoint PPT Presentation

Nov 07, 2023 114 likes •541 views

w i t h Requirements Management Made Simple - 5 Easy Steps Jiri Walek VP Product Management 1 Poor Requirements Management 2 nd main cause for project failures. PMI: Pulse of Profession 2015 48% 24% 90% Overall Small projects Large

slide-1
SLIDE 1

1

Requirements Management Made Simple

  • 5 Easy Steps

Jiri Walek

VP Product Management

w i t h

slide-2
SLIDE 2

2

Poor Requirements Management 2nd main cause for project failures.

PMI: Pulse of Profession 2015

48%

Overall

90%

Large projects

24%

Small projects

slide-3
SLIDE 3

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

Fortune 1000 Deployments

250+

Users

2.5+M

Extensions

200+

Registered Community Members

15K

slide-4
SLIDE 4

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?

slide-5
SLIDE 5

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?

slide-6
SLIDE 6

6 6 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

slide-7
SLIDE 7

7

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

slide-8
SLIDE 8

8

slide-9
SLIDE 9

9

slide-10
SLIDE 10

10 10

User Acceptance

Takeaway: Focus on user acceptance Why are MS Word Documents not enough?

  • Invisible requirements
  • Ignored requirements

?

slide-11
SLIDE 11

11 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?

slide-12
SLIDE 12

12 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
slide-13
SLIDE 13

13 13

Why?

  • Search for specification documents
  • Search for relevant requirements
  • What to search for?
  • Is this list complete?
slide-14
SLIDE 14

14 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

slide-15
SLIDE 15

15 15

slide-16
SLIDE 16

16 16

slide-17
SLIDE 17

17 17

Traceability

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

slide-18
SLIDE 18

18 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?

slide-19
SLIDE 19

19 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
slide-20
SLIDE 20

20 20

Not reliable

  • Not up-to-date
  • Changed without notification/approval
  • Change not propagated / analyzed
slide-21
SLIDE 21

21 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

slide-22
SLIDE 22

22

Large Data Scale 50k Requirements 20mil LoC

Impact Analysis

Functional Design

slide-23
SLIDE 23

23 23

slide-24
SLIDE 24

24 24

No time!

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

slide-25
SLIDE 25

25 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?

slide-26
SLIDE 26

26 26

60% of requirements are being reused

slide-27
SLIDE 27

27 27

Needs for Reuse

Distribute Regulatory Requirements New Versions

  • f your projects

Variants / Product Lines

slide-28
SLIDE 28

28 28

Derived Documents

Derived Documents

  • Share the regulatory requirements across the projects
  • Distribute the updates as necessary
  • Track additional properties with each individual copy

“The biggest benefit for WaveLight is the ease of reuse (of artifacts such as Requirements) across different projects.”

  • Werner Motzet, WaveLight

Safety Req Spec

  • Ver. 1.8

Safety Req Spec

  • Ver. 3.3

Safety Req Spec

  • Ver. 3.4

Product B Product A

Derive Update from 3.3 to 3.4

slide-29
SLIDE 29

29 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 copy-

paste duplication

  • "Visual Diff": Compare documents via change highlights
slide-30
SLIDE 30

30 30

Evolution of Variant Management

Polarion Polarion VARIANTS Add-on

slide-31
SLIDE 31

31

WASTE

slide-32
SLIDE 32

32 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?

slide-33
SLIDE 33

33

Agile / Traditional - WHEN

Specifications (Static) Written up-front User Stories (Dynamic) Written shortly before sprint

slide-34
SLIDE 34

34

Agile / Traditional - HOW

Specifications (Static) Written upfront “The system shall..” User Stories (Dynamic) Written shortly before sprint “I as a user want.. because..”

slide-35
SLIDE 35

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

slide-36
SLIDE 36

36

Traditional Agile

 Command & Control  Commend & Support

slide-37
SLIDE 37

37 37

Requirements

 Structured Specification  Not ordered  Overlapping  Easy to write

User Story

 Focused  Flat structure  Describes increments  Feasible to implement  Estimation Ready

slide-38
SLIDE 38

38 38

Progressive Requirement Specification

Product Documentation Component Specifications Requirements Epics Backlog User Stories

slide-39
SLIDE 39

39 39

39

slide-40
SLIDE 40

40 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?

slide-41
SLIDE 41

41 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

slide-42
SLIDE 42

42 42

Thank you.