The document discusses requirements modeling and analysis modeling in software engineering. It provides information on: 1) The different types of models that can be created during requirements modeling, including requirements models, design models, scenario-based models, data models, class-based models, flow-oriented models, and behavioral models. 2) The purposes of requirements modeling, which include representing customer requirements, gaining a better understanding of the system, and providing information to help with system design and development. 3) Key principles of requirements modeling, such as representing the information, functional, and behavioral domains of the system and partitioning models in a layered/hierarchical way. 4) Specific modeling techniques like scenario-based modeling, data

1. ANALYSIS

2. Modeling
• We create models to gain a better understanding of the
actual entity to be built. When the entity is a physical
thing (e.g., a building, a plane, a machine), we can build a
model that is identical in form and shape but smaller in
scale.
• In software engineering work, two classes of models can
be created: requirements models and design models.
 Requirements models (also called analysis models)
• Represent customer requirements by depicting the
software in three different domains: the information
domain, the functional domain, and the behavioral
domain.
 Design models represent characteristics of the software
that help practitioners to construct it effectively: the
architecture, the user interface, and component-level
detail.

3. Requirements Modeling/
Analysis Modeling
• Requirements modeling in software engineering is
essentially the planning stage of a software application or
system.
• Generally the process will begin when a business or an entity,
for example an educational institution, approaches a
software development team to create an application or
system from scratch or update an existing one.
• Requirements modeling comprises several stages or
'patterns': scenario-based modeling, data modeling, flow-
oriented modeling, class-based modeling and behavioral
modeling.
• Each of these stages/patterns examines the same problem
from a different perspective.

4. Why Requirements Modeling/
Analysis Modeling?
• Attempt to produce the simplest model that will
describe the problem or the software.
• Build models in a way that makes them amenable to
change.
• Be able to state an explicit purpose for each model
that is created: Every time you create a model, ask
yourself why you’re doing so.
• Adapt the models you develop to the system at
hand.
• Get feedback as soon as you can.

5. Requirements Modeling principles /
Analysis Modeling principles.
• Principle 1. The information domain of a
problem must be represented and
understood.
– The information domain encompasses the data
that flow into the system (from end users, other
systems, or external devices), the data that flow
out of the system (via the user interface, network
interfaces, reports, graphics, and other means),
and the data stores that collect and organize
persistent data objects (i.e., data that are
maintained permanently).

6. Requirements Modeling principles /
Analysis Modeling principles.
• Principle 2. The functions that the software
performs must be defined.
– Software functions provide direct benefit to end users
and also provide internal support for those features
that are user visible. Some functions transform data
that flow into the system. In other cases, functions
effect some level of control over internal software
processing or external system elements. Functions can
be described at many different levels of abstraction,
ranging from a general statement of purpose to a
detailed description of the processing elements that
must be invoked.

7. Requirements Modeling principles /
Analysis Modeling principles.
• Principle 3. The behavior of the software (as a
consequence of external events) must be
represented.
– The behavior of computer software is driven by its
interaction with the external environment. Input
provided by end users, control data provided by an
external system, or monitoring data collected over a
network all cause the software to behave in a specific
way.

8. Requirements Modeling principles /
Analysis Modeling principles.
• Principle 4. The models that depict information,
function, and behavior must be partitioned in a
manner that uncovers detail in a layered (or
hierarchical) fashion.
• Principle 5. The analysis task should move from
essential information toward implementation
detail.

9. What is Requirements analysis /
Analysis modeling
• Requirements modeling uses a combination of text and
diagrammatic forms to depict requirements in a way that
is relatively easy to understand, and more important,
straightforward to review for correctness, completeness,
and consistency.
• Who does it?
– A software engineer (sometimes called an “analyst”)
builds the model using requirements elicited from the
customer.
• Why is it important?
– To validate software requirements, you need to
examine them from a number of different points of
view.

10. Analysis modeling
• Analysis modeling
focuses on three
attributes of
software:
– information to be
processed
– function to be
delivered
– behavior to be
exhibited.
 It gives the
situation to
discover what the
problem really is

11. Requirements analysis /
Analysis modeling
• Requirements analysis results in the specification of
software’s operational characteristics, indicates
software’s interface with other system elements,
and establishes constraints that software must
meet.
• Requirements analysis allows you (regardless of
whether you’re called a software engineer, an
analyst, or a modeler) to elaborate on basic
requirements established during the inception,
elicitation, and negotiation tasks that are part of
requirements engineering.

