ISOM221+Lecture+18+-+System+Design+I+with+Solutions

ISOM221+Lecture+18+-+System+Design+I+with+Solutions -...

Info iconThis preview shows pages 1–4. Sign up to view the full content.

View Full Document Right Arrow Icon
ISOM221 Information Systems Analysis and Design Lecture 18: System Design I (Design Strategies) 1 Agenda Understand two key aspects of system design Program design Architecture design evisit the concept of non nctional Revisit the concept of non-functional requirements Understand different design strategies Key Ideas The purpose of the analysis phase is to figure out what the business needs. The purpose of the design phase is to figure out how to rovide it provide it The steps in both analysis and design phases are highly interrelated and may require much “going back and forth” Moving Into Design Analysis phase Focus on business requirements, especially functional requirements (i.e., logical processes and data flows) Design phase Move from business requirements to system requirements Decide how to build the system Describe technical details for building the system Address non-functional requirements formally System specification Final deliverable from design phase Contains all the technical elements and conveys exactly what system the project team will implement during the implementation phase
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Technical Elements of Systems Functional Requirements Program Design defines how the final system will work and develops instructions for the programmers Data Storage Design defines how data is stored and handled by programs that run the system Non-functional Requirements Architecture Design determines how the system will be distributed across computers and what the hardware and software will be used for each computer Interface Design defines how the system will interact with external entities and exchange information with other systems Program Design Two different approaches to logically model system processes have been covered in this course, i.e., 1. Data flow diagram (DFD) 2. Use case modeling (use case diagram, class diagram, etc.) Regardless of which approach is used, the logical models need to be converted to design models to guide program development 1. Moving from Logical DFD to Physical DFD Analysis phase – focus on logical processes and data flows Design phase – create physical process models owing “how” the final system will work showing “how” the final system will work The physical DFD contains the same components as the logical DFD, and the same rules apply There are five steps to perform to make the transition to the physical DFD Steps to Create the Physical Data Flow Diagram
Background image of page 2
Sample Physical Data Flow Diagram 2. Evolving Analysis Models into Design Models Review the use cases and the current set of classes (i.e., analysis models) Are all the classes necessary?
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 4
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 10

ISOM221+Lecture+18+-+System+Design+I+with+Solutions -...

This preview shows document pages 1 - 4. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online