Chapter 5:

Understanding Requirements

1
Requirements Engineering
 Requirement: A function, constraint or
other property that the system must
provide to fill the needs of the system’s
intended user(s)
 Engineering: implies that systematic and
repeatable techniques should be used
 Requirement Engineering means that
requirements for a product are defined,
managed and tested systematically

2
Requirements Engineering

 It is essential that the software engineering team

understand the requirements of a problem before
the team tries to solve the problem.
 In some cases requirements engineering may be
abbreviated, but it is never abandoned.
 RE is software engineering actions that start with
communication activity and continues into the
modeling activity.
 RE establishes a solid base for design and
construction. Without it, resulting software has a
high probability of not meeting customer needs.
3
Characteristics of a Good Requirement
 Clear and Unambiguous
 standard structure
 has only one possible interpretation
 Not more than one requirement in one sentence
 Correct
 A requirement contributes to a real need
 Understandable
 A reader can easily understand the meaning of the
requirement
 Verifiable
 A requirement can be tested
 Complete
 Consistent
 Traceable

4
Why is Getting Good Requirements
Hard?
 Stakeholders don’t know what they really
want.
 Stakeholders express requirements in their
own terms.
 Different stakeholders may have conflicting
requirements.
 Organisational and political factors may
influence the system requirements.
 The requirements change during the RE
process. New stakeholders may emerge
and the business environment change.

5
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.

6
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
 The effectiveness of preliminary
communication and collaboration
between the customer and the developer
7
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

8
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.
 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.
 Problems of volatility:
 Requirement change over time.

9
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.
 End result defines informational, functional and
behavioral domain of the problem

10
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.

11
Specification
 Specification – Different things to different people.
 It can be –
 Written Document (SRS)
 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

12
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.

13
Requirement Management
 Set of activities that help project team to identify, control, and track
requirements and changes as project proceeds
Requirements begin with identification. Each requirement is
assigned a unique identifier. Once requirement have been identified,
traceability table are developed.
Traceability Table:
 Features traceability table - shows how requirements relate to
customer observable features
Source traceability table - identifies source of each requirement
Dependency traceability table - indicate relations among
requirements
Subsystem traceability table - requirements categorized by
subsystem
Interface traceability table - shows requirement relations to
internal and external interfaces
It will help to track, if change in one requirement will affect different
aspects of the system.
14
Requirement Traceability Matrix

15
Initiating Requirements Engineering Process
 Identify stakeholders
 Stakeholder can be “anyone who benefits in a direct or indirect
way from the system which is being developed”
Ex. Business manager, project manager, marketing people,
software engineer, support engineer, end-users, internal-
external customers, consultants, maintenance engineer.
 Each one of them has different view of the system.
 Recognize multiple points of view
 Marketing group concern about feature and function to excite potential
market. To sell easily in the market.
 Business manager concern about feature built within budget and will be
ready to meet market.
 End user – Easy to learn and use.
 SE – product functioning at various infrastructure support.
 Support engineer – Maintainability of software.
Role of RE is to categorize all stakeholder information in a way that
there could be no inconsistent or conflict requirement with one
another

16
Initiating Requirements
Engineering Process
 Work toward collaboration
 RE identify areas of commonality (i.e. Agreed requirement) and
areas of conflict or inconsistency.
 It does not mean requirement defined by committee. It may
happened they providing just view of their requirement.
 Business manager or senior technologist may make final
decision.
 Asking 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 will help – stakeholder interest in the software
& measurable benefit of successful implementation.

17
Asking the question
Next set of questions – better understanding of the
problem.
 What business problem (s) will this solution address?
 Describe business environment in which the solution will
be used?
 will performance or productivity issues affect the solution
is approached?
Final set of questions – Effectiveness of communication
 Are my questions relevant to the problem?
 Am I asking too many questions?
 Can anyone else provide additional information?
 should I be asking you anything else?

18
Eliciting Requirement
Approach for eliciting requirement:
 Collaborative Requirement Gathering
 Quality Function Deployment
 User Scenarios
 Elicitation Work Products

19
Collaborative Requirement
Gathering
 Meetings are attended by all interested 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.
 Flow of event – Outline the sequence of events occurs
 Requirement gathering meeting ( initial meeting)
 During meeting
 Follow the meeting.

20
Collaborative requirement
gathering (contd.)
 In initial meeting, distribute “Product request” (defined by
stakeholder) to all attendee.
 Based on product request, each attendee is asked to
make
 List of objects (Internal or external system objects)
 List of services( Processes or functions)
 List of constraints ( cost, size, business rules) and
