SOFTWARE REQUIREMENT

ENGINEERING

.
 CHAPTER-2

Requirement Elicitation
TABLE OF CONTENT:

 Definition
 Types of requirements
 Product vs project requirements
 Key players
 Requirement development & management
 Good practices for requirement engineering
REQUIREMENTS ELICITATION TECHNIQUES:

• Numerous elicitation techniques can be employed on software projects. In fact, no project team
should expect to use only one elicitation technique.
• Elicitation techniques include both facilitated activities, in which you interact with stakeholders to
elicit requirements, and independent activities, in which you work on your own to discover
information.
• Each technique offers a different exploration of the requirements or might even reveal completely
different requirements.
• The following sections describe several techniques commonly used to elicit requirements.
Interviews
.

• Interviews are a traditional source of requirements input for both commercial products and information systems,
across all software development approaches.
• BAs will facilitate some form of individual or small-group interviews to elicit requirements on their projects.
• Agile projects make extensive use of interviews as a mechanism to get direct user involvement.
• Interviews are easier to schedule and lead than large-group activities such as requirements workshops.
• If you are new to an application domain, interviews with experts can help you get up to speed quickly. This will allow
you to prepare draft requirements and models to use in other interviews or in workshops.
• A few suggestions for conducting interviews follow.
 Establish rapport
 Stay in scope
 Prepare questions and straw man models ahead of time
 Suggest ideas
 Listen actively
Questionnaires
.

• Questionnaires are a way 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.
• Preparing well-written questions is the biggest challenge with questionnaires. Many tips are available for writing
questionnaires and the most important ones here:
 Provide answer options that cover the full set of possible responses.
 Make answer choices both mutually exclusive and exhaustive.
 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.
Workshops
.

• Workshops encourage stakeholder collaboration in defining requirements. It defines a requirements workshop as “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.”
• Workshops are facilitated sessions with multiple stakeholders and formal roles, such as a facilitator and a scribe.
• Workshops often include several types of stakeholders, from users to developers to testers. They are used to elicit requirements
from multiple stakeholders concurrently. Working in a group is more effective for resolving disagreements than is talking to people
individually. Also, workshops are helpful when quick elicitation turnaround is needed because of schedule constraints.
• Following are a few tips for conducting effective elicitation workshops, many of which also apply to interviews.
 Establish and enforce ground 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
 .

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. They are
particularly valuable if you are developing commercial products and don’t have ready access to end users
within your company.
• Focus groups must be facilitated. You will need to keep them on topic, but without influencing the opinions
being expressed. You might want to record the session so you can go back and listen carefully to comments.
Do not expect quantitative analysis from focus groups, but rather a lot of subjective feedback that can be
further evaluated and prioritized as requirements are developed.
 .

Brainstorming

• Brainstorming is a creative and collaborative technique that involves generating as many ideas as possible in
a short time, without judging or evaluating them. The goal is to explore different perspectives, stimulate
creativity, and identify potential solutions or requirements.
• Brainstorming can be done in groups or individually, using various methods such as free association, mind
mapping, or nominal group technique.
• Brainstorming is an effective technique for requirements elicitation, as it can help uncover hidden or implicit
requirements and foster a positive atmosphere among participants. It also encourages the sharing of diverse
ideas, knowledge, and experience, allowing for the generation of novel and creative solutions. Moreover, it
can stimulate innovation and creativity by encouraging participants to think outside the box.
Joint Application Development (JAD)
.

• Joint Application Development (JAD) is a methodology that has direct involvement of the client and
end-user while designing and developing computer-based applications.

• The JAD process enhances user participation, accelerating development, and hence improving the
quality of specifications. This includes approaches for refining the quality of specification through
successive collaborative workshops of JAD sessions.
• As the client is involved throughout the development process, it drives faster development and greater
client satisfaction.
• Advantages of- Produce a design from the customer’s perspective; The teamwork between company and
client helps to remove all risks; Due to the close interactions, progress is faster; JAD helps to accelerate
design and also to enhance quality; JAD cheers the team to push each other which leads them to work faster
and also to deliver on time.
 .

System interface analysis

• Interface analysis is an independent elicitation technique that entails examining the systems to which your
system connects.
• System interface analysis 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.
• 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.
User interface analysis
.

• User interface (UI) analysis is an independent elicitation technique in which you study existing systems to
discover user and functional requirements. It’s best to interact with the existing systems directly, but if
necessary you can use screen shots.
• User manuals for purchased packaged-software implementations often contain screen shots that will work fine
as a starting point. If there is no existing system, you might be able to look at user interfaces of similar
products.
• When working with packaged solutions or an existing system, UI analysis can help you identify a complete
list of screens to help you discover potential features. The common steps users take in the system and draft use
cases to review with users. UI analysis can reveal pieces of data that users need to see.
• Instead of asking users how they interact with the system and what steps they take, perhaps you can reach an
initial understanding yourself.
• 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.
Document analysis
.

