Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.

Slides:



Advertisements
Similar presentations
SYSTEMS ANALYSIS AND DESIGN TOOLS
Advertisements

Using Data Flow Diagrams
Chapter 7 Structuring System Process Requirements
Using Dataflow Diagrams
© 2005 by Prentice Hall Appendix 2 Automated Tools for Systems Development Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Chapter 4 Enterprise Modeling.
Software Design Deriving a solution which satisfies software requirements.
Chapter 4.
Systems Analysis and Design 9th Edition
Copyright 2002 Prentice-Hall, Inc. Chapter 4 Automated Tools for Systems Development 4.1 Modern Systems Analysis and Design Third Edition.
Using Dataflow Diagrams
Chapter 7 Using Data Flow Diagrams
Copyright 2002 Prentice-Hall, Inc. Chapter 4 Automated Tools for Systems Development 4.1 Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer.
Data and Process Modeling
Chapter 9 Using Data Flow Diagrams
L ECTURE 9 – PROCESS MODELLING PART 1 Data Flow Diagrams for Process Modelling Multi-level Data Flow Diagrams Logical Vs Physical DFDs Steps to Construct.
Chapter 4.
System Analysis and Design
DATA FLOW DIAGRAMS IT 155.
Chapter 7 Structuring System Process Requirements
Software Design Description (SDD) Diagram Samples
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Systems Analysis and Design 10th Edition
Chapter 6: The Traditional Approach to Requirements
PHASE 3: SYSTEMS DESIGN Chapter 7 Data Design.
Systems Analysis and Design in a Changing World, Fifth Edition
Data Flow Diagrams (DFDs)
Chapter 6 The Traditional Approach to Requirements
Appendix 2 Automated Tools for Systems Development © 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 2 Slide 1.
Systems Analysis and Design in a Changing World, Fifth Edition
Lesson 7 Guide for Software Design Description (SDD)
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
Managing the development and purchase of information systems (Part 1)
Phase 2: Systems Analysis
Data Flow Diagram A method used to analyze a system in a structured way Used during: Analysis stage: to describe the current system Design stage: to describe.
Week 5: Business Processes and Process Modeling MIS 2101: Management Information Systems.
Chapter 7 Structuring System Process Requirements
Chapter 7 Using Data Flow Diagrams
SYSTEMS ANALYSIS AND DESIGN TOOLS DATA FLOW DIAGRAMS.
5 - 1 Copyright © 2006, The McGraw-Hill Companies, Inc. All rights reserved.
Chapter 4 enterprise modeling
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
Chapter 4 Automated Tools for Systems Development Modern Systems Analysis and Design Third Edition 4.1.
Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Systems Analysis and Design 8th Edition
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Systems Analysis and Design 8th Edition
1Lecture 8 Introduction to Systems Analysis l Objectives –Explain how systems analysis relates to business needs, problems, and opportunities –List and.
Systems Design.  Application Design  User Interface Design  Database Design.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
NURHALIMA 1. Identify the trade-offs when using CASE Describe organizational forces for and against adoption of CASE tools Describe the role of CASE tools.
© 2005 by Prentice Hall Chapter 7 Structuring System Process Requirements Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
SYSTEMS ANALYSIS AND DESIGN ITDB 2101 HAND OUT # 3 1.
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
Appendix 2 Automated Tools for Systems Development
Process Modeling Graphically represent the processes that capture, manipulate, store, and distribute data between a system and its environment Models DFDs.
Modern Systems Analysis and Design Third Edition
Business System Development
IS 334 information systems analysis and design
Problem Solving How do we attack a large problem?
Modern Systems Analysis and Design Third Edition
Tools of Software Development
Modern Systems Analysis and Design Third Edition
Modern Systems Analysis and Design Third Edition
Chapter 7: Data Flow Diagram Structuring System Process Requirements
Modern Systems Analysis and Design Third Edition
Lecture 23 CS 507.
Presentation transcript:

Systems Analysis – Analyzing Requirements

 Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team responsibility to ensure the new system serve the needs of org  Determining accurate user needs and system requirement is important because the design of new system is based on these requirements

Structured analysis, a dominant technique for documenting user requirements It provides methods to analysts for analyzing, organizing, controlling and documenting large complex IS Structured analysis is appropriate for business IS because these systems are predominantly data-driven systems To document IS data and data transformation, structured analysis uses Data Flow Diagram

Description of system problems and solutions are written in narrative form Graphic presentations may be used to enhance the problem description Data flow diagram is a graphic presentation of external entities, data movement, processing functions and data stores necessary to support an IS DFD is popularized using structured analysis and design approach The purpose of diagramming is that any person would be able to understand the system by just looking at the diagram

