SE-Unit 2_ Requirement Analysis and Modeling.pptx

Requirement Analysis and
Modeling

Syllabus
2 Requirement Analysis and Modeling
Core Principles that guide process and practice, Requirement Engineering,
Elicitation, Developing Use Cases, Requirement Specification(SRS),
Requirement Modeling Approaches-Scenario-based modeling, Data
Modeling, Class-based modeling, Flow-oriented Modeling, Behavioral model.
10

Core Principles
Software engineering is guided by a collection of core principles that help in the
application of a meaningful software process and the execution of effective software
engineering methods.
At the process level, core principles establish a philosophical foundation that guides a
software team as it performs framework and umbrella activities, navigates the process
flow, and produces a set of software engineering work products.
At the level of practice, core principles establish a collection of values and rules that serve
as a guide as you analyze a problem, design a solution, implement and test the solution,
and ultimately deploy the software in the user community.
[Practice is a broad array of concepts, principles, methods, and tools that you must

Principles That Guide Process
Principle #1. Be agile. Whether the process model you choose is prescriptive or agile, the basic
tenets of agile development should govern your approach.
Principle #2. Focus on quality at every step. The exit condition for every process activity, action,
and task should focus on the quality of the work product that has been produced.
Principle #3. Be ready to adapt. Process is not a religious experience and dogma has no place
in it. When necessary, adapt your approach to constraints imposed by the problem, the people,
and the project itself.
Principle #4. Build an effective team. Software engineering process and practice are important,
but the bottom line is people. Build a self-organizing team that has mutual trust and respect.

Principle #5. Establish mechanisms for communication and coordination. Projects fail
because important information falls into the cracks and/or stakeholders fail to coordinate
their efforts to create a successful end product.
Principle #6. Manage change. The approach may be either formal or informal, but
mechanisms must be established to manage the way changes are requested, assessed,
approved and implemented.
Principle #7. Assess risk. Lots of things can go wrong as software is being developed. It’s
essential that you establish contingency plans.
Principle #8. Create work products that provide value for others. Create only those work
products that provide value for other process activities, actions or tasks.

Principles That Guide Practice
Principle #1. Divide and conquer. Stated in a more technical manner, analysis and design
should always emphasize separation of concerns (SoC).
Principle #2. Understand the use of abstraction. At it core, an abstraction is a
simplification of some complex element of a system used to communication meaning in a
single phrase.
Principle #3. Strive for consistency. A familiar context makes software easier to use.
Principle #4. Focus on the transfer of information. Pay special attention to the analysis,
design, construction, and testing of interfaces.

Principle #5. Build software that exhibits effective modularity. Separation of concerns
(Principle #1) establishes a philosophy for software. Modularity provides a mechanism for
realizing the philosophy.
Principle #6. Look for patterns. Brad Appleton [App00] suggests that: “The goal of patterns
within the software community is to create a body of literature to help software developers
resolve recurring problems encountered throughout all of software development.
Principle #7. When possible, represent the problem and its solution from a number of
different perspectives.
Principle #8. Remember that someone will maintain the software.

Requirement Engineering
Tasks and techniques that lead to an understanding of requirements is called
requirement engineering.
Objective: Requirements engineering tools assist in Requirements
gathering, requirements modeling, requirements management,
and requirements validation.

Requirements engineering provides the appropriate mechanism for understanding:
➔ what the customer wants
➔ analyzing need
➔ assessing feasibility
➔ negotiating a reasonable solution
➔ specifying the solution unambiguously
➔ validating the specification, and
➔ managing the requirements
as they are transformed into an operational system

Requirements fall into two types
Functional
requirements
Non-Functional
requirements
Functional
requiremen
ts
Non-
Functional
requiremen
ts

Functional Requirements
Any requirement which specifies what the system Should do.
Typical functional requirements
➔ Business Rules
➔ Administrative functions
➔ Transaction corrections,adjustments and cancellations
➔ Reporting Requirements

Non-functional Requirements
Any requirement which specifies how the system performs a certain function.
Typical non-functional requirements
➔ Response time
➔ Availability
➔ Throughput
➔ Recoverability
➔ Reliability
➔ Security

Library Management System
Functional Requirements
➔ Add Article: New entries must be entered in database
➔ Update Article: Any changes in articles should be updated in case of update
➔ Delete Article: Wrong entry must be removed from system
➔ Inquiry Members: Inquiry all current enrolled members to view their details
➔ Inquiry Issuance: Inquiry all database articles
➔ Check out Article: To issue any article must be checked out
➔ Check In article: After receiving any article system will reenter article by Checking
➔ Inquiry waiting for approvals: Librarian will generates all newly application which is in
waiting list
➔ Reserve Article: This use case is used to reserve any book with the name of librarian, it can
be pledged

Non-Functional Requirements
➔ Safety Requirements: The database may get crashed at any certain time due
to virus or operating system failure. So, it is required to take the database
backup.
➔ Security Requirements: We are going to develop a secured database for the
university. There are different categories of users namely teaching staff,
administrator, library staff ,students etc., Depending upon the category of user
the access rights are decided.
➔ Software Constraints: The development of the system will be constrained by
the availability of required software such as database and development tools.
The availability of these tools will be governed by

Requirement Engineering Tasks
Seven tasks are there:
Inception
1
Roughly define scope
A basic understanding of
a problem, people who
want a solution, the
nature of solution
desired
Elicitation (Requirement
Gathering)
Define requirements
The practice of collecting the
requirements of a system from users,
customers and other stakeholders
problems that are encountered as
elicitation occurs.
1) Problems of scope
2) Problems of understanding.
3) Problems of volatility.
2 Elaboration
Further define
requirements
Expand and refine
requirements obtained
from inception &
elicitation
Creation of User
scenarios, extract
analysis class and
3

