1

Please read this disclaimer before

proceeding:
This document is confidential and intended solely for the educational purpose of
RMK Group of Educational Institutions. If you have received this document
through email in error, please notify the system manager. This document
contains proprietary information and is intended only to the respective group /
learning community as intended. If you are not the addressee you should not
disseminate, distribute or copy through e-mail. Please notify the sender
immediately by e-mail if you have received this document by mistake and delete
this document from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in reliance on
the contents of this information is strictly prohibited.

2
 22CS602-OBJECT ORIENTED SOFTWARE ENGINEERING

DEPARTMENT : CSE/ADS/AIML/CSD
BATCH : 2021-2025
YEAR/SEMESTER :III/VI

CREATED BY

OVER ALL CO-ORDINATOR:Dr.N.R.Rejin Paul

CREATED ON :20.12.2024
 Table of Contents
S.NO Topic Page No.

1. Contents 4

2. Course Objectives 5

3. Pre-Requisites 6

4. Syllabus 7

5. Course outcomes 8

6. CO- PO/PSO Mapping 9

7. Unit -I Lecture Plan 11

8. Activity based learning 12

9. Lecture notes 13-51

10. Assignments 52

11. Part A Q&A (WITH K LEVEL AND CO) 53

12. Part B Qs (WITH K LEVEL AND CO) 56

13. Supportive online Certification courses 57

14. Real time Applications in day

58
to day life and to Industry

15. Assessment Schedule 59

16. Prescribed Textbooks & Reference Books 60

17. Mini Project suggestions 61

4
 Course
Objectives

• To explain software engineering principles and activities involved in

building large software programs.
• To describe the process of requirements gathering, analysis and unified
modelling
• To illustrate the object oriented design process.
• To analyse various traditional and object oriented testing methods
• To apply estimation techniques, schedule project activities and
compute pricing.

5
 Pre-Requisites

Semester IV
22CS602 - OBJECT ORIENTED SOFTWARE ENGINEERING

Semester II
22CS201-DATA STRUCTURES

6
 SYLLABUS

22CS602 OBJECT ORIENTED SOFTWARE ENGINEERING LTP C

302 4
UNIT I PRODUCT AND PROCESS 9

The Nature of Software – Defining the Discipline – The Software Process – Process models
– Prescriptive Process Models – Product and Process – Agility and Process – What is an
Agile Process?– Scrum– Other Agile Framework – Kanban – DevOps

UNIT II REQUIREMENTS AND UNIFIED MODELING 9

Requirements Engineering – Establishing the Groundwork: Non-functional Requirements –
Requirements Gathering – Developing Use Cases – Negotiating and Validating
Requirements. Unified Modeling Language – Introduction – Static and Dynamic Models –
Modelling – Introduction to the UML – UML Diagrams – UML Class Diagrams – Use-Case
Diagram – UML Dynamic Modelling.

UNIT III OBJECT ORIENTED ANALYSIS AND DESIGN 9

Object oriented Analysis process – Business object Analysis – Use-case driven OOA –
Business process modelling – Use case model. Design Concepts -Design Process – Design
Concepts – Design Model: Design Principles and Design Elements. Architectural Design–
Designing class- based components - Conducting Component Level Design –-
User Interface Analysis and Design – Pattern-
Based Software Design

UNIT IV SOFTWARE TESTING 9

Component Level: A Strategic Approach to Software Testing – White-Box Testing – Black
Box Testing- Object Oriented Testing. Integration Level: Integration Testing – AI and
Regression Testing- – Integration Testing in the OO Context Specialized Testing for Mobility:
Web application Testing – Web Testing Strategies – Security Testing – Performance Testing
– Real time Testing – Testing AI Systems – Testing Virtual Environments
UNIT V SOFTWARE QUALITY AND PROJECT MANAGEMENT
Software Metrics and Analytics: Software Measurement – Product Metrics. Creating a Viable
Software Plan: The Project Planning Process – Software Scope and Feasibility –
Decomposition and Estimation Techniques – Project Scheduling. Risk Management: Reactive
 Course outcomes

Upon completion of the course, the students will be able to:

8
 CO- PO/PSO
Mapping

Program
Program Outcomes Specific
Level Outcomes
Course
of
OutCome
CO K3,
s K3 K4 K4 K5 K5, A3 A2 A3 A3 A3 A3 A2 PS
K6 PS PS
O-
O-2 O-3
1
PO- PO- PO- PO- PO- PO- PO- PO- PO- PO- PO- PO-
1 2 3 4 5 6 7 8 9 10 11 12

2 1 1 - - - - - - - - - 2 2 -
CO1 K2

2 1 1 - - - - - - - - - 2 2 -
CO2 K2

3 2 2 - - - - - - - - 1 2 2 -
CO3 K2

3 2 2 - - - - - - - - 1 2 2 -
CO4 K3

3 2 2 - - - - - - - - 1 2 2 -
C05 K3

9
 UNIT - II

REQUIREMENTS AND UNIFIED MODELING

10
 Lecture Plan Unit -2
Sl. Topic Number Proposed Actual CO Taxonom Mode of
No of Date Lectur y Level Delivery
Periods e Date
.
1 Requirements 1 C02 K2 PPT,
Engineering Chalk
and Talk

2 Establishing 1 C02 K2 PPT,

the Chalk
Groundwork: and Talk
Nonfunctional
Requirements
3 Requirements 1 C02 K3 PPT,
Gathering Chalk
and Talk

4 Developing 1 C02 K2 PPT,

Use Cases Chalk
and Talk

5 Negotiating 1 C02 K2 PPT,

and Validating Chalk
Requirements. and Talk
Unified
Modeling
Language –
Introduction
6 Static and 1 C02 K3 PPT,
Dynamic Chalk
Models – and Talk
Modelling
7 Introduction to 1 C02 K3 PPT,
the UML – Chalk
UML Diagrams and Talk

