Systems Analysis and Design PDF

Chapter 1 1 Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage Learning. All rights reserved. From Beginning to End: An Overview of Syst...

Chapter 1 1 Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage Learning. All rights reserved. From Beginning to End: An Overview of Systems Analysis and Design Chapter 1 Dr. Sarah Naiem Source book:Systems Analysisthand Design in a Changing World 7 Ed Satzinger, Jackson & Burd  Chapter 1: Outline Software Development and Systems Analysis and Design Systems Development Lifecycle (SDLC) Iterative Development Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 3 Learning. All rights reserved.  Learning Objectives After reading this chapter, you should be able to: Describe the purpose of systems analysis and design when developing information systems Explain the purpose of the system development life cycle and identify its six core processes Explain how information system methodologies provide guidelines for completing the six core processes Describe the characteristics of Agile methodologies and iterative system development Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 4 Learning. All rights reserved.  Software Development (1 of 3) Computer application (app) – a computer software program that executes on a computing device to carry out a specific set of functions Modest scope Information system – a set of interrelated components that collects, processes, stores, and provides as output the information needed to complete business tasks Broader in scope than “app” Includes database and related manual processes Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 5 Learning. All rights reserved.  Software Development (2 of 3) Systems analysis – those activities that enable a person to understand and specify what an information system should accomplish Systems design – those activities that enable a person to define and describe in detail the system that solves the need Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 6 Learning. All rights reserved. Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 7 Learning. All rights reserved.  Software Development (3 of 3) 1. Understand the need (business need) 2. Capture the vision 3. Define a solution 4. Communicate the vision and solution 5. Build the solution 6. Confirm that the solution meets the need 7. Launch the solution system Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 8 Learning. All rights reserved.  System Development Life Cycle (SDLC) (1 of 3) The process consisting of all activities required to build, launch, and maintain an information system. Six core processes are: 1. Identify the problem or need and obtain approval 2. Plan and monitor the project 3. Discover and understand the details of the problem or need 4. Design the system components that solve the problem 5. Build, test, and integrate system components 6. Complete system tests and then deploy the solution Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 9 Learning. All rights reserved.  System Development Life Cycle (SDLC) (2 of 3) Project – a planned undertaking that has a beginning and end and that produces some definite result Used to develop an information system Requires knowledge of systems analysis and systems design tools and techniques Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 10 Learning. All rights reserved.  System Development Life Cycle (SDLC) (3 of 3) System development process or methodology: a set of comprehensive guidelines for carrying out all of the activities of each core process of the SDLC Unified process (UP) Extreme programming (XP) Scrum Most processes/methodologies now use Agile and Iterative development Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 11 Learning. All rights reserved.  Iterative Development Agile development – an information system development process that emphasizes flexibility to anticipate new requirements during development Fast on feet; responsive to change Iterative development -- an approach to system development in which the system is “grown” piece by piece through multiple iterations Complete small part of system (mini-project), then repeat processes to refine and add more, then repeat to refine and add more, until done Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 12 Learning. All rights reserved.  Iterative and Agile Systems Development Lifecycle (SDLC) Systems Analysis and Design in a Changing World, 7th Edition - Chapter 1 ©2016. Cengage 13 Learning. All rights reserved.  Chapter 2 Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 1  Investigating System Requirements Chapter 2 Systems Analysis and Design in a Changing World 7th Ed Satzinger, Jackson & Burd Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 2 Chapter 2: Outline Systems Analysis Activities What Are Requirements? Stakeholders Information-Gathering Techniques Models and Modeling Documenting Workflows with Activity Diagrams Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 3 Learning Objectives Describe the activities of systems analysis Explain the difference between functional and nonfunctional requirements Identify and understand different kinds of stakeholders and their contributions to requirements definition Describe information-gathering techniques and determine when each is best applied Describe the role of models in systems analysis Develop UML activity diagrams to model workflows Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 4 Overview Chapter 1 introduced the system development lifecycle (SDLC) and demonstrated its use for a small project This chapter expands the SDLC processes to cover a wider range of concepts, tools and techniques Core process 3: Discover and understand the details of the problem or need—is the main focus of systems analysis Systems analysis activities are detailed in this chapter Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 5 Systems Analysis Activities: Involve discovery and understanding Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 6 Systems Analysis Activities (2 of 2) Gather Detailed Information Interviews, questionnaires, documents, observing business processes, researching vendors, comments and suggestions Define Requirements Modeling functional requirements and non-functional requirements Prioritize Requirements Essential, important, vs. nice to have Develop User-Interface Dialogs Flow of interaction between user and system Evaluate Requirements with Users User involvement, feedback, adapt to changes Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 7 What Are Requirements? System Requirements = Functional requirements Non-functional requirements Functional Requirements– the activities the system must perform Business uses, functions the users carry out Non-Functional Requirements– other system characteristics Constraints and performance goals Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 8 FURPS+ Requirements Acronym (1 of 2) Functional requirements Usability requirements Reliability requirements Performance requirements Security requirements + even more categories… Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 9 FURPS+ Requirements Acronym (2 of 2) Requirement categories FURPS categories Example requirements Functional Functions Business rules and processes User interface, ease of use Usability Reliability Failure rate, recovery methods Nonfunctional Performance Security Response time, throughput Access controls, encryption Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 10 Additional Requirements Categories Design constraints – Specific restrictions for hardware and software Implementation requirements Specific languages, tools, protocols, etc. Interface requirements Interface links to other systems Physical requirements Physical facilities and equipment constraints Supportability requirements Automatic updates and enhancement methods Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 11 Stakeholders: Who do you involve and talk to? Stakeholders– persons who have an interest in the successful implementation of the system Internal Stakeholders– persons within the organization External stakeholders – persons outside the organization Operational stakeholders – persons who regularly interact with the system Executive stakeholders– persons who don’t directly interact, but use the information or have financial interest Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 12 Stakeholders of a comprehensive accounting system for public company Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 13 Information Gathering Techniques Interviewing users and other stakeholders Distributing and collecting questionnaires Reviewing inputs, outputs, and documentation Observing and documenting business procedures Researching vendor solutions Collecting active user comments and suggestions Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 14 Interviewing Users and Other Stakeholders Prepare detailed questions Meet with individuals or groups of users Obtain and discuss answers to the questions Document the answers Follow up as needed in future meetings or interviews Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 15 Themes for Information Gathering Questions Theme Questions to users What are the business operations and What do you do? processes? How do you do it? How should those operations be What steps do you follow? performed? How could they be done differently? What information do you use? What information is needed to perform What inputs do you use? those operations? What outputs do you produce? Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 16 Preparing for the Interview (1 of 2) Before Establish the objective for the interview. Determine correct user(s) to be involved. Determine project team members to participate. Build a list of questions and issues to be discussed. Review related documents and materials. Set the time and location. Inform all participants of objective, time, and locations. During Arrive on time. Look for exception and error conditions. Probe for details. Take thorough notes. Identify and document unanswered items or open questions. Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 17 Preparing for the Interview (2 of 2) After Review notes for accuracy, completeness, and understanding. Transfer information to appropriate models and documents. Identify areas needing further clarification. Thank the participants. Follow up on open and unanswered questions. Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 18 Interview Session Agenda (1 of 2) Discussion and Interview Agenda Setting Objective of Interview Determine processing rules for sales commission rates Date, Time, and Location April 21, 2016, at 9:00 a.m. in William McDougal’s office User Participants (names and titles/positions) William McDougal, vice president of marketing and sales, and several of his staff Project Team Participants Mary Ellen Green and Jim Williams Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 19 Interview Session Agenda (2 of 2) Interview/Discussion 1. Who is eligible for sales commissions? 2. What is the basis for commissions? What rates are paid? 3. How is commission for returns handled? 4. Are there special incentives? Contests? Programs based on time? 5. Is there a variable scale for commissions? Are there quotas? 6. What are the exceptions? Follow-Up Important decisions or answers to questions See attached write-up on commission policies Open items not resolved with assignments for solution See Item numbers 2 and 3 on open items list Date and time of next meeting or follow-up session April 28, 2016, at 9:00 a.m. Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 20 Keeping an Open Items List Date Target Responsible User ID Issue title Comments identified end date project person contact Partial Jason Ship partials or wait 1 6-12-2016 7-15-2016 Jim Williams shipments Nadold for full shipment? Are commissions Returns and William 2 7-01-2016 9-01-2016 Jim Williams recouped on commissions McDougal returns? How to handle Extra Mary Ellen William 3 7-01-2016 8-01-2016 commissions on commissions Green McDougal special promotions? 21 Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. Distribute and Collect Questionnaires Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 22 Review Inputs, Outputs, and Procedures Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 23 Additional Techniques Observe and Document Business Processes Watch and learn Document with Activity diagram (next section) Research Vendor Solutions See what others have done for similar situations White papers, vendor literature, competitors Collect Active User Comments and Suggestions Feedback on models and tests Users know it when they see it Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 24 Models and Modeling How do we define requirements? After collecting information, create models Model– a representation of some aspect of the system being built Types of Models Textual model– something written down, described Graphical models– diagram, schematic Mathematical models– formulas, statistics, algorithms Unified Modeling Language (UML) Standard graphical modeling symbols/terminology used for information systems Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 25 Reasons for Modeling Learning from the modeling process Reducing complexity by abstraction Remembering all the details Communicating with other development team members Communicating with a variety of users and stakeholders Documenting what was done for future maintenance/enhancement Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 26 Some Analysis and Design Models Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 27 Documenting Workflows with Activity Diagrams Workflow– sequence of processing steps that completely handles one business transaction or customer request Activity Diagram– describes user (or system) activities, the person who does each activity, and the sequential flow of these activities Useful for showing a graphical model of a workflow A UML diagram Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 28 Activity Diagrams Symbols Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 29  Activity Diagram for RMO Order Fulfillment Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 30 Activity Diagram with Concurrent Paths Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 31 Summary (1 of 4) Systems analysis activates correspond to the core SDLC process Discover and understand details System projects originate from the information system strategic plan, which contains an technology architecture plan and an application architecture plan The RMO CSMS Project will be used throughout the text as an example of analysis and design Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 32 Summary (2 of 4) Systems analysis involves defining system requirements– functional and non-functional Analysis activities include Gather detailed information Define requirements Prioritize requirements Develop user-interface dialogs Evaluate requirements with users FURPS+ is the acronym for functional, usability, reliability, performance, and security requirements Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 33 Summary (3 of 4) Stakeholders are the people who have an interest in the success of the project There are internal vs. external stakeholders and operational vs. executive stakeholders Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 34 Summary (4 of 4) Information gathering techniques are used to collect information about the project Interviews, questionnaires, reviewing documents, observing business processes, researching vendors, comments and suggestions The UML Activity Diagram is used to document (model) workflows after collecting information Models and modeling are used to explore and document requirements Unified Modeling Language (U ML) is the standard set of notations and terminology for information systems models Systems Analysis and Design in a Changing World, 7th Edition - Chapter 2 ©2016. Cengage Learning. All rights reserved. 35 Chapter 3 Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 1  Identifying User Stories and Use Cases Chapter 3 Systems Analysis and Design in a Changing World 7th Ed Satzinger, Jackson & Burd Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 2  Chapter 3: Outline User Stories and Use Cases Use Cases and the User Goal Technique Use Cases and Event Decomposition Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 3  Learning Objectives Explain why identifying use cases is the key to defining functional requirements Write user stories with acceptance criteria Describe the two techniques for identifying use cases Apply the user goal technique to identify use cases Apply the event decomposition technique to identify use cases Describe the notation and purpose for the use case diagram Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 4  Overview Chapter 2 provided an overview of systems analysis activities, functional and non-functional requirements, modeling, and information gathering techniques This chapter focuses on identifying and modeling the key aspect of functional requirements– use cases In this chapter’s opening case Waiters on Call, examples of use cases are Record an order, Record delivery, Update an order, Sign in driver, Reconcile driver receipts, Produce end of day deposit slip, and Produce weekly sales reports Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 5  User Stories A User Story is a one-sentence description of a work-related task done by a user to achieve some goal or result Acceptance Criteria identify the features that must be present at the completion of the task The template for a user story description is: “As a I want to so that Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 6  Sample User Story Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 7  Use Cases Use case— an activity that the system performs, usually in response to a request by a user Use cases define functional requirements Analysts decompose the system into a set of use cases (functional decomposition) Two techniques for Identifying use cases User goal technique Event decomposition technique Name each use case using Verb-Noun Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 8  User Goal Technique This technique is the most common in industry Simple and effective Identify all of the potential categories of users of the system Interview and ask them to describe the tasks the computer can help them with Probe further to refine the tasks into specific user goals, “I need to Ship items, Track a shipment, Create a return” Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 9  User Goal Technique: Some RMO CSMS Users and Goals User User goal and resulting use case Potential customer Search for item Fill shopping cart View product rating and comments Marketing manager Add/update product information Add/update promotion Produce sales history report Shipping personnel Ship items Track shipment Create item return Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 10  User Goal Technique: Specific Steps (1 of 2) 1. Identify all the potential users for the new system 2. Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales) 3. Further classify potential users by organizational level (e.g., operational, management, executive) 4. For each type of user, interview them to find a list of specific goals they will have when using the new system (current goals and innovative functions to add value) Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 11  User Goal Technique: Specific Steps (2 of 2) 5. Create a list of preliminary use cases organized by type of user 6. Look for duplicates with similar use case names and resolve inconsistencies 7. Identify where different types of users need the same use cases 8. Review the completed list with each type of user and then with interested stakeholders Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 12  Event Decomposition Technique More Comprehensive and Complete Technique Identify the events that occur to which the system must respond. For each event, name a use case (verb-noun) that describes what the system does when the event occurs Event– something that occurs at a specific time and place, can be described, and should be remembered by the system Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 13  Events and Use Cases Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 14  Types of Events External Event an event that occurs outside the system, usually initiated by an external agent or actor Temporal Event an event that occurs as a result of reaching a point in time State Event an event that occurs when something happens inside the system that triggers some process reorder point is reached for inventory item Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 15  External Event Checklist External agent or actor wants something resulting in a transaction Customer buys a product External agent or actor wants some information Customer wants to know product details External data changed and needs to be updated Customer has new address and phone Management wants some information Sales manager wants update on production plans Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 16  Temporal Event Checklist Internal outputs needed at points in time Management reports (summary or exception) Operational reports (detailed transactions) Internal statements and documents (including payroll) External outputs needed at points of time Statements, status reports, bills, reminders Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 17  Finding the actual event that affects the system Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 18  Tracing a sequence of transactions resulting in many events Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 19  Perfect Technology Assumption Don’t worry about functions built into system because of limits in technology and people. Wait until design. Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 20  Event Decomposition Technique: Specific Steps (1 of 2) 1. Consider the external events in the system environment that require a response from the system by using the checklist shown in Figure 3-3 2. For each external event, identify and name the use case that the system requires 3. Consider the temporal events that require a response from the system by using the checklist shown in Figure 3-4 4. For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 21  Event Decomposition Technique: Specific Steps (2 of 2) 5. Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases. 6. For each state event, identify and name the use case that the system requires and then define the state change. 7. When events and use cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in later. Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 22  Event Decomposition Technique: Benefits Events are broader than user goal: Capture temporal and state events Help decompose at the right level of analysis: an elementary business process (EBP) EBP is a fundamental business process performed by one person, in one place, in response to a business event Uses perfect technology assumption to make sure functions that support the users work are identified and not additional functions for security and system controls Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 23  Use Cases and Brief Use Case Descriptions Brief use case description is often a one sentence description showing the main steps in a use case Use case Brief use case description Create customer account User/actor enters new customer account data, and the system assigns account number, creates a customer record, and creates an account record. Look up customer User/actor enters customer account number, and the system retrieves and displays customer and account data. Process account adjustment User/actor enters order number, and the system retrieves customer and order data; actor enters adjustment amount, and the system creates a transaction record for the adjustment. Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 24  RMO CSMS Project Use Cases (1 of 4) CSMS Sales Subsystem Use cases Users/actors Search for item Customer, customer service representative, store sales representative View product comments and ratings Customer, customer service representative, store sales representative View accessory combinations Customer, customer service representative, store sales representative Fill shopping cart Customer Empty shopping cart Customer Check out shopping cart Customer Fill reserve cart Customer Empty reserve cart Customer Convert reserve cart Customer Create phone sale Customer service representative Create store sale Stores sales representative Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 25  RMO CSMS Project Use Cases (2 of 4) CSMS Order Fulfillment Subsystem Use cases Users/actors Ship items Shipping Manage shippers Shipping Create backborder Shipping Create item return Shipping, customer Look up order status Shipping, customer, management Track shipment Shipping, customer, marketing Rate and comment on product Customer Provide suggestion Customer Review suggestions Management Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 26  RMO CSMS Project Use Cases (3 of 4) CSMS Customer Account Subsystem Use cases Users/actors Create/update customer account Customer, customer service representative, store sales representative Process account adjustment Management Send message Customer Browse messages Customer Request friend linkup Customer Reply to linkup request Customer Send/receive partner credits Customer View “mountain bucks” Customer Transfer “mountain bucks” Customer Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 27  RMO CSMS Project Use Cases (4 of 4) CSMS Marketing Subsystem Use cases Users/actors Add/update product information Merchandising, marketing Add/update promotion marketing Add/update accessory package Merchandising Add/update business partner link Marketing CSMS Reporting Subsystem Use cases Users/actors Produce daily transaction summary report Management Produce sales history report Management, marketing Produce sales trends report Marketing Produce customer usage report Marketing Produce shipment history report Management, shipping Produce promotion impact report Marketing Produce promotional partner activity report Management, marketing Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 28  Use Case Diagrams Use case diagram— a UML model used to graphically show uses cases and their relationships to actors Recall UML is Unified Modeling Language, the standard for diagrams and terminology for developing information systems Actor is the UML name for a end user Automation boundary— the boundary between the computerized portion of the application and the users who operate the application Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 29  Use Case Diagrams Symbols Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 30  Use Case Diagrams: Draw for each subsystem Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 31  Use Case Diagrams: Draw for a single actor, such as customer Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 32  Use Case Diagrams: Draw for internal RMO actors Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 33  Use Case Diagrams— The relationship A relationship between use cases where one use case is stereotypically included within the other use case— like a called subroutine. Arrow points to subroutine Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 34  Use Case Diagrams: Steps 1. Identify all the stakeholders and users who would benefit by seeing a use case diagram 2. Determine what each stakeholder or user needs to review in a use case diagram: each subsystem, for each type of user, for use cases that are of interest 3. For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams 4. Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 35  Summary (1 of 2) This chapter is the first of three that focuses on modeling functional requirements as a part of systems analysis Use cases are the functions identified, the activities the system carries out usually in response to a user request Two techniques for identifying use cases are the user goal technique and the event decomposition technique The user goal technique begins by identifying end users called actors and asking what specific goals they have when interacting with the system The event decomposition technique begins by identifying events that occur that require the system to respond. Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 36  Summary (2 of 2) Three types of events include external, temporal, and state events Brief use case descriptions are written for use cases The use case diagram is the UML diagram used to show the use cases and the actors The use case diagram shows the actors, the automation boundary, the uses cases that involve each actor, and the relationship. A variety of use case diagrams are draw depending on the presentation needs of the analysis Systems Analysis and Design in a Changing World, 7th Edition - Chapter 3 ©2016. Cengage Learning. All rights reserved. 37  Chapter 4 Systems Analysis and Design in a Changing World, 7th Edition - Chapter 4 ©2016. Cengage Learning. All rights reserved. 1  Domain Modeling Chapter 4 Systems Analysis and Design in a Changing World 7th Ed Satzinger, Jackson & Burd Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 2  Chapter 4: Outline “Things” in the Problem Domain The Entity-Relationship Diagram The Domain Model Class Diagram The State Machine Diagram – Identifying Object Behavior Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 3  Learning Objectives Explain how the concept of “things” in the problem domain also define requirements Identify and analyze data entities and domain classes needed in the system Read, interpret, and create an entity-relationship diagram Read, interpret, and create a domain model class diagram Understand the domain model class diagram for the RMO Consolidated Sales and Marketing System Read, interpret, and create a state machine diagram that models object behavior Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 4  Overview This chapter focuses on another key concept for defining requirements— data entities or domain classes In the RMO Tradeshow System from Chapter 1, some domain classes are Supplier, Product, and Contact In this chapter’s opening case Waiters on Call, examples of domain classes are Restaurants, Menu Items, Customers, Orders, Drivers, Routes, and Payments Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 5  Things in the Problem Domain Problem domain—the specific area (or domain) of the users’ business need that is within the scope of the new system. “Things” are those items users work with when accomplishing tasks that need to be remembered Examples of “Things” are products, sales, shippers, customers, invoices, payments, etc. These “Things” are modeled as domain classes or data entities In this course, we will call them domain classes. In database class you may call them data entities Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 6  Things in the Problem Domain: Two Techniques for Identifying Them Brainstorming Technique Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type Noun Technique Identify all of the nouns that come up when the system is described and determine if each is a domain class, an attribute, or not something we need to remember Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 7  Brainstorming Technique Are there any tangible things? Are there any organizational units? Sites/locations? Are there incidents or events that need to be recorded? Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 8  Brainstorming Technique: Steps 1. Identify a user and a set of use cases 2. Brainstorm with the user to identify things involved when carrying out the use case—that is, things about which information should be captured by the system. 3. Use the types of things (categories) to systematically ask questions about potential things, such as the following: Are there any tangible things you store information about? Are there any locations involved? Are there roles played by people that you need to remember? 4. Continue to work with all types of users and stakeholders to expand the brainstorming list 5. Merge the results, eliminate any duplicates, and compile an initial list Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 9  The Noun Technique A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents Popular technique. Systematic. Does end up with long lists and many nouns that are not things that need to be stored by the system Difficulty identifying synonyms and things that are really attributes Good place to start when there are no users available to help brainstorm Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 10  The Noun Technique: Steps (1 of 3) 1. Using the use cases, actors, and other information about the system— including inputs and outputs—identify all nouns. For the RMO C SMS, the nouns might include customer, product item, sale, confirmation, transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back order notification, return, return confirmation… 2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed. For the RMO CSMS, these might include price, size, color, style, season, inventory quantity, payment method, and shipping address. Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 11  The Noun Technique: Steps (2 of 3) 3. As this list of nouns builds, refine it. Ask these questions about each noun to help you decide whether you should include it: Is it a unique thing the system needs to know about? Is it inside the scope of the system I am working on? Does the system need to remember more than one of these items? Ask these questions to decide to exclude it: Is it really a synonym for some other thing I have identified? Is it really just an output of the system produced from other information I have identified? Is it really just an input that results in recording some other information I have identified? Ask these questions to research it: Is it likely to be a specific piece of information (attribute) about some other thing I have identified? Is it something I might need if assumptions change? Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 12  The Noun Technique: Steps (3 of 3) 4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further. 5. Review the list with users, stakeholders, and team members and then define the list of things in the problem domain. Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 13  Partial List of Nouns for RMO (1 of 2) With notes on whether to include as domain class Identified noun Notes on including noun as a thing to store Accounting We know who they are. No need to store it. Back order A special type of order? Or a value of order status? Research. Back-order information An output that can be produced from other information. Bank Only one of them. No need to store. Catalog Yes, need to recall them, for different seasons and years, Include. Catalog activity reports An output that can be produced from other information, Not stored. Catalog details Same as catalog? Or the same as product items in the catalog? Research. Change request An input resulting in remembering changes to an order. Charge adjustment An input resulting in a transaction. Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 14  Partial List of Nouns for RMO (2 of 2) Identified noun Notes on including noun as a thing to store Color One piece of information about a product item. Confirmation An output produced from other information, Not stored. Credit card information Part of an order? Or part of customer information? Research. Customer Yes, a key thing with lots of details required. Include. Customer account Possibly required if an R MO payment plan is included. Research. Fulfillment reports An output produced from information about shipments. Not stored. Inventory quantity One piece of information about a product item. Research. Management We know who they are. No need to store. Marketing We know who they are. No need to store. Merchandising We know who they are. No need to store. Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 15  Details about Domain Classes Attribute— describes one piece of information about each instance of the class Customer has first name, last name, phone number Identifier or key One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes. Customer ID identifies a customer Compound attribute Two or more attributes combined into one structure to simplify the model. (E.g., address rather than including number, street, city, state, zip separately). Sometimes an identifier or key is a compound attribute. Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 16  Attributes and Values Class is a type of thing. Object is a specific instance of the class. Each instance has its own values for an attribute Ea ch custo mer has a va lu e fo re ach attri bute : Ea ch custo mer has a va lu e fo re ach attri bute : All customers have these attributes: Each customer has a value for each attribute: Customer ID 101 102 103 First name John Mary Bill Last name Smith Jones Casper Home phone 555-9182 423-1298 874-1297 Work phone 555-3425 423-3419 874-8546 Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 17  Associations Among Things Association— a naturally occurring relationship between classes (U ML term) Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 18  Just to Clarify… Called association on class diagram in U ML Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many (synonym to cardinality) UML is the primary emphasis of this text Called relationship on ERD in database class Cardinality is term for number of relationships in entity relationship diagrams: 1 to 1 or 1 to many (synonym to multiplicity) Associations and Relationships apply in two directions Read them separately each way A customer places an order An order is placed by a customer Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 19  Minimum and Maximum Multiplicity Associations have minimum and maximum constraints minimum is zero, the association is optional If minimum is at least one, the association is mandatory Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 20  Types of Associations Binary Association Associations between exactly two different classes Course Section includes Students Members join Club Unary Association (recursive) Associations between two instances of the same class Person married to person Part is made using parts Ternary Association (three) N-ary Association (between n) Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 21  Entity-Relationship Diagrams: ERD ERD s have been used for many years to develop data models that are used in database development The term for “things” in ERD models is data entities ERD models are not UML models and do not use standard UML notation ERD models are not as expressive as U ML models They do not model generalization/specialization well They do not model whole/part well Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 22  Example of ERD Notation ERD Models normally use “crows feet” notation to show cardinality Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 23  ERD Cardinality Symbols Examples of crows feet notation for various cardinalities Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 24  Expanded ERD with Attributes ERD with cardinalities and attributes There are several different notation methods for attributes in ERD models This notation places attributes within data entities Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 25  Semantic Net (1 of 2) A semantic net is a graphical representation of an individual data entity and its relationship with other individual entities It is often used to help understand and then develop an ERD model Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 26  Semantic Net (2 of 2) This example shows three classes. Quick quiz What are the classes? How many relationships? What are min and max cardinalities? What type of relationships are they? Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 27  An ERD for a Bank Quick Quiz What are the key fields? How many accounts can a customer have? How many branches can a customer be assigned to? How many customers can a branch have? Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 28  The Domain Model Class Diagram Class A type of classification used to describe a collection of objects Domain Class Classes that describe objects in the problem domain Class Diagram A UML diagram that shows classes with attributes and associations (plus methods if it models software classes) Domain Model Class Diagram A class diagram that only includes classes from the problem domain, not software classes so no methods Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 29  UML Domain Class Notation Domain class a name and attributes (no methods) Class name is always capitalized Attribute names are not capitalized and use camelback notation (words run together and second word is capitalized) Compound class names also use camelback notation Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 30  A Simple Domain Model Class Diagram Note: This diagram matches the semantic net shown previously A customer places zero or more orders An order is placed by exactly one customer An order consists of one or more order items An order item is part of exactly one order Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 31  UML Notation for Multiplicity Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 32  Domain Model Class Diagram (1 of 2) Bank with many branches as show previously in E RD Note notation for the key Note the precise notation for the attributes (camelback) Note the multiplicity notation Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 33  Domain Model Class Diagram (2 of 2) Course Enrollment at a University A Course has many CourseSections A CourseSection has many Students and a Student is registered in many CourseSections Problem How/where to capture student grades? Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 34  Refined Course Enrollment Model with an Association Class CourseEnrollment Association class— an association that is treated as a class in a many to many association because it has attributes that need to be remembered (such as grade) Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 35  Association Class Properties The association class is the same “thing” as the association itself The unique identifier (key) for the association class is the concatenation of the keys of the attached classes In the previous example the key for CourseSection is CourseNumber+SectionNumber Hence the key for CourseEnrollment is CourseNumber+SectionNumber+StudentID Note: If more information is required to uniquely identify instances of the association class, then the model is incorrect, i.e., if the key cannot be formed by the concatenation of the endpoint keys, it is in error. Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 36  Band with members and concerts Quick Quiz How many bands can a person play in? For a band, how many concerts can it play in? For a concert, how many bands may be playing? What attributes can you use for keys? Do you need to add “key” attributes? Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 37  Band with Concert Booking Information Note: The association class (Booking) also provides a name and meaning for the association Given the keys you identified, what is the key for the Booking class? Does it uniquely identify instances? Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 38  More Complex Issues about Classes: Generalization/Specialization Relationships Generalization/Specialization A hierarchical relationship where subordinate classes are special types of the superior classes. Often called an Inheritance Hierarchy Superclass the superior or more general class in a generalization/specialization hierarchy Subclass the subordinate or more specialized class in a generalization/specialization hierarchy Inheritance the concept that subclasses classes inherit characteristics of the more general superclass Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 39  Generalization/Specialization Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 40  Generalization/Specialization: Inheritance for RMO Three Types of Sales Abstract class— a class that allow subclasses to inherit characteristics but never gets instantiated. In Italics (Sale) Concrete class— a class that can have instances Inheritance – Attributes of OnlineSale are: timeOnSite, chatUse, saleDateTime, priorityCode, S&H, tax, totalAmt… Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 41  Generalization/Specialization: Inheritance for the Bank with Special Types of Accounts A SavingsAccount has 4 attributes A CheckingAccount has 5 attributes Note: the subclasses inherit the associations too Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 42  More Complex Issues about Classes: Whole Part Relationships Whole-part relationship— a relationship between classes where one class is part of or a component portion of another class Aggregation— a whole part relationship where the component part exists separately and can be removed and replaced (UML diamond symbol on next slide) Computer has disk storage devices (storage devices exist apart from computer) Car has wheels (wheels can be removed and still be wheels) Composition— a whole part relationship where the parts cannot be removed (filled in diamond symbol) OrderItem on an Order (without the Order, there are no OrderIterms) Chip has circuits (without the chip, there are no circuits) Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 43  Whole Part Relationships: Computer and its Parts Note: this is aggregation, with diamond symbol. Whole part can have multiplicity symbols, too (not shown)\ Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 44  More on UML Relationships There are actually three types of relationships in class diagrams Association Relationships These are associations discussed previously, just like ERD relationships Whole Part Relationships One class is a component or part of another class Generalizations/Specialization Relationships Inheritance Try not to confuse relationship with association Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 45  Object Behavior – State Machine Diagram Each class has objects that may have status conditions or “states” Object behavior consists of the various states and the movement between these states State – a condition during an object’s life when it satisfies some criterion, performs an action, or waits for an event Transition – the movement of an object from one state to another Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 46  State Machine Diagram State Machine Diagram – a diagram which shows the life of an object in states and transitions Origin state – the original state of an object before it begins a transition Destination state – the state to which an object moves after completing a transition pseudostate – the starting point in a state machine diagram. Noted by a black circle. action-expression – some activity that must be completed as part of a transition guard-condition – a true/false test to see whether a transition can fire Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 47  State Machine for a Printer Syntax of transition statement transition-name (parameters, …) [guard-condition] / action-expression Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 48  Concurrency in a State Machine Diagram Concurrent states – when an object is in one or more states at the same time Path – a sequential set of connected states and transitions Concurrent paths – when multiple paths are being followed concurrently, i.e. when one or more states in one path are parallel to states in another path Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 49  Printer with Concurrent Paths Concurrent paths often shown by synchronization bars (same as Activity Diagram) Multiple exits from a state is an “OR” condition. Multiple exits from a synchronization bar is an “AND” condition. Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 50  Creating a State Machine Diagram: Steps (1 of 2) 1. Review the class diagram and select classes that might require state machine diagrams 2. For each class, make a list of status conditions (states) you can identify 3. Begin building diagram fragments by identifying transitions that cause an object to leave the identified state 4. Sequence these states in the correct order and aggregate combinations into larger fragments 5. Review paths and look for independent, concurrent paths Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 51  Creating a State Machine Diagram: Steps (2 of 2) 6. Look for additional transitions and test both directions 7. Expand each transition with appropriate message event, guard condition, and action expression 8. Review and test the state machine diagram for the class Make sure state are really state for the object in the class Follow the life cycle of an object coming into existence and being deleted Be sure the diagram covers all exception condition Look again for concurrent paths and composite states Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 52  RMO – Creating a State Machine Diagram: Steps – SaleItem (1 of 3) 1. Choose SaleItem. It has status conditions that need to be tracked 2. List the states and exit transitions State Transition causing exit Open saleComplete Ready to Ship shipItem On back order itemArrived Shipped No exit transition defined Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 53  RMO – Creating a State Machine Diagram: Steps – SaleItem (2 of 3) 3. Build fragments – see figure below 4. Sequence in correct order – see figure below 5. Look for concurrent paths – none Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 54  RMO – Creating a State Machine Diagram: Steps – SaleItem (3 of 3) 6. Add other required transitions 7. Expand with guard, action-expressions etc. 8. Review and test Below is the final State Machine Diagram Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 55  RMO – Creating a State Machine Diagram: Steps – InventoryItem (1 of 3) 1. Choose InventoryItem. It has status conditions that need to be tracked 2. List the states and exit transitions State Transition causing exit Normal stock reduceInventory Low stock reduceInventory OR restock Zero stock removeItem OR restock On order itemArrives Not on order orderItem Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 56  RMO – Creating a State Machine Diagram: Steps – InventoryItem (2 of 3) 3. Build fragments – see figure below 4. Sequence in correct order – see figure below 5. Look for concurrent paths – see figure below Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 57  RMO – Creating a State Machine Diagram: Steps – InventoryItem (3 of 3) 6. Add other required transitions 7. Expand with guard, action-expressions etc. 8. Review and test Below is the final State Machine Diagram Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 58  Summary (1 of 4) This chapter focuses on modeling functional requirements as a part of systems analysis “Things” in the problem domain are identified and modeled, called domain classes or data entities Two techniques for identifying domain classes/data entities are the brainstorming technique and the noun technique Domain classes have attributes and associations Associations are naturally occurring relationships among classes, and associations have minimum and maximum multiplicity Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 59  Summary (2 of 4) Entity-relationship diagrams (ERDs) show the information about data entities ERD s are often preferred by database analysts and are widely used ERD s are not UML diagrams, and an association is called a relationship, multiplicity is called cardinality, and generalization/specialization (inheritance) and whole part relationships are usually not shown Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 60  Summary (3 of 4) The UML class diagram notation is used to create a domain model class diagram for a system. The domain model classes do not have methods because they are not yet software classes. There are actually three UML class diagram relationships: association relationships, generalization/specialization (inheritance) relationships, and whole part relationships Other class diagram concepts are abstract versus concrete classes, compound attributes, composition and aggregation, association classes, super classes and subclasses Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 61  Summary (4 of 4) Some objects have a life cycle with status conditions that change and should be tracked A State Machine Diagram tracks the behavior of these objects with states and transitions To develop a State Machine Diagram Choose a single object class. Identify the states and exit transitions Identify concurrent paths Identify additional paths Build the State Machine Diagram Systems Analysis and Design in a Changing World, 7th Edition – Chapter 4 ©2016. Cengage Learning. All rights reserved. 62  Chapter 5 Systems Analysis and Design in a Changing World, 7th Edition - Chapter 5 ©2016. Cengage Learning. All rights reserved. 1  Use Case Modeling Chapter 5 Systems Analysis and Design in a Changing World 7th Ed Satzinger, Jackson & Burd Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 2  Chapter 5: Outline Use Case Descriptions Activity Diagrams for Use Cases The System Sequence Diagram—Identifying Inputs and Outputs SSD Notation Use Cases and CRUD Integrating Requirements Models Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 3  Learning Objectives Write fully developed use case descriptions Develop activity diagrams to model flow of activities Develop system sequence diagrams Use the CRUD technique to validate use cases Explain how use case descriptions and UML diagrams work together to define functional requirements Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 4  Overview (1 of 2) Chapters 3 and 4 identified and modeled the two primary aspects of functional requirements: use cases and domain classes This chapter focuses on detail modelling for use cases to document the internal steps within a use case Fully developed use case descriptions provide information about each use case, including actors, stakeholders, preconditions, post conditions, the flow of activities and exceptions conditions Activity diagrams (first shown in Chapter 2) can also be used to show the flow of activities for a use case Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 5  Overview (2 of 2) System sequence diagrams (SSDs) show the inputs and outputs for each use case as messages CRUD analysis, which correlates problem domain classes and use cases, is an effective technique to double check that all required use cases have been identified Not all use cases are modelled at this level of detail. Only model when there is complexity and a need to communicate details Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 6  Use Case Descriptions (1 of 2) Write a brief description as shown in Chapter 3 for most use cases. Use case Brief use case description Create customer account User/actor enters new customer account data, and the system assigns account number, creates a customer record, and creates an account record. Look up customer User/actor enters customer number, and the system retrieves and displays customer and account data. Process account adjustment User/actor enters order number, and the system retrieves customer and order data; actor enters adjustment amount, and the system creates a transaction record for the adjustment. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 7  Use Case Descriptions (2 of 2) Write a fully developed use case description for more complex use cases Typical use case description templates include: Use case name Scenario (if needed) Triggering event Brief description Actors Related use cases () Stakeholders Preconditions Postconditions Flow of activities Exception conditions Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 8  Fully Developed Use Case Description: Use case: Create customer account Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 9  Fully Developed Use Case Description Create customer account (part 1) Use case name: Create customer account. Scenario: Create online customer account. Triggering event: New customer wants to set up account online. Brief description: Online customer creates customer account by entering basic information and then following up with one or more addresses and a credit or debit card. Actors: Customer. Related use cases: Might be invoked by the Check out shopping cart use case. Stakeholders: Accounting, Marketing, Sales. Preconditions: Customer account subsystem must be available. Credit/debit authorization services must be available. Postconditions: Customer must be created and saved. One or more Addresses must be created and saved. Credit/debit card information must be validated. Account must be created and saved. Address and Account must be associated with Customer. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 10  Fully Developed Use Case Description Create customer account (part 2) Flow of activities: Actor System blank 1. Customer indicates desire to create 1.1 System creates a new customer. customer account and enters basic 1.2 System prompts for customer customer information. addresses. 2. Customer enters one or more 2.1 System creates addresses. addresses. 2.2 System prompts for credit/debit card. 3. Customer enters credit/debit card 3.1 System creates account. information. 3.2 System verifies authorization for credit/debit card. 3.3 System associates customer, address, and account. 3.4 System returns valid customer account details. Exception 1.1 Basic customer data are incomplete. Blank conditions: 2.1 The address isn’t valid. 3.2 Credit/debit information isn’t valid. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 11  Use Case Description Details (1 of 2) Use case name Verb-noun Scenario (if needed) A use case can have more than one scenario (special case or more specific path) Triggering event Based on event decomposition technique Brief description Written previously when use case was identified Actors One or more users from use case diagrams Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 12  Use Case Description Details (2 of 2) Related use cases If one use case invokes or includes another Stakeholders Anyone with an interest in the use case Preconditions What must be true before the use case begins Post conditions What must be true when the use case is completed Use for planning test case expected results Flow of activities The activities that go on between actor and the system Exception conditions Where and what can go wrong Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 13  Another Fully Developed Use Case Description Example: Use case Ship items Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 14  Fully Developed Use Case Description Ship items (part 1) Use case name: Ship items. Scenario: Ship items for a new sale. Triggering event: Shipping is notified of a new sale to be shipped. Shipping retrieves sale details, finds each item and records it is shipped, records Brief description: which items are not available, and sends shipment. Actors: Shipping clerk. Related use cases None. Stakeholders: Sales, Marketing, Shipping, warehouse manager. Customer and address must exist. Preconditions: Sale must exist. Sale items must exist. Shipment is created and associated with shipper. Shipped sale items are updated as shipped and associated with the shipment. Postconditions: Unshipped items are marked as on back order. Shipping label is verified and produced. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 15  Fully Developed Use Case Description Ship items (part 2) Flow of activities: Actor System blank 1. Shipping requests sale and sale item information. 1.1 System looks up sale and returns customer, address, sale, and sales item information. 2. Shipping assigns shipper. 2.1 System creates shipment and associates it 3. For each available item, shipping records item is shipped. with the shipper. 3.1 System updates sale item as shipped and 4. For each unavailable item, shipping records back order. associates it with shipment. 5. Shipping requests shipping lablel supplying package size 4.1 System updates sale item as on back order. and weight. 5.1 System produces shipping label for shipment. 5.2 System records shipment cost. Exception 2.1 Shipper is not available to that location, so select another. blank conditions: 3.1 If order item is damaged, get new item and updated item quantity. 3.1 If item bar code isn’t scanning, shipping must enter bar code manually. 5.1 If printing label isn’t printing correctly, the label must be addressed manually. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 16  UML Activity Diagram for Use Case: Create Customer Account Note: this shows flow of activities only Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 17  Activity Diagram for Ship Items Use Case Note: Synchronization bar for loop Decision diamond Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 18  UML Activity Diagram for Use Case: Fill shopping cart Note: this shows use case with relationship Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 19  System Sequence Diagram (SSD) A UML sequence diagram Special case for a sequence diagram Only shows actor and one object The one object represents the complete system Shows input & output messaging requirements for a use case Actor, : System , object lifeline begin underline end underline Messages Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 20  System Sequence Diagram (SSD) Notation Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 21  SSD Message Examples with Loop Frame Systems Analysis and Design in a Changing World, 7th edition – Chapter 5