REQUIREMENTS

ENGINEERING
Requirements Development Techniques

Instructor: Huy Nguyen Dang Quang, Msc

Đà Nẵng, 2018 Email: [email protected]
Lecture Objective
The goal of this lecture is to:
❑Explain relationship of requirements areas.
❑Explain the domain of requirements
engineering.
❑Explain the requirements elicitation techniques.
❑ Collect and verify requirements.
What Are Requirements?*
• A condition or capability needed by a user or customer to solve
a problem or achieve an objective.
• A condition or capability that must be met or possessed by a
system or system component to satisfy a contract, standard,
specification, or other formally imposed document.
• A document representation of a condition or capability.
Requirements Engineering
• A method of obtaining a precise formal specification from the
informal and often vague requirements with customers.
• The science and discipline concerned with analyzing and
documenting requirements. It comprises needs analysis,
requirements analysis, and requirements specifications
Requirements Engineering
• Requirements Engineering consists of:
• Requirements Development:
• Requirements Elicitation (Gathering)
• Requirements Analysis
• Requirements Specification
• Requirements Verification & Validation
• Requirements Management:
• Requirements Baseline
• Requirement Change Management
• Requirements Traceability
Requirements Development
• Establish common understanding among stakeholders and developers.
• Identify business problems or issues.
• Understand stakeholders’ needs and expectations.
• Fill in the gap between the needs and expectations.
• Discover the “unstated” expectations.
• Establish requirements from stakeholders’ views.
• Establish scenarios: How stakeholders will use the system.
• Explain the context for using the product.
• Validate that needs and expectations are being met.
Wants vs. Needs
• Ozkaza’s Definition:
• Wants = How the Stakeholders define the problem.
• Needs = How Software Engineers define the solution.
Wants vs. Needs
• Ozkaza’s Definition:
• Wants = How the Stakeholders define the problem.
• Needs = How Software Engineers define the solution

• Al Davis’s Definition:
• Wants = The Stakeholders wish to have.
• Needs = The Stakeholders must have
Relationships Of Requirements
Scoping & Boundary
• There are many questions that need answers:
• What is the problem to be solved?
• Who are the customers of the development?
• Who are the customers of the solution?
• What are the customers’ expectations?
• What are the immediate and future benefits of the system?
• Why build such a system?
• What is the business case?
• What are the “true requirements”?
• Do we really have users of the system?
• Where is the solution to be positioned?
• What are the priorities in the overall problem?
• What are the sub-problems?
Ask Yourself …
• What problems are they encountering?
• What outcomes are they expecting?
• What kind of proposal is this?
• Who owns “the system” after it is completed?
• Is this a technical solution looking for a problem to solve?
• Document your assumptions, then verify them with stakeholders.
Understand the Environment
• Requirements are discovered, not created.
• Most requirements are based on existing systems.
• Most requirements start with business problems.
• Requirements demand decisions but …
▪ Many stakeholders do not agree with each other.
▪ Many stakeholders do not like making decisions.
▪ Many stakeholders have opinions on how to solve problems.
▪ Many stakeholders like to debate on solutions.
▪ No one has thought all the way through.
▪ No one has done a thorough analysis of the problem.
▪ Some stakeholders already thought about the solution.
• Requirements must be analyzed and aligned with business goals and
objectives.
Requirements Development Issues
• Inability to capture correct requirements.
• Confusion over the problem and solution.
• The desire to reduce requirements efforts to get to the development
phase because of the belief that coding & testing are most important.
• Lack of cooperation from stakeholders in verifying that the requirements
are correct and complete.
• Limited skill for people defining requirements.
• Inconsistent terminology, many terms do not have universally accepted
definitions - Business, System, Software, and Support people often
define their own terminology.
Requirements Development Process
Requirements Development
• Requirements Elicitation
• Requirements Analysis
• Requirements Specification
• Requirements Validation
 Definitions
Requirements Elicitation
• Techniques or methods used by Software Engineers to determine the needs of stakeholders (customers and
users), so that systems can be built with a high probability of satisfying those needs.

Requirements Analysis
• The techniques of deciding which features are appropriate for the product based on stakeholder needs.

Requirement Specification
• The techniques of documenting the external behavior of a system that will be built based on the features
selected during the analysis process.

Requirement Verification & Validation

• The techniques of ensuring that a requirements specification meets the stakeholders’ needs.

