Module-2 ppt.pptx contents for software engineering

Requirements Engineering:
• Understanding Requirements: Requirements Engineering, Establishing the
ground work, 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.
• Requirement Modeling Strategies : Flow oriented Modeling , Behavioral
Modeling.
• Textbook 1: Chapter 5: 5.1 to 5.7, Chapter 6: 6.1 to 6.5, Chapter 7: 7.1 to 7.3

Requirement Engineering
• The process of collecting the software requirement from the client
then understand, evaluate and document it is called as Requirement
Engineering.
• Requirement engineering constructs a bridge for design and
construction.

Requirement Engineering Tasks
 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirement management

 Inception
At project inception, you establish a 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 other stakeholders and the software team.
 Elicitation
It certainly seems simple enough—ask the customer, the users, and
others what the objectives for the system or product are, what is to be
accomplished, how the system or product fits into the needs of the
business, and finally, how the system or product is to be used on a day-
to-day basis.

Elaboration
The information obtained from the customer during inception and
elicitation is expanded and refined during elaboration. This task
focuses on developing a refined requirements model that identifies
various aspects of software function, behavior, and information.
Negotiation. It isn’t unusual for customers and users to ask for more
than can be achieved, given limited business resources. It’s also
relatively common for different customers or users to propose
conflicting requirements, arguing that their version is “essential for our
special needs.”

• Specification. In the context of computer-based systems (and software), the
term specification means different things to different people. A specification
can be a written document, a set of graphical models, a formal mathematical
model, a collection of usage scenarios, a prototype, or any combination of
these.
• Validation. The work products produced as a consequence of requirements
engineering are assessed for quality during a validation step. Requirements
validation examines the specification to ensure that all software requirements
have been stated unambiguously; that inconsistencies, omissions, and errors
have been detected and corrected; and that the work products conform to
the standards established for the process, the project, and the product.

Requirements management. Requirements for computer-based
systems change, and the desire to change requirements persists
throughout the life of the system. Requirements management is a set
of activities that help the project team identify, control, and track
requirements and changes to requirements at any time as the project
proceeds.

The 4 steps of the requirements engineering process
•Eliciting requirements.
•Requirements specification(FR & NFR)
•Verification and validation.
•Requirements management.

Establishing the 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.
• 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. None of these things are desirable, but all are
fairly common, and you are often forced to work within the constraints
imposed by this situation.

• Identifying Stakeholders
• Recognizing Multiple Viewpoints
• Working toward Collaboration
• Asking the First Questions

• Identifying Stakeholders
Each stakeholder has a different view of the system, achieves different benefits
when the system is successfully developed, and is open to different risks if the
development effort should fail.
• Recognizing Multiple Viewpoints
Business managers are interested in a feature set that can be built within budget
and that will be ready to meet defined market windows. End users may want
features that are familiar to them and that are easy to learn and use. Software
engineers may be concerned with functions that are invisible to nontechnical
stakeholders but that enable an infrastructure that supports more marketable
functions and features. Support engineers may focus on the maintainability of the
software.

• Working toward Collaboration
Collaboration does not necessarily mean that requirements are defined by
committee. In many cases, stakeholders collaborate by providing their view
of requirements, but a strong “project champion” (e.g., a business manager
or a senior technologist) may make the final decision about which
requirements make the cut.
• Asking the First Questions
Questions asked at the inception of the project should be “context free”
[Gau89]. The first set of context-free questions focuses on the customer and
other stakeholders, the overall project goals and benefits.

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 help to identify all stakeholders who will have interest in the software
to be built. In addition, the questions identify the measurable benefit of a successful
implementation and possible alternatives to custom software development.

Eliciting 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
[Zah90].

Different Approaches for Requirement Elicitation
• Collaborative Requirements Gathering
• Quality Function Deployment
• Usage Scenarios
• Elicitation Work Products

• Collaborative Requirements 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.
• An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas.

