Understanding Requirements

Chapter 5
 Requirements Engineering
• Helps software engineer to better understand the
problem.
• Participants involved:
 Software Engineers
 Managers
 Customers
 Users
• The goal of RE Process is to create &
maintain a system requirements documents.

Generic activities to all processes:

 Feasibility study: usefulness to the business.

 Elicitation and analysis: discovering requirements.

 Specification: conversion of requirement into some

standard form.
 Validation: check the requirements which defines the
system that the customer wants.
RE Provides the appropriate mechanism for
 Understanding what the customer want.
 Analyzing need.
 Assessing feasibility.
 Negotiating a reasonable solution.
 Specifying a solution unambiguously.
 Validating the specification.
 Managing the requirement as they are
transformed into an operational system.
 Understanding Requirements
• Collecting needs from the customer.

• Managing the Process.

• Tasks involved:
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements Management
• Inception—ask a set of questions that establish …
– basic understanding of the problem.

– the people who want a solution.

– the nature of the solution that is desired, and

– the effectiveness of preliminary communication and collaboration

between the customer and the developer.

• Elicitation—elicit requirements from all stakeholders.

• Elaboration—create an analysis model that identifies data,

function and behavioral requirements.

• Negotiation—agree on a deliverable system that is realistic for

developers and customers.
• Specification—can be any one (or more) of the following:
– A written document.
– A set of models.
– A formal mathematical.
– A collection of user scenarios (use-cases)
– A prototype
• Validation—a 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.
• Requirements management- Manage changing requirements
 Inception
 Identify stakeholders
“who else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration
 The first questions
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful
solution
 Is there another source for the solution that you need
 These questions focus on the customer, other
stakeholders, the overall goals, and the benefits

• Who is behind the request for this work?

• Who will use the solution?
• What will be the economic benefit of a successful
solution?
• Is there another source for the solution that you need?
These questions enable the requirements engineer to gain a better
understanding of the problem and allow the customer to voice his
or her perceptions about a solution
• How would you characterize "good" output that would be
generated by a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in
which the solution will be used?
• Will special performance issues or constraints affect the way
the solution is approached?
 These questions focus on the effectiveness of the
communication activity itself

• Are you the right person to answer these questions?

Are your answers "official"?
• Are my questions relevant to the problem that you
have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
 Elicitation
• It certainly simple enough, but..

Why difficult:
• Problem of Scope:
The boundary of the system is ill-defined
• Problem of Understanding:
• The customer/users are not completely sure of what is needed
• Problem of volatility : The requirement change over time.

• To help overcame these problem, requirement engineers ,must

approach the requirement gathering activity in an organized
manner
• Elicitation may be accomplished through two
activities:
– Collaborative Requirements Gathering.
– Quality Function Deployment(QFD)
 Collaborative Requirements Gathering
• Meetings are attended by all software engineers and other
stakeholders.
• Rules established for preparation and participation.
• Agenda should be formal enough to cover all important points,
but informal enough to encourage the free flow of ideas.
• A facilitator controls the meeting.
• A definition mechanism (blackboard, flip charts, etc.) is used.
During the meeting:
• The problem is identified.
• Elements of the solution are proposed.
• Different approaches are negotiated.
• A preliminary set of solution requirements are obtained.
• The atmosphere is collaborative and non-threatening.
 Quality Function Deployment
• Quality function deployment is a technique that translates the
needs of the customer into technical requirements for software.
• It emphasizes an understanding of what is valuable to the
customer and then deploys these values throughout the
engineering process.

Three types of requirement:

• Normal Requirement: These requirements reflect objectives and

goals stated for product or system during meetings with the
customer. If these requirements are present, the customer is
satisfied.
Ex: Graphical displays, specific system functions and defined
levels of performance.
• Expected requirement:
These requirement are implicit to the product or system and
may be so fundamental that customer does not explicitly state
them. Their absence will be cause for significant
dissatisfaction.
Ex: ease of human/machine interaction, overall operational
correctness and reliability and ease of software installation.

• Exciting requirement:
These requirements reflect features that go beyond the
customer’s expectations and prove to be very satisfying when
present.
Ex: Word Processing software is requested with standard
features.

 Function deployment determines the “value” (to the

customer) of each function required of the system.
 Information deployment identifies data objects and
