SOFTWARE ENGINEERING AND

PROJECT MANAGEMENT
Presentation Material
Department of Computer Science & Engineering
Course Code: Semester: V
Software Engineering & Project
Course Title: Year: III
Management
Dr. Meenakshi Malhotra &
Faculty Name:
Dr Bondu Venkateswarlu

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

SEPM
 rd
3 Module Syllabus
■ Understanding Requirements: Requirements Engineering,
Establishing the groundwork, Eliciting Requirements, Developing
use cases, Building the requirements model, Negotiating
Requirements, Validating Requirements

■ Requirements Modeling Scenarios, Information and Analysis

classes: Requirement Analysis, Scenario based modeling, UML
models that supplement the Use Case, Data modeling Concepts
class Based Modeling.
 Understanding Requirements
Understanding Requirements- WHY?
Understanding the requirements of a problem is among the most
difficult tasks that face a software engineer.
What is it?
lead to an understanding of what the business impact of the software will be
Who Does it?
system engineers or “analysts and other project stakeholders
Why is it important?
solves the wrong problem serves no one’s needs
What are the steps?
inception, elicitation, elaboration, negotiation, specification, validation, and
management.
What is the work product?
a written understanding of the problem.
Requirements Engineering
The broad spectrum of tasks and techniques that lead to an understanding of
requirements.
begins during the communication activity and
continues into the modeling activity.

Requirements 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
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
■ communication and collaboration between the customer and the developer
Requirements Engineering
Elicitation:
Why is it difficult to gain a clear understanding of what the customer wants?
Elicit requirements from all stakeholders
“Christel and Kang [Cri92] identify a number of problems that are encountered as
elicitation occurs.”
■ Problems of scope 🡺 boundary of the system is ill-defined
■ Problems of understanding 🡺customers/users are not completely sure of
what is needed
■ Problems of volatility 🡺 requirements change over time
Requirements Engineering
▪ Elaboration—create an analysis model that identifies data, function and
behavioral requirements
The information obtained from the customer during inception and elicitation
is expanded and refined during elaboration.

▪ 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 model
A collection of user scenarios (use-cases)
A prototype
The formality and format of a specification varies with the size and the
complexity of the software to be built.
Requirements Engineering
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.

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
Requirements Engineering
Requirements management

• Requirements management is the process of managing changing

requirements during the requirements engineering process and system
development.
• New requirements emerge as a system is being developed and after it
has gone into use.
• You need to keep track of individual requirements and maintain links
between dependent requirements so that you can assess the impact of
requirements changes.
• You need to establish a formal process for making change proposals
and linking these to system requirements.
Software Requirements Specification (SRS)
Template
Table of Contents

.
Establishing The Groundwork
1. Identifying Stakeholders
2. Recognizing Multiple Viewpoints
3. Working toward Collaboration
4. Asking the First Questions
Establishing The Groundwork
1. Identify stakeholders
❖ “who else do you think I should talk to?”
At inception, you should create a list of people who will contribute input as
requirements are elicited
❖ Any person who benefits directly or indirectly from the system being
developed is a stakeholder.
❖ Business operations managers, product managers, marketing people, internal
and external customers, end-users, consultants, product engineers, software
engineers, and support/maintenance engineers are the usual stakeholders.
❖ Each stakeholder sees the system differently, gains different benefits when
the system is successfully developed and faces different risks if the
development effort fails.
Establishing The Groundwork
2. Recognize Multiple points of view
Because there are so many different stakeholders, the system’s requirements
will be examined from various perspectives.
Each of these stakeholders will contribute data to the requirements engineering
process. As information is gathered from multiple viewpoints, emerging
requirements may be inconsistent or contradictory.
You should categorise all stakeholder information so that decision-makers can
select an internally consistent set of system requirements for the system.
Establishing The Groundwork
3. Work toward collaboration
• If there are five stakeholders involved in a software project, there may
be five different opinions on the set of requirements.
• Customers must work together as well as with software engineering
practitioners to create a successful system.
• A requirements engineer’s job is to identify areas of commonality as
well as areas of conflict or inconsistency. Collaboration does not always
imply that requirements are set by a committee.
• In many cases, stakeholders collaborate by providing their perspective on
requirements, but a strong “project champion” may ultimately decide on
which requirements are accepted.
Establishing The Groundwork
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 aid in identifying all stakeholders who will be
interested in the software being developed.
Moreover, the questions identify the quantifiable benefit of
successful implementation as well as potential alternatives to
custom software development.

