Requirements

www.relaxedprojectmanager.com
+
Requirements

+
Real requirements
 Client : You seem to be the kind of guy who know what you are doing?
 Client : Educate me : What do you get when you rob a store ?
 Thief: Answer : money
 Client : How much give me a number ?
 Thief : 500 bucks
 Owner : That’s not possible
 Client : OK let’s say a minimum hundred. If you get shot than it emergency will cost you a
1000 bucks .
 Client : What are you going to buy with the money?
 Thief : Beer and Sandwich
 Client : How does 50 bucks of beer and sandwich sounds to you? I assume you are going
to run. That’s all what you can carry?

+
Definion of requirements
What is a Requirement?
 A requirement is something wanted or needed
 Formally documented and written statements
 Capabilities needed to solve a problem
 Conditions of a delivered system, services, product, or process
 Constraints on the system, service, product, or process
Requirements are not :
 Verbal, informal statements or conversations in the hallways
 Solutions that state how to solve the problem or meet the objectives
 Characteristics of other systems, services, products, or processes
 Project budgets, plans, or implementation details

+What are requirements ?
Conditions or capabilities needed by a
user/stakeholder
to solve problem or achieve an objective
Scope : the sum of the products, services and results
to be provided as a project
Project Scope :
the work that must be performed to deliver
a product, service or result with the
specified features and functions
Product Scope :
the features and functions that characterize
the product, service or result

+
What should happen ?

+
How to get close to the real
requirements ?

+
The importance of requirements
Stakeholders
Interests
Requirements
Product/
Service

+
Reasons for failure

+
Is there something like « real »
requirements
 People don’t express what they really need, they express what
they think they need
Esteem and
Belonging needs
Safety needs
Self Realisation

+
Why? Why? Why?
Problem: Your client is refusing to pay for the leaflets you printed for
them.
 Why? The delivery was late, so the leaflets couldn't be used.
 Why? The job took longer than we anticipated.
 Why? We ran out of printer ink.
 Why? The ink was all used up on a big, last-minute order.
 Why? We didn't have enough in stock, and we couldn't order it in
quickly enough.
Counter-measure: We need to find a supplier who can deliver ink at
very short notice.

+
Pain

+
Maslows pyramid of hierarchies

+
Requirements come from business
needs
 You need to know the business model
 On the internet : Advertising – Affiliates – Brokerage -
Merchant – Subscription – Information Community

+ “Set as a clockwork” : McDonald’s
Position : The first and best know fast food company
Process value: Easy food, clean, quick process for young, they get used to
the food and will be also customers when they are adult.
Processus clefs : garantie of fresh food.
Structure : Three layers of management(Restaurant Manager, First Assistant
Manager, Floor Manager, Crew)
Pouvoir : Business model is centralised (Marketing, business model, etc.).
Human ressources are decentralised.
Culture : Quick serving, fresh products, consumerism, US culture …

+
Where’s the pain?
The first and best known fast food company
Easy food, clean, quick process for young, they get used to the food and will
be also customers when they are adult.
garantie of fresh food.
Three layers of management(Restaurant Manager, First Assistant Manager,
Floor Manager, Crew)
Business model is centralised (Marketing, business model, etc.). Human
ressources are decentralised.
Quick serving, fresh products, consumerism, US culture …

+
What does this means for
requirements ?
Constraints === Requirements

+
Organisational Culture
onnel

+
Requirements
Business
Organisation
Individuals
Constraints === Requirements

+
What happens by not adressing the
requirements/constraints

+
Failure : Segway
 $100 million developing the product
 Price point too high for mass consumer base
 Classiefied road vehicle and required licencing

+
Failure : Cosmopolitan Yogurt
 58 international editions
 Client need is not yogurt

+Kano
Delighters
(surprise curve)
Performance
Needs curve
Basic
Needs
(Must have curve)
Not
implemented
Degree
Of fullfillement
Dissatisfied
Customer
satisfaction
Un conscious demand
Unexpected/not declared
Expected/Not declared

