SENG304: Software

Requirement
Engineering and
Construction
LECTURE FOUR: SOFTWARE
REQUIREMENT ELICITATION II
Requirements Elicitation
 The aims of the requirements elicitation process are
 to understand the work that stakeholders do
 how they might use a new system to help support that work.
 During requirements elicitation, software engineers work with stakeholders to
find out about
 the application domain, work activities, the services and system features
that stakeholders want,
 the required performance of the system, hardware constraints, and so on.
Requirements Elicitation
 Eliciting and understanding requirements from system stakeholders might be
a difficult process for several reasons:
 Stakeholders often don’t know what they want from a computer system
except in the most general terms; they may find it difficult to articulate
what they want the system to do; they may make unrealistic demands
because they don’t know what is and isn’t feasible.
 Stakeholders in a system naturally express requirements in their own terms
and with implicit knowledge of their own work. Requirements engineers,
without experience in the customer’s domain, may not understand these
requirements.
Requirements Elicitation
 Different stakeholders, with diverse requirements, may express their
requirements in different ways. Requirements engineers have to discover
all potential sources of requirements and discover commonalities and
conflict.
 Political factors may influence the requirements of a system. Managers
may demand specific system requirements because these will allow them to
increase their influence in the organization.
 The economic and business environment in which the analysis takes place
is dynamic. It inevitably changes during the analysis process. The
importance of particular requirements may change. New requirements may
emerge from new stakeholders who were not originally consulted.
Requirements Elicitation and
Analysis Process

1 2 3 4

Requirements Requirements Requirements

Requirements
discovery and classification and prioritization and
documentation
understanding organization negotiation
Requirements Elicitation and
Analysis Process
 Requirements discovery and understanding - This is the process of interacting
with stakeholders of the system to discover their requirements. Domain
requirements from stakeholders and documentation are also discovered
during this activity.
 Requirements classification and organization - This activity takes the
unstructured collection of requirements, groups related requirements and
organizes them into coherent clusters.
Requirements Elicitation and
Analysis Process
 Requirements prioritization and negotiation - Inevitably, when multiple
stakeholders are involved, requirements will conflict. This activity is
concerned with prioritizing requirements and finding and resolving
requirements conflicts through negotiation. Usually, stakeholders have to
meet to resolve differences and agree on compromise requirements.
 Requirements documentation - The requirements are documented and input
into the next round of the spiral. An early draft of the software requirements
documents may be produced at this stage, or the requirements may simply be
maintained informally on whiteboards, wikis, or other shared spaces.
Requirements Elicitation and
Analysis Process
 Note - Each organization will have its own version or instance of this general
model, depending on local factors such as the expertise of the staff, the type
of system being developed, and the standards used
 The analyst’s understanding of the requirements improves with each round of
the cycle. The cycle ends when the requirements document has been
produced.
Requirements Elicitation
Techniques
 There are two fundamental approaches to requirements elicitation:
 Interviewing, where you talk to people about what they do.
 Observation or ethnography, where you watch people doing their job to see
what artifacts they use, how they use them, and so on.
 In these interviews (formal or informal), the requirements engineering team
puts questions to stakeholders about the system that they currently use and
the system to be developed.
 Then, Requirements are derived from the answers to these questions.
Requirements Elicitation
Techniques
 Interviews may be of two types:
 Closed interviews - where the stakeholder answers a predefined set of
questions.
 Open interviews - in which there is no predefined agenda. The requirements
engineering team explores a range of issues with system stakeholders and
hence develops a better understanding of their needs.
 In practice, interviews with stakeholders are normally a mixture of both of
these.
Requirements Elicitation
Techniques
 Interviews are good for getting an overall understanding of what stakeholders
do, how they might interact with the new system, and the difficulties that they
face with current systems.
 To be an effective interviewer, you should bear two things in mind:
 You should be open-minded, avoid preconceived ideas about the
requirements, and willing to listen to stakeholders. If the stakeholder comes
up with surprising requirements, then you should be willing to change your
mind about the system.
Requirements Elicitation
Techniques
 You should prompt the interviewee to get discussions going by using a
springboard question or a requirements proposal, or by working together on
a prototype system. Saying to people “tell me what you want” is unlikely to
result in useful information. They find it much easier to talk in a defined
context rather than in general terms.
 Interviewing on its own is liable to miss essential information, and so it