.
Establishing The Groundwork

The following set of questions helps in gaining a better understanding of

the problem and allows the customer to express his or her thoughts on
a solution:
❖ How would you characterise “good” output produced by a successful
solution?
❖ To what problem(s) will this solution be applied?
❖ Can you describe (or show me) the business environment in which
the solution will be used?
❖ Will there be any special performance issues or constraints that will
influence how the solution is approached?
 Establishing The Groundwork
The final set of questions is concerned with the effectiveness of the
communication activity itself.
❖ Are you qualified to respond to these questions? Is your response
“official”?
❖ Are my queries relevant to the issue you’re dealing with?
❖ Am I interrogating you too much?
❖ Can anyone else add to this?
❖ Do you have any further questions?
Eliciting Requirements (Requirements
Gathering)
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 that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas.
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
Eliciting Requirements (Requirements
Gathering)
As an example, consider an excerpt from a product request written by a
marketing person involved in the SafeHome project. This person writes the
following narrative about the home security function that is to be part of
SafeHome:

Our research indicates that the market for home management systems
is growing at a rate of 40 percent per year. The first SafeHome function
we bring to market should be the home security function. Most
people are familiar with “alarm systems” so this would be an easy sell.

The home security function would protect against and/or recognize a

variety of undesirable “situations” such as illegal entry, fire, flooding,
carbon monoxide levels, and others. It’ll use our wireless sensors to
detect each situation. It can be programmed by the homeowner, and
will automatically telephone a monitoring agency when a situation is
detected.
THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 Eliciting Requirements (Requirements
Gathering)

✔ Out of these initial meetings, the developer and customers write a

one- or two-page “product request.”
▪ days before the meeting, each attendee is asked to make a list of
objects that are part of the environment that surrounds the system,
▪ the lists may have been posted on an electronic bulletin board, at an
internal website, or posed in a chat room environment for review
prior to the meeting.
▪ the group creates a combined list by eliminating redundant entries,
adding any new ideas that come up during the discussion, but not
deleting anything.
▪ The combined list is shortened, lengthened, or reworded to properly
reflect the product/system to be developed.
▪ stakeholders develop mini-specifications for entries on the lists
Eliciting Requirements (Requirements
Gathering)

For example, the mini-spec for the SafeHome object Control Panel might
be:

The control panel is a wall-mounted unit that is approximately 9x5 inches

in size.
The control panel has wireless connectivity to sensors and a PC. User
interaction occurs through a keypad containing 12 keys. A 3 x 3 inch LCD
color display provides user feedback.

Software provides interactive prompts, echo, and similar functions

