SOFTWARE ENGINEERING

(CSE 2014)

Department of Computer Science and Engineering

School of Engineering,
PRESIDENCY UNIVERSITY
 MODULE II

Understanding Requirements (Chapter

4)

Department of Computer Science and Engineering

School of Engineering, Presidency University
Module 2: Software Requirements and
Design – Comprehension level
Requirements Engineering: Eliciting requirements, Functional and
non- Functional requirements, SRS, Requirements modelling:
Developing Use Cases, Developing Activity diagram and Swim lane
diagram, Design : Design concepts, Architectural design,
Component based design, User interface design.

Dept. of CSE, SOE, Presidency University

3
Contents
1. Requirements Engineering
1.1 Inception
1.2 Elicitation
1.3 Elaboration
1.4 Negotiation
1.5 Specification
1.6 Validation
1.7 Requirements Management
2. Establishing the ground work
3. Eliciting requirements
4. Developing Use-Case
5. Building the requirements model
6. Negotiating requirements
7. Validating requirements

Dept. of CSE, SOE, Presidency University

4
1. Requirements Engineering
-I
1. 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
2. Elicitation - elicit requirements from all stakeholders
3. Elaboration - create an analysis model that identifies data, function and
behavioral requirements
4. Negotiation - agree on a deliverable system that is realistic for developers
and customers

Dept. of CSE, SOE, Presidency University

5
1. Requirements Engineering
-I
5. Specification - can be any one (or more) of the following
 A written document
 A set of models
 A formal mathematical specification
 A collection of user scenarios (use-cases)
 A prototype

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

7. Requirements management

Dept. of CSE, SOE, Presidency University

6
Functional and Non functional Requirements
Functional Requirements
• These are the requirements that the end user specifically demands as
basic facilities that the system should offer.
• All these functionalities need to be necessarily incorporated into the
system as a part of the contract.

Non Functional Requirements

• These are basically the quality constraints that the system must satisfy
according to the project contract.
• The priority or extent to which these factors are implemented varies
from one project to other. They are also called non-behavioral
requirements.

Dept. of CSE, SOE, Presidency University

7
 NON FUNCTIONAL
FUNCTIONAL REQUIREMENTS
REQUIREMENTS
1. A functional requirement defines a system A non-functional requirement defines the
or its component. quality attribute of a software system.

It places constraints on “How should the

2. It specifies “What should the software
software system fulfill the functional
system do?”
requirements?”

Non-functional requirement is specified by

3. Functional requirement is specified by
technical peoples e.g. Architect, Technical
User.
leaders and software developers.
4. It is mandatory. It is not mandatory.
5. It is captured in use case. It is captured as a quality attribute.
6. Defined at a component level. Applied to a system as a whole.
7. Helps you verify the functionality of the Helps you to verify the performance of the
software. software.

8. Functional Testing like System, Non-Functional Testing like Performance,

Integration, End to End, API testing, etc are Stress, Usability, Security testing, etc are
done. done.
9. Usually easy to define. Usually more difficult to define.

Dept. of CSE, SOE, Presidency University 8

Software Requirements Specification
• A software requirements specification (SRS) is a document that is created when a
detailed description of all aspects of the software to be built must be specified before the
project is to commence.
• It is important to note that a formal SRS is not always written
1. Introduction
• 1.1 Purpose
• 1.2 Document Conventions
• 1.3 Intended Audience and Reading Suggestions
• 1.4 Project Scope
• 1.5 References
2. Overall Description
• 2.1 Product Perspective
• 2.2 Product Features
• 2.3 User Classes and Characteristics
• 2.4 Operating Environment

Dept. of CSE, SOE, Presidency University