The process through which the stakeholders and the developers of a software/system discover,
review, articulate, and understand the stakeholders’ needs and the constraints on the software/system
and the development activity.
Questions To Ask …
• What is the problem to be solved?
• What are the constraints?
• Cost
• Deadlines
• Performance
• Platform, Technology…
• What are the needs?
• Successive refinement (Iterative)
• Technical feasibility
• Financial justification
Specific Skills
• Software Engineers who are involved in requirements elicitation must
be able to:
• Ask direct questions about who the stakeholders are.
• Ask what are the stakeholders’ expectations of you.
• State clearly what you want from the stakeholders.
• Ask directly for the stakeholders’ concerns about costs, quality and time, and
other issues.
• Reach agreement with stakeholders.
• Ask for feedback about control and commitment.
• Ask how you and stakeholders will know if you are successful.
• Ask for open communication channels.
• Get feedback early.
Understand Stakeholders’ Needs
• Draw pictures – stay in Problem space.
• Create scenarios – use-cases.
• Tell stories about how you think it works.
• Process modeling and simulation.
• Prototype.
• Verify your assumptions with stakeholders.
• Listen, Listen, and Listen!
Iterative Process
Each step leading to obtaining a requirement statement is:
• An opportunity to engage the stakeholders in the process.
• A reduction in stakeholders’ resistance.
• An increase in the probabilities for project success.
• An opportunity for better collaboration.
• A stepping stone toward the problem-solving goal.
• A relationship creation that you must nurture.
• An essential piece of the system that you are building.
• An education process for both you and the stakeholders.
Elicitation Techniques
• Techniques or methods used by software engineers to determine
the needs of stakeholders, so that systems can be built with a high
probability of satisfying those needs.
• There are many elicitation techniques:
• Interview
• Questionnaire
• Storyboarding
• Brainstorming
• Benchmarking
• Prototyping
Elicitation Techniques: Interviews
• The most popular technique:
• Asking questions of stakeholders about the problem to be solved and their
needs. Listening to their response and documenting them for analysis.
• Very useful when stakeholders are subject matter experts, know the problem
well, are accessible and willing to spend time to be interviewed.
• Software Engineers have to be trained in interview techniques to be effective.
• Interviewing is a good technique to gather information. However, the
experience, understanding, and bias of the stakeholder being
interviewed influence the information obtained.
• Software engineers should use questions that do not suggest a
particular response.
• For example: Who is the owner for this system? What is the reason for wanting to
solve this problem? What environment is this product likely to encounter? What
kind of product precision is required?
Elicitation Techniques: Interviews
• What is the client’s problem?
• What, precisely, is the problem to be solved?
• When does the problem occur?
• What generates the problem?
• Are they new or old? Or Transient?
• Where does the problem occur?
• What are the problem domain boundaries?
• How is the problem handled now?
• Why does the problem exist?
Good Question, Bad Question
• Question:
• When a car suddenly brakes in front of your car, you have to slow down
and not hit it, right?
• Answer:
• Yes, of course.
• What is the requirement here? You learn absolutely nothing!
• Question:
• What happens when a car suddenly brakes in front of your car?
• Answer:
• If that car is too close, I have to do something or else a crash may happen.
I guess all cars need a warning light when braking. If the car is far away, I
may not have to do anything. The only time brakes are used is when the
closing speed is too high for the distance and yet within the capabilities of
the system to slow down. But I guess if a collision is imminent, I should
brake very hard.
Interview Issues - 1
• Most stakeholders are not very good at articulating needs.
• Stakeholders and Software Engineers may not use the same
“language” or “terminology”.
• Many Software Engineers believe they know what stakeholders
want.
• Most stakeholders speak in operational rather than functional
terms.
• Most Software Engineers think in functional rather than operational
terms.
• Most stakeholders are concerned about cost and schedule.
• Most Software Engineers are concerned about “Perfect solutions”.
• Most Software Engineers are not trained to listen carefully.
• Most stakeholders are not trained to express needs concisely.
Elicitation Techniques: Questionnaire
• Distributing pre-defined questions to a sample of stakeholders.
Tallying the results as inputs for further analysis.
• Very useful when stakeholders population is large and
geographically distributed.
• Assume that all questions can be predetermined, and stakeholders
understand them well.
• Work well to ascertain opinion trends about specific, well-defined
requirements.
Questionnaire’s Issues
• Most Stakeholders:
• Focus on their own problems rather than the whole system.
• Think in terms of their own operational needs with many “unstated
needs”.
• Have lots of assumptions.
• Unrealistic expectations.
• Contradictory statements.
Elicitation Techniques: Brainstorming
This technique involves:
• Idea generation: The goal is to identify as many ideas as possible.
• Idea reduction: The goal is to rank the ideas into those considered
most useful by the group.
• Brainstorming is a powerful technique because the most creative
or effective ideas often result from combining seemingly unrelated
ideas. This technique encourages original thinking and unusual
ideas.
Elicitation Techniques: Brainstorming
This technique involves:
• Idea generation: The goal is to identify as many ideas as possible.
• Idea reduction: The goal is to rank the ideas into those considered
most useful by the group.
• Brainstorming is a powerful technique because the most creative
or effective ideas often result from combining seemingly unrelated
ideas. This technique encourages original thinking and unusual
ideas.
Elicitation Techniques: Brainstorming
• Assembling all stakeholders in one location, encourage
participation for all present, allowing every idea to be stated aloud
so others can leverage off them and document them for analysis.
• Effective when stakeholders are subject matter experts, each
brings their expertise about certain aspects of the problem to
discuss in the meeting with the common goal of leveraging each
other’s knowledge to come up with a full picture of the
requirements.
Elicitation Techniques: Brainstorming Issues
• Could lead to lengthy meetings with a lot of debate due to
conflicting requirements.
• “Politically sensitive”.
• Could be time consuming and create conflict.
• Need strong management oversight and skilled Software
Engineers to make it effective.
Elicitation Techniques: Prototyping
• A technique for building a quick and rough version of a desired
system or parts of that system.
• The prototype illustrates the capabilities of the system to users and
designers. It serves as a communications mechanism to allow
reviewers to understand interactions with the system.
• Prototyping sometimes gives an impression that developers are
further along than is actually the case, giving users an overly
optimistic impression of completion possibilities.
Elicitation Techniques: Prototyping
• Constructing a partial implementation of a system in a quick
manner, to gain feedback for the requirements process, and then
discard the prototype.
• Very effective to reduce the risk associated with inadvertently
building the wrong system.
• Good for “proof of concept”.
• Could convert poorly understood requirements into much better
understood requirements.
• Effective way of communication of requirements to stakeholders.
• Time constraints.
• Sometimes prototype implementation became part of the new
system.
Elicitation Techniques: Storyboarding
• A storyboard is a set of drawings depicting a set of user activities
that occur in an existing or envisioned system or capability.
• Storyboards are a kind of “paper prototyping”. Customers, users,
or developers start by drawing pictures of the screens, dialogs,
toolbars, and other elements they believe the software should
provide.
• The activity continues to evolve until real requirements and details
are worked out and agreed upon. Another related technique is
storytelling: the writing of stories to envision new products and
services based on perceived user needs and the possibilities
offered by emerging technologies.
Elicitation Techniques: Storyboarding
• Using physical media such as paper, cardboard to represent
sequential states of the environment for discussion, then using
scenarios and use cases to determine details, documents them for
analysis.
• •Very effective when stakeholders are subject matter experts and
have knowledge of the problem.
• •Effective for enhancing an existing system.
• •Assume problem is well known by stakeholders.
• •Does not work well for brand new systems or if it starts with
completely blank slates and no ideas on how the system is
supposed to work.
Elicitation Techniques: Benchmarking
• What are (or could be) competitors to these products/services?
• What does not work in those competing products/services?
• Who has problems with those products/services?
• How much time do people spend on various parts of those
products/services?
• How much money do people spend on various parts of those
products/services?
• What are the strengths and weaknesses of those
products/services?
Elicitation Techniques: Benchmarking
• Compare requirements to those products/services and ask this
question:
• Why can’t we use those competing products/services?
• Why do we build this products/services?
• What value does the proposed products/services offer?
• How the proposed products/services differ from the competitors?
Requirements Elicitation Issues
• Stakeholders may not convey the true needs of the user’s
community.
• Not all stakeholders are participating in requirements elicitation
activities.
• Software Engineers are not familiar with business processes and
do not understand the application domain.
• Stakeholders are not familiar with the technical requirements
(written by the Software Engineer) which focuses mostly on
functions, performance factors and design constraints, but not
much information on operational characteristics.
• Different views and definitions from multiple groups participating in
requirements elicitation.
Summary
• Elicitation is an iterative process.
• There are many elicitation techniques.
• Software Engineers must learn all elicitation techniques and select
the best to use.
• Software Engineers need to understand stakeholders’ environment
and needs.
Discussion
Students should be ready to discuss the following topics in class:
• Why is requirements engineering is so difficult?
• Why do you need so many different requirements?
• What happens if you only collect requirements from customer only?
• What are the advantages of storyboarding?
• What are the disadvantages of interviewing?
• What happen when stakeholders are busy and could not participate in
requirements engineering process? Explain the issues, reasons, of failure
or success and what should or should not be done in that situation.
QA
Những vấn đề chưa rõ?
The end

THANK YOU