Negotiation
4
Reconcile conflicts
Agree on a deliverable
system that is realistic
for developers and
customers
Specification
Create analysis model
It may be written document, set of
graphical models, formal
mathematical model, collection of
user scenarios, prototype or
collection of these
SRS (Software Requirement
Specification) is a document that
is created when a detailed
description of all aspects of
software to build must be
specified before starting of project
5 Validation
Ensure quality of requirements
Review the requirements
specification for errors,
ambiguities, omissions (absence)
and conflicts
6

Requirements Management
It is a set of activities to identify,
control & trace requirements &
changes to requirements
(Umbrella Activities) at any time
as the project proceeds.
7

SRS(Software Requirements Specification)
Software Requirement Specification (SRS) is a document that completely describes
what the proposed software should do without describing how software will do it.
SRS is also helping the clients to understand their own needs.
SRS Contains
A complete information description
A representation of system behaviour
An indication of performance requirements and design constraints
Appropriate validation criteria
Other information suitable to requirements

Characteristics of a Good SRS
➔ SRS should be accurate, complete, and of high quality, so that it does not affect
the entire project plan.
➔ An SRS is said to be of high quality when the developer and user easily understand
the prepared document.
● Complete: The SRS should include all the requirements for the software system,
including both functional and non-functional requirements.
● Correct: SRS is correct when all user requirements are stated in the requirements
document. Note that there is no specified tool or procedure to assure the
correctness of SRS.

● Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation.
● Ranked for Importance/Stability : All requirements are not equally important, hence
each requirement is identified to make differences among other requirements.
Stability implies the probability of changes in the requirement in future.
● Modifiable : The requirements of the user can change, hence requirements document
should be created in such a manner that those changes can be modified easily.

● Traceable : SRS is traceable when the source of each requirement is clear and
facilitates the reference of each requirement in future.
● Verifiable: SRS is verifiable when the specified requirements can be verified with a cost-
effective process to check whether the final software meets those requirements.
● Consistent : SRS is consistent when the subsets of individual requirements defined do
not conflict with each other.