+
Methods and Tools to understand
requirements

+
What is Requirements Elicitation?
 Elicitation: gathering and understanding what stakeholders
and users need
 Done at both an organizational (business) and a more detailed user
level
 Elicitation is a human-based activity
 Determine requirements sources
 Decide how to gather information
 Involves research, reading, talking, and observing
 Business-level context and framework
How the end users do their jobs
What would help them do their jobs better
 Within the scope of our system, product, or process

+
How to find requirements ?
1. Lighter in stock
2. Point
of Sale
4. Household
waste
3. User
lights a
cigarette
Stakeholder 1
Stakeholder 2
Stakeholder 6
Stakeholder 7 Stakeholder 8
Stakeholder 3
Stakeholder 4
Stakeholder 5
Stakeholder 9

+How to gather requirements ?
SurveyMarket StudyInterview
Workshop
Brainstorm
Meeting
Prototypage

+
Interview technique
 Generally easy, because it can be
done with minimal preparation.
 Interviews of individuals and small
groups require less planning and
scheduling effort than large
workshops.
 Interviews of individuals and small
groups require less stakeholder
commitment than large workshops.
 Interviews provide an opportunity to
explore or clarify topics in more detail.
 The questions used in the interview may
reflect the interviewer’s preconceived
ideas, which can influence the
responses.
 For projects with a large number of
stakeholders the interviews technique
can be time-consuming and inefficient.
 Conflicts and inconsistencies between
stakeholder information need to be
resolved in additional interviews.
 This technique does not allow different
stakeholders to hear and elaborate upon
the information being relayed.
Advantages Disadvantages

+
Joint Application Development
(JAD) Techniques
 This technique allows for the
simultaneous gathering and
consolidating of large amounts of
information.
 This technique produces relatively
large amounts of high-quality
information in a short period of time.
 Discrepancies are resolved
immediately with the aid of the
facilitator.
 This technique provides a forum to
explore multiple points of view
regarding a topic.
 Requires significant planning
and scheduling effort.
 Requires significant stakeholder
commitment of time and effort.
 Requires trained and
experienced personnel for
facilitation and recording.

+
Survey method
 A survey can reach a large number of
stakeholders or other sources of
information.
 A survey is an excellent tool to gather a
significant amount of focused data in a short
period of time.
 Survey method can provide good results
when used to validate assumptions after the
use of the interviewing technique.
 A Survey method is a good tool to gather
statistical preference data.
 A survey requires little scheduling effort.
 A survey requires little stakeholder
commitment of time and effort.
 The response level is often low,
especially to large surveys.
 Responses are usually limited to the
realm of the questions asked, which
reflect the analyst’s preconceived ideas
or assumptions of the survey designer.
 Well-made surveys require trained and
experienced personnel to develop.
 Development time can be significant.
 5. Conflicts and inconsistencies in
information from stakeholders require
additional analysis to resolve.

+What’s a user story
• As a user/stakeholder ...
• I want to … achieve a goal
• So that I can … get some
value

+
How to guaranty quality of
requirements
Stories should be I.N.V.E.S.T:
Independent – Negotiable– Valuable
Estimable – Right Sized – Testable
But also :
Unambiguous – Complete – Verifiable –
Consistent – Modifiable - Traceable

+
Complete
 Inclusion of all significant functional and non-functional
requirements
 Specification of the responses to valid and invalid input values
 Conformity to any standard that applies
 Full labeling and referencing of all figures, tables, and diagrams and
definition of all terms and units of measure
 Any RD&S that uses the phrase to be determined (TBD) is not
complete

+
Unambiguous
Every requirement has only one interpretation
Each characteristic is described using only one term
 Example of ambiguous requirement:
 All customers have the same control field
a) All customers have the same value in their control fields
b) All customers control fields have the same format
c) One control field is issued for all customers

+
Consistent
 No set of individual requirements conflicts
 Examples:
