SOFTWARE

REQUIREMENT &
SPECIFICATION
OBJECTIVES
Requirements elicitation techniques
• Interviews
• Workshops
• Focus groups
• Observations
• Questionnaires
• System interface analysis
• User interface analysis
• Document analysis

Planning elicitation on your project

Preparing for elicitation

SOFTWARE REQUIREMENT & SPECIFICATION 2

OBJECTIVES

Performing elicitation activities

Following up after elicitation

Classifying customer input

How do you know when you’re done?

Some cautions about elicitation

Assumed and implied requirements

Finding missing requirements

SOFTWARE REQUIREMENT & SPECIFICATION 3

• Elicitation: the process of identifying the needs and
constraints of the various stakeholders for a software
system
• It’s a collaborative and analytical process that includes
activities to collect, discover, extract, and define
requirements
• It is used to discover business, user, functional, and
nonfunctional requirements, along with other types of
information
• The output of requirements development is a common
understanding of the needs held by the diverse project
stakeholders
• Elicitation participants should resist the temptation to
design the system until they understand the problem

SOFTWARE REQUIREMENT & SPECIFICATION 4

• Try to understand the thought processes behind the
requirements the users state
• the processes that users follow to make decisions
• the underlying logic behind the decisions
• why the system must perform certain functions
• obsolete or ineffective business processes or rules
that should not be incorporated into a new system
• record significant application domain terms in a
glossary
• Customers must understand that
• a discussion about possible functionality is not a
commitment to include it in the product
• Brainstorming the possibilities is different from
analyzing priorities, feasibility, and constraining
realities

SOFTWARE REQUIREMENT & SPECIFICATION 5

REQUIREMENTS ELICITATION TECHNIQUES

SOFTWARE REQUIREMENT & SPECIFICATION 6

FACILITATED INDEPENDENT
ACTIVITIES ACTIVITIES

• interact with • you work on your

stakeholders to elicit own to discover
requirements information
• primarily focus on • add-on requirements
discovering business that users present
and user and reveal needed
requirements functionality that end
users might not be
aware of

SOFTWARE REQUIREMENT & SPECIFICATION 7

INTERVIEWS
1. Establish rapport: introduce yourself, review the agenda
and objectives, address any preliminary questions
2. Stay in scope: keep the discussion focus on its objective
3. Prepare questions and straw man models ahead of time
4. Suggest ideas watch users work and suggest ways to
automate portions of the job
5. Listen actively Practice the techniques of active
listening (leaning forward, showing patience, giving
verbal feedback, and inquiring when something is
unclear) and paraphrasing (restating the main idea of
a speaker’s message to show your understanding of
that message)

SOFTWARE REQUIREMENT & SPECIFICATION 8

WORKSHOPS
• A structured meeting in which a carefully selected
group of stakeholders and content experts work
together to define, create, refine, and reach closure on
deliverables (such as models and documents) that
represent user requirements
• Facilitator: plan workshop, select participants and
guiding them to a successful outcome
• Scribe: assists the facilitator by capturing the points
• Workshops can be resource intensive, plan ahead

SOFTWARE REQUIREMENT & SPECIFICATION 9

WORKSHOPS
• Establish and enforce ground rules: participants should
agree on some basic operating principles (start and end
time, returning from breaks promptly etc.)
• Fill all of the team roles: important roles are note taking,
time keeping, scope management, rule management
• Plan an agenda: create the plan and workshop agenda
ahead of time, and communicate them to participants
• Stay in scope
• Use parking lots to capture items for later consideration:
they are flipcharts containing array of random but
important information (quality attributes, business rules,
user interface ideas)

SOFTWARE REQUIREMENT & SPECIFICATION 10

WORKSHOPS
• Timebox discussions: allocate a fixed period of time to
each discussion topic, when closing a timeboxed
discussion, summarize status and next steps for it
• Keep the team small but include the right stakeholders:
run multiple workshops in parallel to explore the
requirements of different user classes
• Keep everyone engaged: silent participants need to be
involved in the discussion as well

