systems analysis and design n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Systems Analysis and Design PowerPoint Presentation
Download Presentation
Systems Analysis and Design

Loading in 2 Seconds...

play fullscreen
1 / 111

Systems Analysis and Design - PowerPoint PPT Presentation


  • 128 Views
  • Uploaded on

Systems Analysis and Design. Rabie A. Ramadan Slides by Roberta M. Roth University of Northern Iowa. Questionnaires. A set of written questions, often sent to a large number of people May be paper-based or electronic Select participants using samples of the population

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Systems Analysis and Design' - breanna-mccall


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
systems analysis and design

Systems Analysis and Design

Rabie A. Ramadan

Slides by Roberta M. Roth

University of Northern Iowa

questionnaires1
A set of written questions, often sent to a large number of people

May be paper-based or electronic

Select participants using samples of the population

Design the questions for clarity and ease of analysis

Administer the questionnaire and take steps to get a good response rate

Questionnaire follow-up report

Questionnaires
good questionnaire design
Good Questionnaire Design
  • Begin with non-threatening and interesting questions
  • Group items into logically coherent sections
  • Do not put important items at the very end of the questionnaire
  • Do not crowd a page with too many items
  • Avoid abbreviations
  • Avoid biased or suggestive items or terms
  • Number questions to avoid confusion
  • Pretest the questionnaire to identify confusing questions
  • Provide anonymity to respondents
document analysis1
Study of existing material describing the current system

Forms, reports, policy manuals, organization charts describe the formal system

Look for the informal system in user additions to forms/report and unused form/report elements

User changes to existing forms/reports or non-use of existing forms/reports suggest the system needs modification

Document Analysis
observation1
Watch processes being performed

Users/managers often don’t accurately recall everything they do

Checks validity of information gathered other ways

Be aware that behaviors change when people are watched

Be modest (seems to be shy)

Identify peak and lull (quite) periods

Observation
selecting the appropriate requirements gathering techniques
Type of information

Depth of information

Breadth of information

Integration of information

User involvement

Cost

Combining techniques

Selecting the Appropriate Requirements-Gathering Techniques
your turn
Design a Questionnairefor the project ?

Report your observations on the current projects and usabilities ?

Collect at least 5of them

Your turn
the system is the data
At the core: any system is defined by the data obtained, stored, and displayed

Data flow analysis is the center/core/key

The System is the Data
context diagram
Shows the context into which the system fits

Shows the overall business process as just one process

Shows all the outside entities that receive information from or contribute information to the system

Context Diagram
key definitions
Key Definitions
  • Process model
    • A formal way of representing how a business operates
    • Illustrates the activities that are performed and how data moves among them
  • Data flow diagramming
    • A popular technique for creating process models
key definitions1
Key Definitions
  • Logicalprocess models describe processes without suggesting how they are conducted.
  • Physical process models include process implementation information.
dfd elements
DFD Elements
  • Process
    • An activity or function performed for a specific business reason
    • Manual or computerized
  • Data flow
    • A single piece of data or a logical collection of data
    • Always starts or ends at a process
dfd elements1
DFD Elements
  • Data Store
    • A collection of data that is stored in some way
    • Data flowing out is retrieved from the data store
    • Data flowing in updates or is added to the data store
  • External entity
    • A person, organization, or system that is external to the system but interacts with it.
naming and drawing dfd elements

Process

Data flow

Data store

External

entity

Naming and Drawing DFD Elements
depicting business processes with dfds
Depicting Business Processes with DFDs
  • Business processes are too complex to be shown on a single DFD
  • Decomposition is the process of representing the system in a hierarchy of DFD diagrams
    • Child diagrams show a portion of the parent diagram in greater detail
key definition
Balancinginvolves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.Key Definition
relationship among dfd levels

Context diagram

Level 0 diagram

Level 1 diagram

Level 2 diagram

Relationship Among DFD levels
context diagram1
First DFD in every business process

Shows the contextinto which the business process fits

Shows the overall business process as just one process (process 0)

Shows all the external entities that receive information from or contribute information to the system

Context Diagram
level 0 diagram
Shows all the major processes that comprise the overall system – the internal components of process 0

Shows how the major processes are interrelated by data flows

Shows external entities and the major processes with which they interact

Adds data stores

Level 0 Diagram
level 1 diagrams
Generally, one level 1 diagram is created for every major processon the level 0 diagram

Shows all the internal processes that comprise a single process on the level 0 diagram

Shows how information moves from and to each of these processes