should be used in conjunction with other requirements elicitation techniques.
Requirements Elicitation
Techniques
 Ethnography is an observational technique that can be used to understand
operational processes and help derive requirements for software to support
these processes.
 The day-to-day work is observed, and notes are made of the actual tasks in
which participants are involved.
 The value of ethnography is that it helps discover implicit system
requirements that reflect the actual ways that people work, rather than the
formal processes defined by the organization.
Requirements Elicitation
Techniques
 Actual work practices are far richer, more complex, and more dynamic than
the simple models assumed by office automation systems.
 Ethnography is particularly effective for discovering two types of
requirements:
 Requirements derived from the way in which people actually work, rather
than the way in which business process definitions say they ought to work.
 Requirements derived from cooperation and awareness of other people’s
activities.
 Other Requirements Elicitation
Techniques
 The techniques may also include the following –
 Brainstorming  Laddering  User stories
 Card sorting  Protocol analysis  Viewpoints
 Designer as apprentice  Prototyping  Workshops
 Domain analysis  Quality function  Scenarios
 Goal-based approaches deployment (QFD)
 Group work  Repertory grids
 Introspection  Task analysis
 Joint application  Use cases
development (JAD)
Other Requirements Elicitation
Techniques
 Brainstorming
 Brainstorming consists of informal sessions with customers and other
stakeholders to generate overarching goals for the systems.
 Brainstorming can be formalized to include a set agenda, minute taking, and
the use of formal structures.
 During brainstorming sessions, some preliminary requirements may be
generated, but this aspect is secondary to the process.
 Brainstorming is also useful for general objective setting, such as mission or
vision statement generation.
Other Requirements Elicitation
Techniques
 Card Sorting
 This technique involves having
stakeholders complete a set of cards
that includes key information about
functionality for the system/software
product. It is also a good idea for the
stakeholders/customers to include
ranking and rationale for each of the
functionalities.
Unsorted Card
Other Requirements Elicitation
Techniques

Sorted Card
Other Requirements Elicitation
Techniques
 Designer as Apprentice
 Designer as apprentice is a requirements discovery technique in which the
requirements engineer “looks over the shoulder” of the customer in order to
learn enough about the customer’s work to understand their needs.
 The relationship between customer and designer is like that between a master
craftsman and apprentice.
 That is, the apprentice learns a skill from the master just as we want the
requirements engineer (the designer) to learn about the customer’s work from
the customer
Other Requirements Elicitation
Techniques
 The apprentice is there to learn whatever the master knows
 In order for this technique to work, the requirements engineer must
understand the structure and implication of the work, including:
 The strategy to get work done
 Constraints that get in the way
 The structure of the physical environment as it supports work
 The way work is divided
 Recurring patterns of activity
 The implications these have on any potential system
Other Requirements Elicitation
Techniques
 Domain Analysis
 Domain analysis involves any general approach to assessing the “land scape”
of related and competing applications to the system being designed.
 Such an approach can be useful in identifying essential functionality and,
later, missing functionality.
 Domain analysis can also be used later for identifying reusable components.
Other Requirements Elicitation
Techniques
 Goal-Based Approaches
 Goal-based approaches comprise any elicitation techniques in which
requirements are recognized to emanate from the mission statement, through
a set of goals that lead to requirements.
 That is, looking at the mission statement, a set of goals that fulfill that
mission is generated.
 These goals may be subdivided one or more times to obtain lower-level
goals. Then, the lower-level goals are branched out into specific high-level
requirements. Finally, the high-level requirements are used to generate lower-
level ones.
Other Requirements Elicitation
Techniques
 For example, consider the baggage handling system mission statement:
 To automate all aspects of baggage handling from passenger origin to
destination.
 The following goals might be considered to fulfill this mission:
 Goal 1: To completely automate the tracking of baggage from check-in to
pick-up.
 Goal 2: To completely automate the routing of baggage from check-in
counter to plane.
 Goal 3: To reduce the amount of lost luggage to 1%.
Other Requirements Elicitation
Techniques
 Group Work
 Group work is a general term for any kind of group meetings that are used
during the requirements discovery, analysis, and follow-up processes.
 The most celebrated of group-oriented work for requirements elicitation is
joint application design (JAD), which we will discuss shortly
 Here are the most important things to remember about group meetings.
 Do your homework—research all aspects of the organization, problems,
politics, environment, and so on.
 Publish an agenda (with time allotted for each item) several days before