Problem without SRS
● Without developing the SRS document, the system would not be properly
implemented according to customer needs.
● Software developers would not know whether what they are developing is
what exactly is required by the customer.
● Without SRS, it will be very difficult for the maintenance engineers to
understand the functionality of the system.
● It will be very difficult for user document writers to write the users’
manuals properly without understanding the SRS.

Example of SRS
Software Requirements Specification
For
Attendance Maintenance System
Prepared by XYZ
December 1, 2007
Version 1.0

Table of Contents
1. Introduction………………………………………………………….……….…1
1. Purpose……………………………………………………..…….…1
2. Scope ………………………………………………………..…..…..1
3. Overview ……………………………………………..…..……….1
2. General Description ………………………………………………………2
1. User Manual …………………………………………..………...2
3. Functional Requirements …………………………………………..….3
1. Description ……………………………………………….………3
2. Technical Issues. …………………………………..………….4
4. Interface Requirements ……………………………………………..…4
1. GUI ………………………………………………………...………….4
2. Hardware Interface …………………………………………4
3. Software Interface……………………………………………4
5. Performance Requirements ………………………………………..5
6. Design Constraints ……………………………………………………..6
7. Other Non functional Attributes ……………………………….7
1. Security …………………………………………………………..7
2. Reliability………………………………………………………..7
3. Availability ……………………………………………………..7
4. Maintainability…………………………………………………7
5. Reusability …………………………………………………….7
8. Operational Scenarios ………………………………………………..8
9. Preliminary Schedule……………………………………………...….9

1. Introduction
1.1 Purpose
This document gives detailed functional and nonfunctional requirements for attendance
maintenance system. The purpose of this document is that the requirements mentioned in it
should be utilized by software developer to implement the system.
1.2 Scope
This system allows the Teacher to maintain attendance record of the classes to which it is
teaching. With the help of this system Teacher should be in a position to send email to the
students who remain absent for the class. The system provides a cumulative report at every
month end for the corresponding class.
1.3 Overview
This system provides an easy solution to the Teacher to keep track of student attendance, and

2. General Description
● This attendance maintenance system replaces the traditional, manual attendance system by
which a lot of paperwork will be reduced. The Teacher should able to view photograph of a
student along with his attendance in his Laptop. This is the primary feature of this
system.Another feature is that Teacher can be allowed to edit particular record at desired time.
The system should produce monthly attendance report. And there should be facility to send an
email/warning to the student remaining absent in the class.
● Every Teacher should have Laptop with wireless internet connection. A Teacher may teach to
different classes and a separate record for the corresponding classes should be maintained.
2.1 User Manual: The system should provide Help option in which how to operate the system should
be explained. Also hard copy of this document should be given to the user in a booklet form.

3. Functional Requirements
3.1. Description
The identity of student is verified and then marked present at particular date and time. The system
should display student photograph along with their names for that corresponding class. The student may
be marked present or absent depending upon his presence. The system should send emails to absent
students. A statistical report should display individual's report or a cumulative report whenever required.
3.2 Technical Issues
The system should be implemented in VC++.

4. Interface Requirements
4.1 GUI
GUI 1 : Main menu should provide options such as File, Edit, Report, Help.
GUI 2 : In File menu one can create a new record file or can open an existing record file. For
example : If file SECOMP_SEMIj07 is opened then we may view attendance record of SE
COMPUTER class in year 2007 and a record for semester-I can be viewed.
GUI 3 : The display of record should be (See Fig.)
The photo can be clicked to mark student present for particular class. The email button can be
clicked to send email to the student being absent.
GUI 4 : Report option should display statistical report. It may be for particular student or for the
whole class
GUI 5 : Help option should describe functionality of the system. It should be written in simple

4.2 Hardware Interface
Hardware Interface 1 :The system should be embedded in the laptops
Hardware Interface 2 : The laptop should use wireless Ethernet card to send emails. These
Laptops should be the clients of departmental database server.
4.3 Software Interface
Software Interface 1 :Attendance maintenance system.
Software Interface 2 :The attendance database should be transmitted to departmental database
server.
Software Interface 3 : E-mail message generator which generates standard message of absence.
Software Interface 4 : Report generators