• 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. When replacing an existing system, past documentation can reveal functionality
that might need to be retained, as well as obsolete functionality.
• Document analysis is a way to get up to speed on an existing system or a new domain. Doing some
research and drafting some requirements beforehand reduces the elicitation meeting time needed.
• Document analysis can reveal information people don’t tell you, either because they don’t think of it or
because they aren’t aware of it.
 PLANNING ELICITATION ON YOUR PROJECT

Early in a project, the business analyst should plan the project’s approach to requirements elicitation.
Even a simple plan of action increases the chance of success and sets realistic expectations for the
stakeholders.

An elicitation plan includes the techniques you’ll use, when you plan to use them, and for what purpose.
Your plan should address the following items:

■ Elicitation objectives
■ Elicitation strategy and planned techniques
■ Schedule and resource estimates
■ Documents and systems needed for independent elicitation
■ Expected products of elicitation efforts
■ Elicitation risks
 PREPARING FOR ELICITATION

Facilitated elicitation sessions require preparation to make the best use of everyone’s time. The larger
the group participating in the session, the more important preparation is.

 Plan session scope and agenda

 Prepare resources
 Learn about the stakeholders
 Prepare questions
 Prepare straw man models
 PERFORMING ELICITATION ACTIVITIES

Executing the elicitation activity itself is relatively obvious—if you are interviewing, you talk to people; if you are
performing document analysis, you read the document. However, when facilitating an elicitation activity, the
following tips might be useful.

 Educate stakeholders
 Take good notes
 Exploit the physical space
 FOLLOWING UP AFTER ELICITATION
After each elicitation activity is complete, there’s still a lot to do. You need to organize and share your
notes, document open issues, and classify the newly gathered information.

 Organizing and sharing the notes

 Documenting open issues
 DEFINING BUSINESS REQUIREMENTS
“Business requirements” refers to a set of information that, in the aggregate, describes a need that leads to one or more
projects to deliver a solution and the desired ultimate business outcomes.

Business requirements issues must be resolved before the functional and nonfunctional requirements can be fully
specified. A statement of the project’s scope and limitations helps greatly with discussions of proposed features and
target releases. The business requirements provide a reference for making decisions about proposed requirement
changes and enhancements.

1. Identifying desired business benefits: The business requirements set the context for, and enable the measurement
of, the benefits the business hopes to achieve from undertaking a project. Organizations should not initiate any project
without a clear understanding of the value it will add to the business.

2. Product vision and project scope: The product vision succinctly describes the ultimate product that will achieve
the business objectives. This product could serve as the complete solution for the business requirements or as just a
portion of the solution. The project scope identifies what portion of the ultimate product vision the current project
or development iteration will address. The statement of scope draws the boundary between what’s in and what’s out for
this project.
 Kiosk software is an essential component of self-service kiosks, providing the interface and functionality that enables our .

clients and their customers to interact with these systems, whether for wayfinding, self-payment, or anything in between.

3. Conflicting business requirements: Business requirements collected from multiple sources might conflict. Consider a
kiosk that will be used by a retail store’s customers. The business interests of the kiosk developer, retailer, and customer as we
envision how each of these stakeholders hopes the kiosk will provide an advantage over their current way of doing business.

• The various stakeholders’ objectives sometimes are in alignment.

The kiosk developers and the customers want to have a wide variety
of products or services available through the kiosk.
• The customer wants to spend less time purchasing goods and
services, but the retailer would prefer to have customers linger in
the store and spend more money.
• The project’s decision makers must resolve these conflicts before
the analyst can detail the kiosk’s requirements.
• The focus should be on delivering the maximum business value to
the primary stakeholders. It’s easy to be distracted by superficial
product characteristics that don’t really address the business
objectives.
 SCOPE REPRESENATION TECHNIQUES
The models described in this section can be used to represent project scope in various ways. You don’t need to create
all of these models; consider which ones provide the most useful insight for each project. The models can be included
in the vision and scope document or stored elsewhere and referenced as needed.

The purpose of tools such as the context diagram, ecosystem map, feature tree, and event list is to foster clear and
accurate communication among the project stakeholders.

We strongly recommend, though, that you adopt the notations illustrated in the following examples as standards for drawing
the diagrams. For example, in a context diagram, suppose you were to use a triangle to represent the system instead of a
circle, and ovals rather than rectangles for external entities.