SOFTWARE REQUIREMENT & SPECIFICATION 11

FOCUS GROUPS
• A representative group of users who assemble in a
facilitated elicitation activity to generate input and
ideas on a product’s functional and quality
requirements
• Most valuable if you are developing commercial
products
• Expect a lot of subjective feedback that can be further
evaluated and prioritized as requirements are
developed

SOFTWARE REQUIREMENT & SPECIFICATION 12

OBSERVATIONS
• Observations are time consuming; select important or
high-risk tasks and multiple user classes for observations
• Things to observe:
• validate information collected from other sources
• identify new topics for interviews
• see problems with the current system
• identify ways that the new system can better
support the workflow
• Observations can be silent or interactive

SOFTWARE REQUIREMENT & SPECIFICATION 13

QUESTIONNAIRES
• A way to survey large groups of users to understand their
needs
• Things to remember:
• Make answer choices both mutually exclusive (no
overlaps in numerical ranges) and exhaustive (list all
possible choices)
• Don’t phrase a question that implies a “correct”
answer
• If you use scales, use them consistently in the
questionnaire
• Use closed questions with specific choices for
statistical analysis
• Don’t ask too many questions or people won’t
respond.

SOFTWARE REQUIREMENT & SPECIFICATION 14

SYSTEM INTERFACE ANALYSIS
• An independent elicitation technique that entails
examining the systems to which your system connects
• It reveals functional requirements regarding the
exchange of data and services between systems
• Context diagrams and ecosystem maps help finding
interfaces
• These requirements could describe
• what data to pass to the other system
• what data is received from it
• rules about that data, such as validation criteria
• existing functionality that you do not need to implement

SOFTWARE REQUIREMENT & SPECIFICATION 15

USER INTERFACE ANALYSIS
• An independent elicitation technique in which you study
existing systems to discover user and functional
requirements; in case the existing system is missing, similar
systems can be studied
• User manuals and screenshots help
• UI analysis can help you
• identify a complete list of screens to help you discover
potential features
• reveal pieces of data that users need to see

SOFTWARE REQUIREMENT & SPECIFICATION 16

DOCUMENT ANALYSIS
• Examining any existing documentation for potential
software requirements e.g. SRS, business processes,
lessons-learned collections, manuals, industry standards
• When replacing an existing system, past documentation
can reveal functionality that might need to be retained,
as well as obsolete functionality
• For packaged-solution implementations, the vendor
documentation mentions functionality that your users
might need
• A risk with this technique is that the available documents
might not be up to date

SOFTWARE REQUIREMENT & SPECIFICATION 17

COMPARISON OF SELECTED
ELICITATION TECHNIQUES

SOFTWARE REQUIREMENT & SPECIFICATION 18

PLANNING ELICITATION ON YOUR PROJECT

SOFTWARE REQUIREMENT & SPECIFICATION 19

• Elicitation objectives: Plan objectives for the entire
project and for each activity
• Elicitation strategy and planned techniques: Decide
which techniques to use with different stakeholder
groups; depending on the access you have to
stakeholders, time constraints, and your knowledge of
the existing system
• Schedule and resource estimates
• Documents and systems needed for independent
elicitation: For document, system or UI analysis, identify
the materials needed
• Expected products of elicitation efforts: Knowing your
work products, helps you target the right stakeholders,
topics, and details
• Elicitation risks: Identify factors that can hinder your
ability to complete the elicitation activities as intended,
estimate the severity of each risk, and decide how you
can mitigate or control it
SOFTWARE REQUIREMENT & SPECIFICATION 20
PREPARING FOR ELICITATION

SOFTWARE REQUIREMENT & SPECIFICATION 21