If a parent process is decomposed into, for example, three child processes, these three child processes wholly and completely make up the parent process

Level 1 Diagrams
level 2 diagrams
Shows all processes that comprise a single process on the level 1 diagram

Shows how information moves from and to each of these processes

Level 2 diagrams may not be needed for all level 1 processes

Correctly numbering each process helps the user understand where the process fits into the overall system

Level 2 Diagrams
data flow splits and joins
A data flow split shows where a flow is broken into its component parts for use in separate processes

Data flow splits need not be mutually exclusive nor use all the data from the parent flow

As we move to lower levels we become more precise about the data flows

A data flow join shows where components are merged to describe a more comprehensive flow

Data Flow Splits and Joins
alternative data flows
Where a process can produce different data flows given different conditions

We show both data flows and use the process description to explain why they are alternatives

Tip -- alternative data flows often accompany processes with IF statements

Alternative Data Flows
your turn2
Your Turn
  • At this point in the process it is easy to lose track of the “big picture”.
  • Describe the difference between data flows, data stores, and processes.
  • Describe in your own words the relationship between the DFD and the ultimate new application being developed.
process descriptions
Text-based process descriptions provide more information about the processthan the DFD alone

If the logic underlying the process is quite complex, more detail may be needed in the form of

Structured English

Decision trees

Decision tables

Process Descriptions
structured english
Structured English

Common Statements Example

Action Statement Profits = Revenues - Expenses

Generate Inventory Report

Add Product record to Product Data Store

If Statement IF Customer Not in Customer Data Store

THEN Add Customer record to Customer Data Store

ELSE Add Current Sale to Customer’s Total Sales

Update Customer record in Customer Data Store

For Statement FOR all Customers in Customer Data Store, do

Generate a new line in the Customer Report

Add Customer’s Total Sales to Report Total

Case Statement CASE

If Income < 10,000: Marginal tax rate = 10%

If Income < 20,000: Marginal tax rate = 20%

If Income < 30,000: Marginal tax rate = 31%

If Income < 40,000: Marginal tax rate = 35%

ELSE Marginal tax rate = 38%

ENDCASE

decision trees
Decision Trees
  • Graphical way of depicting if-then-else logic
decision tables
Decision Tables
  • Represent very complex processes with multiple decision rules
integrating scenario descriptions
Integrating Scenario Descriptions
  • DFDs start with the use cases and requirements definition
  • Generally, the DFDs integrate the use cases
  • Names of use cases become processes
  • Inputs and outputs become data flows
  • “Small” data inputs and outputs are combined into a single flow
key ideas
Key Ideas
  • Use cases are a text-based method of describing and documenting complex processes
  • Use cases add detail to the requirements outlined in the requirement definition
  • Systems analysts work with users to develop use cases
  • Systems analysts develop process and datamodels later based on the use cases
role of use cases
Role of Use Cases
  • A use case is a set of activities that produce some output result
  • Describes how the system reacts to an event that triggers the system
  • Trigger -- event that causes the use case to be executed
  • Event-driven modeling – everything in the system is a response to some triggering event
role of use cases1
Role of Use Cases
  • All possible responses to the event are documented
  • Use cases are helpful when the situation is complicated
elements of a use case
Elements of a Use Case
  • Basic information
    • Name, number and brief description
    • Trigger – event that causes the use case to being
      • External trigger – some from outside the system
      • Temporal triggers – time-based occurrences
    • Viewpoint of the use cases should be consistent
  • Major inputs and outputs
    • Sources and destinations
    • Goal is to be all inclusive
  • Details
    • Steps performed and the data inputs and outputs
process of developing use cases
Process of Developing Use Cases
  • Identify the major use cases
  • Identify the major steps within each use case
  • Identify elements within steps
  • Confirm the use case
  • Cycle through the above steps iteratively
step 1 identify the major use cases

Activities

Typical Questions Asked

  • Start a use case form for each use case
  • If more than nine, group into packages
  • Ask who, what, and where about the tasks and their inputs and outputs:
  • What are the major tasks performed?
  • What triggers this task? What tells you to perform this task?
  • What information/forms/reports do you need to perform this task?
  • Who gives you these information/forms/reports?
  • What information/forms/reports does this produce and where do they go?
Step 1 – Identify the major use cases
step 2 identify the major steps within each use case

Activities