12. Requirements analysis /
Analysis modeling
• These models provide a software designer
with information that can be translated to
architectural, interface, and component-level
designs.
• Finally, the requirements model (and the
software requirements specification) provides
the developer and the customer with the
means to assess quality once software is built.

13. Types of Requirements analysis /
Analysis modeling
(It is the first technical representation of systems)
• Scenario-based models of requirements from the point of
view of various system “actors”
• Data models that depict the information domain for the
problem
• Class-based 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 system3
• Behavioral models that depict how the software behaves as a
consequence of external “events”.
– The most common method for creating these diagrams is UML,
Unified Modeling Language.

14. Elements/Types of Requirements analysis /
Analysis modeling

15. Scenario-based Modeling
• For the building of analysis and design models, it is
essential for software engineers to understand how end
users and other actors want to interact with the system.
• it identifies the possible use cases for the system and
produces the use case diagram, to which all the other
stages of requirements modeling refer.
• Analysis Modeling with UML begins with the creation of
scenarios in the form :
• Use-cases Text
• Use-cases diagrams
• Activity Diagrams
• Swim lane Diagrams

16. Usecase
• The use case is essentially a primary example of
how the proposed software application or
system is meant to be used, from the user's
point of view. A use case diagram will typically
show system 'actors' (humans or other entities
external to the system) and how they interact
with the system. Technically, each action such a
system actor can perform with the application
or system is considered to be a separate use
case.
• Usecase can be represented in 2 ways as
usecase text and usecase diagram.

17. Use-cases Text
• The first step in defining a use case is to define the name,
using the verb-noun naming convention.
Sample Use Case Brief
• Use Case Name: Place Order
• Actors:
– Shopper
– Fulfillment System
– Billing System
• Use Case Description: After the user has selected items to
purchase and then order the items. The user will provide
payment and shipping information. The system will respond
with confirmation of the order and a tracking number that
the user can use to check on order status in the future. The
system will also provide the user with an estimated delivery
date for the order, which will include all selected items. The
user may already have an account with the company with
billing and shipping information.

18. Detail/Formal Use Case Example
• You can clarify the use case further by refining the use case into a formal use case.
Example Usecase
• Use Case Name: Place Order
• Actors:
• Registered Shopper (Has an existing account, possibly with billing and shipping
information)
• Non-registered Shopper (Does not have an existing account)
• Fulfillment System (processes orders for delivery to customers)
• Billing System (bills customers for orders that have been placed)
• Triggers:
• The user indicates that she wants to purchase items that she has selected.
• Preconditions:
• User has selected the items to be purchased.
• Post-conditions:
• The order will be placed in the system.
• The user will have a tracking ID for the order.
• The user will know the estimated delivery date for the order.

19. Detail/Formal Use Case Example
• Normal Flow:
• The user will indicate that she wants to order the items that have already been
selected.
• The system will present the billing and shipping information that the user previously
stored.
• The user will confirm that the existing billing and shipping information should be used
for this order.
• The system will present the amount that the order will cost, including applicable taxes
and shipping charges.
• The user will confirm that the order information is accurate.
• The system will provide the user with a tracking ID for the order.
• The system will submit the order to the fulfillment system for evaluation.
• The fulfillment system will provide the system with an estimated delivery date.
• The system will present the estimated delivery date to the user.
• The user will indicate that the order should be placed.
• The system will request that the billing system should charge the user for the order.
• The billing system will confirm that the charge has been placed for the order.
• The system will submit the order to the fulfillment system for processing.
• The fulfillment system will confirm that the order is being processed.
• The system will indicate to the user that the user has been charged for the order.
• The system will indicate to the user that the order has been placed.
• The user will exit the system.

20. Use-cases diagrams
• In the Unified Modeling Language (UML), a use case
diagram can summarize the details of your system's
users (also known as actors) and their interactions with
the system.
• Create a professional diagram for any use case using
UML diagram tool.
• To build one, you'll use a set of specialized symbols and
connectors.
• An effective use case diagram can help project team to
discuss and represent(use of use- case Model):
– Representing the goals of system-user interactions
– Defining and organizing functional requirements in a system
– Specifying the context and requirements of a system
– Modeling the basic flow of events in a use case
– The scope of your system