• Plan session scope and agenda
• Decide on the scope of the elicitation session
according to time available
• The agenda should itemize what topics will be covered,
the available time for each topic, and targeted
objectives
• Share the session agenda with stakeholders in advance.
• Prepare resources
• Schedule the physical resources (rooms, projectors etc.)
needed.
• Schedule the participants
• For geographically dispersed groups, change the
schedule each time you meet
• Collect documentation or system access from various
sources. Gain access to systems as necessary

SOFTWARE REQUIREMENT & SPECIFICATION 22

• Learn about the stakeholders
• Identify relevant stakeholders for the session
• Learn about their cultural preferences; provide support
in case of language barrier
• Prepare questions
• Use areas of uncertainty in straw man models as a
source of questions
• If you are preparing for an interview or workshop, use
results from other elicitation techniques to identify
unresolved questions
• Prepare straw man models
• Analysis models (use cases, process flows) can help
users provide better requirements
• It serves as a starting point that helps you learn about
the topic and inspires your users to think of ideas

SOFTWARE REQUIREMENT & SPECIFICATION 23

PERFORMING ELICITATION ACTIVITIES

SOFTWARE REQUIREMENT & SPECIFICATION 24

• Educate stakeholders
• Teach your stakeholders about your elicitation
approach and why you chose it
• Teach your stakeholders about your analysis model and
why you chose it
• Describe the rules and objective of the session
• Take good notes
• Session notes should contain attendee list, invitees who
did not attend, decisions made, actions to be taken
and who is responsible for each, outstanding issues, high
points of key discussions
• Exploit the physical space
• Have sticky notes, chart papers or white boards for the
session
• Move around and ask attendees to contribute

SOFTWARE REQUIREMENT & SPECIFICATION 25

FOLLOWING UP AFTER ELICITATION

SOFTWARE REQUIREMENT & SPECIFICATION 26

• Organizing and sharing the notes
• Merge your input from multiple sources
• Review and update your notes soon after the session is
complete
• Share consolidated notes with participants for review
• Hold additional discussions to resolve any
inconsistencies
• Documenting open issues
• Open issues include items that need to be further
explored, knowledge gaps you need to close, identified
new questions
• Record them in an issue-tracking tool along with any
relevant, progress already made, an owner, and a due
date

SOFTWARE REQUIREMENT & SPECIFICATION 27

CLASSIFYING CUSTOMER INPUT

SOFTWARE REQUIREMENT & SPECIFICATION 28

Customer input can be divided into 9 categories:
• Business requirements: anything that describes the
financial, marketplace, or other business benefit that
either customers or the developing organization wish to
gain from the product is a business requirement e.g.
“Increase market share in region X by Y percent”
• User requirements: user goals or business tasks that users
need to perform (represented as use cases, scenarios, or
user stories) e.g. “I need to print a mailing label for a
package”
• Business rules: activity only certain users can perform
under specific conditions. These aren’t software
requirements, but functional requirements can be
derived from them e.g. “A new client must pay 30
percent of the fee”

SOFTWARE REQUIREMENT & SPECIFICATION 29

• Functional requirements: the observable behaviors the
system will exhibit under certain conditions and the
actions the system will let users take e.g. “The user must
be able to sort the project list in forward and reverse
alphabetical order”
• Quality attributes: statements that describe how well the
system does something; words that describe desirable
system characteristics (work with users to understand the
meaning of these ambiguous words) e.g. “The mobile
software must respond quickly”
• External interface requirements: describe the connections
between your system and the rest of the universe e.g.
“The mobile app should send the check image to the
bank”

SOFTWARE REQUIREMENT & SPECIFICATION 30

• Constraints: restrict the options available to the
developer (can be logical or physical). Ask why the
constraint exists, confirm its validity, and record the
rationale for including it as a requirement e.g. “Files
submitted electronically cannot exceed 10 MB”
• Data requirements: describe the format, data type,
allowed values, or default value for a data element; the
composition of a complex business data structure; or a
report to be generated e.g. “The ZIP code has five digits,
followed by a hyphen”
• Solution ideas: describe specific way to interact with the
system to perform some action (asking “why” the user
needs it to work this way will reveal the true need) e.g. “I
select the state from a drop-down list”

