Class Notes (838,414)
Canada (510,882)
York University (35,470)
ITEC 3010 (26)
all (20)

lecture_5 notes.doc

8 Pages
Unlock Document

Information Technology
ITEC 3010
All Professors

Systems Analysis and Design I ITEC3010 – Fall 2010 – Luiz Cysneiros Lecture 5 – Modeling System Requirements: Events and Things – Oct 19 Models and Modeling - A model: a representation of some aspect of the system being built - A variety of models o Many are graphical (e.g. Data flow diagram, ER diagram) o Can show different levels of detail o Some focus on data o Some focus on processing - Purpose: creating a model can help clarify and refine the design o Developing the model raises questions that need to be considered o Models help to simplify complex aspects of systems Reasons for Modeling - Learning from the modeling process o New pieces are found to be needed o New questions arise that need to be answered to complete the model - Reducing complexity by abstraction o Systems can be complex and intangible o Models of parts of the system help to clarify and focus on important aspects - Remembering all of the details o Models are a way of storing information for later use in a form that can be digested (e.g. A picture can say a lot) - Communicating with other development team members o Can show others aspects of the system in a succinct way o Support communication – e.g. someone working on inputs and outputs can use the model to communicate with someone working on processing details - Communicating with a variety of users and stakeholders o Users need to see clear and complete models to understand what the analyst is proposing o Users often work with analyst to create models (this process can help users better understand what the system can do) - Documenting what was done for future maintenance/enhancement o Critical development team leaves behind a record of what was created o Need to package everything in a form future developers can understand and use when they modify and update the system o Much of the documentation consists of models (e.g. diagrammatic) as text mentions – also much of documentation also consists of textual reports Types of Models - Mathematical model: a series of formulas that describe technical aspects of a system o Comfortable for scientific or engineering applications o Sometimes used in business systems – e.g. simple formula for payroll where you model gross pay as regular pay plus overtime pay - Descriptive model: narrative memos, reports, or lists that describe some aspect of the system o E.g. might jot down notes from interviewing a user o Users may describe what they do in reports or memos o Analyst can then convert these descriptions to a modeling notation - Sometimes narratives are the best way for recording information - Simple lists of features, inputs, outputs, events or users are examples - A very important form of narrative model: writing a procedure in a very precise way – structured English or pseudocode - Pseudocode used a lot by programmers, can also be used to describe procedures during earlier phases o Example of Pseudocode description of a payroll function:  Input the employees payroll data  If hours worked is greater than 40 then calculate overtime pay  Calculate gross pay for the employee - Gross Pay = hourly pay times 40 plus overtime  Calculate tax for the employee ETC. - Graphical Model: diagrams and schematic representations of some aspect of a system o Easy to understand complex relationships (old saying: a picture is worth a thousand words) o Graphical models may look similar to a real-world part of the system (e.g. a screen design or report layout) o But often represent more abstract things, e.g. processes, data, objects, messages, connections o Key graphical models tend to represent abstract aspects of a system during Analysis Phase o The more concrete models (e.g. screen design) tend to appear later in the Design Phase Notes on Graphical Models - Many different types and formats - Variations in notation - However, still based on basic symbols o Circle o Square o Rectangle o Line Models Used in the Analysis Phase - The analysis phase named “Define System Requirements” involves creating models o Logical models (define what is required without committing to one specific technology) - Many different types of formalisms for defining logical models Models used in the Design Phase - These are physical models – since will be implemented with a specific technology - Some are extensions of requirements models created during systems analysis - Some may be used during both analysis and design (e.g. object-oriented class diagram) Events and System Requirements - Two key concepts to model: o Events o Things - Event – an occurrence at a specific time and place, that can be described and is worth remembering o E.g. customer placing an order, shipping identifies a backorder, nuclear reactor goes to meltdown - When defining system requirements it is useful to begin by asking what events occur that will affect the system being studied o What events will occur that the system will have to respond to? o Allows you to focus on external environment to keep you at high level view of system (not the workings of it) - Also allows you to focus on the interfaces of the system to outside people and systems - End users can easily describe system needs in terms of events that affect their work, very useful when working with users - Gives a way to divide (or decompose) the system requirements so you can study each separately (complex systems need to be decomposed based on events) Background to Event Concept - Structured analysis adapted to real-time systems in the early 1980’s o E.g. process control system, reactors, aerospace etc. o Events like “chemical vat is full”, “boiler overflowing” o System must respond to these types of events immediately o Extended to business applications since they have become more interactive Types of Events - External event o An event that occurs outside the system o Usually initiated by an external agent or actor (a person or organization that supplies or receives data from the system) – can also be another software !! o Classic example of an external agent: a customer o Possible event: the customer wants to place an order o Naming events:  Include the external agent in the name  E.g. Events: “customer places order”, “management checks order status”,”customer reports change of address” - External Events Checklist o External agent wants something resulting in a transaction o External agent wants some information o Data changed needs to be updated o Management wants some information - Temporal Events o An event that occurs as a result of reaching a point in time o Could be reports to management generated regularly o System automatically produces reports etc. at right time (so no external agent needed) o E.g. Payroll systems produce a paycheck every two week (or once a month) - Temporal Events Checklist o Internal outputs needed  Management reports (summary or exception)  Operational reports (detailed transactions)  Statements, status reports (including payroll) o External outputs needed  Statements, status reports, bills, reminders - State Events o An event that occurs when something happens inside the system that triggers the need for processing o E.g. the sale of a product results in an adjustment in the inventory (event “Reorder point reached) o This state change might occur as a result of external events or to temporal events (so could be similar to temporal event, but point in time can’t be defined) Identifyin
More Less

Related notes for ITEC 3010

Log In


Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.