Software Requirements

Engineering
Lecture11-12
Engr. Sara Rehmat
Requirements Elicitation
• The heart of requirements development is elicitation,
• The process of identifying the needs and constraints of the various
stakeholders for a software system.
• Elicitation is not the same as “gathering requirements” nor is it a
simple matter of transcribing exactly what users say.
• Elicitation is a collaborative and analytical process that includes
activities to collect, discover, extract, and define requirements.
• Elicitation is used to discover business, user, functional, and non-
functional requirements, along with other types of information.
Requirements Elicitation
• To facilitate clear communication, use the vocabulary of the business domain instead of
forcing customers to understand technical jargon.
• Record significant application domain terms in a glossary, rather than assuming that all
participants share the same definitions.
• Customers must understand that a discussion about possible functionality is not a
commitment to include it in the product.
• The output of requirements development is a common understanding of the needs held by the
diverse project stakeholders.
• When the developers understand those needs, they can explore alternative solutions to
address them.
• Elicitation participants should resist the temptation to design the system until they understand
the problem.
• Otherwise, they can expect to do considerable design rework as the requirements become better
defined.
Requirements Elicitation
• The nature of requirements development is cyclic.
Requirements Elicitation Techniques
• Numerous elicitation techniques can be employed on software projects.
• No project team should expect to use only one elicitation technique.
• There are always many types of information to be discovered, and different
stakeholders will prefer different approaches.
• Elicitation techniques include
• Facilitated activities, in which you interact with stakeholders to elicit requirements,
• focus on discovering business and user requirements.
• Independent activities, in which you work on your own to discover information.
• supplement requirements that users present and reveal needed functionality that end users might
not be aware of.
• Most projects will use a combination of both facilitated and independent
elicitation activities.
Requirements Elicitation Techniques
1. Interviews
2. Workshops
3. Focus Groups
4. Observations
5. Questionnaires
6. Interface Analysis
7. User Interface Analysis
8. Document Analysis
1. Interviews
• Interviews are a traditional source of requirements input for both
commercial products and information systems, across all software
development approaches.
• Agile projects make extensive use of interviews as a mechanism to get
direct user involvement.
1.1 Suggestions for conducting Interviews
• Establish rapport
• Stay in scope
• Prepare questions and straw man models ahead of time
• Suggest ideas
2. Workshops
• 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.
2. Workshops
• When a team is getting started with new approaches to requirements
elicitation, consider having an outside facilitator or a second BA
facilitate the initial workshops.
• This way the lead BA can devote his full attention to the discussion.
• If the sole BA is also acting as facilitator, she needs to be mindful of when she
is speaking as a facilitator and when she is participating in the discussion.
• A scribe assists the facilitator by capturing the points that come up
during the discussion.
2. Workshops
• Workshops can be resource intensive, sometimes requiring numerous
participants for several days at a time.
• They must be well planned to avoid wasting time.
• Minimize wasted time by coming into a workshop with drafts of materials
prepared ahead of time
2.2 Suggestions for conducting Workshops
• 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
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.
• 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.
• Participants
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.
• Often this is because tasks are complex and it’s hard to remember every minute
detail.
• In other cases, it is because users are so familiar with executing a task that they
can’t articulate everything they do.
• Observations are time consuming, so they aren’t suitable for every user
or every task.
• To avoid disrupting the users’ regularly assigned work activities, limit each
observation time to two hours or less.
• Select important or high-risk tasks and multiple user classes for observations.
• If
4. Observations
• Observations can be silent or interactive.
• Silent observations are appropriate when busy users cannot be interrupted.
• Interactive observations allow the BA to interrupt the user mid-task and ask a
question.
• Document what you observe for further analysis after the session.
5. Questionnaires
• Questionnaires are a way to survey large groups of users to understand
their needs.
• They are inexpensive and can be administered easily across
geographical boundaries.
• The analyzed results of questionnaires can be used as an input to other
elicitation techniques.
• For example, you might use a questionnaire to identify users’ biggest pain
points with an existing system, then use the results to discuss prioritization with
decision makers in a workshop.
• You can also use questionnaires to survey commercial product users for
feedback.
5.1 Suggestions for making efficient
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.
6. 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
• Context diagrams and ecosystem maps are an obvious choice to begin finding
interfaces for further study.
• 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.
7. 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.
• By navigating the existing UI, you can learn about the common steps
users take in the system and draft use cases to review with users.
• It’s a great way to get up to speed on how an existing system works
Instead
8. Document Analysis
• Document analysis entails examining any existing documentation for potential
software requirements.
• When replacing an existing system, past documentation can reveal
functionality that might need to be retained, as well as obsolete functionality.
• 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.
• A risk with this technique is that the available documents might not be up to
date.
Planning Elicitation
• Early in a project, the business analyst should plan the project’s
approach to requirements elicitation.
• 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
Requirements Analysis
Understanding User Requirements
Approaches for gathering User Requirements
• To gather user requirements, there are two approaches.
• Product-centric approach
• User-centric and usage-centric approach
• Product-centric approach
• Focuses on defining the features to implement in the software, with the hope that those
features will appeal to prospective customers.
• User-centric and usage-centric approach
• Focusing on users and their anticipated usage helps reveal the necessary functionality, avoids
implementing features that no one will use, and assists with prioritization.
• Two techniques used are : Use Cases and User Stories
• Difference:
• what users need to accomplish
• asking users what they want the system to do.
Applications of User-centered approach
• Use cases and user stories work well for exploring the requirements
for
• business applications, websites, kiosks, and systems that let a user control a
piece of hardware.
• Use cases or user stories are inadequate for understanding the
requirements of certain types of applications.
• batch processes, computationally intensive systems, business analytics, and
data warehousing, many embedded and other real-time systems.
• The complexity of these applications lies in the computations performed, the
data found and compiled, or the reports generated, not in the user-system
interactions.
Use Case
• 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.
Examples of Use Cases
User Story
• Used on agile development projects,
• A “short, simple description of a feature told from the perspective of
the person who desires the new capability, usually a user or customer
of the system” (Cohn 2010).
• User stories often are written according to the following template,
although other styles also are used:
• As a <type of user>, I want <some goal> so that <some reason>.