Scribd
Upload
18 views

SE Unit 04 Function Oriented Analysis Design HRR

Uploaded by

hrp25082003
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views

SE Unit 04 Function Oriented Analysis Design HRR

Uploaded by

hrp25082003
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

UNIT 4: FUNCTION ORIENTED ANALYSIS AND DESIGN

❖ The requirement analysis model


➢ The purpose of requirement analysis models are:

✓ Describe what the customer wants built


✓ Establish the foundation for the software design
✓ Provide a set of validation requirements

Figure.1 the requirement Analysis

➢ Analysis rule of Thumb

✓ Make sure all points of view are covered


✓ Every element should add value
✓ Keep it simple
✓ Maintain a high level of abstraction
✓ Focus on the problem domain
✓ Minimize system coupling
✓ Model should provides value to all stakeholders

➢ Elements of the Requirements Model

Figure.2 Elements of requirement model

Page | 1
UNIT 4: FUNCTION ORIENTED ANALYSIS AND DESIGN
• Scenario-based elements

➢ Describe the system from the user's point of view using scenarios that are depicted (stated) in use cases
and activity diagrams

• Class-based elements

➢ Identify the domain classes for the objects manipulated by the actors, the attributes of these classes, and
how they interact with one another; which utilize class diagrams to do this.

• Behavioral elements

➢ Use state diagrams to represent the state of the system, the events that cause the system to change state,
and the actions that are taken as a result of a particular event. This can also be applied to each class in
the system.

• Flow-oriented elements

➢ Use data flow diagrams to show the input data that comes into a system, what functions are applied to
that data to do transformations, and what resulting output data are produced.

Figure.3 Analysis Modeling Approaches

❖ Flow Oriented Modeling


➢ Although data flow-oriented modeling is perceived as an outdated technique by some software
engineers, it continues to be one of the most widely used requirements analysis notations in use today.
Although the data flow diagram (DFD) and related diagrams and information are not a formal part of
UML, they can be used to complement UML diagrams and provide additional insight into system
requirements and flow.

❖ Data Flow Diagram:


➢ A data flow diagram is a graphical depiction of flow of data through intended software system and is
used as 1st step to create an overview of system. It’s really useful as it provides overview of data as well
as functionality to software designers

• Components of DFD :

1. External Entities They could be a person (facebook users), another software (like facebook) or a
hardware (sensors) which provide to or consume information from the intended software.

Page | 2
UNIT 4: FUNCTION ORIENTED ANALYSIS AND DESIGN
➢ Rules for External entities are as follows:

✓ Represented by rectangle
✓ Must be named
✓ No direct flow between two External Entities is ever possible

2. Process A circle (sometimes called a bubble) represents a process or transforms that is applied to data
and changes it in some way. The basic rules:

✓ It must be properly labeled


✓ It must not be repeated in a diagram

Ticket
Booking
3. Data Flows

➢ The basic rules:

✓ Data flows can’t be bidirectional, i.e. the input data flow and the output data flow for a process, data
store or for an entity should always be different.
✓ The data flows should always be labeled.
✓ The labels should be precise and informative.
✓ You can join two similar input data flows (join) or two similar output data flows (fork).

4. Data stores

➢ They are places where data may be stored. This information may be stored either temporarily or
permanently by the user. They are internal to the system.

➢ The basic rules:

✓ Never shown in context level diagram


✓ No direct data flows between two data sources

Page | 3
UNIT 4: FUNCTION ORIENTED ANALYSIS AND DESIGN
➢ Basic rules that apply to all DFDs:

✓ No internal logic should be shown like loops, if-else, this is not a flow chart

✓ In order to keep the diagram uncluttered, you can repeat data stores and external entities

✓ No process can have only output data flows (a miracle).

✓ No process can have only input data flows (black hole).

✓ Data cannot be moved directly from one store to another without a process.

✓ Data cannot move directly from an external entity to a data store without a process.

✓ Data stores can’t be sink( only input data flows) or source ( only output data flows) in level 1 DFD

❖ Context Level diagram:


• A level 0 DFD also called a fundamental system model or a context model. It represents the entire
software element as a single process with input and output data. All the external entities should be
identified and shown.

➢ Rule:

✓ Only one process


✓ Data flows should be labeled.
✓ No data store can be shown in context diagram

• Level 1 DFD:

➢ The level 1 DFD we construct is a more refined version of the context diagram. It covers the entire
system, all the main processes are shown

➢ The DFD should be balanced with respect to context diagram

✓ No new external entities should be there


✓ The data flows from context diagrams should be visible

➢ Rules:

✓ It should consist of 5-9 processes (bubbles).


✓ Repetition of data sources is allowed.

Page | 4
UNIT 4: FUNCTION ORIENTED ANALYSIS AND DESIGN
✓ Process can not be repeated.

• Level 2 DFD:

➢ Only those processes that merit being expanded need to have level 2 DFDs. Level 2 DFD completely
describes any one process from the level 1 DFD.

➢ Rules:

✓ All the data flows into and out of selected process on the level 1 DFD also appear on the level 2
DFD.
✓ Repetition of data sources is allowed.
✓ A Data store can appear as a sink or source within level 2 DFD.

Page | 5

You might also like