9
• 2.5 Design and Implementation Constraints
• 2.6 User Documentation
• 2.7 Assumptions and Dependencies
3. System Features
• 3.1 System Feature 1
• 3.2 System Feature 2 (and so on)
4. External Interface Requirements
• 4.1 User Interfaces
• 4.2 Hardware Interfaces
• 4.3 Software Interfaces
• 4.4 Communications Interfaces
5. Other Nonfunctional Requirements
• 5.1 Performance Requirements
• 5.2 Safety Requirements
• 5.3 Security Requirements
• 5.4 Software Quality Attributes
6. Other Requirements

10
Dept. of CSE, SOE, Presidency University
2. Establishing the ground
work
 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?

Dept. of CSE, SOE, Presidency University

11
 3. Eliciting
Requirements
3.1 Collaborative Requirements Gathering

 meetings are conducted and attended by both software engineers and

customers
 rules for preparation and participation are established
 an agenda is suggested
 a "facilitator" (can be a customer, a developer, or an outsider) controls the
meeting
 a "definition mechanism" (can be work sheets, flip charts, or wall stickers
or an electronic bulletin board, chat room or virtual forum) is used
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements

Dept. of CSE, SOE, Presidency University

12
3.2 Quality Function Deployment
Normal requirements: Requirements which are stated during the
meeting with the customer
Example:) normal requirements might be requested types of
graphical displays, specific system functions
Expected requirements: Requirements are implicit to the product or
system that are not explicitly stated by the customer.
Exciting requirements: features go beyond the customer’s
expectations and prove to be very satisfying when present.
Example:) software for a new mobile phone comes with standard
features, but is coupled with a set of unexpected capabilities (e.g.,
multitouch screen, visual voice mail) that delight every user of the
product.

Dept. of CSE, SOE, Presidency University

13
3.3 Usage Scenarios
• A usage scenario, or scenario for short, describes a real-world
example of how one or more people or organizations interact with
a system.
• They describe the steps, events, and/or actions which occur
during the interaction.
• Usage scenarios can be very detailed, indicating exactly how
someone works with the user interface, or reasonably high-level
 describing the critical business actions but not the indicating how
they're performed.

Dept. of CSE, SOE, Presidency University

14
• Usage scenarios are applied in several development processes,
often in different ways.
• In derivatives of the Unified Process (UP) they are used the help
move from use cases to sequence diagrams.
• The basic strategy is to identify a path though a use case, or
through a portion of a use case, and then write the scenario as an
instance of that path.

Dept. of CSE, SOE, Presidency University

15
• For example, the text of the "Withdraw Funds" use case
would indicate what should happens when everything
goes right, in this case the funds exist in the account and
the ATM has the funds.
• This would be referred to as the "happy path" or basic
course of action.
• The use case would include alternate paths describing
what happens when mistakes occur, such as there being
insufficient funds in the account or the ATM being short
of cash to disburse to customers.
• You would write usage scenarios that would explore the
happy path, such as the first scenario above, as well as
each of the alternate courses. You would then develop a
sequence diagram exploring the implementation logic for
each scenario.

Dept. of CSE, SOE, Presidency University

16
3.4 Elicitation work product
• The work product created as a result of requirement elicitation
that is depending on the size of the system or product to be  built.
• The work product consists of a statement need, feasibility,
statement scope for the system.
• It also consists of a list of users participate in the requirement
elicitation.

Dept. of CSE, SOE, Presidency University

17
4. Developing use cases

Use Case Methodology (UCM) (for Requirements

Elicitation)
Key Terms in UCM
 SUD – System under Discussion

 Actor
Actors are basically users of the SUD who are external entities (people or other systems)
who interact with the SUD to achieve a desired goal. Actors are represented as stick
figures.
Types of Actors:
 Primary Actor
The Actor(s) using the system to achieve a goal.
 Secondary Actor
Actors that the system needs assistance from to achieve the primary actors goal.

 Use Case
A use case is a collection of possible sequences of interactions between the SUD and its
Actors, relating to a particular goal. The collection of Use Cases should define all system
behavior relevant to the actors to assure them that their goals will be carried out properly.
A use case is drawn as a horizontal ellipse.

