CS445/ECE 451/CS645

Software Requirements Specifications & Analysis

Elicitation
To elicit means “to bring out, to evoke, to call forth”

U Waterloo CS445/ECE451/CS645 Winter 2019 1

Purpose
The purpose of elicitation is to get information about:
• Current work and current problems
• The requirements of the system
• The environment in which the system will operate

In order to:
• identify relevant requirement resources
• elicit existing requirements from the identified sources
• develop new and innovative requirements

U Waterloo CS445/ECE451/CS645 Winter 2019 2

 The expectation gap
Without adequate customer
involvement, the inescapable
outcome at the end of the project is
an expectation gap, a gulf between
what customers really need and
what developers deliver based on
what they heard at the beginning of
the project (Wiegers 1996).

U Waterloo CS445/ECE451/CS645 Winter 2019 3

 Who is the stakeholder?
A stakeholder is a person, group, or organization that is
actively involved in a project, is affected by its process or
outcome, or can influence its process or outcome.
Stakeholders can be internal or external to the project team
and to the developing organization.

U Waterloo CS445/ECE451/CS645 Winter 2019 4

U Waterloo CS445/ECE451/CS645 Winter 2019 5
 Who is the customer?
Customers are a subset of stakeholders. A customer is an individual or
organization that derives either direct or indirect benefit from a product.
Software customers could request, pay for, select, specify, use, or receive the
output generated by a software product.

U Waterloo CS445/ECE451/CS645 Winter 2019 6

 The customer-development partnership
• An excellent software product results from a well-executed design based on
excellent requirements.
• Excellent requirements result from effective collaboration between
developers and customers — a partnership.
• A collaborative effort can work only when all parties involved know what
they need to be successful and when they understand and respect what
their collaborators need to be successful.
• As project pressures rise, it’s easy to forget that all stakeholders share a
common objective: to build a product that provides adequate business value
and rewards to all stakeholders.
• The business analyst typically is the point person who has to forge this
collaborative partnership.
U Waterloo CS445/ECE451/CS645 Winter 2019 7
 Requirements Bill of Rights for Software Customers
You have the right to
1. Expect BAs to speak your language.
2. Expect BAs to learn about your business and your objectives.
3. Expect BAs to record requirements in an appropriate form.
4. Receive explanations of requirements practices and deliverables.
5. Change your requirements.
6. Expect an environment of mutual respect.
7. Hear ideas and alternatives for your requirements and for their solution.
8. Describe characteristics that will make the product easy to use.
9. Hear about ways to adjust requirements to accelerate development through
reuse.
10. Receive a system that meets your functional needs and quality expectations.
U Waterloo CS445/ECE451/CS645 Winter 2019 8
Requirements Bill of Responsibilities for Software Customers
You have the responsibility to
1. Educate BAs and developers about your business.
2. Dedicate the time that it takes to provide and clarify requirements.
3. Be specific and precise when providing input about requirements.
4. Make timely decisions about requirements when asked.
5. Respect a developer’s assessment of the cost and feasibility of requirements.
6. Set realistic requirement priorities in collaboration with developers.
7. Review requirements and evaluate prototypes.
8. Establish acceptance criteria.
9. Promptly communicate changes to the requirements.
10. Respect the requirements development process.

U Waterloo CS445/ECE451/CS645 Winter 2019 9

The business analyst role

U Waterloo CS445/ECE451/CS645 Winter 2019 10

 The business analyst’s tasks
• Define business requirements.
• Plan the requirements approach.
• Identify project stakeholders and user classes.
• Elicit requirements.
• Analyze requirements.
• Document requirements.
• Communicate requirements.
• Lead requirements validation.
• Facilitate requirements prioritization.
• Manage requirements.
U Waterloo CS445/ECE451/CS645 Winter 2019 11
 Essential analyst skills
• Listening skills
• Interviewing and questioning skills.
• Thinking on your feet.
• Analytical skills.
• Systems thinking skills.
• Learning skills.
• Facilitation skills.
• Leadership skills.
• Observational skills.
• Communication skills.
• Organizational skills.
• Modeling skills.
• Interpersonal skills.
• Creativity

U Waterloo CS445/ECE451/CS645 Winter 2019 12

The cyclic nature of requirements elicitation,
analysis, and specification.

U Waterloo CS445/ECE451/CS645 Winter 2019 13

Activities for a single requirements elicitation session.

Before we walk through this process, though, let’s explore some of the
requirements elicitation techniques you might find valuable.

U Waterloo CS445/ECE451/CS645 Winter 2019 14

 Requirements elicitation techniques
1. Interviews (The most obvious way to find out what the
users of a software system need is to ask them):
• Establish rapport
• Stay in scope
• Prepare questions
• Suggest ideas
• Listen actively

U Waterloo CS445/ECE451/CS645 Winter 2019 15

