Requirements Engineering-I

Requirement
 Something required, something wanted or needed
 Webster’s dictionary

 There is a huge difference between wanted and needed and it should

be kept in mind all the time
 Need- something you have to have
 Want -something you would like to have
 3

Chapter 4 Requirements
engineering

Requirement Cont’d…
• It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification.
• This is inevitable as requirements may serve a dual
function
▫ May be the basis for a bid for a contract - therefore
must be open to interpretation;
▫ May be the basis for the contract itself - therefore must
be defined in detail;
▫ Both these statements may be called requirements.
Software Requirements
 A complete description of what the software system will do without describing
how it will do it is represented by the software requirements

 Software requirements are complete specification of the desired external

behavior of the software system to be built

Response of
software against
the input
 Software requirements may be:
 Abstract statements of services and/or constraints
 Detailed mathematical functions
 Part of the bid of contract
 The contract itself
 Part of the technical document, which describes a product
Requirement[3]
Can be Functionality
constraint

 A condition or capability that must be met or possessed by a system...to

satisfy a contract, standard, specification, or other formally imposed
document
▫ IEEE Std 729
Examples of Requirements
• The system shall maintain records of all library
materials including books, serials, newspapers
and magazines, video and audio tapes, reports,
collections of transparencies, CD-ROMs, DVDs,
etc.

• The system shall support at least twenty

transactions per second
Examples of Requirements
• The system shall allow users to search for an
item by title, author, or by International
Standard Book Number

• The system’s user interface shall be

implemented using a web browser
Sources of Requirement
• Stakeholders
 People affected in some way by
the system

• Interviews with users and

other stakeholders

• Documents
Sources of Requirement
• Existing system
 Enhancement Requests for the
existing system

• Domain/business area
Sources of Requirement
• Observations of users performing tasks
• Concept of Operation or Vision document
• Procedure manuals and user task lists
• Marketing material and product definitions
• Analysis of a market leader or competitor's
products
 The Goal of Software Development[1]
 The goal of software development is to
develop quality software—on time and on
budget—that meets customers' real needs.

 A software is good if its meets

STAKEHOLDERS EXPECTATIONS:
 it is (at least) correct, reliable, maintainable,
user-friendly …
 the total cost it incurs over all phases of its
life cycle is minimal and within the budget
The Root Causes of Project Success and Failure[1]
Thereafter, the data diverges rapidly. Of course, your project
could fail
 because of an unrealistic schedule or time frame (4 percent of the
projects cited this),
 inadequate staffing and resources (6 percent),
 inadequate technology skills (7 percent), or various other reasons.

 The survey shows that at least a third of development projects run

into trouble for reasons that are directly related to requirements
gathering, requirements documentation, and requirements management.
The Root Causes of Project Success and Failure[1]
 Executive management support: 14 percent of all successful projects
 Clear statement of requirements: 12 percent of all successful projects
Levels of requirements

• User requirements
• System requirements
• Business requirements
• Functional requirements
Case study:
In an international airport, many different
counters for the different airlines have been set up
in order to assist their passengers. But due to
budget cuts the manager of the airport has to let go
of some of the counter staff. In order to
compensate for this assistance, the airport has
decided to install self- service kiosk at different
places throughout the airport.
User requirements
“These requirements describe goals or tasks the user must
be able to perform with the product that will provide value
to someone.”

Statements in natural language plus diagrams of the services the

system provides and its operational constraints. Written for
customers. User requirements describe what the user will be able
to do with the system.

According to Case study User can:

• Check in for a flight
• Book a seat for a flight
System requirements
“A structured document setting out detailed descriptions of
the system’s functions, services and operational
constraints. Defines what should be implemented so may
be part of a contract between client and contractor.”

• More detailed specifications of user requirements

• Serve as a basis for designing the system
• May be used as part of the system contract
• System requirements may be expressed using system
models.
Business requirements
“Business requirements describe why the organization is
implementing the system- the business benefits the
organization hopes to achieve.”

In accordance to the case study mentioned above

the business requirements could be:
To reduce the airport counter staff by some percentage (lets
say 25 percent)
Functional requirements
“These requirements specify what the developers must
implement to enable users to accomplish their tasks.”

Case study
• The passenger can view schedule of a flight by
entering source, destination and date.
• The system will show all possible flights available.
• Passenger can select a particular flight and click on
“book now” button.
• If the passenger’s profile does not indicate a seating
preference, the system shall assign an available seat.
 20

Chapter 4 Requirements
engineering

Requirements engineering
• The process of establishing the services that the
customer requires from a system and the
constraints under which it operates and is
developed.
• The requirements themselves are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.
RE process
Definition:
“RE is a set of activities concerned with
identifying and communicating the purpose of a
software intensive system and the context in
which it will be used.”
 Requirements Engineering Process
 Elicitation: work with the customer on
gathering requirements

 Analysis: process this information to

understand it, classify in various
categories, and relate the
customer needs to possible
software requirements

 Specification: Structure the customer

input and derived requirements as
written documents and diagrams

 Validation: you’ll ask your customer to

confirm that what you’ve written is
accurate and complete and to correct
errors.
 Requirements Management
• Requirements management is the process of documenting,
analyzing, tracing, prioritizing and agreeing on requirements
and then controlling change and communicating to relevant
stakeholders.
Various documents of RE
 25

Ta Daaaa!!!!
Found few new things in Slides ??? Different from lectures?
Well !
HAPPY READING..!