Four symbols used in DFD (Yourdon symbols): – A circle Indicate some process or transformation of data Process shows what a system does Each process has data input and output A process name should consist of one single phrase and should define a specific action rather than general process The name and number appear inside the circle – A pair of parallel lines To indicate data store Process can enter data or retrieve data from data store

A rectangle  To indicate external entity  Entity – person, department, system or org out of the system  The system interacts with these entities An arrow  Indicate flow of data  Arrow pointing to a data store indicates writing or updating to data store  Arrow coming out of data store shows reading process

DFD are organized hierarchically There is a master DFD (context DFD) followed by subDFD Context DFD – First diagram that displays the least amount of detail – Used to identify system boundary and its relationship to the entities – Has only one process labeled with the system’s name – The entities that interact with the system are shown with their labeled data flows – No data stores are shown

Context DFD show system in general, therefore there is a need to “explode” into other DFD Intermediate DFD will show the sequence of processes done by the system together with data stores accessed by the processes Each process is given number depicting their sequence of occurrence An important characteristics of all DFD: anything represented on the previous level must also be represented on all levels that follow All entities in context DFD must also appear on all levels that follow

It is not a good idea to include all details in one DFD because it would be too large It would be too large that it would be difficult to understand and the DFD then no longer serve as a comm tool This is why the context level DFD needs to “explode” into intermediate DFD The processes must be numbered to show sequence in which they are being performed The process name should define a specific action rather than a general process

 Data stores not shown in context DFD are drawn in intermediate DFD  When naming a data store, use specific names and avoid general terms  The DFD does not indicate which media the data are being stored

What is a good DFD? – The word in the process symbol in the context DFD is the name of the system – Context DFD should possess one process symbol only – Data store symbols should not appear in the context DFD – The first word in the process symbol in intermediate DFD must begin with a verb followed by a descriptive noun

– Processes must be numbered – Label clearly all data flows, entities, data stores and processes. No need to label data flows from process to process but it is a good practice to do so – The arrow direction for the data flows must be correct – Crossing of lines will not be allowed. You are to duplicate entities and data stores where necessary – No incorrect connections

 Characteristics of good diagrams Should be graphical with supporting textual detail Should allow the system to be viewed top-down, partitioned fashion Should have minimal redundancy

Two technologies offering increase in productivity of IS dev are – Computer aided software engineering (CASE) – Object-oriented development technology CASE assist IS dev team in planning, analyzing, designing, programming and maintaining IS The principal advantage of CASE is that it offers an integrated packages of capabilities for several of these tasks

CASE provides automatic assistance for checking the consistency and completeness of the system The availability of this info makes it easier to introduce modifications in a consistent manner at any time during dev or maintenance phase CASE provides good platform for quick app dev through prototyping. It helps to dev hierarchy of menus for the user interface and specify screens and reports all done in consultation with the users of the system

 Prototyping tools include report writers, query languages, screen generators and 4GL  A report writer is a nonprocedural language for producing reports from data in a data base  A query language is a nonprocedural language for retrieving, sorting adding and presenting data from a database  a screen generator is a software for generating and maintaining display and data entry for screen forms  A program generator is a software toll that generates a second or third language program  4GL has both procedural and nonprocedural features allowing programmers to write programs faster and accurately

A central repository stores, analyzes, updates and reports on the info about the system. The central repository can be used to analyze the DFD for balance and also print a report of the DFD Command can be issued to delete components of DFD or manipulate the positions of the components Processes can be expanded into lower level DFD

A data design tool will assist in design phase to model files and database CASE will maintain Entity Relationship Diagram (ERD) of the system Tools will make up the various input modes An evaluation mode is available to check models for consistencies or to suggest changes A reporting mode is used to produce listings and describe the model object sets and attributes to draw ERD A generation mode will help create database definitions from the model

The user input the ERD by entering all known attributes as a volume input ERD itself will be drawn by entering the entity and the relationship sets and adding attributes to them The modeling tool guides the user towards developing a model A programming tool will assist in writing out the programs which include code generators, program debuggers and testing modules A project mgt tool assists in scheduling the IS project

CASE contribute to improving maintenance of IS The use of CASE during early task means better documented systems in repository and thus easy to maintain It is possible to trace a user request for an enhancement from DFD to program coding modules and determine the impact of changes CASE makes it possible to maintain system specification as they are changed during maintenance

 CASE is a complex technology requiring learning  The complexity of CASE and lack of integrated support limited the adoption  CASE tools make systems dev team better and more effective but they are not a substitute  Skills and experience cannot be automated

Management together with system steering committee will review the analysis report The review is to determine if work on the proposed system should proceed to the next phase The problems identified and solutions to overcome will be documented in the systems analysis report together with the diagrams used to document the existing system You may also need to present the analysis findings