bncvbnvcnb

1. Tools of Analysis/Requirements
Modelling

2. • The written word is a wonderful vehicle for communication, but it is
not necessarily the best way to represent the requirements for
computer software.
• 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

3. • Much of the work you will be doing as a system analyst involves
modelling the system user wants
• There are many different kinds of models that you can build just as
there are many different models of a new house that an architect can
build .

5. • We will now introduce and briefly discuss three important systems
modeling tools: the dataflow diagram, the entity-relationship
diagram, and the state-transition diagram.
• The dataflow diagram illustrates the functions that the system must
perform;
• the entity-relationship diagrams emphasize the data relationships,
and the
• state­
transition diagram focuses on the time-dependent behavior of
the system

6. • all three of the major modeling tools consist of graphics (pictures) and
supporting textual modeling tools.
• The graphics provide a vivid and easy-to-read way for the systems
analyst to show the users the major components of the model, as
well as the connections (or interfaces) between the components.
• The supporting textual modeling tools provide precise definitions of
the meaning of the components and connections

7. Requirements Modelling Strategies
• One view of requirements modeling, called structured analysis,
considers data and the processes that transform the data as separate
entities.
• Data objects are modeled in a way that defines their attributes and
relationships.
• Processes that manipulate data objects are modeled in a manner that
shows how they transform data as data objects flow through the system.
• Second approach to modelling , called object-oriented analysis, focuses
on the definition of classes and the manner in which they collaborate
with one another to effect customer requirements

8. • The requirements modeling action results in one or
more of the following types of models:
• • Scenario-based models of requirements from the
point of view of various system “actors”
• • Data models that depict the information domain
for the problem
• • 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”

9. Data Modelling
• If software requirements include the need to create, extend, or
interface with a database or if complex data structures must be
constructed and manipulated, the software team may choose to
create a data model as part of overall requirements modeling.
• A software engineer or analyst defines all data objects that are
processed within the system, the relationships between the data
objects, and other information that is pertinent to the relationships.
The entity-relationship diagram (ERD) addresses these issues and
represents all data objects that are entered, stored, transformed, and
produced within an application

10. Basic Concepts of ER Model
•The basic concepts provided by the ER model are Data objects/entities, relationships, and attributes.
Data Objects/Entities.
• A data object/Entity is a representation of composite information
that must be understood by software. By composite information,
means something that has a number of different properties or
attributes. Therefore, width (a single value) would not be a valid
data object, but dimensions (incorporating height, width, and
depth) could be defined as an object. Entities represent classes of real-
world objects. Data obects/Entities are graphically represented by means of
rectangles

11. • 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).
• For example, a person or a car can be viewed as a data object in the sense that either can be
defined in terms of a set of attributes. The description of the data object incorporates the
data object and all of its attributes

12. •Relationships. Relationships represent aggregations of two or
more entities. An example of a binary relationship in the
personnel database is IS_BORN_IN, which relates PERSON and
CITY of birth. Another binary relationship between the same
entities is LIVES_JN, which indicates the city where the person
currently lives. Relationships are graphically represented by
means of diamonds

14. Flow oriented Modelling: The Data Flow
Diagram (DFD)
• The DFD takes an input-process-output view of a system.
• That is, data objects flow into the software, are transformed by
processing elements, and resultant data objects flow out of the
software.
• Data objects are represented by labeled arrows, and transformations
are represented by circles (also called bubbles)

15. • The DFD is presented in a hierarchical fashion.
• That is, the first data flow model (sometimes called a level 0 DFD or
context diagram) represents the system as a whole.
• Subsequent data flow diagrams refine the context diagram, providing
increasing detail with each subsequent level.

16. Components of a DFD: Process
• The first component of the DFD is known as a process.
• Common synonyms are a bubble, a function, or a transformation. The
process shows a part of the system that transforms inputs into
outputs; that is, it shows how one or more inputs are changed into
outputs. The process is represented graphically as a circle, as shown
in Figure.

17. • A flow is represented graphically by an arrow into or out of a
process. The flow is used to describe the movement of chunks, or
packets of information from one part of the system to another part.
Thus, the flows represent data in motion, whereas the stores
represent data at rest.

18. A combination of input and output flows

19. Store
• The store is used to model a collection of data packets at rest. The
notation for a store is two parallel lines.

20. Terminator
• The next component of the DFD is a terminator; it is graphically
represented as a rectangle. Terminators represent external entities
with which the system communicates.
• A terminator is a person or a group of people, for example, an outside
organization or government agency, or a group or department that is
within the same company or organization, but outside the control of
the system being modeled.
• In some cases, a terminator may be another system, for example,
some other computer system with which your system will
communicate.

21. Creating a Data Flow Diagram
• The data flow diagram enables you to develop models of the
information domain and functional domain.
• As the DFD is refined into greater levels of detail, you perform an
implicit functional decomposition of the system.
• At the same time, the DFD refinement results in a corresponding
refinement of data as it moves through the processes that embody
the application

22. Guidelines for drawing the DFD
(1) the level 0 data flow diagram should depict the
software/system as a single bubble;
(2) primary input and output should be carefully noted;
(3) Refinement should begin by isolating candidate processes,
data objects, and data stores to be represented at the next level;
(4) all arrows and bubbles should be labeled with meaningful
names;
(5) information flow continuity must be maintained from level 1 to
level,2 and
(6) one bubble at a time should be refined.

23. Safehome Security Function: Narrative
• The Itaclised words are the verbs
• Underlined words are the nouns

