Slides used in the "Gathering Requirements" breakout session by Dr Eugene O'Loughlin of the National College of Ireland (27th February, 2015).

1. Gathering Requirements
DR EUGENE O’LOUGHLIN,
SCHOOL OF COMPUTING,
NATIONAL COLLEGE OF IRELAND

2. Agenda
 Reality and Success
 Describe your job
 Horrible Requirements
 Critical Success Factors
 Impact of Poor Requirements
 Business Analysis Body of Knowledge (BABOK)
 Characteristics of Good Requirements

3. Reality
Image source: http://www.raymondjames.com/vandenboschcapitalmanagement/retirees.htm

4. What is Success?
Image source: http://daneecehernandez.internetlifestylenetwork.com/what-does-success-really-look-like

5. Project Failure

6. Project Failure – Why?
 Technology projects fail when they do not meet the
following criteria for success:
 Project delivered on time
 Project completed on or under budget
 The delivered solution works as required by business
stakeholders.

7. Factors Involved in Project Failure
 Lack of stakeholder involvement
 Unrealistic time scales
 Poor requirements
 Scope creep
 Uncontrolled changes
 Insufficient testing
Image source: http://www.leadernetworks.com/2013/04/avoid-online-customer-community-failure.html

8. Explain Your Job to Your Kids!
Image source: http://www.clipartpanda.com/clipart_images/parents-and-children-clip-art-8453141

9. Navigator (BA), Captain (PM)
Image source: Wikimedia Commons Image source: http://www.thewahine.co.nz/Captain.html

10. Typical?
“You start
programming and
I’ll go find out
what they want”

11. Taking Your Requirements Pulse
(Weigers & Beatty, 2013)

12. Five Horrible Requirements
#1 – “The system must have good usability”
#2 – “Response time should be less than 2 seconds”
#3 – “Round-the-clock availability”
#4 – The system shall work just like the previous system but on platform X
#5 – The system has to be bug-free
Ulf Eriksson (ReQtest)
Source: http://reqtest.com/requirements-blog/5-of-the-worst-requirements-i-have-ever-seen

13. Five (More) Horrible Requirements
#1 “Reporting”
#2 “Accessibility”
#3 “X cannot change”
#4 “Easy to use”
#5 “Robust”
Ulf Eriksson (ReQtest)
Source: http://reqtest.com/requirements-blog/5-of-the-worst-requirements-i-have-ever-seen

14. Lost in Translation
Image Source: http://reqtest.com/requirements-blog/chinese-whispers-in-requirements-management Image Source: https://commons.wikimedia.org/wiki/File:Flag-map_of_the_world.svg

15. Critical Success Factors (Weigers)
• A shared understanding of what requirements are and why we care
• Clearly defined business objectives
• Trained, skilled, and motivated business analysts
• A collaborative partnership with customers
• Rigorous and ongoing requirements prioritization
• Taking an incremental and iterative approach to requirements development
• Anticipating and accommodating change
Karl E. Wiegers

16. Critical Success Factors (Daly)
• Choose the right member of your team
• Meet with the customer early and often
• Ask questions
• Clarify what the system will not do
• No technical jargon allowed
• Document and reconfirm
• Revisit the requirements often
P.G. Daly (2003)

17. Impact of Poor Requirements
Image source: http://aoteastudios.com/files/poor-reqs-impact-poster.pdf

18. Ways to Improve the Situation
 Align high-level requirements with the strategic goals
 Work closely with stakeholders (mutual trust)
 Ensure that the high level requirements are
 Understood
 Accepted
 Fully agreed
…by Stakeholders before moving towards the business requirements

19. NOT…
The 3 most common tasks that are NOT part of
the Business Analyst Roles and Responsibilities
(but are often performed by Business Analysts):
 Taking minutes
 Creating Risk and Issue Logs
 Performing Testing
B
A

20. Lessons from Project Management:
What the Winners Do
 Winners clearly spell out what needs to be
done in a project, by whom, when, and how.
 For this they use an integrated toolbox,
including PM tools, methods, and techniques
 If a scheduling template is developed and
used over and over, it becomes a repeatable
action that leads to higher productivity and
lower uncertainty.
 Laggards exhibited almost no use of the
templates
Milosevic, D. & Ozbay, A. (2001) “Delivering Projects: What the Winners Do” Proceedings of the Project Management
Institute Annual Seminars & Symposium
Image source: http://photolesa.com

21. Requirements Elicitation
Requirements Elicitation Definition
◦ Webster's Encyclopedic Unabridged Dictionary
of the English Language…
◦ “elicit” is defined as "to draw or bring out or forth; educe; evoke"
Image source: http://www.goodreads.com

22. Categories of Requirements
Source: Paul, Yeates, & Cadle (2010) p172