Typical Questions Asked

  • For each use case, fill in the major steps needed to process the inputs and produce the outputs
  • Ask how about each use case:
  • How do you produce this report?
  • How do you change the information on the report?
  • How do you process forms?
  • What tools do you use to do this step (e.g., on paper, by email, by phone)?
Step 2 - Identify the major steps within each use case
step 3 identify elements within steps
Step 3 – Identify elements within steps

Activities

Typical Questions Asked

  • For each step, identify its triggers and its inputs and outputs
  • Ask how about each step
  • How does the person know when to perform this step?
  • What forms/reports/data does this step produce?
  • What forms/reports/data does this step need?
  • What happens when this form/report/data is not available?
step 4 confirm the use case

Activities

Typical Questions Asked

  • For each use case, validate that it is correct and complete
  • Ask the user to execute the process using the written steps in the use case – that is, have the user role-play the use case
Step 4 – Confirm the use case
summary
Summary
  • Use cases contain all the information needed for process modeling, but are easier for users to comprehend
  • Use cases are created in an iterative cycle of steps until they are considered accurate and complete
some of the use cases to work on
Some of the Use Cases to work on
  • Registration Use Cases
  • Grades recording Use Case
  • Uploading lectures Use Case
  • Exams Use Case
steps in building dfds
Steps in Building DFDs
  • Build the context diagram
  • Create DFD fragments for each use case
  • Organize DFD fragments into level 0 diagram
  • Decompose level 0 processes into level 1 diagrams as needed; decompose level 1 processes into level 2 diagrams as needed; etc.
  • Validate DFDs with user to ensure completeness and correctness
build the context diagram
Build the Context Diagram
  • Draw one process representing the entire system (process 0)
  • Find all inputs and outputs listed at the top of the use cases that come from or go to external entities; draw as data flows
  • Draw in external entities as the source or destination of the data flows
creating dfd fragments
Creating DFD Fragments
  • Each use case is converted into one DFD fragment
  • Number the process the same as the use case number
  • Change process name into verb phrase
  • Design the processes from the viewpoint of the organization running the system
creating dfd fragments1
Creating DFD Fragments
  • Add data flows to show use to data stores as sources and destinations of data
  • Layouts typically place
    • processes in the center
    • inputs from the left
    • outputs to the right
    • stores beneath the processes
creating the level 0 diagram
Creating the Level 0 Diagram
  • Combine the set of DFD fragments into one diagram
  • Generally move from top to bottom, left to right
  • Minimize crossed lines
  • Iterate as needed
    • DFDs are often drawn many times before being finished, even with very experienced systems analysts
creating level 1 diagrams and below
Creating Level 1 Diagrams (and Below)
  • Each use case is turned into its own DFD
  • Take the steps listed on the use case and depict each as a process on the level 1 DFD
  • Inputs and outputs listed on use case become data flows on DFD
  • Include sources and destinations of data flows to processes and stores within the DFD
  • May also include external entities for clarity
creating level 1 diagrams and below1
Creating Level 1 Diagrams (and Below)
  • Input data flows shown on a parent DFD are often unbundled on the child diagram using splits
  • Output data flows shown on a child DFD are often bundled using joins and shown as a larger data flow on the parent diagram
  • When to stop decomposing DFDs?
    • Ideally, a DFD has at least 3 processes and no more than 7-9.
validating the dfd

For each DFD:

Check each process for:

A unique name: action verb phrase; number; description

At least one input data flow

At least one output data flow

Output data flow names usually different than input data flow names

Between 3 and 7 processes per DFD

Validating the DFD
  • Syntax errors – diagram follows the rules
    • Assure correct DFD structure
validating the dfd1
Validating the DFD

For each DFD:

Check each data flow for:

A unique name: noun; description

Connects to at least one process

Shown in only one direction (no two-headed arrows)

A minimum number of crossed lines

Check each data store for:

A unique name: noun; description

At least one input data flow

At least one output data flow

Check each external entity for:

A unique name: noun; description

At least one input or output data flow

validating the dfd2
Validating the DFD

Across DFDs:

Context Diagram:

Every set of DFDs must have one Context Diagram

Viewpoint:

There is a consistent viewpoint for the entire set of DFDs

Decomposition:

Every process is wholly and complete described by the processes on

its children DFDs

Balance:

Every data flow, data store, and external entity on a higher level DFD

is shown on the lower level DFD that decomposes it

No data stores or data flows appear on lower-lever DFDs that do not

appear on their parent DFD