• Quality Function Deployment
• Quality function deployment (QFD) is a quality management technique that
translates the needs of the customer into technical requirements for software.
QFD “concentrates on maximizing customer satisfaction from the software
engineering process”
• To accomplish this, QFD emphasizes an understanding of what is valuable to the
customer and then deploys these values throughout the engineering process.
• QFD identifies three types of requirements.
• Normal requirements.
• Expected requirements.
• Exciting requirements

Quality Function Deployment
• Normal requirements
• Example of normal requirements might be requested types of graphical displays,
specific system functions, and defined levels of performance.
• Expected requirements
• Examples of expected requirements are: ease of human/machine interaction
overall operational correctness and reliability, and ease of software installation.
• Exciting requirements
• For 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

• Usage Scenarios
• An overall vision of system functions and features begins to
materialize. However, it is difficult to move into more technical
software engineering activities until you understand functions and
features will be used by different classes of end users.
• 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 [ Jac92]

• Elicitation Work Products
The work products produced as a consequence of requirements elicitation will vary depending
on the size of the system or product to be built. For most systems, the work products include
• 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

• Stakeholder Interviews: Discussing needs, expectations, and pain
points with end-users, domain experts, and project managers.
• Workshops and Brainstorming Sessions: Facilitating group
discussions to uncover ideas and identify functionalities.
• Document Analysis: Reviewing existing documents like business
process models or user manuals.
• Surveys and Questionnaires: Gathering quantitative data on user
preferences and priorities.
• Prototyping: Building basic models to gain user feedback and refine
requirements.

Developing Use-Cases
• A use case diagram is a visual representation of how users interact
with a system to achieve specific goals. It's a core part of Unified
Modeling Language (UML) and is used in software design and
development.

Components of Use case Diagram
• Actors: These represent anything that interacts with the system, like a person (customer, administrator),
another system, or an external device. By identifying the actors, you understand who uses the system and for
what purposes.
• Use Cases: These are functionalities or features offered by the system. Each use case represents a complete
flow of activities where an actor interacts with the system to achieve a goal. Use cases help define the
system's functionalities from the user's perspective.
• Relationships: Use case diagrams show how actors and use cases connect. This helps visualize how different
functionalities work together and how users interact with them. There are different types of relationships, like
includes (common functionality) and extends (optional functionality), that provide a more nuanced
understanding of the system's behavior.

Importance of Use Case Diagrams:
• Functionality Depiction:
• Early Identification of Issues
• System Scope Definition
• Documentation

• In essence, use case diagrams offer a high-level overview of a system's functionalities and user
interactions. This visual representation fosters better communication, helps identify potential
problems early on, and lays the foundation for successful system development.

SAFE HOME SYSTEM(please refer text book
for detailed understanding safe Home)

SAFE HOME SYSTEM
• Objects described for Safe Home might include the control panel,
• Smoke detectors, window and door sensors , motion detectors,
• An alarm, an event (a sensor has been activated), a display, a PC, telephone numbers, a
telephone call, and so on.
• The list of services might include configuring the system, setting the alarm, monitoring
the sensors, dialing the phone,
• Programming the control panel, and reading the display (note that services act on objects).
• In a similar fashion, each attendee will develop
• lists of constraints (e.g., the system must recognize when sensors are not operating, must
be user-friendly, must interface directly to a standard phone line) and performance criteria
(e.g., a sensor event should be recognized within one second, and an event priority scheme
should be implemented)

SAFE HOME SYSTEM
Recalling basic Safe Home requirements
• we define four actors: 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 Safe Home
home security function).
• For the purposes of this example, we consider only the homeowner
actor. The homeowner actor interacts with the home security function in
a number of different ways using either the alarm control panel or a PC:

SAFE HOME SYSTEM
• Enters a password to allow all other interactions.
• Inquires about the status of a security zone.
• Inquires about the status of a sensor.
• Presses the panic button in an emergency.
• Activates/deactivates the security system.