23. Business Analysis Body of Knowledge
(BABOK)
“…generally accepted practices in the field of business analysis”
“ …confidence that the tasks and techniques described in the
BABOK Guide should be applicable in most contexts where
business analysis is performed, most of the time”
“…not be construed as a methodology for the performance of
business analysis”

24. BABOK Knowledge Areas

25. http://aoteastudios.com/files/business-analysis-poster.pdf

26. Insights from BABOK® Guide V3
Perspectives describe
specialized ways which
business analysis
professionals provide unique
value to the enterprise:
• Agile
• Business Intelligence
• Information Technology
• Business Architecture
• Business Process
Management
New techniques have been
added to the business
analysis tool belt.
• Backlog Management
• Business Model
Canvas
• Collaborative Games
• Decision Modelling
• Financial Analysis
• Prioritization
• Process Analysis
• Reviews
• Roles and Permission
The Business Analysis Core
Concept Model
™
uses key
concepts to define a conceptual
framework for business
analysis.
• Change
• Need
• Solution
• Value
• Stakeholder
• Context

27. Generally Accepted Techniques
BABOK p53

28. Requirements Elicitation Tasks (BABOK)
BABOK p54

29. Input/Output Diagram
Source: BABOK

31. Good Requirements
 Good requirements should have the following characteristics:
 Unambiguous
 Testable (verifiable)
 Clear (concise, terse, simple, precise)
 Correct
 Understandable
 Feasible (realistic, possible)
 Independent
 Atomic
 Necessary
 Implementation-free (abstract)
Source: Zielczynski, P. (2008). Requirements Management Using IBM® Rational® RequisitePro®. IBM Press.

32. Characteristics of Good Requirements
Unambiguous:
REQ1 The system shall not accept passwords longer than 15 characters.
It is not clear what the system is supposed to do:
• The system shall not let the user enter more than 15 characters.
• The system shall truncate the entered string to 15 characters.
• The system shall display an error message if the user enters more than
15 characters.
The corrected requirement reflects the clarification:
REQ1 The system shall not accept passwords longer than 15 characters. If
the user enters more than 15 characters while choosing the password, an
error message shall ask the user to correct it.
Source: Zielczynski, P. (2008). Requirements Management Using IBM® Rational® RequisitePro®. IBM Press.

33. Characteristics of Good Requirements
Testable:
REQ1 The search facility should allow the user to find a reservation based on Last
Name, Date, etc.
In this requirement, all search criteria should be explicitly listed. The designer and
developer cannot guess what the user means by “etc.”.
Source: Zielczynski, P. (2008). Requirements Management Using IBM® Rational® RequisitePro®. IBM Press.

34. Characteristics of Good Requirements
Clear (Concise, Terse, Simple, Precise):
REQ1 Sometimes the user will enter Airport Code, which the system will
understand, but sometimes the closest city may replace it, so the user does not
need to know what the airport code is, and it will still be understood by the
system.
This sentence may be replaced by a simpler one:
REQ1 The system shall identify the airport based on either an Airport Code or a
City Name.
Source: Zielczynski, P. (2008). Requirements Management Using IBM® Rational® RequisitePro®. IBM Press.

35. Characteristics of Good Requirements
Independent:
To understand the requirement, there should not be a need to know any
other requirement:
REQ1 The list of available flights shall include flight numbers, departure time,
and arrival time for every leg of a flight.
REQ2 It should be sorted by price.
The word “It” in the second sentence refers to the previous requirement.
However, if the order of the requirements changes, this requirement will not
be understandable.
Source: Zielczynski, P. (2008). Requirements Management Using IBM® Rational® RequisitePro®. IBM Press.

36. Characteristics of Good Requirements
Atomic:
The requirement should contain a single traceable element:
REQ1 The system shall provide the opportunity to book the flight,
purchase a ticket, reserve a hotel room, reserve a car, and provide
information about attractions.
This requirement combines five atomic requirements, which makes
traceability very difficult. Sentences including the words “and” or “but”
should be reviewed to see if they can be broken into atomic
requirements.
Source: Zielczynski, P. (2008). Requirements Management Using IBM® Rational® RequisitePro®. IBM Press.

37. EG: Detail (Data Fields)
Source: https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf

38. EG: Detail (Data Fields)
Source: https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf`
NAME FIELD
Should provide UTF-8 string of characters containing an
organization or user’s preferred name. When displaying the
value of this field, the label “Name” should be used.
ADDRESS FIELD
Should provide UTF-8 string of characters
corresponding to the organization, or user’s
physical address. When displaying the value of this
field, the label “Name” should be used.

39. Contact
@eoloughlin
www.eugeneoloughlin.com
www.youtube.com/eoloughlin
eoloughlin@ncirl.ie