Context diagrams, ecosystem maps, feature trees, and event lists are the most common ways to represent scope
visually. However, other techniques are also used. Identifying affected business processes also can help define the
scope boundary. Use case diagrams can depict the scope boundary between use cases and actors.
 1. CONTEXT DIAGRAM

The scope description establishes the boundary and

connections between the system you’re developing and
everything else in the universe.
The context diagram visually illustrates this boundary. It
identifies external entities (also called terminators)
outside the system that interface to it in some way, as
well as data, control, and material flows between the
terminators and the system.
The context diagram is the top level in a data flow
diagram developed according to the principles of
structured analysis, but it’s a useful model for all
projects. Figure illustrates a portion of the context
diagram for the Chemical Tracking System. The entire
system is depicted as a single circle; the context diagram
deliberately provides no visibility into the system’s
internal objects, processes, or data.
 2. ECOSYSTEM MAP
An ecosystem map shows all of the systems related to the system
of interest that interact with one another and the nature of those
interactions. An ecosystem map represents scope by showing all the
systems that interconnect and that therefore might need to be
modified to accommodate your new system.

Ecosystem maps differ from context diagrams in that they show other systems that have a relationship with the system you’re
working on, including those without direct interfaces.
Figure is a partial ecosystem map for the Chemical Tracking System. The systems are all shown in boxes. The primary system
is shown in a bold box (Chemical Tracking System), but if all systems have equal status in solution, you can use the same box
style for all of them.
The lines show interfaces between systems (for instance, the Purchasing System interfaces to the Chemical Tracking System).
Lines with arrows and labels show that major pieces of data are flowing from one system to another (for instance, “training
records” are passed from the Corporate Training Database to the C
 3. FEATURE TREE
A feature tree is a visual depiction of the product’s features
organized in logical groups, hierarchically subdividing each
feature into further levels of detail.
The feature tree provides a concise view of all of the features
planned for a project, making it an ideal model to show to
executives who want a quick glance at the project scope. A
feature tree can show up to three levels of features, commonly
called level 1 (L1), level 2 (L2), and level 3 (L3). L2 features
are sub features of L1 features, and L3 features are sub
features of L2 features.
Figure shows a partial feature tree for the Chemical Tracking
System. The main branch of the tree in the middle represents
the product being implemented. Each feature has its own line
or “branch” coming off that central main branch. The grey
boxes represent the L1 features, such as Order Chemicals and
Inventory Management. The lines coming off an L1 branch
are L2 features: Search and Chemical Request are sub features
of Order Chemicals. The branches off an L2 branch are the L3
features: Local Lab Search is a sub feature of Search.
 4. EVENT LIST

An event list identifies external events that could trigger

behavior in the system. The event list depicts the scope
boundary for the system by naming possible business
events triggered by users, time-triggered (temporal)
events, or signal events received from external components,
such as hardware devices. The event list only names the events; the functional requirements that describe how the system
responds to the events would be detailed in the SRS by using event-response tables.
Figure is a partial event list for the Chemical Tracking System. Each item in the list states what triggers the event (“Chemist”
does something or the “Time to” do something arrives), as well as identifying the event action. An event list is a useful scoping
tool because you can allocate certain events to be implemented in specific product releases or development iterations.
 UNDERSTANDING USER REQUIREMENTS
A use case describes a sequence of interactions between a
system and an external actor that results in the actor being
able to achieve some outcome of value. The names of use
cases are always written in the form of a verb followed by
an object. Select strong, descriptive names to make it
evident from the name that the use case will deliver
something valuable for some user. Table lists some sample
use
cases from a variety of applications.
 USE CASES AND USAGE SCENARIOS
A use case describes a discrete, standalone activity that an actor can perform to achieve some outcome of value. A use case
might encompass a number of related activities having a common goal. A scenario is a description of a single instance of usage
of the system.
A use case is therefore a collection of related usage scenarios, and a scenario is a specific instance of a use case. When
exploring user requirements, you can begin with a general use case statement and develop more specific usage scenarios, or you
can generalize from a specific scenario example to the broader use case.
The essential elements of a use case are the following:
■ A unique identifier and a succinct name that states the user goal
■ A brief textual description that describes the purpose of the use case
■ A trigger condition that initiates execution of the use case
■ Zero or more preconditions that must be satisfied before the use case can begin
■ One or more postconditions that describe the state of the system after the use case is
successfully completed
■ A numbered list of steps that shows the sequence of interactions between the actor and the
system—a dialog—that leads from the preconditions to the postconditions
THANKS!