5 Performance Requirements
● This system should work concurrently on multiple processors between the college hours.
The system should support 50 users.
● The email should be sent within one hour after the class gets over.
● The system should support taking attendance of maximum 100 students per class.

6 Design Constraints
● The system should be designed within 6 months.
7 Other Non Functional Attributes
7.1. Security
● The teacher should provide password to log on to the system. He/she should be able to see
the record of his/her class.
● The password can be changed by the Teacher by providing existing password

7.2 Reliability
● Due to wireless connectivity , reliability cannot be guaranteed.
7.3 Availability
● The system should be available during college hours.
7.4 Maintainability
● There should be a facility to add or delete or update Teachers and students for each
semester.
7.5 Reusability
● The same system will be used in each new semester

8 Operational Scenarios
● There will be student database, Teacher database. The student database will contain
students name, class, attendance, e-mail address, address, phone number.
● The Teacher database will contain Teacher's name, classes taught, e-mail address, phone
number.
9 Preliminary Schedule
● The system has to be implemented within 6 months.
Other example:
https://www.slideshare.net/slideshow/attendance-management-system-250069475/250
069475#2

Requirement Modeling
It is the process which allows an analyst to model requirements visually, showing how requirements
relate to each other and how they connect with other elements in the model.
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 requirements model as a bridge between the system description
and the design model.

The requirements modeling action results in one or more of the following types of models:
➔ Scenario-based models : The system is described from the user’s point of view using a scenario-
based approach.
➔ Data models that depict the information domain for the problem
➔ Class-oriented models that represent object-oriented classes (attributes and operations) and
the manner in which classes collaborate to achieve system requirements
➔ Flow-oriented models that represent the functional elements of the system and how they
transform data as it moves through the system
➔ Behavioral models that depict how the software behaves as a consequence of external “events”

Scenario-based Modeling
Scenario-based modeling primary objective is to look at a system from the user's
perspective and produce a use case.
[success of a computer-based system or product is measured in many ways, user
satisfaction resides at the top of the list.
If you understand how end users want to interact with a system,your software team will
be better able to properly characterize requirements and build meaningful analysis and
design models.]
Ex. USE CASES

Use Case Diagram
→ A use case diagram is a representation of a user's interaction with the system.
→ This interaction shows the relationship between the user and the different use cases in which the user is involved
Components of Use Case Diagram:
1) Actor
2) Use Case
3) Association
4) System Boundary
5) Include
6) Extends
7) Generalization

1. Actor
→ 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. (An actor is an entity that
interacts directly with the system but that is not part of system ).
→ Defined somewhat more formally, an actor is anything that communicates with the
system or product and that is external to the system itself.
→ Actor may be people, computer hardware, other systems, etc.
→ Actor are two type:
○ Primary Actor : Interact to achieve required system function
○ Secondary Actor : support the system so that primary actors can do their work.

2. Use Case
→ A use case represents a user goal / piece of functionality that can be achieved by
accessing the system or software application.
→ For Example:
In the online shopping system, examples of use cases could be “Place Order,”
“Track Delivery,” or “Update Product Information”.

3. System Boundary
→ Represent the scope of the system
→ Use cases of the system are placed inside the system boundary
→ Actors who interact with the system are placed outside the system
→ The system boundary is typically represented by a rectangular box
that surrounds all the use cases of the system.
4. Association
→ An actor and use case can be associated to indicate that the actor participates in that use
case
→ It is depicted by a line connecting the actor to the use case.

5. Include
→ An include relationship is a relationship in which one use case includes the functionality
of another use case
→ The include relationship supports the reuse of functionality in a use-case model
→ It is denoted by a dashed arrow pointing from the including use case to the included use
case.
Example: Social Media Posting
Use Cases: Compose Post, Add Image
Include Relationship: The “Compose Post” use case includes the functionality of “Add Image.”
Therefore, composing a post includes the action of adding an image.

