Mastering
Requirements
Silvia Cojocariu
Diana Antohi
21 aug 2014
Agenda
Agenda
● BA role?
● Requirements elicitation
● Writing requirements
● Q&A
BA role?
Key areas of responsibility
•Investigating business situations
•Identifying and evaluating options
•Defining requirements
•Ensuring the effective use of information
systems
From requirements to solution
decreasing abstractization
WHAT
HOW
•
Why we undertake the project (business objectives, project goal)
•
What the user will be able to do with the product (use cases, scenarios,
stories)
•
What the team builds (features, functional req., product characteristics)
•
System components and how they fit together
•
Behavior of individual components
•
Implementation of each component
Scope breakdown
●
What the user will be able to do with the product (use cases,
scenarios, stories)
Scope breakdown
Business Use Cases
Business Event:Customer decides to pay using Pay.Safe
Preconditions: The customer does not have an online account
Trigger: Customer registers for an online account (create account
request)
Business Use Case: Decide on account creation
Interested Stakeholders: banks, merchants, buyer
Active Stakeholders: Buyer (the customer)
- The customer requests the account creation for a specific bank
-The customer is requested to provide a card issued by that specific
bank
- If the customer provides an eligible card, account is created
otherwise
the user is asked to provide another card
Outcome: The decision on account creation is done and the customer
is notified
Determine requirements
What the team builds (features, functional req., product characteristics)
Functional requirements
• identify what the system does , how it functions => describing the
behavior of the system
Non-functional
• place constraints on how the system will do so.
Functional
Non-Functional
Product features.
Product properties.
Describe the actions with
which the user work is
concerned.
Describe the experience of
the user while doing the work.
Characterized by
verbs (active)
Characterized by
adjectives.
Functional requirements
typically are written at the level of what a given “user/personas” can
get the system to do
So that {I receive some benefit}
as a {user} / { personas},
I can {do something}
Non-functional requirements
Elaborates a performance characteristic
• are sometimes defined in terms of metrics (something that can be
measured about the system) to make them more tangible.
Captured in
– special NFR’s requirements
– or in AC
Non-functional requirements
Non-functional requirements
Reliability
The Card management must provide 99% availability during normal operating hours i.e.
07:00 to 19:00 hours a day, 6 days per week
Recoverability
In the event of disruption to the Card management service, the service must be restored
up to the last transaction/event within 1 hour (from point of failure).
Back-Up & Restore
In the event of disruption to the on boarding test environment service and support tools to
bank, the service must:
- be restored within 12 hours from point of failure
- restore the data from the previous day
Non-functional requirements
Compatibility
The solution must be compatible with the following versions of the Internet Explorer
browser:
- IE7,IE8,IE9 - Current stable version
The solution must adhere to Web Content Accessibility Guidelines (WCAG 2.0) Level AA.
Security
For file-level encryption, public-private key cryptography must be used for authentication
as opposed to username/password.
Passwords (where used) shall be:
a) Minimum 8 characters
b) Alphanumeric and minimum 1 special character
c) Lockout after 3 invalid login attempts
d) Force change on first login after reset
e) Passwords shall never be displayed in clear text
Requirements elicitation - Using…
•
Personas
•
Prototyping
•
Scenarios
•
Data model - CRUD
Personas
Personas
Online banking personas:
Jay -- the Reactive
Consumer
Karen -- the Improver
Elizabeth -- the Balanced
Achiever
Source: http://ecommerce.about.com/
Personas
Jay: The Reactive Consumer
●
is notable for his lack of guidance,
●
lack of direction and motivation,
●
as well as his impulsive spending and overall level of financial stress,
●
unorganized,
●
finds financial management very stressful
●
avoid paying bills whenever possible.
Karen: The Improver
●
is notable for her awareness
●
no motivation to improve her financial circumstances,
●
she finds financial management stressful
●
actively seeking help with finances.
Source: http://ecommerce.about.com/
Personas
Elizabeth: The Balanced Achiever:
●
Is notable for her healthy financial habits and peace of mind,
●
she is interested in making the most of her existing financial assets
●
she values her personal time,
●
use credit cards heavily for the miles/points and financially secure,
●
likes to try the latest products and services
●
she considered herself knowledgeable about technology
Source: http://ecommerce.about.com/
Scenarios
Classic/exception scenarios
Classic/exception scenarios
“Bad guy” scenarios
A case from the point of view of
an actor hostile to the system
designed
'what-if' - goes beyond happy-day scenarios
Identify NFRs
Response is often a SubSystem Function,
possibly to handle an Exception
•
Identifying Test Cases => Mitigate the
misuse cases
•
there will be several misuse cases for each
BUC and PUC
•
design Trade-offs
Prototypes
Data model
CRUD = Create Retrieve Update Delete
•
Every data class must have a business event to Create it and another to
Retrieve it
•
CRUD check ensures all events were captured
In order to have a healthy financial account
As a Balanced Achiever,
I can manage my account. =>
...I can sign up for an account.
...I can edit my account settings.
...I can cancel my account.
Write the requirements
Write the requirements
Card, Conversation and Confirmation (Jeffries 2001)
● a written description of the story used for planning and as a reminder
● conversations about the story that serve to flesh out the details of the story
● tests that convey and document details and that can be used to determine
when a story is complete
Write the requirements
Good practice: Invest in your stories to tell
Independent
Negotiable
Valuable to users or customers
Estimable
Small
Testable
Breakdown requirements
Breakdown requirements
Demand item
In order to offer support on payments for American customers, as an American bank,
I want the online payment solution to integrate the ePay brand
Epic 1
In order to offer support on payments for American customers, as an American
bank, I want the online user account to support managing an ePay branded card
S1
S2
Epic 2
In order to offer support on payments for American customers, as an American
bank, I want the checkout portal to support a payment transaction with a ePay
branded card
Breakdown requirements
Epic 1
Stories
In order to manage my ePay card, as a Balanced Achiever, I want my
ePay card to be recognized as valid when managed into my online
account
In order to offer support for payments for American customers, as an
American bank, I want the card management portal to display the
acceptance mark of the ePay brand.
Prioritizing requirements
MOSCOW
• Must have (Minimum Usable SubseT)
• Should have
• Could have
• Would/Won’t have
Definition of ready
•
Lets everyone know when a requirement is really ready to be
implemented
•
It does not need to be “100% defined” with all acceptance criteria,
etc.
•
It should be “ready enough” so that the team is confident they can
successfully deliver the requirement.
Thoughts to take away
From requirements to solution
● identify/clarify scope and stakeholders
● scope breakdown
● requirements elicitation using Personas, Scenarios, Prototypes,
Data models
● write requirements
- structure
- breakdown
- prioritize
- readiness check
Q&A
Thank you
[email protected]
[email protected]