events.
 Task deployment examines the behavior of the system.
 Value analysis determines the priority of requirements.
• Customer voice table: i.e. reviewed with the customer.
(The raw data requirement obtained from customer
interaction is translated into tables).
 Elicitation Work Product
 Statement of need and feasibility.
 Statement of scope.
 List of participants in requirements elicitation.
 Description of the system’s technical environment.
 List of requirements and associated domain
constraints.
 List of usage scenarios.
 Any prototypes developed to refine requirements.
 Elaboration

• Takes the information obtained during inception and

elicitation.
• Focuses on developing a refined model of software
functions, features & Constraints.
• This is an analyzing phase :
It defines the functional, informational and
behavioral constraints of the problem domain.
• Expand requirement into analysis model
• Elements of the analysis model
– Scenario-based elements
The system is described from the user’s point of view.
 Functional—processing narratives for software functions
 Use-case—descriptions of the interaction between an “actor”
and the system
– Class-based elements
• Implied by scenarios- a set of objects : that are manipulated as an
actor interacts with the system.
(Collection of things that have similar attributes and common
behaviour)
– Behavioral elements
• State diagram (depicts its state and the events that cause the
system to change the state).
– Flow-oriented elements
• Data flow diagram
• Analysis Pattern:
Requirement engineering on more than few
software projects begins to notice that certain
thing reoccur across all projects within a
specific application domain- analysis
pattern( represent something within the
application domain that can be reused when
modeling many application)
 Use Case
• Use-cases are a scenario based technique in the UML
which identify the actors in an interaction and which
describe the interaction itself.
• A set of use cases should describe all possible
interactions with the system.
• High-level graphical model supplemented by more
detailed tabular description .
• Sequence diagrams may be used to add detail to use
cases by showing the sequence of event processing in
the system.
Use case
 Negotiation
• Agree on a deliverable system that is realistic for developers
and customers
• SW team & other project stakeholders negotiate the priority,
availability, and cost of each requirement
• The Process are :
– Identify the key stakeholders
• These are the people who will be involved in the negotiation
– Determine each of the stakeholders “win conditions”
• Win conditions are not always obvious
– Negotiate
• Work toward a set of requirements that lead to “win-win”
 The Art of Negotiation

• Recognize that it is not competition

• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit
 Specification
• Final work product produced by requirement
engineer.
• Can be any one (or more) of the following:
– A written document
– A set of models
– A formal mathematical
– A collection of user scenarios (use-cases)
– A prototype
• Requirement – understanding between
customer and supplier
• Specification – what the software must do
• Requirements that are not in the SRS
– Costs
– Delivery dates
– Acceptance procedures etc.
 Validation
• Examine the specification to ensure that SW
requirement is not ambiguous, consistent, error free
etc .
A 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.
• Validation: “Am I building the right product?”
checking a work product against higher-level
work products or authorities that frame this
particular product. – Requirements are
validated by stakeholders
• Verification: “Am I building the product
right?” checking a work product against some
standards and conditions imposed on this type
of product and the process of its development.
– Requirements are verified by the analysts
mainly
• A review of the analysis model addresses the following
question :
– Is each requirement consistent with the overall objective for the
system/product?
– Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
– Is the requirement really necessary or does it represent an add-
on feature that may not be essential to the objective of the
system?
– Is each requirement bounded and unambiguous?
– Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
– Do any requirements conflict with other requirements?
 Requirement Management
• Project team performs a set of activities to
identify, control and track requirements and
changes to the requirements at any times as the
project proceeds.
• Each requirement is assigned a unique identifier.
• Place the requirements into one or traceability
tables.
• Tables may be stored in a database that relate
features, sources, dependencies subsystems and
interfaces to the requirements interfaces to the
requirements.
• Features traceability table: Show how requirements
relate to important customer observable
system/product features.
• Source traceability table: Identifies the source of each
requirement.
• Dependability traceability table: Indicates how
requirements are related to one another.
• Subsystem traceability table: Categorizes
requirements by the subsystem that they govern.
• Interface traceability table: Show how requirements
relate to both internal and external system interface.