validating the dfd3
Validating the DFD
  • Semantics errors – diagram conveys correct meaning
    • Assure accuracy of DFD relative to actual/desired business processes
  • To verify correct representation, use
    • User walkthroughs
    • Role-play processes
  • Examine lowest level DFDs to ensure consistent decomposition
  • Examine names carefully to ensure consistent use of terms
summary1
Summary
  • The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes.
  • Use cases record the input, transformation, and output of business processes and are the basis for process models.
  • Eliciting use cases and modeling business processes are critically important skills for the systems analyst to master.
extended entity relationship eer model
Extended Entity Relationship(EER) Model

The ER model has been widely used but does not have some shortcomings.

It is difficult to represent cases where an entity may have varying attributes dependent upon some property.

ER model has been extended into Extended Entity Relationship model

It includes more semantics such as generalization, categorization and aggregation.

cardinality one to one relationship
Cardinality: One-to-one relationship

A one-to-one relationship between set A and set B is defined as:

For all a in A, there exists at most one b in B such that a and b are related, and vice versa.

Example

A president leads a nation.

cardinality one to one relationship1
Cardinality: One-to-one relationship

Relational Model:

Relation President (President_name, Race, *Nation_name)

Relation Nation (Nation_name, Nation_size)

Where underlined are primary keys and "*" prefixed are foreign keys

Extended Entity Relationship model

in election system one to one relationship
In Election System : One-to-one relationship !!!!!

Person and ID

Persons’ and Vote

Judge and Box

Username and Person

cardinality many to one relationship
Cardinality: Many-to-one relationship

A many-to-one relationship from set A to set B is defined as:

For all a in A, there exists at most one b in B such that a and b are related,

and for all b in B, there exists zero or more a in A such that a and b are related.

Example A director directs many movies.

cardinality many to one relationship1
Cardinality: Many-to-one relationship

Relational Model:

Relation Director (Director_name, Age)

Relation Movies (Movie_name, Sales_volume, *Director_name)

Extended entity relationship model:

in election system many to one relationship
In Election System : many to one relationship !!!!

Box and judge

President position and candidates

Candidate and votes

Candidate and position

cardinality many to many relationship
Cardinality: Many-to-many relationship

A many-to-many relationship between set A and set B is defined as:

For all a in A, there exists zero or more b in B such that a and b are related, and vice versa.

Example

Many students take many courses such that a student can take many courses and a course can be taken by many students.

many-many

cardinality many to many relationship1
Cardinality: Many-to-many relationship

Relational Model:

Relation Student (Student_id, Student_name)

Relation Course (Course_id, Course_name)

Relation take (*Student_id, *Course_id)

Extended entity relationship model:

in election system many to many relationship
In Election System : many to many relationship !!!!

Boxes and judges at the same place

Security table contains many user names and passwords for many persons

data semantic is a subtype relationship
DataSemantic: Is-a (Subtype) relationship

The relationship A isa B is defined as:

A is a special kind of B.

Example

Father is Male.

data semantic is a subtype relationship1
DataSemantic: Is-a (Subtype) relationship

Relational Model:

Relation Male (Name, Height)

Relation Father (*Name, Birth_date)

Extended entity relationship model

data semantic disjoint generalization
Data Semantic: Disjoint Generalization

The process of generalization is to classify similar entities into a single entity.

More than one isa relationship can form data abstraction (i.e. superclass and subclasses) among entities.

A subclass entity is a subset of its superclass entity.

There are two kinds of generalization.

The first is disjoint generalization such that subclass entities are mutually exclusive.

The second is overlap generalization such that subclass entities can overlap each other.

Example of Disjoint Generalization

A refugee and a non-refugee can both be a boat person, but a refugee cannot be a non-refugee, and vice versa.

data semantic disjoint generalization1
Data Semantic: Disjoint Generalization

Relational Model:

Relation Boat_person (Name, Birth_date, Birth_place)

Relation Refugee (*Name, Open_center)

Relation Non-refugee (*Name, Detention_center)

Extended entity relationship model:

data semantic overlap generalization
DataSemantic: Overlap Generalization

Example of Overlap Generalization

A computer programmer and a system analyst can both be a computer professional, and a computer programmer can also be a system analyst, and vice versa.

data semantic overlap generalization1
DataSemantic: Overlap Generalization

Relational Model:

Relation Computer_professional (Employee_id, Salary)

Relation Computer_programmer (*Employee_id, Language_skill)

Relation System_analyst (*Employee_id, Application_system)

Extended entity relationship model:

data semantic categorization relationship
DataSemantic: Categorization Relationship