Eliciting Requirements (Requirements
Gathering)

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
Eliciting
Requirements
Eliciting Requirements (Requirements
Gathering)
2. Quality Function Deployment(QFD)
Function deployment determines the “value” (as perceived by
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 relative priority of
requirements
QFD “concentrates on maximizing customer satisfaction from the
software engineering process”

QFD uses customer interviews and observation, surveys, and examination of

historical data (e.g., problem reports) as raw data for the requirements
gathering activity
Eliciting Requirements (Requirements
Gathering)
2. Quality Function Deployment(QFD)
QFD identifies three types of requirements
i. Normal requirements. The objectives and goals that are
stated for a product or system during meetings with the
customer.
ii. Expected requirements. These requirements are implicit to
the product or system and may be so fundamental that the
customer does not explicitly state them.
iii. Exciting requirements. These features go beyond the
customer’s expectations and prove to be very satisfying when
present
Eliciting Requirements (Requirements
Gathering)
3. Usage Scenarios
how the system functions and features will be used by
different classes of end users.
To accomplish this, developers and users can create a set of
scenarios that identify a thread of usage for the system to
be constructed.
The scenarios, often called use cases provide a description
of how the system will be used.
Eliciting Requirements (Requirements
Gathering)
4. Elicitation Work Products
a statement of need and feasibility.
a bounded statement of scope for the system or product.
a list of customers, users, and other stakeholders who
participated in requirements elicitation
a description of the system’s technical environment.
a list of requirements (preferably organized by function) and the
domain constraints that apply to each.
a set of usage scenarios that provide insight into the use of the
system or product under different operating conditions.
any prototypes developed to better define requirements.
Eliciting Requirements (Requirements
Gathering)
5. Agile Requirements Elicitation
requirements are elicited by asking all stakeholders to create
user stories .
Each user story describes a simple system requirement written
from the user’s perspective.
This approach is attractive for many software teams
consideration of overall business goals and nonfunctional
requirements is often lacking.
Rework
May not provide a sufficient basis for system evolution over time
Eliciting Requirements (Requirements
Gathering)
6. Service-Oriented Methods
views a system as an aggregation of services.
A service can be “as simple as providing a single function”
Each requirement should be traceable to a specific service.
DEVELOPING USE CASES
A use case tells a stylized story about how an end user (playing
one of a number of possible roles) interacts with the system
under a specific set of circumstances

The story may be narrative text, an outline of tasks or interactions, a

template-based description, or a diagrammatic representation.
Use cases are defined from an actor’s point of view.
An actor is a role that people (users) or devices play as they
interact with the software.

The first step in writing a use case is to define the set of

“actors” that will be involved in the story.
DEVELOPING USE CASES
Unified Modelling language(UML) use case diagrams are ideal for:

Representing the goals of system-user interactions

Defining and organizing functional requirements in a system

Specifying the context and requirements of a system

Modeling the basic flow of events in a use case

DEVELOPING USE CASES
DEVELOPING USE CASES
Types of Actors:
Primary actors
❖ interact to achieve required system function and derive the intended
benefit from the system.
❖ They work directly and frequently with the software.

Secondary actors
❖ support the system so that primary actors can do their work.
DEVELOPING USE CASES
Jacobson [Jac92] suggests a number of questions that should be answered by a use
Case
Who is the primary actor, the secondary actor(s)?
What are the actor’s goals?
What preconditions should exist before the story begins?
What main tasks or functions are performed by the actor?
What exceptions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
DEVELOPING USE CASES
Basic SafeHome requirements, we define four actors (primary):
homeowner (a user),
setup manager (likely the same person as homeowner, but playing a
different role),
sensors (devices attached to the system), and
the monitoring and response subsystem (the central station that monitors
the SafeHome home security function).
DEVELOPING USE CASES
Basic SafeHome requirements, we define four actors (primary):
homeowner (a user),
setup manager (likely the same person as homeowner, but playing a
different role),
sensors (devices attached to the system), and
the monitoring and response subsystem (the central station that monitors
the SafeHome home security function).
DEVELOPING USE CASES
Secondary Actors: These are external systems or users who indirectly interact
with the home security system:

Emergency Services (e.g., Police, Fire Department): Receives notifications

when alarms are triggered.

Maintenance Technician: Interacts with the system to perform diagnostics or

maintenance.

Remote Monitoring Service: A third-party service that may receive alerts

and status updates for monitoring the property remotely.
DEVELOPING USE CASES
DEVELOPING USE CASES
DEVELOPING USE CASES
DEVELOPING USE CASES –
UML use case diagram for SafeHome home security function

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
DEVELOPING USE CASES –
Restaurant
UML Use Case Diagram Example

Purpose: Two alternative examples

of business use case diagram for a
Restaurant - external and internal
business views of a restaurant.
Summary: Several business actors
having some needs and goals as
related to the restaurant and business
use cases expressing expectations of
the actors from the business.
DEVELOPING USE CASES –
Online Library Public Access Catalog
Purpose: List top level use cases for e-Library online public access catalog.
Summary: Patrons of a library can search library catalog online to locate various resources -
books, periodicals, audio and visual materials, or other items under control of the library.
Patrons may reserve or renew item, provide feedback, and manage their account.

Calculate late fee

Update profile

Category based

Not reserved articles

THESE SLIDES ARE DESIGNED TO ACCOMPANY SOFTWARE ENGINEERING: A PRACTITIONER’S APPROACH, 7/E
(MCGRAW-HILL, 2009). SLIDES COPYRIGHT 2009 BY ROGER PRESSMAN.
 DEVELOPING USE CASES –
University Course Registration System
Description:
A course registration system allows students to register for courses, professors to manage
course content, and administrators to handle course scheduling.

Actors:

1.Student – Registers and drops courses, views grades.

2.Professor – Manages course content and grades students.

3.Registrar/Admin – Schedules courses and manages student records.

.
DEVELOPING USE CASES –
Use Cases:
1.Search Courses (Student)
1. Browse courses based on department, professor, or semester.
2.Register for Course (Student)
1. Add a course to the student's schedule.
3.Drop Course (Student)
1. Remove a previously registered course.
4.View Grades (Student)
1. Access grades for completed courses.
5.Manage Course Content (Professor)
1. Update course syllabus, add assignments, and upload materials.
6.Grade Students (Professor)
1. Enter grades for student assessments and assignments.
7.Schedule Courses (Registrar/Admin)
1. Plan and organize course availability for each semester.
8.Manage Student Records (Registrar/Admin)
1. Update student profiles and academic records.
Building the Analysis Model
the analysis model is a snapshot of requirements at any given time.

Elements of the analysis model

Scenario-based elements
Functional—processing narratives for software functions
Use-case—descriptions of the interaction between an “actor” and the system

they serve as input for the creation of other modeling elements.

🡺 UML activity diagram

Class-based elements
Implied by scenarios

Behavioral elements
State diagram

Flow-oriented elements
Data flow diagram
Class Diagram

From the SafeHome system …

Class Diagrams

Depicts a static view of an application

Purpose of Class Diagrams

1.It analyses and designs a static view of an application.

2.It describes the major responsibilities of a system.
3.It is a base for component and deployment diagrams.
4.It incorporates forward and reverse engineering.

48
Class Diagrams

Benefits of Class Diagrams

It can represent the object model for complex systems.

It reduces the maintenance time by providing an overview of how
an application is structured before coding.
It provides a general schematic of an application for better
understanding.
It represents a detailed chart by highlighting the desired code,
which is to be programmed.
It is helpful for the stakeholders and the developers.

49
Class Diagram Example: Order System
State Diagram

Reading
Commands
System status = “ready” State name
Display msg = “enter cmd”
Display status = steady
State variables
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input
State activities
 State diagram (state machine diagram or
statechart diagram)
an illustration of all the possible behavioral states a software system component
may exhibit and the various state changes it's predicted to undergo over the
course of its operations

Benefits and uses of state diagrams

• List the events responsible for altering system states.

• Model dynamic behavior and activity of a system.

• Demonstrate the response of a system to different types of stimuli.

• Represent finite state machines visually.

• Illustrate the entire lifecycle of an object.

 State diagram
Symbols and components of state diagrams

•Initial state. A solid black circle that represents the initial state of a system or a class.
•States. Individual states are portrayed as boxes with rounded corners that contain the
name of the state (usually written in CamelCase).
•State actions. Any actions that a particular state is expected to invoke are designated by
a box with two sections:
•An upper section containing the name of the state and
•a lower section containing the actions it will initiate (as well as any relevant variable
names).
•Transitions. Straight lines each with an arrow at one end connect various pairs
of state boxes, providing an ordered designation of the state transitions that will
occur.
•Final state. Final state is portrayed as a large black dot with a circle around it.
State diagram
Symbols and components of state diagrams
State diagram
Bank ATM behavioral state machine UML diagram example
State diagram-Alarm System
State diagram
Analysis Patterns
▪ Pattern name: A descriptor that captures the essence of the pattern.
▪ Intent: Describes what the pattern accomplishes or represents
▪ Motivation: A scenario that illustrates how the pattern can be used to address
the problem.
▪ Forces and context: A description of external issues (forces) that can affect how
the pattern is used and also the external issues that will be resolved when the
pattern is applied.
▪ Solution: A description of how the pattern is applied to solve the problem with
an emphasis on structural and behavioral issues.
▪ Consequences: Addresses what happens when the pattern is applied and what
trade-offs exist during its application.
▪ Design: Discusses how the analysis pattern can be achieved through the use of
known design patterns.
▪ Known uses: Examples of uses within actual systems.
▪ Related patterns: On e or more analysis patterns that are related to the named
pattern because (1) it is commonly used with the named pattern; (2) it is
structurally similar to the named pattern; (3) it is a variation of the named
pattern.
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”
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?
Validating Requirements - II
❖ 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?
Processes of Requirements Gathering in
Software Development: