Understanding and Modeling a System
Thinking of a company as a system and understanding the business problems are keys to modeling a solution. We have to answer the question, Is this project worth looking at? To answer this question, in this phase, we define the scope of the project and the perceived problems, who is involved, and what the system will need to accomplish.
Your first team task this week is to describe the business and the business problem. How does the business system work? Who is involved, and what do they do? Using our massage example, we might find we have massage therapists, schedulers who answer the phone and make appointments, an accountant who does the billing, customers, and a manager. Business may be conducted at a central office and at customer homes. The business problem might be a lack of competitive advantage with other, more automated massage businesses or problems with missed or broken appointments or customers that do not pay for the service.
Next, the team will need to define the business requirements for an information system to solve the business problem. We put to work what we learned in our Week 1 readings.
Deliverables:
Statement of the Business Problem (System Request Form)
Business Requirements: Using Microsoft Visio and Microsoft Word or Excel, your team will need to create the following diagrams for your project. (Refer to the textbook for examples.)
Context Level Data Flow Diagram (Visio)
Use Case List (normal business activities/work flows)
Use Case Diagram (Visio)
Use Case Scenarios (Description or narrative of steps in each use case)
Part 2 of 5: Milestone 2-Due Week 3Back to Top
Before teams typically begin planning a project, they define the initial scope and seek permission to proceed with planning with a project charter. This week, your team needs to work together to complete a project charter for your project.
Deliverable:
Project Charter
(See Week 2 Lecture for Project Charter outline)
Part 3 of 5: Milestone 3-Due Week 5Back to Top
Every system has two perspectives that are reflected in the user requirements which are data and process. Any systems that exist will these two perspectives, among others, that must be addressed to build a quality application/system. In this milestone, you are creating diagrams for both the data model and process model perspectives to accurately capture the business requirements initiated in the milestones above.
Data modeling is a technique for organizing and documenting a system's data. Data modeling is sometimes called database modeling or database design because a data model is direct input into the implementation of the physical database, depending on the database platform for the organization. Data is viewed as a resource to be shared by as many processes as possible. As a result, data must be organized in a way that is flexible and adaptable to unanticipated business requirements, and that is the purpose of data modeling.
Process modeling is a technique for organizing and documenting a system's functionality. Keep in mind, data and processes/ business functions are derived from the analysis of the business requirements graphically captured in Milestone 1 and 2 deliverables above. The business functions will ultimately be translated into program code in the implementation phase of the SDLC, if we were to really build the application/system.
Notice, the process model is just another graphical approach to capturing the business functional requirements. The process model meets the same objective of creating the Use Case Diagram in the UML/object oriented analysis and design (OOAD) approach, but the symbols/syntax is slightly different given the specific objective of the two graphical approaches. You will be creating the remaining UML/OOAD diagrams to graphically capture additional requirements in the next milestone assignment.
Deliverables:
Milestone 3.1 (Data Model Diagrams - for database requirements - Week 5 Lecture)
Logical Entity Relationship Diagram (LERD) (Visio)
Physical Entity Relationship Diagram (PERD) (Visio)
Milestone 3.2 (Process Model Diagrams - for functional/process requirements - Week 4 Lecture)
Logical Data Flow Diagram (LDFD) (Visio)
Physical Data Flow Diagram (PDFD) (Visio)
Part 4 of 5: Milestone 4-Due Week 6Back to Top
This section will explore data modeling in an object-oriented development approach.
Deliverables:
UML Use Case Diagram (Visio)
UML Class Diagram (Visio)
UML Sequence Diagram (Visio)
Part 5 of 5: Final Project Paper-Due Week 7Back to Top
Now that we have defined and modeled the business requirements, the next task is to look at technical solutions. In this section, we will create three technical alternatives that meet business requirements and use feasibility analysis to decide which alternative best meets the needs of our customer. We will then describe the hardware, software, and database components required to meet the alternative, the architecture we propose, and the approximate costs for the project. All of this is done within the context of the system proposal outline, which consolidates all milestone deliverables in to one Final Project Paper.
Deliverables:
System Proposal (Final Project Paper)
Cover letter
Cover or title page of project
Table of contents
Executive summary (including recommendations)
Outline of system study (all milestone lab assignments)
Detailed results of the system study (deliverables from each milestone lab assignment)
System alternatives (Use system alternative assessment and feasibility matrix in Doc Sharing.)
System analysts' recommendation (Use system alternative assessment and feasibility matrix in Doc Sharing.)
Proposal summary (Summarize information into a PowerPoint presentation.)
Appendices (assorted documentation as needed)