SOFTWARE
ENGINEERING AND
PROJECT
MANAGEMENT(SEPM)
Mr Arun P
Assistant Professor
Department of
Computer Science & Engineering
Department of
Computer Science & Engineering
[Link]
MODULE 2 - SYLLABUS
• Understanding Requirements: Requirements Engineering,
Establishing the ground work, Eliciting Requirements,
Developing use cases, Building the requirements model,
Negotiating Requirements, Validating Requirements
CHAPTER 5
UNDERSTANDING
REQUIREMENTS
REQUIREMENTS ENGINEERING
▪The broad spectrum of tasks and techniques that lead to an
understanding of requirements is called requirements engineering.
▪Requirements engineering is a major software engineering action
that begins during the communication activity and continues into the
modeling activity
▪Key Points : Requirements engineering establishes a solid base for
design and construction. Without it, the resulting software has a high
probability of not meeting customer’s needs.
ELICTING REQUIREMENTS
• Requirements elicitation (also called requirements gathering) combines
elements of problem solving, elaboration, negotiation, and specification.
• In order to encourage a collaborative, team-oriented approach to
requirements gathering, stakeholders work together to identify the
problem, propose elements of the solution, negotiate different approaches
and specify a preliminary set of solution requirements
COLLABORATIVE REQUIREMENT
GATHERING
▪Many different approaches to collaborative requirements gathering have
been proposed. Each makes use of a slightly different scenario, but all
apply some variation on the following basic guidelines
▪ Meetings are conducted and attended by both software engineers and
other stakeholders.
▪Rules for preparation and participation are established.
COLLABORATIVE REQUIREMENT
GATHERING
• 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.
ESTABLISHING GROUND WORK
•In an ideal setting, stakeholders and software engineers work together
on the same team
•In such cases, requirements engineering is simply a matter of
conducting meaningful conversations with colleagues who are well-
known members of the team. But reality is often quite different.
ESTABLISHING GROUND WORK
•Customer(s) or end users may be located in a different city or country, may
have only a vague idea of what is required, may have conflicting opinions
about the system to be built, may have limited technical knowledge, and
may have limited time to interact with the requirements engineer
•Key Points : A stakeholder is anyone who has a direct interest in or
benefits from the system that is to be developed.
DEVELOPING USE CASES
• The story may be narrative text, an outline of tasks or interactions, a
template-based description, or a diagrammatic representation. Regardless of
its form, a use case depicts the software or system from the end user’s point
of view.
•The first step in writing a use case is to define the set of “actors” that will
be involved in the story
•Actors are the different people (or devices) that use the system or product
within the context of the function and behavior that is to be described.
DEVELOPING USE CASES
• Actors represent the roles that people (or devices) play as the system
operates. Defined somewhat more formally, an actor is anything that
communicates with the system or product and that is external to the system
itself. Every actor has one or more goals when using the system
•Key Points: 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
DEVELOPING USE CASES
• 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.
•Once actors have been identified, use cases can be developed.
Developing Use Cases Example Safe
Home control panel
.
UML use case diagram for SafeHome
home security function
BUILDING THE REQUIREMENTS
MODEL
•The intent of the analysis model is to provide a description of the
required informational, functional, and behavioral domains for a
computer-based system.
•The model changes dynamically as you learn more about the system to
be built, and other stakeholders understand more about what they really
require.
Elements of the Requirements Model
Scenario-based elements. The system is described from the user’s
point of view using a scenario-based approach. For example, basic use
cases and their corresponding use-case diagrams evolve into more
elaborate template-based use cases. Scenario-based elements of the
requirements model are often the first part of the model that is
developed.
Class-based elements. Each usage scenario implies a set of objects
that are manipulated as an actor interacts with the system.
Elements of the Requirements Model
These objects are categorized into classes—a collection of things that
have similar attributes and common behaviors. For example, a UML
class diagram can be used to depict a Sensor class for the SafeHome
security function
Behavioral elements. The behavior of a computer-based system can
have a profound effect on the design that is chosen and the
implementation approach that is applied. Therefore, the requirements
model must provide modeling elements that depict behavior.
UML activity diagrams for eliciting
requirements
UML activity diagrams for eliciting
requirements
Class diagram for sensor The state diagram is one method for
representing the behavior of a system by
depicting its states and the events that
cause the system to change state. A state
is any externally observable mode of
behavior. In addition, the state diagram
indicates actions (e.g., process
activation) taken as a consequence of a
particular event.
UML activity diagrams for eliciting
requirements
UML state diagram notation To illustrate the use of a state diagram,
consider software embedded within the
Safe Home control panel that is responsible
for reading user input. A simplified UML
state diagram is shown.
Key Points : A state is an externally
observable mode of behavior. External
stimuli cause transitions between states.
NEGOTIATING REQUIREMENTS
•In an ideal requirements engineering context, the inception, elicitation,
and elaboration tasks determine customer requirements in sufficient detail
to proceed to subsequent software engineering activities.
•. Unfortunately, this rarely happens. In reality, you may have to enter into
a negotiation with one or more stakeholders.
•In most cases, stakeholders are asked to balance functionality,
performance, and other product or system characteristics against cost and
time-to-market.
NEGOTIATING REQUIREMENTS
•Boehm [Boe98] defines a set of negotiation activities at the beginning of
each software process iteration. Rather than a single customer
communication activity, the following activities are defined:
1. Identification of the system or subsystem’s key stakeholders.
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a
set of win-win conditions for all concerned (including the software team).
VALIDATING REQUIREMENTS
•As each element of the requirements model is created, it is examined for
inconsistency, omissions, and ambiguity.
•The requirements represented by the model are prioritized by the
stakeholders and grouped within requirements packages that will be
implemented as software increments. A review of the requirements model
addresses the following questions:
VALIDATING REQUIREMENTS
⮚A review of the requirements model addresses the following questions:
• Is each requirement consistent with the overall objectives 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?
VALIDATING REQUIREMENTS
⮚A review of the requirements model addresses the following questions:
•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?
VALIDATING REQUIREMENTS
⮚A review of the requirements model addresses the following questions:
• Do any requirements conflict with other requirements?
• 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?
REQUIREMENT ANALYSIS
•Requirements analysis results in the specification of software’s
operational characteristics, indicates software’s interface with other
system elements, and establishes constraints that software must meet.
•Requirements analysis allows you (regardless of whether you’re
called a software engineer, an analyst, or a modeler) to elaborate on
basic requirements established during the inception, elicitation, and
negotiation tasks that are part of requirements engineering
REQUIREMENT ANALYSIS
•The requirements modeling action results in one or more of the
following types of models:
•Scenario-based models of requirements from the point of view of
various system “actors”
• Data models that depict the information domain for the problem
•Class-oriented models that represent object-oriented classes
(attributes and operations) and the manner in which classes collaborate
to achieve system requirements
REQUIREMENT ANALYSIS
•The requirements modeling action results in one or more of the
following types of models:
•Flow-oriented models that represent the functional elements of the
system and how they transform data as it moves through the system
• Behavioral models that depict how the software behaves as a
consequence of external “events”
THE REQUIREMENT MODEL AS A
BRIDGE BETWEEN THE SYSTEM
DESCRIPTION AND DESIGN MODEL
Modeling — A representation of the
object-oriented classes and the resultant
collaborations that allow a system to
function.
REQUIREMENT ANALYSIS
The requirements model must achieve three primary objectives:
(1) To describe what the customer requires.
(2) To establish a basis for the creation of a software design.
(3) To define a set of requirements that can be validated once the
software is built.
DOMAIN ANALYSIS
▪Analysis patterns often reoccur across many applications within a specific
business domain
▪If these patterns are defined and categorized in a manner that allows you
to recognize and apply them to solve common problems, the creation of the
analysis model is expedited
▪More important, the likelihood of applying design patterns and
executable software components grows dramatically. This improves time-
to-market and reduces development costs.
SOFTWARE
DOMAIN ANALYSIS
•Software domain analysis is the identification, analysis, and specification
of common requirements from a specific application domain, typically for
reuse on multiple projects within that application domain.
• [Object-oriented domain analysis is] the identification, analysis, and
specification of common, reusable capabilities within a specific application
domain, in terms of common objects, classes, subassemblies, and
frameworks.
INPUT AND OUTPUT OF DOMAIN
ANALYSIS
REQUIREMENTS MODELING
APPROACHES
REQUIREMENTS MODELING
APPROACHES
▪One view of requirements modeling, called structured analysis,
considers data and the processes that transform the data as separate
entities.
▪Data objects are modeled in a way that defines their attributes and
relationships.
▪Processes that manipulate data objects are modeled in a manner that
shows how they transform data as data objects flow through the
system.
SCENARIO-BASED MODELING
▪ Your software team will be better able to properly characterize
requirements and build meaningful analysis and design model
▪Hence, requirements modeling with UML begins with the creation of
scenarios in the form of use cases, activity diagrams, and swim lane
diagrams.
CREATING A PRELIMINARY USE
CASE
▪The “contract” defines the way in which an actor uses a computer-
based system to accomplish some goal.
▪In essence, a use case captures the interactions that occur between
producers and consumers of information and the system itself.
CREATING A PRELIMINARY USE
CASE
Use case: Access camera surveillance via the Internet—display
camera views (ACS-DCV)
Actor: homeowner
1. The homeowner logs onto the Safe Home Products website.
2. 2. The homeowner enters his or her user ID.
CREATING A PRELIMINARY USE
CASE
3. The homeowner enters two passwords (each at least eight characters in
length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function
buttons.
.
CREATING A PRELIMINARY USE
CASE
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the
camera ID.
11. The system displays video output within the viewing window at
one frame per second.
Preliminary use-case diagram for the
Safe Home system
UML MODELS THAT SUPPLEMENT
THE USE CASE
▪There are many requirements modeling situations in which a text-
based model— even one as simple as a use case There are many
requirements modeling situations in which a text-based model— even
one as simple as a use case.
▪In such cases, you can choose from a broad array of UML graphical
models.
Key Points : A UML activity diagram represents the actions and
decisions that occur as some function is performed.
DEVELOPING AN ACTIVITY
DIAGRAM
▪The UML activity diagram supplements the use case by providing a
graphical representation of the flow of interaction within a specific
scenario.
▪Similar to the flowchart, an activity diagram uses rounded rectangles to
imply a specific system function, arrows to represent flow through the
system, decision diamonds to depict a branching decision (each arrow
emanating from the diamond is labeled), and solid horizontal lines to
indicate that parallel activities are occurring.
Activity diagram for Access camera
surveillance via the Internet— display
camera views function.
SWIM LANE DIAGRAMS
▪The UML swim lane diagram is a useful variation of the activity diagram
and allows you to represent the flow of activities described by the use case
and at the same time indicate which actor (if there are multiple actors
involved in a specific use case) or analysis class has responsibility for the
action described by an activity rectangle.
▪Responsibilities are represented as parallel segments that divide the
diagram vertically, like the lanes in a swimming pool. Three analysis classes
—Homeowner, Camera, and Interface—have direct or indirect
responsibilities in the context of the activity diagram represented in Figure.
Swim lane diagram for Access camera
surveillance via the Internet—display
camera views function
DATA MODELING CONCEPTS
▪If software requirements include the need to create, extend, or interface
with a database or if complex data structures must be constructed and
manipulated, the software team may choose to create a data model as part
of overall requirements modeling.
▪A software engineer or analyst defines all data objects that are
processed within the system, the relationships between the data objects,
and other information that is pertinent to the relationships
DATA MODELING CONCEPTS
▪The entity-relationship diagram (ERD) addresses these issues and
represents all data objects that are entered, stored, transformed, and
produced within an application.
▪Data Objects :
▪A data object is a representation of composite information that must
be understood by software. By composite information, I mean something
that has a number of different properties or attributes.
DATA MODELING CONCEPTS
▪Therefore, width (a single value) would not be a valid data object, but
dimensions (incorporating height, width, and depth) could be defined as
an object.
▪A data object can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a display), an occurrence
(e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson),
an organizational unit (e.g., accounting department), a place (e.g., a
warehouse), or a structure (e.g., a file).
DATA MODELING CONCEPTS
▪For example, a person or a car can be viewed as a data object in the
sense that either can be defined in terms of a set of attributes.
Data Attributes :
▪Data attributes define the properties of a data object and take on one of
three different characteristics.
▪They can be used to (1) name an instance of the data object, (2)
describe the instance, or (3) make reference to another instance in
another table
DATA MODELING CONCEPTS
Tabular representation of data objects