In cases the need arises for modeling a single superclass/subclass relationship with more than one superclass(es), where the superclasses represent different entity types.

In this case, we call the subclass a category.

data semantic categorization relationship1
DataSemantic: Categorization Relationship

Relational Model:

Relation Department (Borrower_card, Department_id)

Relation Doctor (Borrower_card, Doctor_name)

Relation Hospital (Borrower_card, Hospital_name)

Relation Borrower (*Borrower_card, Return_date, File_id)

Extended Entity Relationship Model

data semantic aggregation relationship
Data Semantic: Aggregation Relationship

Aggregation is a method to form a composite object from its components.

It aggregates attribute values of an entity to form a whole entity.

Example

The process of a student taking a course can form a composite entity (aggregation) that may be graded by an instructor if the student completes the course.

data semantic aggregation relationship1
Data Semantic: Aggregation Relationship

Relational Model:

Relation Student (Student_no, Student_name)

Relation Course (Course_no, Course_name)

Relation Takes (*Student_no, *Course_no, *Instructor_name)

Relation Instructor (Instructor_name, Department)

Extended Entity Relationship Model

data semantic total participation
DataSemantic: Total Participation

An entity is in total participation with another entity provided that all data occurrences of the entity must participate in a relationship with the other entity.

Example

An employee must be hired by a department.

data semantic total participation1
DataSemantic: Total Participation

Relational Model:

Relation Department (Department_id, Department_name)

Relation Employee (Employee_id, Employee_name, *Department_id)

Extended entity relationship model:

data semantic partial participation
Data Semantic: Partial Participation

An entity is in partial participation with another entity provided that the data occurrences of the entity are not totally participate in a relationship with the other entity.

Example

An employee may be hired by a department.

data semantic partial participation1
Data Semantic: Partial Participation

Relational Model:

Relation Department (Department_id, Department_name)

Relation Employee (Employee_no, Employee_name, &Department_id)

Where & means that null value is allowed

Extended entity relationship model:

data semantic weak entity
Data Semantic: Weak Entity

The existence of a weak entity depends on its strong entity.

Example

A hotel room must concatenate hotel name for identification.

data semantic weak entity1
Data Semantic: Weak Entity

Relational Model:

Relation Hotel (Hotel_name, Ranking)

Relation Room (*Hotel_name, Room_no, Room_size)

Extended entity relationship model

cardinality n ary relationship
Cardinality: N-ary Relationship

Multiple entities relate to each other in an n-ary relationship.

Example

Employees use a wide range of different skills on each project they are associated with.

cardinality n ary relationship1
Cardinality: N-ary Relationship

Relational Model:

Relation Engineer (Employee_id, Employee_name)

Relation Skill (Skill_name, Years_experience)

Relation Project (Project_id, Start_date, End_date)

Relation Skill_used (*Employee_id, *Skill_name, *Project_id)

Extended entity relationship model:

example
Example

name

addr

Bars

license

name

manf

Beers

Sells

Bars sell some

beers.

Drinkers like

some beers.

Frequents

Likes

Note:

license =

beer, full,

none

Drinkers frequent

some bars.

Drinkers

name

addr

example1
Example

Bar Beer

Joe’s Bar Bud

Joe’s Bar Miller

Sue’s Bar Bud

Sue’s Bar Pete’s Ale

Sue’s Bar Bud Lite

For the relationship Sells, we might have a relationship set like:

example2
Example

name

addr

name

manf

Bars

Beers

license

Preferences

Drinkers

name

addr

a typical relationship set
A Typical Relationship Set

Bar Drinker Beer

Joe’s Bar Ann Miller

Sue’s Bar Ann Bud

Sue’s Bar Ann Pete’s Ale

Joe’s Bar Bob Bud

Joe’s Bar Bob Miller

Joe’s Bar Cal Miller

Sue’s Bar Cal Bud Lite

your assignment build entity relationship model
Your Assignment Build Entity-relationship model

Relation Order (Order_code, Order_type, Our_reference, Order_date, Approved_date, *Head, *Supplier_code)

Relation Supplier (Supplier_code, Supplier_name)

Relation Product (Product_code, Product_description)

Relation Department (Department_code, Department_name)

Relation Head (Head, *Department_code, Title)

Relation Order_Product (*Order_code, *Product_code, Qty, Others, Amount)

Relation Note (*Order_code, Sequence#, Note)

where underlined are primary keys and prefixed with ‘*’ are foreign keys.