2 SAD_MIDTERMS_COMPLETE.pdf

1 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS SYSTEM BOUNDARY VS. AUTOMATION BOUNDARY WEEK 2: THE WORLD OF THE INFORMATION SYSTEMS ANALYST NATURE OF ANALYSIS AND DESIGN Systems Analysis - Process of understandin...

1 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS SYSTEM BOUNDARY VS. AUTOMATION BOUNDARY WEEK 2: THE WORLD OF THE INFORMATION SYSTEMS ANALYST NATURE OF ANALYSIS AND DESIGN Systems Analysis - Process of understanding in detail what a system should accomplish. Systems Design - Process of specifying in detail how components of an information system should be physically implemented. Systems Analyst - Uses analysis and design techniques to solve business problems using information technology TYPES OF INFORMATION SYSTEMS Transaction Processing System (Tps) SYSTEMS ANALYSIS AND DESIGN - Capture and record information about organization’s Systems analysis and design is a systematic approach to identifying transactions problems, opportunities, and objectives; analyzing the information flows in organizations; and designing computerized information Management Information System (Mis) systems to solve a problem. - Take information captured by TPS - Produce reports for planning and control SYSTEMS THAT SOLVE BUSINESS PROBLEMS Decision Support System/Knowledge-Based System (Dss/Kbs) System - Interrelated components functioning together to achieve - Explore impact of available options or decisions (what-if an outcome scenarios) - Automate routine decision making Information systems - Collection of interrelated components that collect, process, store, and provide as output information needed to complete tasks TYPES OF INFORMATION SYSTEMS cont'd Subsystem - Part of a larger system Office Automation Systems And Knowledge Work System Supersystem - Larger system that contains subsystems (Oas/Kws) Functional decomposition - Dividing a system into smaller - OAS support data workers subsystems and components - KWS support professional workers Artificial Intelligence And Expert Systems (Ai/Es) COMPONENTS OF AN INFORMATION SYSTEM - The general thrust of AI has been to develop machines that behave intelligently. - ES effectively captures and uses the knowledge of a human expert for solving a particular problem in an organization Group Decision Support System And Computer-Supported Collaborative Work Systems (Gdss/Cscws) - GDSS intends to bring the group together to solve a problem - CSCWS include software support called groupware Executive Support System (Ess) - Help executives organize their interactions with the external environment 2 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS OTHER TYPES OF INFORMATION SYSTEM QUALITIES OF A SYSTEMS ANALYST Problem-solver Communicator Strong personal and professional ethics Self-disciplined and self-motivated as an individual REQUIRED SKILLS OF THE SYSTEMS ANALYST WHAT KINDS OF PROBLEMS DOES AN ANALYST TYPICALLY SOLVE? INTEGRATING TECHNOLOGIES FOR SYSTEMS Customers want to order products any time of the day or E-commerce and Web Systems night. Enterprise Resource Planning Systems Production needs to plan very carefully the amount of each type of product to produce each week. Wireless Systems Open Source Software Suppliers want to minimize their inventory holding costs by shipping parts used in the manufacturing process in smaller daily batches INTEGRATING NEW TECHNOLOGIES INTO TRADITIONAL SYSTEMS WHAT KINDS OF PROBLEMS DOES AN ANALYST TYPICALLY SOLVE? cont'd Marketing wants to anticipate customer needs better by tracking purchasing patterns and buyer trends. Management continually wants to know the current financial picture of the company, including profit and loss, cash flow, and stock market forecasts. Employees demand more flexibility in their benefits programs, and management wants to build loyalty morale. ROLES OF THE SYSTEMS ANALYST THE ANALYST AS A BUSINESS PROBLEM SOLVER Systems analyst as Consultant Has computer technology knowledge and programming expertise Systems analyst as Supporting Expert Understands business problems Systems analyst as Agent of Change 3 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS Uses logical methods for solving problems Has fundamental curiosity WEEK 3: APPROACHES TO SYSTEMS DEVELOPMENT Wants to make things better THE SYSTEMS DEVELOPMENT LIFE CYCLE Is more of a business problem solver than a technical It is a systematic approach to solving business problems. It is divided programmer into seven phases, and each phase has unique activities. ANALYST’S APPROACH TO PROBLEM SOLVING ACTIVITIES OF EACH SDLC PHASE 1. Identifying Problems, Opportunities, and Objectives (known as Planning) The very first stage of SDLC is initial planning. The phase includes aspects of both project management and product management, such as: o Scheduling o Capacity planning o Material and human resource allocation o Cost estimation o Provisioning 2. Determining Human Information Requirement (Analysis) Stakeholders and managers must collaborate with the IT team to communicate their requirements for new development and enhancement. The deliverables at this stage include: o A document that lists all requirements (in Waterfall). o A backlog of tasks to be performed (in Agile). 3. Design and Prototyping (Design) After defining requirements, developers and software architects start to design the software. Developers apply established software development patterns to solve algorithmic problems. 4. Software Development (Development) This step is actually about the software under development. By the defined development methodology, the work can be conducted in: o Time-boxed Sprints (Agile) o A single block of effort (Waterfall) 4 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS 5. Testing This Spiral model is a combination of the iterative development This stage is one of the most important in the software process model and the sequential linear development model (i.e., development life cycle, as there is no way to deliver high- the waterfall model) with a very high emphasis on risk analysis. quality software without testing. The variety of testing It allows incremental releases of the product or incremental procedures necessary to measure quality includes: development of prototypes through each iteration around the o Code quality review spiral. o Unit testing o Integration testing ITERATIVE METHOD o Performance testing o Security testing 6. Deployment It is quite logical to guess that this stage must require maximum attention to detail. However, this phase is highly automated. It can be almost invisible because the software is deployed the moment it is ready. In the Iterative model, the iterative process starts with a simple implementation of a small set of the software requirements and 7. Operations and Maintenance iteratively enhances the evolving versions until the complete system It might seem that this is already a happy end. However, is implemented and ready to be deployed. the operations and maintenance phase is rather important too. The software development life cycle does An iterative life cycle model does not attempt to start with a full not end with the software rollout. specification of requirements. Instead, development begins by specifying and implementing just part of the software, which is then reviewed to identify further requirements. METHODOLOGIES, MODELS, TOOLS, AND TECHNIQUES IN SYSTEM DEVELOPMENT INCREMENTAL METHOD WATERFALL METHOD First introduced by Dr. Winston W. Royce in a paper published in 1970, the waterfall model is a software development process. The The incremental model is a process of software development where waterfall model emphasizes that a logical progression of steps be requirements are broken down into multiple standalone modules of taken throughout the software development life cycle (SDLC), much the software development cycle. Incremental development is done like the cascading steps down an incremental waterfall. in steps from analysis, design, implementation, testing/verification, and maintenance. SPIRAL METHOD RAPID APPLICATION DEVELOPMENT (RAD) Describes a method of software development that heavily emphasizes rapid prototyping and iterative delivery. The RAD model is, therefore, a sharp alternative to the typical waterfall 5 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS development model, which often focuses largely on planning and sequential design practices. CURRENT TRENDS IN SYSTEM DEVELOPMENT Software/System Development trends in 2020 according to AGILE MODELING outsystems.com: 1. AI-Assisted Development 2. AI for Applications 3. Robotic Process Automation 4. Progressive Web Apps 5. Continuous Integration and Delivery 6. Rapid Prototyping and Innovation The agile SDLC model is a combination of iterative and incremental 7. Digital Transformation Enablers process models with a focus on process adaptability and customer 8. Low-Code Development satisfaction by rapid delivery of a working software product. 9. "Future-Proof" Applications Agile Methods break the product into small incremental builds. These builds are provided in iterations. The agile method anticipates 10. New Dual Speed Development change and allows for much more flexibility than traditional methods. METHODOLOGIES AND MODELS Methodologies Methodologies are the comprehensive guidelines to follow for completing every SDLC activity. It is a collection of models, tools, and techniques. Models Models are a representation of an important aspect of the real world, but not the same as the real thing. An abstraction is used to separate aspects, diagrams, and charts. Also used in project planning and budgeting aids. The following are some models of system components: Flowchart Data Flow Diagram (DFD) Entity-relationship Diagram (ERD) Use Case Diagram Class Diagram Some models used to manage the development process: PERT Chart Gantt Chart Organizational Hierarchy Chart Financial Analysis Models – NPV, ROI 6 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS External Responsibilities WEEK 4-5: APPROACHES TO SYSTEMS DEVELOPMENT WHAT IS PROJECT MANAGEMENT? Project management is the process of planning and controlling the development of a system within a specified time frame, at a minimum cost, with the right functionality. In general, a project is a set of activities with a starting point and an ending point meant to create a system that brings value to the VARIOUS TITLES/ROLES OF A PROJECT MANAGER business. ELEMENTS OF PROJECT MANAGEMENT The five major project management fundamentals that the systems analyst must handle are: 1. Project Initiation — Defining the problem. 2. Determining Project Feasibility 3. Activity Planning and Control 4. Project Scheduling PROJECT INITIATION AND PROJECT PLANNING 5. Managing Systems Analysis Team Members Determine what are the problems in the organization: Problems that lend themselves to system solutions. Determine what are the opportunities for improvement: WHAT IS A PROJECT MANAGER? Caused through upgrading, altering, or installing new systems. A project manager has the primary responsibility for managing the Checking output, observing employee behavior, and listening to hundreds of tasks and roles that need to be carefully coordinated. feedback are all ways to help the analyst pinpoint system problems and opportunities. Today, project management is an actual profession, and analysts spend years working on projects before tackling the management of them. However, in many cases, unreasonable demands set by IDENTIFYING THE PROBLEMS project sponsors and business managers can make project The following information can describe how you will identify the management very difficult. problems through a specific sign: RESPONSIBILITIES OF A PROJECT MANAGER Responsibilities are both internal and external. Internal Responsibilities 7 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS ACTIVITIES OF THE PROJECT PLANNING PHASE PERT/CPM CHART A PERT chart is a project management tool that provides a graphical representation of a project's timeline. The Program Evaluation Review Technique (PERT) breaks down the individual tasks of a project for analysis. DEFINING THE PROBLEM Problem Statement A paragraph or two stating the problem or opportunity. Issues Independent pieces pertaining to the problem or opportunity. Objectives Goals that match the issues point-by-point. SAMPLE SCHEDULE Requirements The things that must be accomplished along with the possible solutions and constraints that limit the development of the system. Use the problem definition to create a preliminary test plan. PROBLEM DEFINITION STEPS Find a number of points that may be included in one issue. State the objective. SAMPLE PERT DIAGRAM Determine the relative importance of the issues of objectives that are most critical. PRODUCING THE PROJECT SCHEDULE Develop Work Breakdown Structure (WBS) List of tasks and duration required for the project. Similar to an outline for a research paper. WBS is the foundation for the project schedule. Build a PERT/CPM Chart Assists in assigning tasks. Critical path method. Gantt Chart and Tracking Gantt Chart. 8 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS SAMPLE GANTT CHART o Calculate using the table of costs and benefits. Uses net present value (NPV), payback period, and return on investment (ROI) techniques. ORGANIZATIONAL AND CULTURAL FEASIBILITY Organizational feasibility focuses on how well a proposed information system supports the objective of the organization and its strategic plan for an information system. Each company has its own culture. o The new system must fit into the culture. CONFIRMING PROJECT FEASIBILITY Evaluate related issues for potential risks: Risk Management o Low level of computer competency Economic Feasibility o Computer phobia o Cost-Benefit Analysis o Perceived loss of control o Sources of funds (cash flow, long-term capital) o Shift in power Organizational and Cultural Feasibility o Fear of job damage or employment loss Technological Feasibility o Reversal of established work procedures Schedule Feasibility Resource Feasibility TECHNOLOGICAL FEASIBILITY It is established when the company has completed a detailed RISK MANAGEMENT program design and has determined that a product can be produced to meet its design specifications, including functions, features, and Is the process of identifying, assessing and controlling threats to an technical performance requirements. organization's capital and earnings. Does the system stretch the state-of-the-art technology? Does in-house expertise presently exist for development? Does an outside vendor need to be involved? Solutions include: o Training or hiring more experienced employees. Risk management is the process of identifying, assessing and o Hiring consultants. controlling threats to an organization's capital and earnings. These threats, or risks, could stem from a wide variety of sources, including o Changing the scope and project approach. financial uncertainty, legal liabilities, strategic management errors, accidents and natural disasters. SCHEDULE FEASIBILITY It is the degree to which a deadline for a strategy, plan, project, or ECONOMIC FEASIBILITY process is realistic and achievable. It is a kind of cost-benefit analysis of the examined project, which assesses whether it is possible to implement it. Estimates are needed without complete information. Cost/Benefit Analysis Management deadlines may not be realistic. o Estimate project development costs. Project managers should: o Estimate operational costs after the project. o Drive realistic assumptions and estimates. o Estimate financial benefits based on annual o Recommend completion date flexibility. savings and increased revenues. 9 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS o Assign interim milestones to periodically reassess completion dates. WEEK 6: INVESTIGATING SYSTEM REQUIREMENTS o Involve experienced personnel. o Manage the proper allocation of resources. THE ANALYSIS PHASE IN MORE DETAIL Gather information RESOURCE FEASIBILITY Define system requirements This aspect looks at the resources that are required to complete the project and whether the available resources are sufficient to o Functional and nonfunctional complete the project effectively. Prioritize requirements Team member availability. Prototype for feasibility and discovery Team skill levels. Generate and evaluate alternatives Computers, equipment, and supplies. Review recommendations with management Support staff time and availability. Physical facilities. STAFFING THE PROJECT Putting together the project team is a vital part of making a project successful. Therefore you should: Develop resource plan for the project Identify and request specific technical staff ACTIVITIES OF THE ANALYSIS PHASE AND THEIR KEY QUESTIONS Identify and request specific user staff Organize the project team into workgroups Conduct preliminary training and team building exercises Key staffing question: “Are the resources available, trained and ready to start?” LAUNCHING THE PROJECT Scope defined, risks identified, project is feasible, schedule developed, team members identified and ready. BUSINESS PROCESS REENGINEERING AND ANALYSIS Oversight committee finalized, meet to give the go-ahead, Fundamental strategic approach to organizing the and released funds. company Formal announcement made to all involved parties within Streamlines internal processes to be as efficient and the organization. effective as possible Key launch question: “Are we ready to start?” Questions basic assumptions for doing business and seeks to find a better way Uses IT as a BPR enabler Systems analyst may discover opportunities for process improvement Any project may include components of BPR 10 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS o Management users need summary information o Executive users need strategic information FUNCTIONAL AND NONFUNCTIONAL SYSTEM REQUIREMENTS o External users may have access to the system New system capabilities and constraints Functional requirements TECHNIQUES FOR INFORMATION GATHERING Activities system must perform (use cases) Analysis phase done to understand business functions and develop system requirements Based on procedures and business functions Original structured approach Documented in analysis models o Create a model of the existing system Nonfunctional requirements o Derive requirements from the existing system Technical environment or performance objectives model Usability, reliability, and security requirements Current approach o Identify logical requirements for the new system ZACHMAN FRAMEWORK FOR ENTERPRISE ARCHITECTURE o Balance the review of current business functions with new system requirements STAKEHOLDERS—THE SOURCE OF SYSTEM REQUIREMENTS Relationship Between Information Gathering and Model Building People with an interest in successful system implementation Three primary groups of stakeholders: o Users (use the system) o Clients (pay for and own the system) o Technical staff (ensure system operation) TECHNIQUES FOR INFORMATION GATHERING Every type of stakeholder is identified by the analyst Characteristics For Successful Requirements Determination Question everything MORE ON USERS AS STAKEHOLDERS Be impartial Horizontal user roles – information flow across departments Assume anything is possible Vertical user roles – information needs of clerical staff, Pay attention to details middle management, and senior executives Reframe o Business users perform day-to-day operations o Information users need current information 11 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS TECHNIQUES FOR INFORMATION GATHERING TECHNIQUES FOR INFORMATION GATHERING Sampling Sample Checklist To Prepare For User Interviews Sampling is the process of systematically selecting representative elements of a population. We use sampling to make assumptions about the population as a whole. We sample to: o Contain costs o Speed up data gathering o Improve effectiveness o Reduce bias TECHNIQUES FOR INFORMATION GATHERING Fact-Finding Methods Review existing reports, forms, and procedure descriptions TECHNIQUES FOR INFORMATION GATHERING Interview and discuss processes with users Interviewing Observe and document business processes Planning the Interview Build prototypes Conducting the Interview Distribute and collect questionnaires Writing the Interview Report Conduct joint application design (JAD) sessions Joint Application Design (JAD) Research vendor solutions TECHNIQUES FOR INFORMATION GATHERING TECHNIQUES FOR INFORMATION GATHERING Question Types – Open-Ended Questions Conduct Interviews And Discussions With Users Benefits Effective way to understand business functions and rules o Interviewee at ease Time-consuming and resource-intensive o Uses interviewee vocabulary May require multiple sessions to: o Detail o Meet all users o Generates new questions o Understand all processing requirements o More interesting for the interviewee Can meet with individuals or groups of users o More spontaneity List of detailed questions prepared o Phrasing is easier for the interviewee o Could be used when not fully prepared Drawbacks o May result in too much detail o Possibly lose control of the interview o Responses may take too much time o Appears unprepared 12 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS o Appears that objectives are lacking o Easy, non-threatening way to start the interview o Useful when the interviewee is emotional about the topic TECHNIQUES FOR INFORMATION GATHERING Diamond-shaped Structure Question Types – Closed-Ended Questions o Uses a combination of the two approaches Benefits above o Interviewee at ease o Combines strengths of two approaches o Use interviewee vocabulary o Takes longer o Detail o Keeps interviewee’s interest by using a variety of o Generate new questions questions o More interesting for interviewee o More spontaneity TECHNIQUES FOR INFORMATION GATHERING o Phrasing is easier for interviewee Making A Record Of The Interview o Could use them when not prepared Making an Audio Recording Drawbacks o Provides an accurate record o May result in too much detail o You can listen and respond more rapidly o Possibly lose control of interview o Allows better eye contact o Response may take too much time o Allows replay o Appear unprepared o Can make interviewees nervous o Appear that objectives are lacking o Difficult to locate messages on long tapes o Cost (need to transcribe tapes) TECHNIQUES FOR INFORMATION GATHERING Note-taking Question Types – Probes o Keeps the interviewer alert Follow-up question o Shows interest in the interview Used to get more meaning out of an answer o Demonstrates preparedness o Lose vital eye contact Can be either open or closed-ended questions o Interviewees stop when notes are taken Indicates that you are listening o Cause attention to facts and little attention to feelings and opinions TECHNIQUES FOR INFORMATION GATHERING Arranging Questions TECHNIQUES FOR INFORMATION GATHERING Pyramid Structure Writing The Interview Report o Open with a specific question and close with a Write the report as soon as possible after the interview general one Note the main points of the interview and your own o Used to warm up the interviewee opinions o Ideal for reluctant interviewees Review the report with the respondent at a follow-up Funnel Structure meeting o Open with a general question and close with a specific one 13 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS TECHNIQUES FOR INFORMATION GATHERING Flowchart Basic Symbols Observe And Document Business Processes Varies from office walkthroughs to performing actual tasks Not necessary to observe all processes at the same level of detail May make users nervous, so use common sense Can document workflows with UML activity diagrams VALIDATING THE REQUIREMENTS Make sure gathered information is correct Structured walkthrough Flowchart Example o Effective means of implementing quality control early in the project o Verifies and validates system requirements o Review of findings from investigation and of models based on findings Project manager responsible for system quality o Systems analyst and project manager are partners FLOWCHARTING REVIEW WHAT IS A FLOWCHART? A flowchart is a diagram that depicts a process, system, or computer algorithm. They are widely used in multiple fields to document, study, plan, improve and communicate often complex processes in clear, easy-to-understand diagrams. A flowchart is simply a graphical representation of steps. It shows steps in sequential order and is widely used in presenting the flow of algorithms, workflow or processes. Typically, a flowchart shows the steps as boxes of various kinds and their order by connecting them with arrows. 14 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS WEEK 7: MODELING SYSTEM REQUIREMENTS MODELS AND MODELING Analyst describes information system requirements using a collection of models Complex systems require more than one type of model Models represent some aspect of the system being built Process of creating models helps the analyst clarify and refine design Models assist communication with system users TYPES OF MODELS Different types of models are used in information systems development: Mathematical – formulas that describe technical aspects of the system (i.e., reorder quantity) Descriptive – narrative memos, reports, or lists that describe aspects of the system Graphical – diagrams and schematic representations of some aspect of the system OVERVIEW OF MODELS USED IN ANALYSIS AND DESIGN Analysis phase: “Define system requirements” Logical models Provide detail without regard to specific technology Design phase: Physical models Provide technical details Extend logical models MODELS CREATED BY ANALYSIS ACTIVITIES 15 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS MODELS USED IN DESIGN USE CASE EXAMPLE USE CASE DIAGRAM Use Case ENTITY-RELATIONSHIP DIAGRAM An entity-relationship diagram (ERD) shows the relationships of An activity the system performs in response to a user entity sets stored in a database. An entity in this context is an object request. or a component of data. A “case” where the system is used by an actor. The major activity of this phase is identifying entities, attributes, and Techniques for identifying use cases: their relationships to construct a model using the Entity Relationship Identify user goals Diagram. o Each goal at the elementary business process Entity → Table (EBP) level is a use case Attribute → Column o EBP – a task performed by one user, in one place Relationship → Line in response to a business event, that adds measurable business value, and leaves system and data in a consistent state Event decomposition technique CRUD analysis technique (create, read, update, delete) USE CASE EXAMPLE RELATIONSHIPS NATURALLY OCCUR BETWEEN THINGS USE CASES DIAGRAM HOW TO FIND ENTITIES? Entity: o "...anything (people, places, objects, events, etc.) about which we store information (e.g., supplier, machine tool, employee, utility pole, airline seat, etc.)" o Tangible: customer, product o Intangible: order, accounting receivable 16 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS Three basic cardinalities (degrees of relationship). One-to-one (1:1), One-to-many (1), Many-to-many (M:N) ENTITY INSTANCE Entity Instance: A single occurrence of an entity. IDENTIFIER “Attributes that uniquely identify entity instances.” Becomes a PK (primary key) in the relational database system (RDS). Composite identifiers consist of two or more attributes. Identifiers are represented by underlining the name of the attribute(s). o Employee (Employee_ID), Student (Student_ID) CROW’S FOOT NOTATION HOW TO FIND ATTRIBUTES? Also known as IE notation (most popular) Attribute: Entity: Attributes are data objects that either identify or describe entities (property of an entity). Represented by a rectangle, with its name on the top. The In other words, it is a descriptor whose values are name is singular (entity) rather than plural (entities). associated with individual entities of a specific entity type o The process for identifying attributes is similar except now you want to look for and extract those names that appear to be descriptive noun phrases. HOW TO FIND RELATIONSHIPS? Relationship: CROW’S FOOT NOTATION Relationships are associations between entities. Typically, a relationship is indicated by a verb connecting two or more entities. Employees are assigned to projects Relationships should be classified in terms of cardinality. o one-to-one, one-to-many, etc. ATTRIBUTES Identifiers are represented by underlining the name of the attribute(s). HOW TO FIND CARDINALITIES? Cardinality: The cardinality is the number of occurrences in one entity which are associated to the number of occurrences in another. 17 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS BASIC CARDINALITY TYPE EXAMPLE MODEL DATA MODEL BY PETER CHEN’S NOTATION (FIRST - ORIGINAL) CARDINALITY 18 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS Actor WEEK 8: THE OBJECT-ORIENTED APPROACH TO REQUIREMENTS Role played by the user. Outside automation boundary. OBJECT-ORIENTED REQUIREMENTS Object-oriented modeling notation is Unified Modeling SIMPLE USE CASE WITH AN ACTOR Language (UML 2.0). UML was accepted by Object Management Group (OMG) as a standard modeling technique. Purpose of Object Management Group: o Promote theory and practice of object-oriented technology for development of distributed systems. o Provide a common architectural framework for OO. USE CASE DIAGRAM WITH AUTOMATION BOUNDARY AND ALTERNATE ACTOR NOTATION OBJECT-ORIENTED REQUIREMENTS CONT'D Object-oriented system requirements are specified and documented through the process of building models. The modeling process starts with the identification of use cases and problem domain classes (things in users’ work environment). Business events trigger elementary business processes (EBP) that the new system must address as use cases. Use cases define functional requirements. ALL USE CASES INVOLVING CUSTOMER AS ACTOR OBJECT-ORIENTED REQUIREMENTS MODELS Use case diagrams – identify actors and their use cases (goals). Use case descriptions – include details of a use case and how actors use the system. Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case. Activity diagrams – describe user and system activities for a use case. USE CASES OF ORDER ENTRY SUBSYSTEM State machine diagrams – describe states of each object. THE SYSTEM ACTIVITIES— A USE CASE/SCENARIO VIEW Use case analysis is used to identify and define all business processes that the system must support. Use case – an activity a system carries out, usually in response to a user request. 19 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS USE CASE RELATIONSHIP BRIEF DESCRIPTION OF CREATE NEW ORDER USE CASE Documents a situation in which one use case requires the services of a common subroutine. Another use case is developed for this common subroutine. A common use case can be reused by multiple use cases. INTERMEDIATE DESCRIPTION OF THE WEB ORDER SCENARIO FOR EXAMPLE OF ORDER-ENTRY SUBSYSTEM WITH USE CREATE NEW ORDER CASES CRUD ANALYSIS FOR IDENTIFYING/CONFIRMING USE CASES FULLY DEVELOPED DESCRIPTION OF TELEPHONE ORDER SCENARIO FOR CREATE NEW ORDER USE CASE CRUD – create, read/report, update, delete. Information Engineering (IE) technique to identify an event table or directly develop a use case diagram. Compares identified use cases with the domain model class diagram. Every class in the class diagram must have use cases to support creating, reading, reporting, updating, and deleting object instances. Confirms system integration requirements. USE CASE DESCRIPTION A use case description provides details of preconditions, postconditions, sequence of activities, and exception conditions in the use case. Describes an actor interacting with the computer system step-by-step to carry out a business activity. May have several scenarios for a use case, each being a specific use case instance. Three levels of detail: brief, intermediate, and fully developed description. Many analysts prefer to write narrative descriptions of use cases instead of drawing activity diagrams. 20 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS TOP DETAIL FROM FULLY DEVELOPED USE CASE DESCRIPTION Used to model input and output messaging requirements for a use case or scenario. Shows the actor interacting with the system. Shows the sequence of interactions as messages during the flow of activities. The system is shown as one object: a “black box.” SYSTEM SEQUENCE DIAGRAM (SSD) NOTATION MIDDLE DETAIL FROM FULLY DEVELOPED USE CASE DESCRIPTION BOTTOM DETAIL FROM FULLY DEVELOPED USE CASE DESCRIPTION SSD NOTATION Actor represented by a stick figure – a person (or role) that interacts with the system by entering input data and receiving output data. Object is a rectangle with the name of the object underlined – shows an individual object and not a class of all similar objects (for SSD). Lifeline or object lifeline is a vertical line under an object or USE CASE DESCRIPTION COMPONENTS actor to show the passage of time for the object. Use case name/scenario name. Message is labeled on arrows to show messages sent to or received by the actor or system. Actors/stakeholders. Related use cases. SSD LIFELINES Preconditions – set of criteria that must be true prior to initiation of the use case. Vertical line under the object or actor. Postconditions – set of criteria that must be true upon Shows the passage of time. completion of the use case. If vertical line dashed: Flow of activities (steps in one column or two). o Creation and destruction of the thing is not Exception conditions. important for the scenario. o Long narrow rectangles. IDENTIFYING INPUTS AND OUTPUTS— THE SYSTEM SEQUENCE o Activation lifelines emphasize that the object is DIAGRAM active only during part of the scenario. System sequence diagram (SSD) is a type of UML 2.0 interaction diagram. 21 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS SSD MESSAGES SSD OF THE WEB ORDER SCENARIO FOR THE CREATE NEW ORDER USE CASE Internal events identified by the flow of objects in a scenario. Requests from one actor or object to another to perform some action. Invokes a particular method. REPEATING MESSAGE IDENTIFYING OBJECT BEHAVIOR— THE STATE MACHINE DIAGRAM A state machine diagram is a UML 2.0 diagram that models object states and transitions. o Complex problem domain classes can be DEVELOPING A SYSTEM SEQUENCE DIAGRAM modeled. Begin with a detailed description of the use case from a State of an object: fully developed form or activity diagram. o A condition that occurs during its life when it Identify input messages. satisfies some criteria, performs some action, or waits for an event. Describe the message from the external actor to the o Each state has a unique name and is a system using message notation. semipermanent condition or status. Identify and add any special conditions on input messages, Transition including iteration and true/false conditions. o The movement of an object from one state to Identify and add output return messages. another state. ACTIVITY DIAGRAM AND RESULTING SSD FOR TELEPHONE ORDER SIMPLE STATE MACHINE DIAGRAM FOR A PRINTER SCENARIO 22 SYSTEMS ANALYSIS AND DESIGNS - MIDTERMS STATE MACHINE TERMINOLOGY Pseudo state – the starting point of a state machine, indicated by a black dot. Origin state – the original state of an object from which the transition occurs. Destination state – the state to which an object moves after the completion of a transition. Message event – the trigger for a transition, which causes the object to leave the origin state. Guard condition – a true/false test to see whether a transition can fire. Action expression – a description of the activities performed as part of a transition. RULES FOR DEVELOPING STATE MACHINE DIAGRAM Review the domain class diagram, select important ones, and list all state and exit conditions. Begin building state machine diagram fragments for each class. Sequence fragments in the correct order and review for independent and concurrent paths. Expand each transition with a message event, guard- condition, and action-expression. Review and test each state machine diagram. INTEGRATING OBJECT-ORIENTED MODELS A complete use case diagram is needed to understand the total scope of the new system. Domain model class diagrams should also be as complete as possible for the entire system. With an iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration. The development of a new diagram often helps refine and correct previous diagrams. RELATIONSHIPS BETWEEN OO REQUIREMENTS MODELS