Requirements Modeling

1
Requirements Modeling

• CMSC 445
• Pressman Chapters 11/12

2
Overview

• What techniques are useful for constructing
  system models?
• What modeling techniques are useful for
  understanding system models?
• What are the benefits of the various modeling
  strategies?
• What information is captured in various
  representation strategies?

3
Analysis Model

• Three objectives of the analysis model
• describe what the customer requires
• establish as basis for the creation of a software
  design
• define a set of requirements that can be
  validated.

4
Analysis Models
5
Data Modeling

• Data modeling is the basis for understanding the
  information domain of the problem.
• Data modeling seeks to identify the major data
  objects that are processed by the system.
• Data modeling considers data independent of
  processing.
• Data modeling establishes the composition of each
  data object, its attributes and the relationship
  between data objects.

6
Data Objects

• A data object is a representation of composite
  information used by the system. Things from the
  problem domain that are important for the users
  of the system.
• Typically these are the things that are kept as
  data. We can also consider as entities classes of
  objects.
• Making a distinction here between the
  description of a class of items and a particular
  item.
• Consider the distinction between the class of
  items defined by the concept PERSON and a
  particular instance of that class, perhaps FRED.
  The entity defines, generally, the qualities that
  make an item a member of that class

7
Attributes

• Attributes define properties of a data object.
  They can name an instance, describe the instance,
  or make reference to another item.
• Attributes are those values that combine to help
  us "define" an entity.
• Want to take some care to define entities and
  attributes in a way that assists us in
  establishing an entities descriptive
  characteristics so we can differentiate one
  entity from another.

8
Relationships

• Data objects relate to each other in a variety
  of, sometimes complex, ways.
• Relationship try to indicate the connection
  between two data objects.

9
An Example
Name Address Insurance Company
Fred
Attributes
Owns/Leases
Objects
Relationships
Make Model Body Type Color
10
ER Diagrams

• Cardinality
• specifies the number of occurrences of an object
  in a relationship with another object.
• Cardinality defines the maximum number of objects
  in the relationship.
• Example How many cars a Person may own

11
ER Diagrams

• Modality
• An indication of whether an object is required to
  participate in a relationship.
• Used to indicate when there is no need for a
  relationship or when a relationship is optional.

12
Example
13
Continuing the Example
14
Information Flow

• A system accepts inputs from various places in
  various forms.
• The system transforms the inputs as they flow
  through the system.
• At each level the system can be viewed as a
  series of transformations on data.
• Structured analysis focus was on modeling
  information flow through system.

15
Data Flow Diagrams

• Capture information regarding process and data as
  it moves from process to process. DFDs are a
  graphical/diagrammatic representation
• Processes rendered as circles.
• Directed arcs indicate that data moves from one
  process to another with the name of the data
  labeling the arc.
• Data flow diagrams can be used to model a system
  at any level of abstraction. Level 0 DFD is the
  context diagram (context model or fundamental
  system model).
• The model can be decomposed, refined, reveal more
  detail.

16
Introducion

• Data Flow Diagrams (DFD)
• describe data processes and flows in a system
• depict overview of system inputs, processes and
  output
• are used to represent analyze detailed
  procedures in the larger system
• crystallize acquired information in a useful way
• eventually become solid system documentation

17
Advantages of DFDs

• Freedom from involving with technical
  implementation too early
• Provide information inter-relatedness of systems
  and sub-systems
• Can be used as a tool for communicating with
  users (but, users must have some knowledge about
  the DFD)
• Analysis of a proposed system to determine all
  important data and process have been defined

18
Level 1 - Context Diagram
19
Level Two Diagram
20
Four Basic Symbols Used in DFD

• Entity
• is considered as EXTERNAL to the system
• e.g., a department, a person, or a business
• should be named with a noun
• can be used more than once in order to avoid
  crossing
• Data Flow
• shows movement of data
• should be named with a noun
• each arrow represents only one data flow

21
Four Basic Symbols Used in DFD

• Process
• represents a process
• should use verb-adjective-noun format for naming
  all processes
• e.g., Add Inventory Record must record also
  have unique number which represent each process
  and indicate its level
• Data
• may represent database or filing cabinet
• should be named with a noun
• Note temporary data stores, scratch paper, or
  temporary computer files are not included

22
Process for Developing DFD

• Make a list of business activities and use it to
  determine
• External entities
• Data Flows
• Processes
• Data Stores
• Draw a Context diagram which shows only a single
  process (represent the entire system), and
  external entities
• Draw a Diagram-0 (Level-0 diagram)
• shows general processes
• shows data stores
• Draw child diagrams (Level-1 diagram) for each of
  the process in Diagram-0

23
Behavior Modeling

• Behavioral modeling captures the behavior of the
  system by focusing on states the system can be in
  and the events that cause transitions from one
  state to another.
• Typically state transition diagrams are used to
  represent this information. A state is an
  observable mode of behavior for the system.
• Harel (1987) proposed an extension to FSM that
  made it easier to model complex real-time system
  behavior.
• The Harel extensions provide a notation and set
  of conventions that facilitate the hierarchical
  decomposition of FSM and a mechanism for
  communication between concurrent finite state
  machines.

24
Example Library Book Holdings
25
Example Class Model
Class Size 0 gt Empty Class Size lt 25 gt
Small Class Size gt 25 gt Large