SAFE HOME SYSTEM
• Considering the situation in which the homeowner uses the control
panel, the basic use case for system activation follows:
• 1. The homeowner observes the Safe Home control panel to
determine if the system is ready for input. If the system is not ready, a
not ready message is displayed on the LCD display, and the
homeowner must physically close windows or doors so that the not
ready message disappears. [A not ready message implies that a
sensor is open; i.e., that a door or window is open.]

SAFE HOME SYSTEM
2.The homeowner uses the keypad to key in a four-digit password. The
password is compared with the valid password stored in the system. If
the password is incorrect, the control panel will beep once and reset
itself for additional input. If the password is correct, the control panel
awaits further action.
3. The homeowner selects and keys in stay or away (see Figure 5.1) to
activate the system. Stay activates only perimeter sensors (inside
motion detecting sensors are deactivated). Away activates all sensors.
4. When activation occurs, a red alarm light can be observed by the
homeowner.

Requirements Specification
• Functional Requirements: Functional requirements define a function that a system or
system element must be qualified to perform and must be documented in different forms.
The functional requirements are describing the behavior of the system as it correlates to the
system's functionality.
• Non-functional Requirements: This can be the necessities that specify the criteria that can
be used to decide the operation instead of specific behaviors of the system.
Non-functional requirements are divided into two main categories:

Building the requirement models
• 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

Building the requirement models
• Scenario-based elements.
• Class-based elements.
• Behavioral elements.

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 (Section 5.4) and their
corresponding use-case diagrams (Figure 5.2) evolve into more
elaborate template-based use cases.
Figure 5.3 depicts a UML activity diagram for eliciting requirements and
representing them using use cases. Three levels of elaboration are
shown, culminating in a scenario-based representation.

UML Activity diagram for Eliciting Requirements

• Class-based elements
Each usage scenario implies a set of objects that are manipulated as an
actor interacts with the system. 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 Safe Home security function (Figure 5.4).
Note that the diagram lists the attributes of sensors (e.g., name, type)
and the operations (e.g., identify, enable) that can be applied to modify
these attributes

• 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 state diagram
• 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 in Figure 5.5

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

• Flow-oriented elements: Information is transformed as it flows
through a computer-based system. The system accepts input in a
variety of forms, applies functions to transform it, and produces
output in a variety of forms. Input may be a control signal
transmitted by a transducer, a series of numbers typed by a human
operator, a packet of information transmitted on a network link, or a
voluminous data file retrieved from secondary storage.

• Analysis Patterns
These analysis patterns [Fow97] suggest solutions (e.g., a class, a
function, a behavior) within the application domain that can be reused
when modeling many applications.
First, analysis patterns speed up the development of abstract analysis
models that capture the main requirements of the concrete problem by
providing reusable analysis models with examples as well as a
description of advantages and limitations.
Second, analysis patterns facilitate the transformation of the analysis
model into a design model by suggesting design patterns and reliable
solutions for common problems.

Negotiating requirement
• 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.
• The best negotiations strive for a “win-win” result. That is,
stakeholders win by getting the system or product that satisfies the
majority of their needs and you (as a member of the software team)
win by working to realistic and achievable budgets and deadlines.

Negotiating requirement
• 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).
• Successful completion of these initial steps achieves a win-win result, which
becomes the key criterion for proceeding to subsequent software
engineering activities.

Validating requirements
• 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.
• 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?
• Is the requirement really necessary or does it represent an add-on feature that
may not be essential to the objective of the system?

Validating requirements
• 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?
• 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?

MODULE-2
• 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.

Requirements Modeling Scenarios, Information
and Analysis classes
• 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.

Module-2 ppt.pptx contents for software engineering

Overall Objectives and Philosophy
• 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, and
(3) to define a set of requirements that can be validated once the
software is built.
The analysis model bridges the gap between a system level description
that describes overall system or business functionality as it is achieved
by applying software, hardware, data, human, and other system
elements and a software design.