21. Use case diagram components
• Actors: The users that interact with a system. An
actor can be a person, an organization, or an
outside system that interacts with your application
or system. They must be external objects that
produce or consume data.
• System: A specific sequence of actions and
interactions between actors and the system. A
system may also be referred to as a scenario.
• Goals: The end result of most use cases. A
successful diagram should describe the activities
and variants used to reach the goal.

22. Example 1

23. Use case diagram symbols and notation
• Use cases: Horizontally shaped ovals that represent the
different uses that a user might have.
• Actors: Stick figures that represent the people actually
employing the use cases.
• Associations: A line between actors and use cases. In
complex diagrams, it is important to know which actors
are associated with which use cases.
• System boundary boxes: A box that sets a system scope
to use cases. All use cases outside the box would be
considered outside the scope of that system. For
example, Psycho Killer is outside the scope of occupations
in the chainsaw example found below.
• Packages: A UML shape that allows you to put different
elements into groups. Just as with component diagrams,
these groupings are represented as file folders.

24. Book publishing use case diagram example

25. Railway reservation use case diagram example

26. Activity Diagrams
• Activity diagram is another important diagram in
UML to describe the dynamic aspects of the
system.
• Activity diagram is basically a flowchart to
represent the flow from one activity to another
activity. The activity can be described as an
operation of the system.
• The control flow is drawn from one operation to
another. This flow can be sequential, branched,
or concurrent. Activity diagrams deal with all
type of flow control by using different elements
such as fork, join, etc

27. Purpose of Activity Diagrams
 Activity diagram is another important behavioural diagram
in UML diagram to describe dynamic aspects of the system.
 Activity diagram is essentially an advanced version of flow chart
that modelling the flow from one activity to another activity.
 Activity diagram can be used for
o Modeling work flow by using activities.
o Modeling business requirements.
o High level understanding of the system's functionalities.
o Describe the sequence from one activity to another.

28. How to Draw an Activity Diagram?
• Before drawing an activity diagram, we must have a clear
understanding about the elements used in activity
diagram.
• The main element of an activity diagram is the activity
itself. An activity is a function performed by the system.
• After identifying the activities, we need to understand
how they are associated with constraints and conditions.
• Components of Activity Diagram:
– Activities
– Association
– Conditions
– Constraints

29. Example - order management system
• The activity diagram is made to understand the flow of
activities and is mainly used by the business users.
• Following diagram is drawn with the four main activities −
– Send order by the customer
– Receipt of the order
– Confirm the order
– Dispatch the order
• After receiving the order request, condition checks are
performed to check if it is normal or special order. After
the type of order is identified, dispatch activity is
performed and that is marked as the termination of the
process.

30. Example - order management system

31. Activity diagram can be used for
• Activity diagram can be used for −
–Modeling work flow by using activities.
–Modeling business requirements.
–High level understanding of the system's
functionalities.
–Investigating business requirements at a
later stage.

32. Swimlane Diagram
• A swimlane diagram is a type of flowchart that delineates who
does what in a process.
• Activity diagrams tell you what happens, but they do not tell you
who does what.
• Like a flowchart, it diagrams a process from start to finish, but it
also divides these steps into categories(lanes) to help distinguish
which departments or employees are responsible for each set of
actions.
• It shows connections, communication and handoffs between
these lanes, and it can serve to highlight waste, redundancy and
inefficiency in a process.

33. Why Swimlane Diagrams Are Useful
• During any process improvement initiative, swimlanes help identify not just the
bottlenecks in a process, but also which department is responsible for them.
• Helping to clarify responsibilities and help departments work together in a world
where departments often don't understand what the other departments do.
• You may find costly redundancies and duplications or gaps and communication
problems.
How to Create a Swim Lane Flowchart
• Identify the lanes. Decide what divisions you need represented by swimlanes
and label them.
• Start your chart. Define the starting point of the process. Add a rounded
rectangle to the top of the appropriate swim lane to indicate its starting point
and label it.
• Add steps. Next add more steps to your chart. Each step should be connected
to the one before it with a line. To draw steps in the same swimlane, draw
from top to bottom. To add a step in another division go from left to right.
With each step, describe what it represents until you reach the end of the
process. The arrows between the steps indicate the transfer of information or
flow.

34. Example - order management system

35. Swimlane Diagram

36. Example – ATM System