the meeting occurs..
Other Requirements Elicitation
Techniques
 Stay on the agenda throughout the meeting (no meeting scope creep).
 Have a dedicated note-taker (scribe) on hand.
 Do not allow personal issues to creep in.
 Allow all to have their voices heard.
 Look for consensus at the earliest opportunity.
 Do not leave until all items on the agenda have received sufficient
discussion.
 Publish the minutes of the meeting within a couple of days of meeting
close and allow attendees to suggest changes.
Other Requirements Elicitation
Techniques
 Introspection
 When a requirements engineer develops requirements based on what he
thinks the customer wants, then he is conducting the process of introspection.
 In essence, the requirements engineer puts himself in the place of the
customer and opines “if I were the customer I would want the system to do
this …”
Other Requirements Elicitation
Techniques
 An introspective approach is useful when the requirements engineer’s domain
knowledge far exceeds that of the customer.
 Occasionally, the customer will ask the engineer questions similar to the
following—“if you were me, what would you want?” While introspection
will inform every aspect of the requirements engineer’s interactions,
remember our admonition about not telling a customer what he ought to
want.
Other Requirements Elicitation
Techniques
 Joint Application Design
 Joint application device (JAD) involves highly structured group meetings or
mini-retreats with system users, system owners, and analysts focused on a
specific set of problems for an extended period.
 JAD and JAD-like techniques are commonly used in systems planning and
 systems analysis activities to obtain group consensus on problems, objectives,
and requirements.
 Specifically, the requirements engineer can use JAD sessions for concept of
operation definition, system goal definition, requirements elicitation,
requirements analysis, requirements document review, and more.
Other Requirements Elicitation
Techniques
 Planning for a JAD review or audit session involves three steps:
 1. Selecting participants
 2. Preparing the agenda
 3. Selecting a location
 Great care must be taken in preparing each of these steps.
 The following rules are for conducting software requirements, design audits,
or code walkthroughs.
 The session leader must make every effort to ensure these practices are
implemented.
Other Requirements Elicitation
Techniques
 Stick to the agenda.
 Stay on schedule (agenda topics are allotted specific time).
 Ensure that the scribe can take notes.
 Avoid technical jargon (if the review involves nontechnical personnel).
 Resolve conflicts (try not to defer them).
 Encourage group consensus.
 Encourage user and management participation without allowing
individuals to dominate the session.
 Keep the meeting impersonal.
 Allow the meetings to take as long as necessary
Other Requirements Elicitation
Techniques
 The end product of any review session is typically a formal written document
providing a summary of the items (specifications, design changes, code
changes, and action items) agreed upon during the session.
 The content and organization of the document depend on the nature and
objectives of the session. Regarding requirements elicitation, however, the
main artifact could be a first draft of the SRS.
Other Requirements Elicitation
Techniques
 Laddering
 In laddering, the requirements engineer asks the customer short prompting
questions (probes) to elicit requirements.
 Follow-up questions are then posed to dig deeper below the surface. The
resultant information from the responses is then organized into a tree-like
structure.
 To illustrate the technique, consider the following laddering questions and
responses for the pet store POS system.
Other Requirements Elicitation
Techniques
 RE: Name a key feature of the system.
 Customer: Customer identification.
 RE: How do you identify a customer?
 Customer: They can swipe their loyalty card.
 RE: What if a customer forgets their card?
 Customer: They can be looked up by phone number.
 RE: When do you get the customer’s phone number?
 Customer: When customers complete the application for the loyalty card.
 RE: How do customers complete the applications?
 Other Requirements Elicitation
Techniques
The laddering technique
assumes that information
can be arranged in a
Laddering hierarchical fashion, or, at
diagram for the least, it causes the
pet store POS information to be arranged
system. hierarchically.
Other Requirements Elicitation
Techniques
 Protocol Analysis
 A protocol analysis is a process where customers, with the requirements
engineers, walk through the procedures they are automating.
 During such a walkthrough, the customers explicitly state the rationale for
each step that is being taken.
Other Requirements Elicitation
Techniques
 Prototyping
 Prototyping involves system model construction to discover new features,
particularly usability requirements.
 Prototyping is an important technique for requirements elicitation.
 Prototypes can involve
 working models and
 nonworking models.
 Working models can include executable code in the case of software