2. Workshops (Workshops encourage stakeholder
collaboration in defining requirements):
• Establish and enforce round rules
• Fill all of the team roles
• Plan an agenda
• Stay in scope
• Timebox discussions
• Keep the team small but include the right stakeholders
• Keep everyone engaged

U Waterloo CS445/ECE451/CS645 Winter 2019 16

3. Focus groups:
• A focus group is a representative group of users who convene in a
facilitated elicitation activity to generate input and ideas on a product’s
functional and quality requirements.
• Focus group sessions must be interactive, allowing all users a chance to
voice their thoughts.
• Focus groups are useful for exploring users’ attitudes, impressions,
preferences, and needs
4. Observations:
• When you ask users to describe how they do their jobs, they will likely
have a hard time being precise, details might be missing or incorrect
• Observations are time consuming.
• Observations can be silent or interactive.

U Waterloo CS445/ECE451/CS645 Winter 2019 17

5. Questionnaires:
• To survey large groups of users to understand their needs.
• They are inexpensive, making them a logical choice for eliciting
information from large user populations, and they can be administered
easily across geographical boundaries.
• The analyzed results of questionnaires can be used as an input to other
elicitation techniques.
• You can also use questionnaires to survey commercial product users for
feedback.
U Waterloo CS445/ECE451/CS645 Winter 2019 18
• Preparing well-written questions is the biggest challenge with questionnaires:
• Provide answer options that cover the full set of possible responses.
• Make answer choices both mutually exclusive (no overlaps in numerical ranges) and
exhaustive (list all possible choices and/or have a write-in spot for a choice you didn’t think of).
• Don’t phrase a question in a way that implies a “correct” answer.
• If you use scales, use them consistently throughout the questionnaire.
• Use closed questions with two or more specific choices if you want to use the
questionnaire results for statistical analysis. Open-ended questions allows users to
respond any way they want, so it’s hard to look for commonalities in the results.
• Consider consulting with an expert in questionnaire design and administration to
ensure that you ask the right questions of the right people.
• Always test a questionnaire before distributing it. It’s frustrating to discover too late
that a question was phrased ambiguously or to realize that an important question was
omitted.
• Don’t ask too many questions or people won’t respond.
U Waterloo CS445/ECE451/CS645 Winter 2019 19
6. System interface analysis:
• An independent elicitation technique that entails examining the systems to
which your system connects.
• Reveals functional requirements regarding the exchange of data and services
between systems.
• For each system that interfaces with yours, identify functionality in the other
system that might lead to requirements for your system.
• These requirements could describe what data to pass to the other system, what data
is received from it, and rules about that data, such as validation criteria.
• You might also discover existing functionality that you do not need to implement in
your system.
• Example: Suppose you thought you needed to implement validation rules for a shopping-cart
order in an e-commerce website before passing it to an order-management system. Through
system interface analysis, you might learn that multiple systems pass orders to the order-
management system, which performs the validation, so you don’t need to build this function.

U Waterloo CS445/ECE451/CS645 Winter 2019 20

7. User interface analysis:
• You study existing systems to discover user and functional requirements.
• Can help you identify a complete list of screens to help you discover
potential features.
• It’s a great way to get up to speed on how an existing system works
(unless you need a lot of training to do so).
• Instead of asking users how they interact with the system and what steps
they take, perhaps you can reach an initial understanding yourself.
• Do not assume that certain functionality is needed in the new system just
because you found it in an existing one.
• Do not assume that because the UI looks or flows a certain way in the
current system that it must be implemented that way in the future
system.

U Waterloo CS445/ECE451/CS645 Winter 2019 21

8. Document analysis:
• Entails examining any existing documentation for potential software
requirements.
• The most useful documentation includes requirements specifications,
business processes, lessons learned collections, and user manuals for
existing or similar applications.
• Documents can describe corporate or industry standards that must be
followed or regulations with which the product must comply.
• Comparative reviews point out shortcomings in other products that you
could address to gain a competitive advantage.
• Problem reports and enhancement requests collected from users by help
desk and field support personnel can offer ideas for improving the system in
future releases.

U Waterloo CS445/ECE451/CS645 Winter 2019 22

U Waterloo CS445/ECE451/CS645 Winter 2019 23
 How do you know when you’re done?
• The users can’t think of any more use cases or user stories. Users tend to identify
user requirements in sequence of decreasing importance.
• Users propose new scenarios, but they don’t lead to any new functional
requirements. A “new” use case might really be an alternative flow for a use case
you’ve already captured.
• Users repeat issues they already covered in previous discussions.
• Suggested new features, user requirements, or functional requirements are all
deemed to be out of scope.
• Proposed new requirements are all low priority.
• The users are proposing capabilities that might be included “sometime in the
lifetime of the product” rather than “in the specific product we’re talking about
right now.”
• Developers and testers who review the requirements for an area raise few
questions.

U Waterloo CS445/ECE451/CS645 Winter 2019 24