6. Extends
→ The extend relationship specifies that the incorporation of the extension use case is dependent on
what happens when the base use case executes.
→ It is represented by a dashed arrow with the keyword “extend.”
Example: E-commerce site
Use Cases: pay for item, pay on delivery or pay by card
Extends Relationship: When paying for an item, you may choose to pay
on delivery or pay by card. These are all alternatives to the "pay for item“
use case. I may choose any of these options depending on my preference.

7. Generalization
● Generalization Relationship establishes an “is-a” connection between two use cases

Use case Diagram Example
● ATM Machine
Functional Requirements:
1. Details of Transactions ( Like Account
name, number, date & time of transaction ,
Type of transaction, account balance after
transaction )
2. Validate Bank Client ( 4 digit pin)
3. Operations
4. Amount withdrawn
5. Cross withdrawn limit
Non-Functional Requirements:
1. Unauthorized users
2. Handle card stuck-up, network and power
failure
3. Validate and cancel operation if incorrect
pin, incomplete transaction, insufficient
fund, Time delay.

Transfer
Funds
Deposit
Funds
Withdrawn
money
Make
payment
View
balance
Bank
Customer
Change
Pin
Authenticate
Customer
Insufficient
funds
Use Case
Diagram for
ATM machine

Search
Show
Time
Booking
Cancel
Booking
Payment
Manage
Booking
Manage
Show
Time
Generate
Reports
Admin
Customer
Filter
Login
Use Case
Diagram for
Bookmyshow

Use Case for Library Management System(LMS)
Functionality:
1. Register User
2. Add Article
3. Update Article
4. Delete Article
5. Inquiry Members
6. Inquiry Issuance
7. Check out Article
8. Check in Article
9. Reserve Article
10. Set user Permission
11. Search Article
12. Check Account
13. Prepare Library Database
Stakeholders:
1. Librarian
2. Member
3. Guest

Relationship Between Functionality & Stakeholders

SE-Unit 2_ Requirement Analysis and Modeling.pptx

Data Modeling
➔ Data Modeling is used to explain the different types of data that are used and stored in the system(data
object),
➔ how different types of data are connected(relationship),
➔ what its formats and features are(attributes).
Data Object:
➔ A data object is a representation of composite information that must be understood by software.
➔ A data object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a
report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an
organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file).

Attributes:
➔ Attributes name a data object, describe its characteristics, and in some cases, make reference to
another object.
➔ They can be used to (1) name an instance of the data object, (2) describe the instance, or (3) make
reference to another instance in another table.

➔ Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the key attribute.
➔ Composite Attribute
An attribute composed of many other attributes is called a composite attribute.
➔ Multivalued Attribute
An attribute consisting of more than one value for a given entity.
➔ Derived Attribute
An attribute that can be derived from other attributes of the entity type is known as a derived attribute.

Relationships:
➔ Relationships indicate the manner in which data objects are connected to one another
➔ Consider the two data objects, person and car
➔ A person owns a car.
➔ A person is insured to drive a car

Entity-Relationship Diagram (ERD)
➔ The object-relationship pair is the cornerstone of the data model. These pairs can
be represented graphically using the entity-relationship diagram (ERD)
➔ The model is called "entity–relationship model", because it depicts data in terms of
the entities and relationships described in the data.

➔ Strong Entity Type: It is an entity that has its own existence and is independent.
➔ Weak Entity Type: It is an entity that does not have its own existence and relies on a
strong entity for its existence.

Class Based Modeling and Class Diagram
➔ The purpose of class modeling is to describe objects in systems and different
types of relationships between them.
➔ Class Diagram: The class diagram is used to construct and visualize object-
oriented systems.
➔ Class Diagram represent static view, static aspect, object-oriented view of system.
➔ Class diagrams represent an overview of the system like classes, attributes,
operations, and relationships.