• One requirement might state the format on the output
 One requirement might state the format on the output : a field is
report as tabular, but another as textual

+
Modifiable
 Necessary changes to the requirements can be made easily,
completely, and consistently
 Coherent, easy-to-use organization – table of contents, an
index, explicit cross-referencing
 • Not be redundant

+
They want it all: ask your customer
 How fast should the service/product perform?
 How available should the service/product be?
 How about security?
 — As fast as possible!
— 24 x 7 x 365!
— Everything should be secure!

+
 Customer: We want to have 100% system uptime.
 Architect: OK, that might be doable, but requires all
components to be redundant and eligible for automatic failover.
That would take a year and $1,000,000 to implement.
As an alternative, we can build a simpler system for $500,000
in 8 months but it will require manual maintenance in case of
failure. Which one would be more suitable for you at this
point?
 Customer: Let’s build the second option, it’s much cheaper
and faster. We’re a startup and time-to-market is our top
priority.

+
Wouldn’t you?
 Speak to stakeholders in their own language.
 Explain the tradeoffs in terms of cost, schedule, and realism.
 Together, try to come up with specific, measurable NFRs.
 Prioritize: the domain matters a lot!

What are Non Functional Requirements
“Functional requirements define WHAT a system
is supposed to do”
“Non-Functional requirements define HOW a
system is supposed to be”

+
Knowing of non-functional
requirements
Helps to avoid of customers say
„You should thing better!“

+
Non-functional requirements are
aspects
• Users have implicit expectations about how well the software
will work.
• These characteristics include
• how easy the software is to use,
• how quickly it executes,
• how reliable it is,
• and how well it behaves when unexpected conditions arise.
• The non-functional requirements define these aspects about
the system.

+
Non Fuctional Requirements -
General
• Security
• Exception Handling
• Validation
• Logging
• Tracing / Testing
• Monitoring / Reliability
• Transaction
• Storage
• GUI Binding
• Configuration

+ Non Fuctional Requirements– System
/ Dev
• Naming conventions
• Caching, Performance
• Scalability
• RAM usage
• Thread Sync

+ How to fetch non-functional
requirements?
• Anti-stories are things the user does not want to happen, commonly
for safety or security reasons.

+
Security
- Should access to be limited?
- Is an access list necessary?
- Access Control List
- White List
- Black List

+
Exception handling
- What errors can occur on runtime?
- What it should do in case of error?

+
Validation
• Which input items are required?
• Which of them need to be validated?
• What to do if input is invalid?
• How to recognize if an item is valid? (email, personal number,
ZIP code...)
 Be aware - customer tends to change it frequently!

+
Logging
• It is about loggin from the user perspective, not developer’s logging
• Which events should be logged?
• Which items should log contain?
• Is the last operation enough or you need history?
• How deep the history should be?
• Where to log? (file/db/…)
• Who should have access to logs?
• Incremental or rotation log?
• How to purge/delete logs?

+
Tracing - testing
• How to test an application?
• Which parts of the application should traceable?

+
Transaction
• Which operation is „atomic“- what must be proceeded all at
once?
• How to do rollback/cancel an operation?

+
Satisfied Dissatisfied Neutral
Don’t
care
Dissatisfied
If I didn’t have this …
If had this …
Making decisions on features

+
How to manage requirements?
 Fundamental Needs - Usages scenarios
 Requirements linked to the usage
 Constraints
 Priorities
Main
Needs
Specific
requiremen
ts linked to
the need
Level of
required
perform
ance
Measures
and tests
to verify
that de
deliverable
MoSCoW Status

+
Must Have Could Have
Should
Have
Won’t Have
Use MoSCoW to prioritize requirements !
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement 1
Requirement 2
Requirement 3 Requirement 4
Requirement 5
Requirement 6

Requirements

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Requirements

Ähnlich wie Requirements (20)

Mehr von Stefan Csosz

Mehr von Stefan Csosz (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Requirements