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 projects 2
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+ 2.5+M 200+ 15K Registered Fortune 1000 Users Extensions Community Deployments Members 3
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
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
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 6 6
#1 - MS Word Documents 50% - plain text specifications 7
8
9
User Acceptance Takeaway: Focus on user acceptance ? Why are MS Word Documents not enough? • Invisible requirements • Ignored requirements 10 10
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 11
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 12
Why? • Search for specification documents • Search for relevant requirements • What to search for? • Is this list complete? 13 13
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 14
15 15
16 16
Traceability Takeaway: Focus on traceability Traceability is about data structure and exposure, it does not ensure application of requirement. 17 17
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 18
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 19
Not reliable • Not up-to-date • Changed without notification/approval • Change not propagated / analyzed 20 20
Secure collaboration • Online collaboration • Lifecycle definition • Version management • Control who can change what and WHEN • Permissions to control • Impact propagation access rights through suspect links • Workflow Automation : enforcement of SOP 21 21
Impact Analysis Functional Design Large Data Scale 50k Requirements 20mil LoC 22
23 23
No time! It slows down our productivity, we have no time for managing requirements properly. 24 24
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 25
60% of requirements are being reused 26 26
Needs for Reuse Distribute Regulatory New Versions Variants / Product Lines Requirements of your projects 27 27
Derived Documents Safety Derived Documents Req Spec • Share the regulatory requirements across the projects Safety • Distribute the updates as necessary Req Spec • Track additional properties with each individual copy Ver. 3.4 Safety Req Spec Update from 3.3 to 3.4 Ver. 3.3 Derive Ver. 1.8 Product B Product A “The biggest benefit for WaveLight is the ease of reuse (of artifacts such as Requirements) across different projects.” - Werner Motzet, WaveLight 28 28
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 29 29
Evolution of Variant Management Polarion VARIANTS Add-on Polarion 30 30
WASTE 31
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 32
Agile / Traditional - WHEN User Stories Specifications (Dynamic) (Static) Written shortly before sprint Written up-front 33
Agile / Traditional - HOW User Stories Specifications (Dynamic) (Static) Written shortly before sprint Written upfront “I as a user want.. because..” “The system shall..” 34
Agile / Traditional - LIFESPAN User Stories Specifications (Dynamic) (Static) Written shortly before sprint Written upfront “I as a user want.. because..” “The system shall..” Discarded when done Maintained 35
Traditional Command & Control Agile Commend & Support 36
User Story Requirements Focused Structured Specification Flat structure Not ordered Describes increments Overlapping Feasible to implement Easy to write Estimation Ready 37 37
Progressive Requirement Specification Product Documentation Requirements Backlog Component Specifications Epics User Stories 38 38
39 39 39
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 40
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 41
Thank you. 42 42
Recommend
More recommend