Elements of Class Diagram
Class Name
Class Attributes
(Properties)
Class Operation

Class Name
Class Attributes
(Properties)
Class Operation
CLASS NAME
➔ The name of the class appears in the upper section.
➔ Class name should be meaningful.
➔ Class name should always be aligned center of the
upper section.
➔ Class name should start with capital letters.
➔ Class name should be always bold format.
Example:
Account Employee Customer

Class Name
Class Attributes
(Properties)
Class Operation
➔ Abstract class name should be written in italic format.
➔ For e.g. in the banking system, there are two types of
accounts; one is a saving account and another is a
current account.
➔ Account is an abstract class and saving account and
the current account is a subclass of Account.
➔ The system can’t directly access the Account class. It is
accessible by only saving accounts and current
accounts.
Example:

Class Name
Class Attributes
(Properties)
Class Operation
CLASS ATTRIBUTES
➔ An attribute is a named property of a class that
describes a value held by each object of the class.
➔ The UML notation lists attributes in the second
compartment of the class box.
➔ The attribute name should be in the regular face, left
align in the box & use the lowercase letters for the first
character.
➔ The data type for the attribute should be written after the
colon.
➔ Accessibility of attribute must be defined using a member
access modifier.
➔ For e.g. in this example ‘–’ represents private access
modifier

Access Modifiers
➔ Syntax : accessModifier attributeName:dataType=defaultValue
Access Modifiers:
➔ Public (+): Member accessible by all classes, whether these classes are in the same
package or in another package.
➔ Private (-): Member cannot be accessed outside the enclosing/declaring class.
➔ Protected (#): Member can be accessed only by subclasses and within a class.
➔ Package (~): Member can be accessible by all classes, within the package. Outside
package member not accessible.

Class Name
Class Attributes
(Properties)
Class Operation
Class Operation
➔ operation is a function or procedure that may be applied to
objects in a class.
➔ The UML notation is to list operations in the third compartment
of the class box.
➔ The operation name in the regular face, left align the name in
the box, and use a lowercase letter for the first character.
➔ Optional detail, such as an argument list and result type, may
follow each operation name.
➔ The return type of method should be written after colon.
➔ Accessibility of operation must be defined using a member
access modifier.
➔ Syntax:accessModifiermethodName(argumentList):returnType
➔ For e.g.: you can see change phone number is a method that
accepts phone number as an argument and return the int value
as a response.

Relationship for Class Diagram
➔ Association
➔ Dependency
➔ Aggregation
➔ Composition
➔ Generalization and specialization

1. Association
➔ It depicts Static relationship between classes.
➔ It depicts how many objects are there in the
relationship.
➔ Multiplicity: Multiplicity is the specification of
the number of instances of one class that may
be related to the instance of another class.
Teacher Student
Teaches to ►
➔ Example of Multiplicity:
1. One to One Association : One student has one
branch
2. Many to Zero or One Association : An account
holder can issue at most one debit card.
3. Many to Many Association : Every account
holder can withdraw money from all ATMs.
4. One to One or Many Association : The bank
should have at least one branch

2. 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.
➔ example, Student_Name is dependent on the Student_Id.

3. Aggregation
➔ It represents ‘has a’ relationship.
➔ Aggregation implies a relationship where the child is independent of its parent.
For example:
➔ Here we are considering a car and a wheel example. A car cannot move without a wheel.
➔ But the wheel can be independently used with the bike, scooter, cycle, or any other vehicle.
➔ The wheel object can exist without the car object, which proves to be an aggregation
relationship.

4. Composition
➔ The composition is a part of the aggregation.
➔ It represents the dependency between a parent and its children, which means if the parent is
discarded then its children will also discard.
➔ It represents ‘part-of’ relationship.
For example:
➔ A contact book consists of multiple contacts, and if you delete the contact book, all the contacts will be
lost.

5. Generalization and Specialization
➔ Generalization is the process of extracting
shared characteristics from two or more
classes and combining them into a
generalized superclass
➔ Shared characteristics can be attributes or
methods.
➔ Represents an "is-a" relationship
➔ For example, a car is a vehicle and a truck is a
vehicle. In this case, vehicle is the general thing,
whereas car and truck are the more specific
things.

➔ For example in a bank, any Customer
opens an account.
➔ The account can be either a savings
account or a current account. In
saving account, customer earns fixed
interest on the deposit. But this facility
is not available in the current account.

Class Diagram for Bank Management System

Class Diagram for Library Management System

Flow-oriented Modeling
➔ Flow oriented Modeling represents how data objects are transformed as they move
through the system.
➔ Data flow diagram is used to represents flow oriented modeling

Data Flow Diagram
➔ The flow of data in a system or process is represented by a Data Flow Diagram (DFD)
➔ It provides an overview of
 What data is system processes.
 What transformation are performed.
 What data are stored.
 What results are produced , etc.

Components of Data Flow Diagram
➔ Process : Input to output transformation in a system takes place because
of process function.
➔ External Entity: A source of System inputs/ A sink of system outputs
➔ Data flow: Used to connect process to each other - to source or sink , arrow
head indicates direction of data flow
➔ Data store/Warehouse: Repository of data
Process
Entity
Data Store

Levels in DFD
➔ Level 0
It is also known as fundamental system model, or context diagram represents the entire
software requirement as a single bubble with input and output data denoted by
incoming and outgoing arrows.
➔ Level 1
In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes.
In this level, we highlight the main objectives of the system and breakdown the high-
level process of 0-level DFD into sub-processes.
➔ Level n
This level provides an even more detailed view of the system by breaking down the
sub-processes identified in the level 1 DFD into further sub-processes.

Administrator
Data entry
operator
Marks entry
operator
Student
result
management
DFD for
Result
Managemen
t System

Administrator
Marks entry
operator
Coordinator
Data entry
operator
Subject
info
management

Example:
data-flow-diagram-for-online-banking-system

Behavioral model.
➔ The behavioral model indicates how software will respond to external events or
stimuli.
➔ Behavior of a system is explained and represented with the help of a diagram. This
diagram is known as State Transition Diagram.
➔ It is a collection of states and events. It usually describes overall states that a system
can have and events which are responsible for a change in state of a system

State Transition Diagram
Basic components and notations of a State Machine diagram
1) Initial state: We use a black filled circle represent the initial state of a System or a Class.
2) State : We use a rounded rectangle to represent a state. A state represents the conditions
or circumstances of an object of a class at an instant of time.

