7 System Analysis Mulugeta H.(MPH) 1 7 Investigating system requirements 7 Gather information Analysis involves gathering a considerable amount of information. Systems analysts obtain some information from people who will be using the system, either by interviewing them or by watching them work. They obtain other information by reviewing planning documents and policy statements. Documentation from the existing system should also be studied carefully. 7 Insights into the business of the organization in detail, system interfaces with other systems both inside and outside the organization, software packages that will be used The key question to be answered when completing this activity is: Do we have all of the information (and insight) we need to define what the system must do? 7 DEFINE SYSTEM REQUIREMENTS The information gathered should be documented. Some of it may be about technical requirements and some of it may be about be functional requirements Thus, models should be created to help record and communicate requirements The modeling process is a learning process for an analyst. 7 logical model: any model that shows what the system is required to do without committing to any one technology physical model: any model that shows how the system will actually be implemented systems analysis involves creating detailed logical models, and systems design involves detailed physical models. 7 The key question to be answered when completing this activity is: What (in detail) do we need the system to do? 7 PRIORITIZE REQUIREMENTS The key question to be answered when completing this activity is: What are the most important things the system must do? PROTOTYPE FOR FEASIBILITY AND DISCOVERY 7 Prototyping helps answer two key questions: Have we proven that the technology proposed can do what we think we need it to do? and equally important, Have we built some prototypes to ensure the users fully understand the potential of what the new system can do? GENERATE AND EVALUATE ALTERNATIVES 7 The key question to be answered when completing this activity is: What is the best way to create the system? Should the system be developed by in-house development staff or by a consulting firm? Should we use one or more off the shelf software packages? REVIEW RECOMMENDATIONS WITH MANAGEMENT 7 The key question to be answered when completing this activity is: Should we continue with the design and implement the system we propose? 7 SYSTEM REQUIREMENTS Specifications that define the functions to be provided by a system Functional requirement: a system requirement that describes an activity or process that the system must perform 7 Nonfunctional requirement: characteristics of the system other than activities it must perform or support, such as technology, performance, usability, reliability, and security 7 Technical requirement: a system requirement that describes an operational characteristic related to an organization’s environment, hardware, and software Performance requirement: a system requirement that describes an operational characteristic related to workload measures, such as throughput and response time 7 usability requirement: a system requirement that describes an operational characteristic related to users, such as the user interface, work procedures, online help, and documentation 7 Reliability requirement: a system requirement that describes the dependability of a system, such as how it handles service outages, incorrect processing, and error detection and recovery Security requirement: a system requirement that describes user access to certain functions and the conditions under which access is granted STAKEHOLDERS—THE SOURCE OF SYSTEM REQUIREMENTS Stakeholders: all the people who have an interest in the success of a new system Generally, we categorize stakeholders into one of three groups: 1. The users, those who actually use the system on a daily basis 2. The clients, those who pay for and own the system 3. The technical staff, the people who must ensure that the system operates in the computing environment of the organization. 7 Modeling system requirements overview 7 Document functional requirements by creating models Models created during analysis phase activity – Define system requirements Two concepts help identify functional requirements in the traditional approach and object-oriented approach Use cases and the events that trigger them Things in the users’ work domain 7 User Goals, Events, and Use Cases Use Case -- An activity the system performs in response to a user request Techniques for identifying use cases User goal technique Each goal at the elementary business process (EBP) level is a use case – a task performed by one user, in one place in response to a business event, that adds measurable business value, and leaves system and data in consistent state EBP 7 CRUD analysis technique (create, read, update, delete) Event decomposition technique 7 The analyst starts by looking at the types of data stored by the system Examples of types of data include Customer, Order, Inventory Item, and Shipment Identifying Use Cases Based on User Goals 7 Use Case Based on CRUD Technique 7 7 Event Decomposition Technique Event – an occurrence at a specific time and place and which needs to be remembered Business events trigger elementary business processes (EBPs) EBPs are at correct level of analysis for use cases Identify business events to decompose system into activities/use cases 7 Types of Events External Outside system Initiated by external agent or actor Temporal Occur as result of reaching a point in time Based on system deadlines State Something inside system triggers processing need Events Affecting a Charge Account Processing System that Lead to Use Cases 7 7 External Event Checklist 7 Temporal Event Checklist 7 Events and Use Cases Event Table – a catalogue of use cases listed by event. Contains detailed information Trigger – a signal that indicates an event has occurred Source – an external agent that initiates event and supplies data for the event Response – an output produced by the system Destination – an external agent that receives the response 7 7 Use Case Descriptions Use case description – a description of the processing steps for a use case Actor – a person or thing that uses the system. Actors have contact with the system Scenario or Instance – a particular set of internal steps that represent a unique path of the use case Three types of descriptions Brief description Intermediate description Fully developed description 7 Brief Description 7 Intermediate Description 7 7 “Things” in the Problem Domain Define system requirements by understanding system information that needs to be stored Store information about things in the problem domain that people deal with when they do their work 7 Types of Things Procedure for Developing an Initial List of Things Step 1: Using the event table and information about each use case, identify all nouns Step 2: Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed Step 3: Refine list and record assumptions or issues to explore Questions to include it, exclude it, or research it 7 7 7 Characteristics of Things Relationship Naturally occurring association among specific things Occur in two directions Number of associations is cardinality or multiplicity Binary, unary, ternary, n-ary Attribute One specific piece of information about a thing Relationships Naturally Occur Between Things 7 Cardinality/Multiplicity of Relationships 7 7 Attributes and Values 7 The Domain Model Class Diagram Unified Modeling Language (UML) diagram Domain model class diagram Models things in the users’ work domain Used to define requirements for OO (very similar to entities in ERD) 7 UML Class Symbol 7 Simple Domain Model Class Diagram 7 No methods shown in domain model Domain classes are not software classes Very similar to ERD UML and domain model can be used in place of ERD in traditional approach 7 Multiplicity of Associations University Course Enrollment Domain Model Class Diagram 7 Refined Model with Association Class and Grade Attribute 7 7 Object-Oriented Requirements Object-oriented modeling notation is Unified Modeling Language (UML 2.0) UML was accepted by Object Management Group (OMG) as standard modeling technique Purpose of Object Management Group Promote theory and practice of object-oriented technology for development of distributed systems Provide common architectural framework for OO 50 Object-Oriented Requirements (continued) Object-oriented system requirements are specified and documented through process of building models Modeling process starts with identification of use cases and problem domain classes (things in users’ work environment) Business events trigger elementary business processes (EBP) that new system must address as use cases Use cases define functional requirements 7 51 Object-Oriented Requirements Models Use case model – a collection of models to capture system requirements Use case diagram – identify actors and their roles and how the actor roles utilize the system Systems sequence diagrams (SSDs) – define inputs and outputs and sequence of interactions between user and system for a use case 7 52 Object-Oriented Requirements Models (continued) Message – the communication between objects within a use case Domain model – describes the classes of objects and their states State machine diagrams – describe states of each object 7 53 Requirements Models—Traditional vs OO 7 54 The System Activities— A Use Case/Scenario View 7 Use case analysis used to identify and define all business processes that system must support Use case – an activity a system carried out, usually in response to a user request Actor Role played by user Outside automation boundary 55 7 Use Case Diagram Graphical UML diagram that summarizes information about actors and use cases Simple diagram shows overview of functional requirements Can have multiple use case diagrams By subsystem By actor 56 7 Simple Use Case with an Actor 57 Use Case Diagram with Automation Boundary and Alternate Actor Notation 7 58 All Use Cases Involving Customer as Actor 7 59 Use Cases of an Order Entry Subsystem 7 60 7 <<Includes>> Relationship Documents 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 61 Example of Order-Entry Subsystem with <<Includes>> Use Cases 7 62 7 Developing a Use Case Diagram Underlying conditions for describing use cases Based on automated system, e.g. users “touch” the system Assume perfect technology condition Iterate through these two steps Identify actors as roles List goals, e.g. use cases, for each actor. A goal is a unit of work. Finalize with a CRUD analysis to ensure completeness 63 7 Activity Diagrams Used to document workflow of business process activities for each use case or scenario Standard UML 2.0 diagram Can support any level of use case description; a supplement to use case descriptions Helpful in developing system sequence diagrams 64 7 Activity Diagram— Telephone Order Scenario 65 7 Activity Diagram— Web Order Scenario 66 Identifying Inputs and Outputs— The System Sequence Diagram Interaction diagram – a communication diagram or a sequence diagram System sequence diagram (SSD) is type of UML 2.0 interaction diagram Used to model input and output messaging requirements for a use case or scenario Shows sequence of interactions as messages during flow of activities System is shown as one object: a “black box” 7 67 7 SSD Notation Lifeline or object lifeline is a vertical line under object or actor to show passage of time for object Message is labeled on arrows to show messages sent to or received by actor or system Actor is role interacting with the system with messages Object is the component that interacts with actors and other objects 68 System Sequence Diagram (SSD) Notation 7 69 7 SSD Lifelines Vertical line under object or actor If vertical line dashed Shows passage of time Creation and destruction of thing is not important for scenario Long narrow rectangles Activation lifelines emphasize that object is active only during part of scenario 70 7 SSD Messages Internal events identified by the flow of objects in a scenario Requests from one actor or object to another to do some action Invoke a particular method 71 7 Repeating Message 72 Developing a System Sequence Diagram Begin with detailed description of use case from fully developed form or activity diagram Identify input messages Describe message from external actor to system using message notation Identify and add any special conditions on input message, including iteration and true/false conditions Identify and add output return messages 7 73 Activity Diagram of the Telephone Order Scenario 7 74 Resulting SSD for the Telephone Order Scenario 7 75 7 SSD of the Web Order Scenario for the Create New Order Use case 76 Identifying Object Behavior— The State Machine Diagram State machine diagram is UML 2.0 diagram that models object states and transitions 7 Complex problem domain classes can be modeled State of an object A condition that occurs during its life when it satisfies some criterion, performs some action, or waits for an event Each state has unique name and is a semipermanent condition or status Transition The movement of an object from one state to another state 77 Simple State Machine Diagram for a Printer 7 78 State Machine Terminology Pseudostate – 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 7 79 Composite States and Concurrency— States within a State 7 80 Concurrent Paths for Printer in the On State 7 81 Rules for Developing State Machine Diagram Review 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 correct order and review for independent and concurrent paths Expand each transition with message event, guardcondition, and action-expression Review and test each state machine diagram 7 82 States and Exit Transitions for OrderItem 7 83 7 Partial State Machine for OrderItem 84 7 Final State Machine for OrderItem 85 Order Domain Class for RMO— States and Exit Transitions 7 86 First-Cut State Machine Diagram for Order 7 87 Second-Cut State Machine Diagram for Order 7 88 7 Integrating Object-Oriented Models Complete use case diagram is needed to understand total scope of new system Domain model class diagrams should also be as complete as possible for entire system With iterative approach, only construct use case descriptions, activity diagrams, and system sequence diagrams for use cases in iteration Development of a new diagram often helps refine and correct previous diagrams 89 Relationships Between OO Requirements Models 7 90
