Introduction to Software Engineering

Understanding Requirements

Muhammad Nasir
m.nasir@iiu.edu.pk
Agenda
 Understanding Requirements
 Requirement Engineering Tasks
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Management
Understanding Requirement
 Understanding the requirements of a
problem is among the most difficult tasks
that face a software engineer.
 When you first think about it, developing a
clear understanding of requirements
doesn’t seem that hard.
 After all, doesn’t the customer know what is
required?
 Surprisingly, in many instances the answer
to these questions is “No.”
Understanding Requirements
 It’s your worst nightmare. A customer walks
into your office, sits down, looks you straight
in the eye, and says,
 “I know you think you understand what I said,
but what you don’t understand is what I said is
not what I meant.”
 Invariably, this happens late in the project,
after deadline commitments have been
made, reputations are on the line, and
serious money is at stake.
Requirement Engineering
 “…the process of discovering the
requirements for a system by communication
with customers, system users and other who
have a stake in the system development.”
(Ian Sommerville)
 “...the process of discovering the
requirements for a system by communication
with stakeholders and through the
observation of them in their domain”
(Tony Gorschek)
Requirement Engineering
Requirement Engineering provides the
appropriate mechanism for understanding
what the customer wants, analyzing need,
assessing feasibility, negotiating a
reasonable solution, specifying the
solution unambiguously, validating the
specification and managing the
requirements as they are transformed into
an operational system
Requirements Engineering Tasks
 Inception —Establish a basic understanding of the
problem and the nature of the solution.
 Elicitation —Draw out the requirements from
stakeholders.
 Elaboration (Highly structured)—Create an analysis
model that represents information, functional, and
behavioral aspects of the requirements.
 Negotiation—Agree on a deliverable system that is
realistic for developers and customers.
 Specification—Describe the requirements formally or
informally.
 Validation —Review the requirement specification for
errors, ambiguities, omissions, and conflicts.
 Requirements Management —Manage changing
requirements.
Inception
 Inception— Ask “context-free”
questions that establish …
 Basic understanding of the problem
 The people who want a solution
 The nature of the solution that is
desired, and
Elicitation
 Elicitation - elicit requirements from
customers, users and others.
 Find out from customers, users and
others what the product objectives are
 what is to be done
 How the product fits into business needs,
and
 How the product is used on a day to day
basis
Why Requirement elicitation is
difficult?
 Problems of scope:
 The boundary of the system is ill-defined.
 Customers/users specify unnecessary technical
detail that may confuse rather than clarify
objectives.
 Problems of volatility:
 Requirement change over time
Why Requirement elicitation is
difficult?
 Problem of understanding:
 Customers are not completely sure of what is
needed.
 Customers have a poor understanding of the
capabilities and limitations of the computing
environment.
 Customers don’t have a full understanding of their
problem domain.
 Customers have trouble communicating needs to the
system engineer.
 Customers omit detail that is believed to be obvious.
 Customers specify requirements that conflict with
other requirements.
 Customers specify requirements that are ambiguous
or not able to test.
Elaboration
 Focuses on developing a refined technical model of
software functions, features, and constraints using
the information obtained during inception and
elicitation
 Create an analysis model that identifies data,
function and behavioral requirements.
 It is driven by the creation and refinement of user
scenarios that describe how the end-user will interact
with the system.
 Each user scenario is parsed to extract analysis
classes—business domain entities that are visible
to the end user.
Negotiation
 Negotiation - agree on a deliverable system that is
realistic for developers and customers
 Requirements are categorized and organized
into subsets
 Relations among requirements identified
 Requirements reviewed for correctness
 Requirements prioritized based on customer
needs
 Negotiation about requirements, project cost
and project timeline.
 There should be no winner and no loser in
effective negotiation.
Specification
 Specification – Different things to different people.
 It can be –
 Written Document
 A set of graphical models
 A formal mathematical models
 Collection of usage scenario.
 A prototype
 Combination of above.
 The formality and format of a specification varies with the
size and the complexity of the software to be built.
 For large systems, written document, language
descriptions, and graphical models may be the best
approach.
 For small systems or products, usage scenarios
Validation
 Requirements Validation - formal
technical review mechanism that looks for
 Errors in content or interpretation
 Areas where clarification may be
required
 Missing information
 Inconsistencies (a major problem when
large products or systems are engineered)
 Conflicting or unrealistic (unachievable)
requirements.
Requirement Management
 Requirements for computer-based systems
change, and the desire to change
requirements persists throughout the life of
the system.
 Requirements management is a set of
activities that help the project team identify,
control, and track requirements and
changes to requirements at any time as the
project proceeds
The End
 Thanks for listening
 Questions would be appreciated.