3) Transition: We use a solid arrow to represent the transition or change of control from one
state to another. The arrow is labelled with the event which causes the change in state.
4) Fork: We use a rounded solid rectangular bar to represent a Fork notation with incoming
arrow from the parent state and outgoing arrows towards the newly created states. We
use the fork notation to represent a state splitting into two or more concurrent states.

5) Join: We use a rounded solid rectangular bar to represent a Join notation with incoming
arrows from the joining states and outgoing arrow towards the common goal state. We
use the join notation when two or more states concurrently converge into one on the
occurrence of an event or events.
6) Self transition: We use a solid arrow pointing back to the state itself to represent a self
transition. There might be scenarios when the state of the object does not change upon
the occurrence of an event. We use self transitions to represent such cases.

7) Composite state: We use a rounded rectangle to represent a composite state also. We
represent a state with internal activities using a composite state.
8) Final State: We use a filled circle within a circle notation to represent the final state in a
state machine diagram.

State
Initial State
Event
Composite State
Transaction
Internal activity
Submachine State
Final
State

SE-Unit 2_ Requirement Analysis and Modeling.pptx

More Related Content

Similar to SE-Unit 2_ Requirement Analysis and Modeling.pptx (20)

More from nilampatoliya (15)

Recently uploaded (20)

SE-Unit 2_ Requirement Analysis and Modeling.pptx