Embed Size (px)
Citation preview
Gathering RequirementsDR EUGENE O’LOUGHLIN,
SCHOOL OF COMPUTING,
NATIONAL COLLEGE OF IRELAND
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
Reality
Image source: http://www.raymondjames.com/vandenboschcapitalmanagement/retirees.htm
What is Success?
Image source: http://daneecehernandez.internetlifestylenetwork.com/what-does-success-really-look-like
Project Failure
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.
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
Explain Your Job to Your Kids!
Image source: http://www.clipartpanda.com/clipart_images/parents-and-children-clip-art-8453141
Navigator (BA), Captain (PM)
Image source: Wikimedia Commons Image source: http://www.thewahine.co.nz/Captain.html
Typical?
“You start programming and
I’ll go find out what they want”
Taking Your Requirements Pulse (Weigers & Beatty, 2013)
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
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
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
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
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)
Impact of Poor Requirements
Image source: http://aoteastudios.com/files/poor-reqs-impact-poster.pdf
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
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 TestingBA
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
Requirements ElicitationRequirements 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
Categories of Requirements
Source: Paul, Yeates, & Cadle (2010) p172
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”
BABOK Knowledge Areas
http://aoteastudios.com/files/business-analysis-poster.pdf
Insights from BABOK® Guide V3Perspectives 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
Generally Accepted Techniques
BABOK p53
Requirements Elicitation Tasks (BABOK)
BABOK p54
Input/Output Diagram
Source: BABOK
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.
Characteristics of Good RequirementsUnambiguous:
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.
Characteristics of Good RequirementsTestable:
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.
Characteristics of Good RequirementsClear (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.
Characteristics of Good RequirementsIndependent:
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.
Characteristics of Good RequirementsAtomic:
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.
EG: Detail (Data Fields)
Source: https://darkmail.info/downloads/dark-internet-mail-environment-december-2014.pdf
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.
