1. Requirements Management
The Foundation of the Business Analyst’s
Practice

2. 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”

3. Requirements matter now more then ever!
% of Projects
that are
Successful

4. Requirements Maturity = Strong Foundation

5. Without 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

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

7. Requirements 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

8. What 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

9. SCRUM – An Agile Development Process

10. The 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

11. SCRUM - 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”

12. 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.

13. Stories Detailed
• Stories can be elaborated using traditional methods!
User Story
… ..
UI mock ups
Others
Use Cases
… ..
Architecture Diagrams
BPMN

14. Requirements Structure in an Agile world
Level Requirements Backlog Owner Requirement Types
Themes
Portfolio
1 Portfolio Manager
Business Vision
Epics
Traceability
*
Program Manager Architectural
Program
Requirements
1 Release Manager
Features
Product Owners
Stories
Project
*
Scrum Master
Spikes
Agile Team Members

15. Requirements Organizational Constructs
• Hierarchy
• Modules
• Links User Systems Test
Requirements Requirements Requirements
• Baselines TREQ1
UREQ1 SREQ1
UREQ2 SREQ2 TREQ2
UREQ3 SREQ3 TREQ3
UREQ4 SREQ4 TREQ4
UREQ5 SREQ5 TREQ5
UREQ6 SREQ6 TREQ6
UREQ7 SREQ7 TREQ7
UREQ8 SREQ8 TREQ8
UREQ9 SREQ9 TREQ9
UREQ10 SREQ10 TREQ10
Version 2.0

16. Requirements 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

17. 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

18. Simple link vs. Traceability
Simple link e.g. hyperlink Traceability
• Unbounded, and unstructured • Bounded
• Implicit semantics • Explicit well defined semantics
• Unidirectional • Bi-directional
• Ad-hoc • Often process governed

19. Traceability Anti-pattern
- Requirements in MS Word
Documents
- Tests in Excel
- Link by a common ID

20. Requirements – Standard Models
• Common Model
• More detailed requirement
model

21. Requirements – 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.

22. Requirements – Dependency
• Usage: when requirements are dependent on other
requirements being satisfied. Structure is
• Link Type: "depends on".

23. Requirements – Test Case Coverage
• Usage: Show that specific tests are to be carried out
proving application meets requirement.
• Link type: “Qualifies” (or “Verify”)

24. Requirements – Architecture as a constraint
• Usage: when architecture is predetermined, rather
than derived from the requirements.
• Link type: “Constrains”

25. Traceability – Impact Analysis

26. Traceability and Change

27. The Consequences of Change

28. The Consequences of Change

29. Requirements 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

30. Requirement Re-use Best Practices
• Module can embed Call Center
Mobile
Application requirements from others Application
Requirements Requirements
MREQ1 • Requirements can TREQ1
MREQ2 CREQ1
CREQ1 extended or specialized TREQ2
MREQ3 TREQ3
CREQ2 CREQ3
CREQ4 Core TREQ4
MREQ4 Application TREQ5
MREQ5 Requirements TREQ6
CREQ5 CREQ5
CREQ6 CREQ6
CREQ1
CREQ2
CREQ3
CREQ4
CREQ5
CREQ6

31. Summary - Applications are only as good as
their 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

32. Bibliography
• 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