performance criteria( speed, accuracy) are developed.
 Collect lists from everyone and combined.
 Combined list eliminates redundant entries, add new
ideas , but does not delete anything.
 Objective is to develop a consensus list in each topic area
(objects, services, constraints and performance).
 Based on lists, team is divided into smaller sub-teams :
each works to develop mini-specification for one or more
entries on each of the lists.
21
Collaborative requirement
gathering (Contd.)
 Each sub-team then presents its mini-specification
to all attendees for discussion. Addition, deletion
and further elaboration are made.
 Now each team makes a list of validation criteria for
the product and present to team.
 Finally, one or more participants is assigned the
task of writing a complete draft specification.

22
Quality Function Deployment
 It is a technique that translate the needs of the customer into technical
requirement for software.
 Concentrates on maximizing customer satisfaction.
 QFD emphasizes – what is valuable to the customer and then deploys
these values throughout the engineering process.
Three types of requirement:
1. Normal Requirements – reflect objectives and goals stated for product. If
requirement are present in final products, customer is satisfied.
2. Expected Requirements – customer does not explicitly state them.
Customer assumes it is implicitly available with the system.
3. Exciting Requirements- Features that go beyond the customer’s
expectation.
During meeting with customer –
Function deployment determines the “value” of each function required of the
system.
Information deployment identifies data objects and events and also tied with
functions.
Task deployment examines the behavior of the system.
Value analysis determines the priority of requirements during these 3
deployments.

23
User Scenario
 It is difficult to move into more software engineering
activities until s/w team understands how these
functions and features will be used by diff. end-users.
 Developers and users create a set of usage threads for
the system to be constructed
 A use-case scenario is a story about how someone or
something external to the software (known as an actor)
interacts with the system.
 Describe how the system will be used
 Each scenario is described from the point-of-view of an “actor”—a
person or device that interacts with the software in some way

24
Elicitation Work Products
Elicitation work product will vary depending upon the size of
the system or product to be built.
 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.

25
Software Prototype
 Prototype constructed for customer and developer
assessment.
 In some circumstances construction of prototype is
require in beginning of analysis. (To derive requirement
effectively)
Selecting Prototype Approach
1. Close ended (Throwaway Approach)
2. Open ended (Evolutionary Approach)
Close Ended – It serves as a rough demonstration of
requirement. It is then discarded, and the software
engineered using a different paradigm.
Open Ended - uses the prototype as the first part of an
analysis activity that will be continued into design and
construction. The prototype of the software is the first
evolution of the finished system.

26
 Approaches to prototyping

Evolutionary Delivered
prototyping system
Outline
Requirements
Throw-away Executable Prototype +
Prototyping System Specification

27
Evolutionary prototyping

Develop abstract Build prototype Use prototype

specification system system

Deliver YES System

system adequate?

28
Evolutionary prototyping
advantages
 Accelerated delivery of the system
 Rapid delivery and deployment are
sometimes more important than
functionality or long-term software
maintainability
 User engagement with the system
 Not only is the system more likely to
meet user requirements, they are more
likely to commit to the use of the system

29
Evolutionary prototyping problems
 Management problems
 Existing management processes assume a
waterfall model of development
 Specialist skills are required which may not be
available in all development teams
 Maintenance problems
 Continual change tends to corrupt system
structure so long-term maintenance is expensive
 Contractual problems
 Due to cost or time line agreed

30
 Throw-away prototyping
Outline Develop Evaluate Specify
requirements prototype prototype system

Reusable
components

Delivered
Develop Validate software
software system system

31
Throw-away prototyping
 Used to reduce requirements risk
 The prototype is developed from an initial
specification, delivered for experiment then
discarded
 The throw-away prototype should NOT be
considered as a final system
 Some system characteristics may have been
left out
 There is no specification for long-term
maintenance
 The system will be poorly structured and
difficult to maintain

32
Prototyping Methods and Tools
 A prototype must be developed rapidly so that the customer may assess results and
recommend changes.
3 methods are available:
1. Fourth Generation Techniques (4GT)
 4GT enable the software engineer to generate executable code quickly, they are ideal for
rapid prototyping.
 Ex. Tool for Database query language or reporting language.
2. Reusable software components
 To rapid prototyping is to assemble, rather than build, the prototype by using a set of
existing software components.
 Should maintain library for existing software components
 An existing software product can be used as a prototype for a "new, improved"
competitive product
3. Formal specification and prototyping environments
 Enable an analyst to interactively create language-based specifications of a system or
software,
 Invoke automated tools that translate the language-based specifications into executable
code,
 Enable the customer to use the prototype executable code to refine formal requirements.

33