Dept. of CSE, SOE, Presidency University

18
Key Terms in UCM
Use Cases:
 Hold Functional Requirements in an easy to read, easy to track text format.
 Represents the goal of an interaction between an actor and the system. The goal represents a
meaningful and measurable objective for the actor.
 Records a set of paths (scenarios) that traverse an actor from a trigger event (start of the use case) to
the goal (success scenarios).
 Records a set of scenarios that traverse an actor from a trigger event toward a goal but fall short of
the goal (failure scenarios).
 Are multi-level: one use case can use/extend the functionality of another.
 Use Case Names Begin With a Strong Verb
 Use Cases are named using the domain terminologies

Use Cases Do Not…

 Specify user interface design. They specify the intent, not the action detail
Mock up screens/ Prototype may be included depicting the functionality
 Specify implementation detail (unless it is of particular importance to the actor to be assured that the
goal is properly met)

Dept. of CSE, SOE, Presidency University

19
Key Terms in UCM

 Use Case Relationships (Associations)

Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved
with an interaction described by a use case. 
There are several types of relationships that may appear on a use case
diagram:
 An association between an actor and a use case
 An association between two use cases
 A generalization between two actors
 A generalization between two use cases

Dept. of CSE, SOE, Presidency University

20
Key Terms in UCM

 Includes Relationship
"X includes Y" indicates that the task "X" has a subtask "Y"; that is, in
the process of completing task "X", task "Y" will be completed at least
once.

 Extends Relationship
"X extends Y" indicates that "X" is a task of the same type as "Y", but
"X" is a special, more specific case of doing "Y". That is, doing X is a
lot like doing Y, but X has a few extra processes to it that go above and
beyond the things that must be done in order to complete Y.

Dept. of CSE, SOE, Presidency University

21
Key Terms in UCM

 Use Case Diagram

A use case diagram shows the relationships among actors and use cases
within a SUD.

 Use Case Model

A use case model is comprised of one or more use case diagrams and any
supporting documentation such as use case specifications and actor
definitions.  Within most use case models the use case specifications tend
to be the primary artifact with use case diagrams filling a supporting role
as the “glue” that keeps the requirements model together.

Dept. of CSE, SOE, Presidency University

22
 Use Case Diagram

Association
Use Case 1 <<include>> Use Case 3
relationship

Generalization

Actor
Use Case 2 <<extend>> Use Case 4

Dept. of CSE, SOE, Presidency University

 Use Case Diagram
Airline Reservation System

Reservation System

Add Reservation

Cancel Reservation

Ticket Clerk
Check-in Passenger <<include>> Weigh Luggage

<<include>>

Assign Seat <<extend>> Assign Window Seat

<<extend>>

Assign Aisle Seat

Dept. of CSE, SOE, Presidency University

Use Case Diagram
ATM Transaction

Dept. of CSE, SOE, Presidency University

5. Building the Requirements Model
Activity Diagram for Eliciting Requirements

Dept. of CSE, SOE, Presidency University

26
Elements
• Scenario based elements
• Class based elements
• Behavioral elements
• Flow – oriented elements

Analysis Patterns
• suggest solutions (e.g., a class, a function, a behavior) within the
application domain that can be reused when modeling many
applications.

Dept. of CSE, SOE, Presidency University

27
6. Negotiating Requirements

 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”

Dept. of CSE, SOE, Presidency University

28
7. Validating Requirements - I

 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?

Dept. of CSE, SOE, Presidency University

29
Validating Requirements - I

 Is each requirement achievable in the technical environment that

will house the system or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the information,
function and behavior of the system to be built.
 Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the system.
 Have requirements patterns been used to simplify the requirements
model. Have all patterns been properly validated? Are all patterns
consistent with customer requirements?

Dept. of CSE, SOE, Presidency University

30