SOFTWARE REQUIREMENT & SPECIFICATION 31

A need that doesn’t fit in any of the categories can most
likely be:
• A requirement not related to the software development,
such as the need to train users on the new system
• A project constraint, such as a cost or schedule
restriction
• An assumption
• Additional information of a historical, context-setting, or
descriptive nature
• Unnecessary information that does not add much value

SOFTWARE REQUIREMENT & SPECIFICATION 32

HOW DO YOU KNOW WHEN YOU’RE DONE?

SOFTWARE REQUIREMENT & SPECIFICATION 33

You can never really be done but some indications can
include:
• Users can’t think of any more use cases or user stories.
• Users propose new scenarios, but they don’t lead to any
new functional requirements
• Users repeat issues they already covered in previous
discussions
• Suggested new features, user requirements, or functional
requirements are all 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”
• Developers and testers who review the requirements for
an area raise few questions.

SOFTWARE REQUIREMENT & SPECIFICATION 34

SOME CAUTIONS ABOUT ELICITATION

SOFTWARE REQUIREMENT & SPECIFICATION 35

• Balance stakeholder representation: do not overlook
requirements that are important to certain user classes;
best balance involves a few product champions who
can speak for their respective user classes
• Define scope appropriately: if the scope is too large, you’ll
gather more requirements than are needed to deliver a
valuable product; if the scope is too small, it won’t yield
a satisfactory product
• Avoid the requirements-versus-design argument:
requirements are about what the system has to do,
design is how the solution will be implemented;
imaginary hows help to clarify and refine the
understanding of user needs (make it clear to users that
these screens and prototypes are illustrative only)

SOFTWARE REQUIREMENT & SPECIFICATION 36

• Research within reason: need to do exploratory research
sometimes arises from an idea or a suggestion;
Prototyping is one way to explore such issues; if your
project requires extensive research, use an incremental
approach to explore the requirements in small, low-risk
portions
• Analysis paralysis: spending too much time on
requirements elicitation in an attempt to avoid missing
any requirements

SOFTWARE REQUIREMENT & SPECIFICATION 37

ASSUMED AND IMPLIED REQUIREMENTS

SOFTWARE REQUIREMENT & SPECIFICATION 38

• The requirements you don’t specify pose a risk that the
project might deliver a solution different from what
stakeholders expect:
• Assumed requirements are those that people
expect without having explicitly expressed them.
What you assume as being obvious might not be the
same as assumptions that various developers make.
• Implied requirements are necessary because of
another requirement but aren’t explicitly stated.
Developers can’t implement functionality they don’t
know about.
• People assume things have to be the way they’re
familiar with

SOFTWARE REQUIREMENT & SPECIFICATION 39

• Ask context-free questions, high-level and open-ended
questions that elicit information about global
characteristics of both the business problem and the
potential solution
• Study the results of initial elicitation sessions to identify
areas of incompleteness
• Read between the lines to identify features or
characteristics the customers expect to be included
without having said so

SOFTWARE REQUIREMENT & SPECIFICATION 40

FINDING MISSING REQUIREMENTS

SOFTWARE REQUIREMENT & SPECIFICATION 41

• Decompose high-level requirements into enough detail
to reveal exactly what is being requested; a vague
requirement will lead to a gap between what the
requester has in mind and what the developer builds.
• Ensure that all user classes have provided input; make
sure that each user requirement has at least one
identified user class
• Trace system requirements, user requirements, event-
response lists, and business rules to their corresponding
functional requirements
• Check boundary values for missing requirements
• Represent requirements information in more than one
way e.g. decision tables, data models etc.

SOFTWARE REQUIREMENT & SPECIFICATION 42