Analysis Rules of Thumb
• The model should focus on requirements that are visible within the
problem or business Don’t get bogged down in details domain. The level
of abstraction should be relatively high. [Arl02] that try to explain how
the system will work.
• Each element of the requirements model should add to an overall
understanding of software requirements and provide insight into the
information domain, function, and behavior of the system.
• Delay consideration of infrastructure and other nonfunctional models
until design. That is, a database may be required, but the classes
necessary to implement it, the functions required to access it, and the
behavior that will be exhibited as it is used should be considered only
after problem domain analysis has been completed.

Analysis Rules of Thumb
 Minimize coupling throughout the system. It is important to represent relation-
ships between classes and functions. However, if the level of
“interconnectedness” is extremely high, effort should be made to reduce it.
 Be certain that the requirements model provides value to all stakeholders. Each
constituency has its own use for the model. For example, business stakeholders
should use the model to validate requirements; designers should use the model
as a basis for design; QA people should use the model to help plan acceptance
tests.
 Keep the model as simple as it can be. Don’t create additional diagrams when
they add no new information. Don’t use complex notational forms, when a simple
list will do.

Domain Analysis
• The “specific application domain” can range from avionics to
banking, from multimedia video games to software embedded within
medical devices.
• The goal of domain analysis is straightforward: to find or create
those analysis classes and/or analysis patterns that are broadly
applicable so that they may be reused.

The “specific application domain” can range from avionics to banking,
from multimedia video games to software embedded within medical
devices. The goal of domain analysis is straightforward: to find or create
those analysis classes and/or analysis patterns that are broadly
applicable so that they may be reused.

Elements of Analysis Model
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.
A second approach to analysis modeling, called object-oriented
analysis, focuses on the definition of classes and the manner in which
they collaborate with one another to effect customer requirements.
UML and the Unified Process are predominantly object oriented.

Elements of Analysis Model
• Scenario-based elements depict how the user interacts with the system
and the specific sequence of activities that occur as the software is used.
• Class-based elements model the objects that the system will manipulate,
the operations that will be applied to the objects to effect the
manipulation, relationships(some hierarchical) between the objects,
and the collaborations that occur between the classes that are defined.
• Behavioral elements depict how external events change the state of the
system or the classes that reside within it. Finally, flow-oriented elements
represent the system as an information transform, depicting how data
objects are transformed as they flow through various system functions.

Scenario based modeling
• 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.

Scenario based modeling
Scenario based modeling has the following steps
• Creating a Preliminary Use Case
• Refining a Preliminary Use Case
• Writing a Formal Use Case

Creating a Preliminary Use Case
• To illustrate, consider the function access camera surveillance via the
Internet—display camera views (ACS-DCV). The stakeholder who takes
on the role of the homeowner actor might write the following
narrative:
• Use case: Access camera surveillance via the Internet—display
camera views(please refer text book complete example)

Refining a Preliminary Use Case
• A description of alternative interactions is essential for a complete understanding
of the function that is being described by a use case. Therefore, each step in the
primary scenario is evaluated by asking the following questions [Sch98a]:
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter some error condition at this point? If
so, what might it be?
• Is it possible that the actor will encounter some other behavior at this point (e.g.,
behavior that is invoked by some event outside the actor’s control)? If so, what
might it be?

Writing a Formal Use Case
• Use case: Access camera surveillance via the Internet—display
camera views (ACS-DCV)
• The ACS-DCV use case shown in the sidebar follows a typical outline
for formal use cases. The goal in context identifies the overall scope of
the use case. The precondition describes what is known to be true
before the use case is initiated.
• The trigger identifies the event or condition that “gets the use case
started”. The scenario lists the specific actions that are required by
the actor and the appropriate system responses.

UML models that supplement the Use Case
• UML Models that Supplements the USE case are
• Activity Diagram
• Swimlane Diagram
• 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 flow chart, 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 control

Swimlane 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 (discussed later
in this chapter) 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 6.5

Module-2 ppt.pptx contents for software engineering

More Related Content

Similar to Module-2 ppt.pptx contents for software engineering (20)

Recently uploaded (20)

Module-2 ppt.pptx contents for software engineering