8 UML Class 1 C02 K2 PPT,

Diagrams – Chalk
Use-Case and Talk
Diagram
9 UML Dynamic 1 C02 K3 PPT,
Modelling Chalk
and Talk
 Activity based learning
Exercise:
Crossword Puzzle

`
ACTIVITY-Represent workflows in an graphical way.
CLASS-Main building block of any object oriented solution.
DEPLOYMENT-Shows the hardware of your system and the software in those
hardware
PACKAGE-Shows the dependencies between different packages in a system
OBJECT-Sometimes referred as Instance diagrams and very similar to class
diagrams.
STATEMACHINE-Describes the behavior of objects that act different
according to the state they are at the moment.
COMMUNICATION-Focuse on messages passed between objects
COMPONENT-Displays the structural relationship of components of a
software system
USECASE-Gives a graphic overview of the actors involved in a system,
different functions needed by those actors.
PROFILE-Which describes lightweight extension mechanism to the UML
TIMING-Represent the behavior of objects in a given time frame
SEQUENCE-Shows how object interact with each other and the order those
interactions occur

12
 22CS602 OBJECT ORIENTED SOFTWARE ENGINEERING
UNIT II REQUIREMENTS AND UNIFIED MODELING

Requirements Engineering – Establishing the Groundwork: Non-functional Requirements

– Requirements Gathering – Developing Use Cases – Negotiating and Validating
Requirements. Unified Modeling Language – Introduction – Static and Dynamic Models –
Modelling – Introduction to the UML – UML Diagrams – UML Class Diagrams – Use-Case
Diagram – UML Dynamic Modelling.

Requirements Engineering:

Designing and building computer software is challenging, creative, and just plain
fun. In fact, building software is so compelling that many software developers want to
jump right in before they have a clear understanding of what is needed. They argue that
things will become clear as they build, that project stakeholders will be able to understand
need only after examining early iterations of the soft- ware, that things change so rapidly
that any attempt to understand requirements in detail is a waste of time, that the bottom
line is producing a working program, and that all else is secondary. What makes these
arguments seductive is that they contain elements of truth.' But each argument is flawed
and can lead to a failed software project.
The broad spectrum of tasks and techniques that lead to an understanding of
requirements is called requirements engineering. From a software process per- spective,
requirements engineering is a major software engineering action that begins during the
communication activity and continues into the modeling activity. It must be adapted to
the needs of the process, the project, the product, and the people doing the work.
Requirements engineering encompasses seven distinct tasks: inception, elicitation,
elaboration, negotiation, specification, validation, and management. It is important to
note that some of these tasks occur in parallel and all are adapted to the needs of the
project

13
 Inception.

How does a software project get started? Is there a single event that becomes
the catalyst for a new computer-based system or product, or does the need evolve
over time? There are no definitive answers to these questions. In some cases, a
casual conversation is all that is needed to precipitate a major software engineering
effort. But in general, most projects begin when a business need is identified or a
potential new market or service is discovered. Stakeholders from the business
community (e.g., business managers, marketing people, product managers) define a
business case for the idea, try to identify the breadth and depth of the market, do a
rough feasibility analysis, and identify a working description of the project's scope. All
of this information is subject to change, but it is sufficient to precipitate discussions
with the software engineering organization. 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. But it isn't simple— it's very hard.
An important part of elicitation is to establish business goals. Your job is to
engage stakeholders and to encourage them to share their goals honestly. Once the
goals have been captured, a prioritization mechanism should be established, and a
design rationale for a potential architecture (that meets stake- holder goals) can be
created.
 Christel and Kang identify a number of problems that are encountered as
elicitation occurs.

Problems of scope
It occur when the boundary of the system is ill-defined or the customers
and users specify unnecessary technical detail that understanding may confuse,
rather than clarify, overall system objectives.

Problems of understanding
These are encountered when customers and users are not completely sure
what is needed, have a poor understanding of the capabilities and limitations of
their computing environment, don't have a full understanding of the problem
domain, have trouble communicating needs, omit information that is believed to be
“obvious,” specify requirements that conflict with the needs of other customers and
users, or specify requirements that are ambiguous or untestable.

Problems of volatility
It occur when the requirements change over time.
To help overcome those problems, you must approach the requirements-gathering
activity in an organized manner.

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.
Elaboration is driven by the creation and refinement of user scenarios that
describe how the end user will interact with the system. Each user scenario is
parsed to extract analysis classes—business domain entities that are visible to the
end user. The attributes of each analysis class are defined, and the services' that
are required by each class are identified. The relationships and collaboration
between classes are identified, and a variety of supplementary diagrams are
produced.
 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.”

You have to reconcile these conflicts through a process of negotiation.

Customers, users, and other stakeholders are asked to rank requirements
and then discuss conflicts in priority. Using an iterative approach that prioritizes
require- ments, assesses their cost and risk, and addresses internal conflicts,
requirements are eliminated, combined, and/or modified so that each party
achieves some measure of satisfaction.

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.
Some suggest that a “standard template” should be developed and used for
a specification, arguing that this leads to requirements that are presented in a
consistent and therefore more understandable manner. However, it is sometimes
necessary to remain flexible when a specification is to be developed. For large
systems, a written document, combining natural language descriptions and
graphical models may be the best approach. However, usage scenarios may be all
that are required for smaller products or systems that reside within well-understood
technical environments.
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.
The primary requirements validation mechanism is the technical
review . The review team that validates requirements includes software
engineers, customers, users, and other stakeholders who examine the specification
looking 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 requirements, or unrealistic (unachievable)
requirements.

Establishing the Groundwork

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.
In the sections that follow, we discuss the steps required to establish the
groundwork for an understanding of software requirements—to get the project started in
a way that will keep it moving forward toward a successful solution
 Identifying Stakeholders
We have already identified the usual suspects: business operations
managers, product managers, marketing people, internal and external customers,
end users, consultants, product engineers, software engineers, support and
maintenance engineers, and others. 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.
At inception, you should create a list of people who will contribute input as
requirements are elicited . The initial list will grow as stakeholders are contacted
because every stakeholder will be asked: “Whom else do you think I should talk
to?”

Recognizing Multiple Viewpoints

Because many different stakeholders exist, the requirements of the system
will be explored from many different points of view. For example, the marketing
group is interested in functions and features that will excite the potential market,
making the new system easy to sell. 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.
Each of these constituencies (and others) will contribute information to the
requirements engineering process. As information from multiple viewpoints is
collected, emerging requirements may be inconsistent or may conflict with one
another. You should categorize all stakeholder information including inconsistent
and conflicting requirements) in a way that will allow decision makers to choose
an internally consistent set of requirements for the system.
 Working towards collaboration

If five stakeholders are involved in a software project, you may have five (or
more) different opinions about the proper set of requirements. Throughout earlier
chapters, we have noted that customers (and other stakeholders) should collaborate
among themselves (avoiding petty turf battles and with software engineering
practitioners if a successful system is to result. But how is this collaboration
accomplished?
The job of a requirements engineer is to identify areas of commonality (i.e.,
requirements on which all stakeholders agreed and areas of conflict or inconsistency
(i.e., requirements that are desired by one stakeholder but conflict with the needs of
another stakeholder). It is, of course, the latter category that presents a
challenge.
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” The
first set of context-free questions focuses on the customer and other stake-holders,
the overall project goals and benefits. For example, you might ask:

• 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.
 The next set of questions enables you to gain a better understanding of the
problem and allows the customer to voice his or her perceptions about a solution:

How would you characterize “good” output that would be generated by a

successful solution?
What problem(s) will this solution address?
Can you show me (or describe) the business environment in which the solution
will be used?
Will special performance issues or constraints affect the way the solution is
approached?

The final set of questions focuses on the effectiveness of the communication

activity itself. Gause and Weinberg [Gau89l call these “meta-questions” and pro- pose
the following (abbreviated) list:
Are you the right person to answer thèse questions? Are your answers “official”?
Are my questions relevant to the problem that you have?
Am I asking too many questions?
Can anyone else provide additional information?
Should I be asking you anything else?
These questions (and others) will help to “break the ice” and initiate the com-
munication that is essential to successful elicitation. But a question-and-answer meeting
format is not an approach that has been overwhelmingly successful. In fact, the Q&A
session should be used for the first encounter only and then re- placed by a
requirements elicitation format that combines elements of problem solving, negotiation,
and specification.
 Nonfunctional Requirements

A nonfunctional requirement (NFR) can be described as a quality attribute, a

performance attribute, a security attribute, or a general constraint on a system. These
are often not easy for stakeholders to articulate. Chung [Chu09l suggests that there is
a lopsided emphasis on functionality of the software, yet the software may not be
useful or usable without the necessary non-functional characteristics. we discuss a
technique called quality Function deployment (QFDJ. Quality function deployment
attempts to translate unspoken customer needs or goals into system requirements.
Nonfunctional requirements are often listed separately in a software requirements
specification.
As an adjunct to QFD, it is possible to define a two-phase approach [Hue Ill that
can assist a software team and other stakeholders in identifying nonfunc- tional
requirements. During the first phase, a set of software engineering guide- lines is
established for the system to be built. These include guidelines for best practice, but
also address architectural style and the use of design patterns . A list of NFRs (e.g.,
requirements that address usability, testability, security or maintainability) is then
developed. A simple table lists NFRs as column tables and software engineering
guidelines as row tables. A relationship matrix compares each guideline to all others,
helping the team to assess whether each pair of guidelines is complementary,
overlapping, conflicting, or independent.
In the second phase, the team prioritizes each nonfunctional requirement by
creating a homogeneous set of nonfunctional requirements using a set of decision
rules that establish which guidelines to implement and which to reject.
 Requirements Gathering
Requirements elicitation (also called Requirements gatherings 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 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 (either real or virtual) are conducted and attended by both soft- ware
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.

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. A one- or
two-page "product request" is generated during inception . A meeting place, time, and
date are selected; a facilitator is chosen; and attendees from the software team and
other stakeholder organizations are invited to partic- ipate. The product request is
distributed to all attendees before the meeting date.
As an example, consider an excerpt from a product request written by a
marketing person involved in the SafeHome project. This person writes the fol- lowing
narrative about the home security function that is to be part of SafeHome
 In reality, others would contribute to this narrative during the requirements-
gathering meeting and considerably more information would be available. But even with
additional information, ambiguity is present, omissions are likely to exist, and errors
might occur. For now, the preceding “functional description” will suffice.
While reviewing the product request in the days before the meeting, each at-
tendee is asked to make a list of objects that are part of the environment that surrounds
the system, other objects that are to be produced by the system, and objects that are
used by the system to perform its functions. In addition, each attendee is asked to make
another list of services (processes or functions) that manipulate or interact with the
objects. Finally, lists of constraints (e.g., cost, size, business rules and performance
criteria (e.g., speed, accuracy) are also developed. The attendees are informed that the
lists are not expected to be exhaustive but are expected to reflect each person's
perception of the system.
Objects described for Safe Home might include the control panel, smoke de-
tectors, 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).
The lists of objects can be pinned to the walls of the room using large sheets of
paper, stuck to the walls using adhesive-backed sheets, or written on a wall board.
Alternatively, the lists may have been posted on a group forum, at an internal website,
or posed in a social networking environment for review prior to the meeting. Ideally,
each listed entry should be capable of being manipulated separately so that lists can be
combined, entries can be deleted, and additions can be made. At this stage, critique and
debate are strictly prohibited.
 After individual lists are presented in one topic area, the group creates a
combined list by eliminating redundant entries, adding any new ideas that come
up during the discussion, but not deleting anything. After you create combined
lists for all topic areas, discussion coordinated by the facilitator—ensues. The
combined list is shortened, lengthened, or reworded to properly reflect the
product or system to be developed. The objective is to develop a consensus list of
objects, services, constraints, and performance for the system to be built.

In many cases, an object or service described on a list will require further

explanation. To accomplish this, stakeholders develop mini-specifications for
entries on the lists or by creating a use case that involves the object or service.
The mini specs are presented to all stakeholders for discussion. Additions,
deletions, and further elaboration are made. In some cases, the development of
mini-specs will uncover new objects, services, constraints, or performance re-
quirements that will be added to the original lists. During all discussions, the team
may raise an issue that cannot be resolved during the meeting. An issues list is
maintained so that these ideas will be acted on later.
Many stakeholder concerns (e.g., accuracy, data accessibility, securityJ are
the basis for nonfunctional system requirements . As stakeholders enunciate these
concerns, software engineers must consider them within the context of the system
to be built. Among the questions that must be answered Laglol are as follows:

Can we build the system?

Will this development process allow us to beat our competitors to market?
Do adequate resources exist to build and maintain the proposed system?
Will the system performance meet the needs of our customers?

The answers to these and other questions will evolve over time.
 Developing Use Cases

Alistair Cockburn notes that “a use case captures a contract ... [thatl describes the
system's behavior under various conditions as the system responds to a request from one
of its stakeholders ...” In essence, 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. 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. Actors
represent the roles that people (or devices play as the system operates. Defined
somewhat more formally, an actor is anything that communi- cates with the system or
product and that is external to the system itself. Every actor has one or more goals when
using the system.
It is important to note that an actor and an end user are not necessarily the same
thing. A typical user may play a number of different roles when using a system, whereas
an actor represents a class of external entities (often, but not always, people that play
just one role in the context of the use case. As an ex- ample, consider a machine
operator (a user) who interacts with the control com- puter for a manufacturing cell that
contains a number of robots and numerically controlled machines. After careful review of
requirements, the software for the control computer requires four different modes (roles)
for interaction: program- ming mode, test mode, monitoring mode, and troubleshooting
mode. Therefore, four actors can be defined: programmer, tester, monitor, and
troubleshooter. In some cases, the machine operator can play all of these roles. In
others, different people may play the role of each actor.
 Because requirements elicitation is an evolutionary activity, not all actors
are identified during the first iteration. It is possible to identify primary actors
during the first iteration and secondary actors as more is learned about the
system. Primary actors interact to achieve required system function and do- rive
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. Jacobson
suggests a number of questions" that should be answered by a use case:

Who is the primary actor, the secondary actor?

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?
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
SafeHome home se- curity function). For the purposes of this example, we
consider only the home- owner 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. The homeowner

(1J enters a password to allow all other interactions,

(2) inquires about the status of a security zone,
(3) inquires about the status of a sensor,
(4) presses the panic button in an emergency,
(5) activates/deactivates the security system.
 Considering the situation in which the homeowner uses the control panel,
the basic use case for system activation follows:'3

1. The homeowner observes the Safe Home control panel (Figure) 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 read y message disappears. EA not read y
message implies that a sensor is open; i.e., that a door or window is open.1
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 (Figure ) to activate the
system. Stay activates only perimeter sensors (inside motion detecting sensors are
deactivated). Sway activates all sensors.
4. When activation occurs, a red alarm light can be observed by the
homeowner.
 The basic use case presents a high-level story that describes the interaction
between the actor and the system.

In many instances, uses cases are further elaborated to provide considerably more
detail about the interaction. For example, Cockburn suggests following template for
detailed descriptions of use cases:

Use case: Initiate Monitoring

Primary actor: Homeowner.
Goal in context: To set the system to monitor sensors when the homeowner leaves
the house or remains inside.
Preconditions: System has been programmed for a password and to recognize
various sensors.
Trigger: The homeowner decides to “set” the system, that is, to turn on the alarm
functions.

Scenario.
Homeowner: observes control panel
Homeowner: enters password

Homeowner: selects “stay" or ‘away"

Homeowner: observes read alarm light to indicate that Safe home has been armed

Exceptions:
1. Control panel is not ready: homeowner checks all sensors to determine which are
open; closes them.

2. Password is incorrect (control panel beeps once): homeowner reenters correct

password.
3. Password not recognized: monitoring and response subsystem must be contacted
to reprogram password.
4. Stay is selected: control panel beeps twice and a stay light is lit; perimeter sensors
are activated.
5. Away is selected: control panel beeps three times and an away light is lit; all
sensors are activated.
 Priority: Essential, must be implemented
When available: First increment
Frequency of use: Many times per day
Channel to actor: Via control panel interface
Secondary actors: Support technician, sensors

Channels to secondary actors:

Support technician. phone line
Sensors: hardwired and radio frequency interfaces
Open issues:

1. Should there be a way to activate the system without the use of a

password or with an abbreviated password?
2. Should the control panel display additional text messages?
3. How much time does the homeowner have to enter the password from
the time the first key is pressed?

4. Is there a way to deactivate the system before it actually activates?

Use cases for other homeowner interactions would be developed in a

similar manner. It is important to review each use case with care. If some element
of the interaction is ambiguous, it is likely that a review of the use case will
indicate a problem.
UML use case diagram for Safe Home home security function
 Negotiating and Validating Requirements

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.The intent of this negotiation is to develop a project plan that meets
stakeholder needs while at the same time reflecting the real-world constraints (e.g.,
time, people, budget) that have been placed on the software team.

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.

Boehm defines a set of negotiation activities at the beginning of each

publications/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
be- comes the key criterion for proceeding to subsequent software engineering
activities.
 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 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
or 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 individuals 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?
Has the requirements model been “partitioned“ in a way that exposes pro-
gressively 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?
These and other questions should be asked and answered to ensure that
the requirements model is an accurate reflection of stakeholder needs and that it
provides a solid foundation for design.
 Unified Modeling Language
Introduction to the UML
The Unified Modeling Language is a visual language for specifying, constructing
and documenting the artifacts of systems. The word visual in the definition is a key
point the UML is the de facto standard diagramming notation for drawing or
presenting pictures. The standard is managed, and was created, by the Object
Management Group. It was first added to the list of OMG adopted technologies in
1997.

UML Diagrams
UML is composed of 9 graphical diagrams:

1. Class Diagram-describes the structure of a system by showing the system’s

classes ,their attributes, and the relationships among the classes.

2. Use Case Diagram-describes the functionality provided by a system in terms of

actors, their goals represented as use cases, and any dependencies among those
use cases.

2.Behaviour Diagram

a. Interaction Diagram
1. Sequence Diagram-shows how objects communicate with each other in terms
of a sequence of messages .Also indicates the lifespan of objects relative to those
messages.
2. Communication diagram: how the interactions between objects or parts in
terms of sequenced messages

a. State Chart Diagram –describes the states and state transitions of the
system.

b. Activity Diagram-describes the business and operational step-by step –

workflows of components in a system.an activity diagram shows he overall flow of
control.
 4.Implementation Diagram
A. Component Diagram-describes how a software system is split up into
components and shows the dependencies among these components.
B. Deployment Diagram-describes the hardware used in system
implementations and the execution environments and artifacts deployed on
the hardware.

Three Ways to Apply UML

UML as sketch : Informal and incomplete diagrams created to explore
difficult parts of the problem or solution space, exploiting the power of visual
languages.

UML as blueprint : Relatively detailed design diagrams used either for

1) Reverse Engineering : UML tool reads the source or binaries and
generates UML package, class, and sequence diagrams to visualize and
better understanding of existing code in UML diagrams .

2) Forward Engineering : code generation . Before programming, some

detailed diagrams can provide guidance for code generation (e.g., in
Java), either manually or automatically with a tool. It's common that the
diagrams are used for some code, and other code is filled in by a
developer while coding

UML as programming language : Complete executable specification of a

software system in UML. Executable code will be automatically generated
 Three Perspectives to Apply UML

The same UML class diagram notation can be used to draw pictures of
concepts in the real world or software classes in Java.

1. Conceptual perspective - the diagrams are interpreted as describing things

in a situation of the real world or domain of interest.

2. Specification (software) perspective - the diagrams (using the same

notation as in the conceptual perspective) describe software abstractions or
components with specifications and interfaces, but no commitment to a
particular implementation (for example, not specifically a class in C# or Java).

3. Implementation (software) perspective - the diagrams describe

software implementations in a particular technology (such as Java).

Figure 5:Conceptual Perspective and Software Perspective.

The Meaning of "Class" in Different Perspectives

Conceptual class real-world concept or thing. A conceptual or essential

perspective. The UP Domain Model contains conceptual classes.

Software class a class representing a specification or implementation

perspective of a software component, regardless of the process or method.
Implementation class a class implemented in a specific OO language such as
Java.
Static and Dynamic Models
Static modeling is used to specify the structure of the objects, classes or components

that exist in the problem domain. These are expressed using class, object or
component. While dynamic modeling refers to representing the object interactions

during runtime. It is represented by sequence, activity, collaboration, and state. UML

diagrams represent these two aspects of a system:

● Structural (or Static) view: emphasizes the static structure of the system

using objects, attributes, operations and relationships. It includes class

diagrams and composite structure diagrams.

● Behavioral (or Dynamic) view: emphasizes the dynamic behavior of the

system by showing collaborations among objects and changes to the internal

states of objects. This view includes sequence diagrams, activity diagrams, and

state machine diagrams.

14 types of UML diagrams, which are divided into these two categories:
● 7 diagram types represent structural information

● Another 7 represents general UML diagram types for behavioral modeling,

including four that represent different aspects of interactions.

These diagrams can be categorized hierarchically as shown in the following UML

diagram map:
 Behavioral Diagrams
UML’s five behavioral diagrams are used to visualize, specify, construct, and document
the dynamic aspects of a system. It shows how the system behaves and interacts with
itself and other entities (users, other systems). They show how data moves through
the system, how objects communicate with each other, how the passage of time
affects the system, or what events cause the system to change internal states. Since
behavior diagrams illustrate the behavior of a system, they are used extensively to
describe the functionality of software systems. As an example, the activity diagram
describes the business and operational step-by-step activities of the components in a
system.
In other words, a behavioral diagram shows how the system works ‘in motion’, that is
how the system interacts with external entities and users, how it responds to input or
event and what constraints it operates under. There are seven behavioral diagrams
that you can model the dynamics of a system as listed in the Table below:

Behavioral Diagram Brief Description

Activity Diagram It is a graphical representations of workflows of stepwise

activities and actions with support for choice, iteration and
concurrency

Use Case Diagram It describes a system’s functional requirements in terms of use

cases that enable you to relate what you need from a system
to how the system delivers on those needs.

State Machine Diagram It shows the discrete behavior of a part of a designed system
through finite state transitions.

Sequence Diagram It shows the sequence of messages exchanged between the

objects needed to carry out the functionality of the scenario.

Communication It shows interactions between objects and/or parts

Diagram (represented as lifelines) using sequenced messages in a free-
form arrangement.

Interaction Overview It depicts a control flow with nodes that can contain other
Diagram interaction diagrams.

Timing Diagram It shows interactions when the primary purpose of the diagram
is to reason about time by focusing on conditions changing
within and among lifelines along a linear time axis.
 Structural Diagrams
Structure diagrams depict the static structure of the elements in your system. i.e., how
one object relates to another. It shows the things in the system – classes, objects,
packages or modules, physical nodes, components, and interfaces. For example, just as
the static aspects of a house encompass the existence and placement of such things as
walls, doors, windows, pipes, wires, and vents. The Seven UML structural diagrams are
roughly organized around the major groups of things you’ll find when modeling a
system.
Since structure diagrams represent the structure, they are used extensively in
documenting the software architecture of software systems.
For example, the component diagram describes how a software system is split up into
components and shows the dependencies among these components.

Structural Diagram Brief Description

Composite Structure It shows the internal structure of a classifier, classifier

Diagram interactions with the environment through ports, or behavior of
a collaboration.

Deployment Diagram It shows a set of nodes and their relationships that illustrates
the static deployment view of an architecture.

Package Diagram It groups related UML elements into a collection of logically

related UML structure.

Profile Diagram

Class Diagram It shows a set of classes, interfaces, and collaborations and their
relationships, typically, found in modeling object-oriented
systems.

Object Diagram It shows a set of objects and their relationships, which is the
static snapshots of instances of the things found in class
diagrams.

Component Diagram It shows a set of components and their relationships that

illustrates the static implementation view of a system.
UML Class Diagram
The class diagram depicts a static view of an application. It represents the types of
objects residing in the system and the relationships between them. A class consists
of its objects, and also it may inherit from other classes. A class diagram is used to
visualize, describe, document various different aspects of the system, and also
construct executable software code.

It shows the attributes, classes, functions, and relationships to give an overview of

the software system. It constitutes class names, attributes, and functions in a
separate compartment that helps in software development. Since it is a collection of
classes, interfaces, associations, collaborations, and constraints, it is termed as a
structural diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is

the only diagram that is widely used for construction, and it can be mapped with
object-oriented languages. It is one of the most popular UML diagrams. Following
are the purpose of class diagrams given below:

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

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

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.
Vital components of a Class Diagram
The class diagram is made up of three sections:

● Upper Section: The upper section encompasses the name of the class. A class
is a representation of similar objects that shares the same relationships,
attributes, operations, and semantics. Some of the following rules that should
be taken into account while representing a class are given below:

a. Capitalize the initial letter of the class name.

b. Place the class name in the center of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format.
● Middle Section: The middle section constitutes the attributes, which describe
the quality of the class. The attributes have the following characteristics:

a. The attributes are written along with its visibility factors, which are public
(+), private (-), protected (#), and package (~).
b. The accessibility of an attribute class is illustrated by the visibility factors.
c. A meaningful name should be assigned to the attribute, which will
explain its usage inside the class.
● Lower Section: The lower section contain methods or operations. The
methods are represented in the form of a list, where each method is written in
a single line. It demonstrates how a class interacts with data.
Relationships
In UML, relationships are of three types:

● Dependency: A dependency is a semantic relationship between two or more

classes where a change in one class cause changes in another class. It forms a
weaker relationship.
In the following example, Student_Name is dependent on the St udent_Id.

● Generalization: A generalization is a relationship between a parent class

(superclass) and a child class (subclass). In this, the child class is inherited from
the parent class.
For example, The Current Account, Saving Account, and Credit Account are the
generalized form of Bank Account.

● Association: It describes a static or physical connection between two or more

objects. It depicts how many objects are there in the relationship.
For example, a department is associated with the college.
 Multiplicity: It defines a specific range of allowable instances of attributes. In case
if a range is not specified, one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

Aggregation: An aggregation is a subset of association, which represents has a

relationship. It is more specific then association. It defines a part-whole or part-of
relationship. In this kind of relationship, the child class can exist independently of its
parent class.

The company encompasses a number of employees, and even if one employee resigns,
the company still exists.

Composition: The composition is a subset of aggregation. It portrays the dependency

between the parent and its child, which means if one part is deleted, then the other part
also gets discarded. It represents a whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all the
contacts will be lost.
How to draw a Class Diagram?

The class diagram is used most widely to construct software applications. It not only
represents a static view of the system but also all the major aspects of an application. A
collection of class diagrams as a whole represents a system.

Some key points that are needed to keep in mind while drawing a class diagram are
given below:

1. To describe a complete aspect of the system, it is suggested to give a meaningful

name to the class diagram.

2. The objects and their relationships should be acknowledged in advance.

3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of
the unwanted property will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the aspects
of a diagram.

6. The diagrams should be redrawn and reworked as many times to make it correct
before producing its final version.

Class Diagram Example

A class diagram describing the sales order system is given below.

Usage of Class diagrams

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.

USE CASES
Introduction : Use cases are text stories, widely used to discover and record
requirements. use cases are text stories of some actor using a system to meet goals.
There are 3 formats to represent the use case
I) Brief Format II) Casual Format III) Fully Dressed Format
Definition: What are Actors, Scenarios, and Use Cases
An actor is something with behavior, such as a person (identified by role),
computer system, or organization; for example, a cashier.

A scenario is a specific sequence of actions and interactions between actors

and the system; it is also called a use case instance. It is one particular story of using
a system, or one path through the use case; for example, the scenario of successfully
purchasing items with cash, or the scenario of failing to purchase items because of a
credit payment denial.

A use case is a collection of related success and failure scenarios that describe
an actor using a system to support a goal.
Use Cases and the Use-Case Model
∙ Use cases are text documents, not diagrams, and use-case modeling is primarily an
act of writing text, not drawing diagrams.
∙ There are also the Supplementary Specification, Glossary, Vision, and Business Rules.
These are all useful for requirements analysis.
∙ The Use-Case Model may optionally include a UML use case diagram to show the
names of use cases and actors, and their relationships. This gives a nice context
diagram of a system and its environment. It also provides a quick way to list the use
cases by name.
Motivation: Why Use Cases?
● Lack of user involvement in software projects is near the top of the list of reasons
for project failure. Use cases are a good way to help keep it simple, and make it
possible for domain experts or requirement donors to themselves write use cases.

● Another value of use cases is that they emphasize the user goals and
perspective; we ask the question "Who is using the system, what are their typical
scenarios of use, and what are their goals?" This is a more user-centric emphasis
compared to simply asking for a list of system features.
 Definition: Are Use Cases Functional Requirements
Use cases are requirements, primarily functional or behavioral requirements that
indicate what the system will do. A related viewpoint is that a use case defines a contract
of how a system will behave

What are Three Kinds of Actors?

An actor is anything with behavior, including the system under discussion (SuD)
itself when it calls upon the services of other systems. Primary and supporting actors will
appear in the action steps of the use case text. Actors are roles played not only by
people, but by organizations, software, and machines. There are three kinds of external
actors in relation to the SuD:

∙ Primary actor has user goals fulfilled through using services of the SuD. For
example, the cashier.

Why identify? To find user goals, which drive the use cases.
∙ Supporting actor provides a service (for example, information) to the SuD. The
automated payment authorization service is an example. Often a computer system,
but could be an organization or person.

Why identify? To clarify external interfaces and protocols.

∙ Offstage actor has an interest in the behavior of the use case, but is not primary or

supporting; for example, a government tax agency.

Why identify? To ensure that all necessary interests are identified and satisfied.
Offstage actor interests are sometimes subtle or easy to miss unless these actors
are explicitly named.

Three Common Use Case Formats

∙ Brief - Terse one-paragraph summary, usually of the main success scenario. The prior

Process Sale example was brief. It was created during early requirements analysis, to
get a quick sense of subject and scope. May take only a few minutes to create.
 Guideline

∙ Use case diagram is an excellent picture of the system context

∙ It makes a good context diagram that is, showing the boundary of a system,
what lies outside of it, and how it gets used.

∙ It serves as a communication tool that summarizes the behavior of a

system and its actors.

∙ Guideline: Diagramming
Notice the actor box with the symbol «actor». This style is used for UML
keywords and stereotypes, and includes guillemet symbols special single-
character brackets («actor», not <<actor>>)
Alternate actor notation.

Alternate actor notation.

Kinds of relationships

1. The include Relationship

1. The extend Relationship

1. The generalize Relationship

The extend relationship.

Use case include relationship in the Use-Case Model.
 The Dynamic Model

The dynamic model is used to express and model the behaviour of the system over time.
It includes support for activity diagrams, state diagrams, sequence diagrams and
extensions including business process modelling.

Sequence Diagrams
Sequence diagrams are used to display the interaction between users, screens, objects
and entities within the system. It provides a sequential map of message passing
between objects over time. Frequently these diagrams are placed under Use Cases in
the model to illustrate the use case scenario - how a user will interact with the system
and what happens internally to get the work done. Often, the objects are represented
using special stereotyped icons, as in the example below. The object labelled Login
Screen is shown using the User Interface icon. The object labelled SecurityManager is
shown using the Controller icon. The Object labelled users is shown using the Entity
icon.
Activity Diagrams
Activity diagrams are used to show how different workflows in the system are
constructed, how they start and the possibly many decision paths that can be taken
from start to finish. They may also illustrate the where parallel processing may occur in
the execution of some activities.
State Charts
State charts are used to detail the transitions or changes of state an object can go
through in the system. They show how an object moves from one state to another and
the rules that govern that change. State charts typically have a start and end condition.

Process Model

A process model is a UML extension of an activity diagram used to model a

business process - this diagram shows what goal the process has, the inputs,
outputs, events and information that are involved in the process.
 ASSIGNMENTS

Examples: Case study, Comprehensive design, etc.,)

Category 1:
1. You have been given the responsibility to elicit requirements
from a customer who tells you he is too busy to meet with you. What should
you do?

Category 2: Develop a complete use case for one of the following activities:
a. Making a withdrawal at an ATM
b. Using your charge card for a meal at a restaurant
c. Searching for books (on a specific topic) using an online
bookstore

Category 3:
Consider the use case Searching for books (on a specific topic)
using an online book store , and write a nonfunctional requirement for the
application

Category 4:
suggest one or more analysis patterns for the following
application domains:
a. E-mail software.
b. Internet browsers.
c. Mobile app creation software

Category 5:

What do you think happens when requirement validation

uncovers an error? Who is involved in correcting the error?

Case study:

Design UML diagrams for

1. ATM application

2. Quiz application

52
11. Part A Q & A (with K level and CO)
S.No Questions
K Level CO Level

1 What is requirement engineering? K3 C02

Requirement engineering is the process of establishing
the services that the customer requires from the system
and the constraints under which it operates and is
developed
2 List the tasks of Requirement engineering. K2 C02
Requirements engineering encompasses seven distinct
tasks: inception, elicitation, elaboration, negotiation,
specification, validation, and management

3 What are the various types of traceability in software K2 C02

engineering?
Source traceability – These are basically the links from
requirement to stakeholders
Requirements traceability – These are links between
dependant requirements.
Design traceability – These are links from requirements
to design.

4 Define QFD. K2 C02

Quality function deployment attempts to translate
unspoken customer needs or goals into system
requirements. Nonfunctional requirements are often
listed separately in a software requirements
specification.

5 What is data modeling? K2 C02

Data modelling is the basic step in the analysis
modelling. In data modelling the data objects are
examined independently of processing. The data model
represents how data are related with one another.
6 What are functional requirements? K2 C01
Functional requirements are” statements of services the
system should provide how the system should react to
particular input and how the system should behave in
particular situation.

7 What are non-functional requirements? K2 C02

Non functional requirements are constraints on the services
or functions offered by the system such as timing
constraints, constraints on the development process,
standards, etc……..

8 What is the outcome of feasibility study? K2 C02

The outcome of feasibility study is the results obtained from
the following questions:
x Which system contributes to organizational objectives?
x Whether the system can be engineered? Is it within the
budget?
x Whether the system can be integrated with other existing
system?

9 What is meant by structural analysis? K2 C02

The structural analysis is mapping of problem domain to
flows and transformations. The system can be modelled by
using Entity Relationship diagram, Data flow diagram and
Control flow diagrams.

10 List the number of problems that are identified by Christel K3 C02

and Kang
Problems of scope
Problems of understanding
Problems of volatility

11 K2 C02
Define Use Cases
It is a Scenarios that describe how the product will be used
in specific situations
Use-cases designed from the actor’s point of view.
12 What is Activity Diagram? K2 C02
Activity diagram is basically a flowchart to represent the flow
from one activity to another activity.
Activity diagram is used to describe the dynamic aspects of the
system.

13 What are the three ways and perspectives to apply UML K2 C02
Three ways to apply UML
UML as sketch UML as
blueprint
UML as programming language
Three perspectives to apply UML
Conceptual perspective Specification
perspective Implementation perspective

14
K2 C02
Define Sequence Diagram.
A Sequence diagram simply depicts interaction between
objects in a sequential order i.e the order in which these
interactions take place.

15 What is extend relationship in use case? K2 C01

An Extend is a relationship from an extending UseCase (the
extension) to an extended UseCase (the extendedCase) that
specifies how and when the behavior defined in the extending
UseCase can be inserted into the behavior defined in the
extended UseCase.
12. Part B Qs (with K level and CO)
S.No Questions
K Level CO Level

1 Explain in detail about phases in Requirements

K2 CO2
Engineering.
2 Explain in detail about steps required to establish the
K2 CO2
groundwork for understanding the Software Requirement.
3 What is Non functional Requirement ? explain
K3 CO2

4 Explain in detail about Requirements Gathering?

K3 CO2

5 Explain in detail about developing use case with

K3 CO2
examples.
6 Discuss in detail about Negotiating and Validating
K3 CO2
requirements.
7 Explain in detail about UML.
K3 CO2

8 Differentiate Static and Dynamic Models

K3 CO2

9 Explain in detail about UML Dynamic Modelling.

k2 CO2

10 Explain the following UML Diagrams.

k3 CO2
Use-Case Diagram
UML Class Diagrams
tatic and Dynamic Diagrams
11 A Library lends books and magazines to member, who
K3 CO2
is registered in the system. It also maintains the
purchase of new books and magazines for the Library.
A member can reserve a book or magazine that is not
currently available in the library, so that when it is
returned or purchased by the library, that person is
notified. The library can easily create, replace and
delete information about the books, members, and
reservation in the system. The books transactions are
stored in the database. The fine list while the member
returns the book after the due date must be
generated. Design the use case diagram and discover
the users and actors of this system, and the
interactions between them must be depicted.
 Supportive online Certification
courses
NPTEL/OTHER REFERENCES / WEBSITES:

http://nptel.ac.in

Software Engineering Tutorial – javatpoint

https://www.tutorialspoint.com/software_engineering/

Software Engineering Tutorial for Beginners: Learn in 3 Days (guru99.com)

Software Engineering Tutorial | A Complete Guide for Beginners(educba.com)

www.udemy.com

www.upgrad.com

www.simplilearn.com

57
Real time Applications in day to day life and to Industry

1. Real time Home Automation System.

2. Hospital management system
3. Exam management system
4. Online monitoring of students in with respect to Attendance,
Fees payment, assignment submission, Skill rack status,etc
5. Designing an expert system for medical diagnosis.

58
 ASSESSMENT
SCHEDULE

• Tentative schedule for Odd Semester 2022

Internal Assessment Test I : 28.01.2024 – 02.02.2025

Internal Assessment Test II :

10-03.2025 - 15.03.2025

Model Examination : 03.04.2025 - 17.04.2025

59
 PRESCRIBED TEXTBOOKS & REFERENCE
BOOKS
TEXT BOOKS:
1. Roger S. Pressman, “Software Engineering: A Practitioner‘s Approach” , McGraw Hill
International Edition, Nineth Edition, 2020.
2. Ali Bahrami, “Object Oriented Systems Development”, McGraw Hill International
Edition,2017.

REFERENCES:

1. Micheal Blalh and James Rumbaugh, Object Oriented Modeling and Design with UML,
2nd edition Pearson 2013.
2. Ian Sommerville, “Software Engineering”, Tenth Edition, Pearson Education, 2016.
3. Ivar Jacobson, Harold Bud Lawson, Pan-Wei Ng, Paul E. McMahon, Michael Goedicke,
“The Essentials of Modern Software Engineering”, Morgan & Claypool Publishers, 2019.
4. Booch, G, Jacobson I, Rumbaugh J, “The Unified Modeling Language User Guide”,
Addison Wesley, 2008.
5. Martin Fowler, “UML Distilled: A Brief Guide to the Standard Object Modeling
6. Language”, 3rd edition, Addison Wesley, 2003.

60
 Mini Project suggestions

1. Develop a SRS for Courier Management System

2. Generate Sample Document for Generating Consistent Professional
Reports

61
 Thank you

Disclaimer:

This document is confidential and intended solely for the educational purpose of RMK Group of Educational
Institutions. If you have received this document through email in error, please notify the system manager. This
document contains proprietary information and is intended only to the respective group / learning community as
intended. If you are not the addressee you should not disseminate, distribute or copy through e-mail. Please notify
the sender immediately by e-mail if you have received this document by mistake and delete this document from
your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly prohibited.

62