24. • The SafeHome security function enables the homeowner to
configure the security system when it is installed, monitors all
sensors connected to the security system, and interacts with the
homeowner through the Internet, a PC, or a control panel. During
installation, the SafeHome PC is used to program and configure the
system. Each sensor is assigned a number and type, a master
password is programmed for arming and disarming the system, and
telephone number(s) are input for dialing when a sensor event
occurs. When a sensor event is recognized, the software invokes an
audible alarm attached to the system. After a delay time that is
specified by the homeowner during system configuration activities,
the software dials a telephone number of a monitoring service,
provides information about the location, reporting the nature of the
event that has been detected. The telephone number will be redialed
every 20 seconds until telephone connection is obtained. The
homeowner receives security information via a control panel, the PC,
or a browser, collectively called an interface. The interface displays
prompting messages and system status information on the control

25. • Referring to the grammatical parse, verbs are SafeHome processes and
can be represented as bubbles in a subsequent DFD. Nouns are either
external entities (boxes),data or control objects (arrows), or data stores
(double lines).
• Therefore, by performing a grammatical parse on the processing
narrative for a bubble at any DFD level, you can generate much useful
information about how to proceed with the refinement to the next level.
• Using this information, a level 1 DFD is shown in Figure
• The context level process shown in Figure has been expanded into six
processes derived from an examination of the grammatical parse.
• Similarly, the information flow between processes at level 1 has been
derived from the parse.
• In addition, information flow continuity is maintained between levels 0
and 1.

26. Context level DFD for the Safehome security
Function

27. •The level 0 DFD must now be expanded into a
level 1 data flow model.
•But how do we proceed?
• The context level process has been expanded into six
processes derived from an examination of the grammatical
parse.
• Similarly, the information flow between processes at level 1
has been derived from the parse.
• In addition, information flow continuity is maintained
between levels 0 and 1

28. Level1 DFD

29. • The processes represented at DFD level 1 can be further
refined into lower levels.
• For example, the process monitor sensors can be refined into
a level 2 DFD as shown in Figure .
• Information flow continuity has been maintained between
levels.
• The refinement of DFDs continues until each bubble
performs a simple function.
• That is, until the process represented by the bubble
performs a function that would be easily implemented as a
program component

30. Level2 DFD

31. Creating a Control Flow Model
• For some types of applications, the data model and the data flow
diagram are all that is necessary to obtain meaningful insight into
software requirements.
• However , a large class of applications are “driven” by events rather
than data, produce control information rather than reports or
displays, and process information with heavy concern for time and
performance.
• Such applications require the use of control flow modeling in addition
to data flow modeling.

32. Modelling time Dependent Behaviour- The
State Transition Diagram
•A third aspect of many complex systems is their time-
dependent behavior, that is, the sequence in which
data will be accessed and functions will be performed.

33. •For some business computer systems, this is not an
important aspect to highlight, since the sequence is
essentially trivial. Thus, in many batch computer
systems (those which are neither on-line nor real-
time), function N cannot carry out its work until it
receives its required input; and its input is produced
as an output of function N - 1; and so on

34. • However, many on-line systems and real-time systems, both in the
business area and in the scientific/engineering area, have complex
timing relationships that must be modeled just as carefully as the
modeling of functions and data relationships.
• Many real-time systems, for example, must respond within a very
brief period of time, perhaps only a few microseconds, to certain
inputs that arrive from the external environment.
• And they must be prepared for various combinations and sequences
of inputs to which appropriate responses must be made.

35. •The modeling tool that we use to describe this aspect
of a system's behavior is the state-transition diagram,
sometimes abbreviated as STD..

36. State Transtion diagram Components
• The major components of the diagram are states and arrows
representing state changes.
• a state represents some behavior of the system that is observable and
that lasts for some finite period of time.

37. Conditions and States

38. • A typical diagram is shown in Figure ; it models the behavior of a
computer-controlled washing machine.
• The rectangular boxes represent states that the system can be in .
• Each state represents a period of time during which the system
exhibits some observable behavior;
• the arrows connecting each rectangular box show the state-change,
or transitions from one state to another.
• Associated with each state-change is one or more conditions (the
events or circumstances that caused the change of state) and zero or
more actions (the response, output, or activity that takes place as
part of the change of state).

39. • A condition is some event in the external environment that the system
is capable of detecting; it will typically be a signal, an interrupt, or the
arrival of a packet of data. This will typically cause the system to
change from a state of waiting for X to a new state of waiting for Y, or
carrying out activity X to carrying out activity Y.
• But as part of the change of state, the system will typically take one or
more actions: it will produce an output, display a message on the
user's terminal, carry out a calculation, and so on. Thus, actions shown
on the STD are either responses sent back to the external
environment, or they are calculations whose results are remembered
by the system

40. State Transition Diagram of a Washing
Machine

41. State Transition Diagram for an ATM machine

42. • An event or control item is implemented as a Boolean value (e.g., true or
false, on or off, 1 or 0) or a discrete list of conditions (e.g., empty, jammed,
full).
• To select potential candidate events, the following guidelines are suggested:
• • List all sensors that are “read” by the software.
• • List all interrupt conditions.
• • List all “switches” that are actuated by an operator.
• • List all data conditions.
• • Recalling the noun/verb parse that was applied to the processing narrative,
review all “control items” as possible control specification inputs/outputs.
• • Describe the behavior of a system by identifying its states, identify how each
state is reached, and define the transitions between states.
• • Focus on possible omissions—a very common error in specifying control; for
example, ask: “Is there any other way I can get to this state or exit from it?”

43. Changes of states
• A system that existed in only one state would not be very interesting
to study: it would be static.
• Indeed, the information systems that we typically model may have
dozens of different states.
• But how does a system change from one state to another? If the
system has orderly rules governing its behavior, then typically only
certain kinds of state changes will be meaningful and valid.

44. Change of states

45. Multiple Final states of a system