business analyst requirements management
DESCRIPTION
TRANSCRIPT
Requirements Management Requirements Management
The Foundation of the Business Analyst’s The Foundation of the Business Analyst’s PracticePractice
Do Formal Requirements still matter?Do Formal Requirements still matter?
• What does the Agile development world mean to Business Analysts?
• Myths concerning “Agile” and requirements management– “Working code is all that is needed” – “All we need are stories?” – “Small self organizing team can manage architecture” – “Small self organizing team can manage non functional
requirements” – “Agile processes have built-in governance”
Requirements matter now more then ever!Requirements matter now more then ever!
% of Projects that are Successful
Requirements Maturity = Strong FoundationRequirements Maturity = Strong Foundation
Without Requirements we can’t prove completionWithout Requirements we can’t prove completion
• Requirements are the contract between business customer and development/IT• Requirements are only as good as their management• Requirements management key components:
– Requirements definition– Requirements organization and process– Requirements traceability– Requirements change management– Requirement re-use
Requirements Definition Best Practices - TypesRequirements Definition Best Practices - Types
• Not all requirements are created equal• Requirements must have types and attributes• “FURPS+” is a good guide
– Functionality - What the customer wants! Note that this includes security-related needs.
– Usability - How effective is the product from the standpoint of the person who must use it? Is it aesthetically acceptable? Is the documentation accurate and complete?
– Reliability - What is the maximum acceptable system downtime? Are failures predictable? Can we demonstrate the accuracy of results? How is the system recovered?
– Performance - How fast must it be? What's the maximum response time? What's the throughput? What's the memory consumption?
– Supportability - Is it testable, extensible, serviceable, installable, and configurable? Can it be monitored?
– + - addresses design constraints, physical systems needs, interfaces, design rules
Requirements Definition AbstractionRequirements Definition Abstraction
• Four example requirements for an insurance claims processing application:– “We must be able to reduce our backlog of claims” – “The system must be able to automatically check claim forms for eligibility
issues” – “The system shall determine whether a claimant is already a registered
user, based on his/her social security number”
– “The system shall support the simultaneous processing of up to 100 claims” • Requirements have type and abstraction level
– Business needs – Features – Functional software requirements – Non-functional software requirements
What is Agile DevelopmentWhat is Agile Development
• The Manifesto for Agile Software Development– Individuals and interactions over processes and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation – Responding to change over following a plan
SCRUM – An Agile Development ProcessSCRUM – An Agile Development Process
The SCRUM RolesThe SCRUM Roles• The Product Owner represents the stakeholders, ensuring that the team
delivers value to the business. The Product Owner writes customer-centric items user stories, prioritizes them, and adds them to the product backlog
• The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.)
• Scrum Master - Scrum is facilitated by a Scrum Master who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables
• Stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefits that justify its production. They are only directly involved in the process during the sprint reviews
SCRUMSCRUM - Business Analysts as Product Owners
• Product owners are the interface between business and technology implementers.
• User Stories are Agile Requirements• (User) Story
– A feature that is added to the backlog is commonly referred to as a story and has a specific suggested structure. The structure of a story is: "As a <user type> I want to <do some action> so that <desired result>" This is done so that the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand
– Example: “As a mobile banking customer I want to take a picture of check from smart phone so I can see deposit instantly”
Are stories enough?Are stories enough?
• A story - “As a mobile banking customer I want to take picture of check from smart phone so I can see deposit instantly.”
• Stories often lead to other requirements that need to be typed and organized– “mobile check deposit” leads to architectural requirements of persistence,
storage, image support– “mobile check deposit” leads to non functional requirements such as image
throughput bandwidth, response time, security– “mobile check deposit” likely needs function requirements decomposition
for imaging components, for image quality analysis, user verification etc.
Stories DetailedStories Detailed
• Stories can be elaborated using traditional methods!
User Story
UI mock ups
Use Cases
Architecture DiagramsBPMN
Others
…..
…..
Requirements Structure in an Agile worldRequirements Structure in an Agile worldP
ortf
olio
Level Requirements Backlog Owner Requirement Types
Portfolio ManagerThemes
Business Vision
Pro
gram
Program Manager Architectural Requirements
Features
Pro
ject
Product OwnersStories
Spikes
Release Manager
Scrum Master
Agile Team Members
1
*
1
*
Epics
Traceability
Requirements Organizational ConstructsRequirements Organizational Constructs
• Hierarchy• Modules• Links• Baselines
UREQ1UREQ2UREQ3UREQ4UREQ5UREQ6UREQ7UREQ8UREQ9UREQ10
User Requirements
SREQ1SREQ2SREQ3SREQ4SREQ5SREQ6SREQ7SREQ8SREQ9
SREQ10
Systems Requirements
TREQ1TREQ2TREQ3TREQ4TREQ5TREQ6TREQ7TREQ8TREQ9
TREQ10
Test Requirements
Version 2.0
Requirements Definition Best Practices - TraceabilityRequirements Definition Best Practices - Traceability
• Traceability is a dependency relationship between artifacts.• It is a methodical approach to managing process and relationship between artifacts• Wikipedia:
– Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction
– Requirements traceability refers to the ability to define, capture and follow the traces left by requirements on other elements of the software development environment and the trace left by those elements on requirements
Why Traceability is important?Why Traceability is important?
• Determine the origin of any requirement • Ensure quality
– You can verify that the software fulfills all requirements – You can verify that the software does only what was requested
• Help with requirement change management • Analyze impact of a change to a requirement. For example, if a
feature is modified, traceability enables you to determine: – Which use cases need to be modified – Which supplementary requirements are affected
• Auditiblity/Regulatory certification (DO178B, Sarbanes-Oxley…)• “Every line of code should be directly traceable to a requirement, no
extraneous code outside of this process should be included in the build” – DO178B
Simple link vs. TraceabilitySimple link vs. Traceability
Simple link e.g. hyperlink • Unbounded, and unstructured• Implicit semantics• Unidirectional• Ad-hoc
Traceability• Bounded• Explicit well defined semantics• Bi-directional• Often process governed
Traceability Anti-patternTraceability Anti-pattern
- Requirements in MS Word Documents
- Tests in Excel- Link by a common ID
Requirements – Standard ModelsRequirements – Standard Models
• Common Model
• More detailed requirement model
QualifiesRequirement
Implements
Change Request
Test Case
Manages
Effects
Use CaseSystem Requirement
User Requirement
Satisfies
Defines
Requirements – Sanitize, Clarify and ConsolidateRequirements – Sanitize, Clarify and Consolidate
• Usage: to collate together requirements (possibly from several sources) into an agreed specification.
• Link Type: “Satisifies".• When Appropriate
– When there is a need to clarify and standardize terminology.– When there is a need to reconcile conflicting requirements from different sources.
Information Source 2
Collection or Module
Satisfies
Information Source 1
Information Source 3Asdf lksad lk as;lSdfaasdfDsfdasdfasdfAsdasdfasdfasdFasdfasdfasdfa dsfjsadajs flkasdj f;asdaskd jf;laj aw;ief a;lsdjf ;lajf ;alsjf ;alsfa;lsjf lksajf ;lsa ;ahgawoie a;sdhgaasdga adsfasdfwefawgfasdvasg ; aksd lkja flksadf lkajsflkasjf sajf ladsjfla fiwa elkvsz dj asd jfjfs d asdjf asdfjdsf ajf lkwaj lfwalkef jajf ajflksadjf ajf lksajf alskdjf alksdjf aflksaf ksafdj alskdfj alsdfj alsjf lasjf lksajf alksjf alks jf ds jfalf alsjfa sf safd
Satisfies
Satisfies
User Requirement
User Requirement
User Requirement
User Requirement
Requirements – DependencyRequirements – Dependency
• Usage: when requirements are dependent on other requirements being satisfied. Structure is
• Link Type: "depends on".
Depends
System Requirement 1
System Requirement 2
User Requirement 1Satisifies
User Requirement 2Satisifies
Requirements – Test Case CoverageRequirements – Test Case Coverage
• Usage: Show that specific tests are to be carried out proving application meets requirement.
• Link type: “Qualifies” (or “Verify”)
QualifiesRequirement
Implements
Change Request
Test Case
Manages
Effects
Requirements – Architecture as a constraintRequirements – Architecture as a constraint
• Usage: when architecture is predetermined, rather than derived from the requirements.
• Link type: “Constrains”
Satisifies
Architecture
User Requirement
Satisifies
Constrains
Constrains
System Requirement
Sub-System Requirement
Traceability – Impact AnalysisTraceability – Impact Analysis
Traceability and ChangeTraceability and Change
Lifecycle ToolRequirementsManagement
User Requirements
System Requirements
Test Cases
Change in User
Requirements
Lifecycle ToolQualityManagement
The Consequences of ChangeThe Consequences of Change
Lifecycle ToolRequirementsManagement
User Requirements
System Requirements
Test Cases
Lifecycle ToolQualityManagement
Change in User
Requirements
Artifacts become suspect
Test Cases
Lifecycle ToolQualityManagement
Lifecycle ToolRequirementsManagement
User Requirements
System Requirements
Artifacts become suspect
Cross toolsuspect artifacts
Change in User
Requirements
Change in System
Requirements
The Consequences of ChangeThe Consequences of Change
Requirements Change Management Best PracticeRequirements Change Management Best Practice
• Requirements can be managed like any other form of work item (task)– Managed with a lifecycle– Assigned, reviewed, approved by appropriate roles based
stakeholders– Important in high compliance or governed environments (audit
history)– A mechanism to document impact analysis exercise
Requirement Re-use Best PracticesRequirement Re-use Best Practices
CREQ1CREQ2CREQ3CREQ4CREQ5CREQ6
CoreApplication
Requirements
MREQ1MREQ2CREQ1MREQ3CREQ2CREQ4MREQ4MREQ5CREQ5CREQ6
Mobile Application
RequirementsTREQ1CREQ1TREQ2TREQ3CREQ3TREQ4TREQ5TREQ6CREQ5CREQ6
Call CenterApplication
Requirements
• Module can embed requirements from others
• Requirements can extended or specialized
Summary - Applications are only as good as Summary - Applications are only as good as their Requirementstheir Requirements• Requirements are the contract between business customer and development/IT• Requirements are only as good as their management• Requirements management key components:
– Requirements definition– Requirements organization and process– Requirements traceability– Requirements change management– Requirement re-use
BibliographyBibliography
• Writing good requirements is a lot like writing good code Jim Heumann, IBM, Software Group, 14 Jul 2004
• IIBA BABOK Guide V2.0, 2009• Six Things Your CIO Needs to Know About Requirements Maturity, IAG Consulting,
2012• Agile Software Requirements, Dean Leffingwell, 2011• The Benefits of Well Managed Traceability, Ed Genrty, Innovate 2012