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”
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
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
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
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”
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
Hinweis der Redaktion
Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against
Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against
Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against
Source Information modules contain information from any relevant sources. Each could contain collected notes from meetings, emails or entire documents. The Stakeholder Requirements module is the module wherein all the information in the source modules is collated. This collation process must include identification and resolution of conflicts, duplications, irrelevance, etc. The intent is that the module contains a well-written, well-structured requirements specification that can be agreed by all the relevant stakeholders.
For example, there is no point in being able to bill customers if no records are kept of their expenditure. Two requirements at the same level and A depends on B being met.
Although the pattern refers to 'Test Cases", in practice, the same could apply for any test or qualification information Need to add test points to a device. These points are not needed normally. Access coverers for mechanical
The major aspects of this information model are as follows: Specification documents are shaded blue, and are related through “satisfies” links. The Architecture is related to the Specification documents through “constrained by” links. In other words, the Architecture is used to hold design constraints from the design philosophy, for example “use polling not interrupts”. This Link Module captures those relationships that demonstrate how a requirement is constrained by an element in the architecture.
Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against
Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against