systems and simulations, or temporary or to-scale prototypes for non-
software systems.
Other Requirements Elicitation
Techniques
 Nonworking models can include storyboards and mock-ups of user
interfaces.
Other Requirements Elicitation
Techniques
 Quality Function Deployment
 Quality function deployment (QFD) is a technique for discovering customer
requirements and defining major quality assurance points to be used
throughout the production phase.
 QFD provides a structure for ensuring that customers’ needs and desires are
carefully heard, and then directly translated into a company’s internal
technical requirements—from analysis through implementation to
deployment.
Other Requirements Elicitation
Techniques
 Scenarios
 Scenarios are informal descriptions of the system in use that provide a high-
level description of system operation, classes of users, and exceptional
situations.
 Here is a sample scenario for the pet store POS system.
 A customer walks into the pet store and fills the cart with a variety of items.
When checking out, the cashier asks if the customer has a loyalty card. If
so, the cashier swipes the card, authenticating the customer. If not, then the
cashier offers to complete one on the spot. After the loyalty card activity,
the cashier scans products using a bar code reader.
Other Requirements Elicitation
Techniques
 As each item is scanned, the sale is totaled and the inventory is
appropriately updated. Upon completion of product scanning a subtotal is
computed. Then any coupons and discounts are entered. A new subtotal is
computed and applicable taxes are added. A receipt is printed and the
customer pays using cash, credit card, debit card, or check. All appropriate
totals (sales, tax, discounts, rebates, etc.) are computed and recorded.
 Scenarios are quite useful when the domain is novel. User stories are, in fact,
a form of scenario.
Other Requirements Elicitation
Techniques
 Task Analysis
 Task analysis involves a functional decomposition of tasks to be performed
by the system. That is, starting at the highest level of abstraction, the designer
and customers elicit further levels of detail. This detailed decomposition
continues until the lowest level of functionality (single task) is achieved.
Other Requirements Elicitation
Techniques

task analysis for

the pet store POS
system.
Other Requirements Elicitation
Techniques
 User Stories
 User stories are short conversational texts that are used for initial
requirements discovery and project planning. User stories are widely
employed in conjunction with agile methodologies.
 User stories are written by the customers in terms of what the system needs to
do for them and in their own “voice.”
 User stories usually consist of two to four sentences written on a three-by-
five-inch card.
 About 80 user stories are usually appropriate for one system increment or
evolution, but the appropriate number will vary widely depending on the
application size and scope, and the development methodology to be
Other Requirements Elicitation
Techniques
 An example of a user story for the pet store POS system is as follows:
 Each customer should be able to register easily.
 Self-service shall be supported.
 All coupons, discounts, and refunds should be handled this way.
Other Requirements Elicitation
Techniques
 Viewpoints
 Viewpoints are a way to organize information from the (point of view of)
different constituencies.
 For example, in the baggage handling system, there are differing perspectives
of the system for each of the following stakeholders:
 Baggage handling personnel
 Travelers
 Maintenance engineers
 Airport managers
 Regulatory agencies
Other Requirements Elicitation
Techniques
 By recognizing the needs of each stakeholder and the contradictions raised by
these viewpoints, conflicts can be reconciled using various approaches.
 The actual viewpoints incorporate a variety of information from the business
domain, process models, functional requirements specifications,
organizational models, etc.
 The following components should be in each viewpoint:
 A representation style, which defines the notation used in the specification
 A domain, which is defined as “the area of concern addressed by the
viewpoint.
Other Requirements Elicitation
Techniques
 A specification, which is a model of a system expressed in the defined
style
 A work plan, with a process model, which defines how to build and check
the specification
 A work record, which is a trace of the actions taken in building, checking,
and modifying the specification
 Viewpoint analysis is typically used for prioritization, agreement, and
ordering of requirements
Other Requirements Elicitation
Techniques
 Workshops
 Workshops are a gathering of stakeholders aimed at resolving requirements
issues.
 We can distinguish workshops as being of two types – formal and informal.
 Formal workshops are well-planned meetings and are events that are
mandated by contract. A good example of a formal workshop style is
embodied in JAD.
 Informal workshops are usually less boring than highly structured
meetings.
 Techniques and Approaches for
Elicitation Activities
Interviews Domain Group Ethnography Prototyping Goals Scenarios Viewpoints
work
Understanding the
domain
Identifying sources of
requirements
Analyzing the
stakeholders
Selecting techniques and
approaches
Eliciting the
requirements