© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard.

Slides:



Advertisements
Similar presentations
© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard.
Advertisements

Software Design Process A Process is a set of related and (sequenced) tasks that transforms a set of input to a set of output. Inputs Outputs Design Process.
Chapter 7 Structuring System Process Requirements
MIS 325 PSCJ. 2  Business processes can be quite complex  Process model: any abstract representation of a process  Process-modeling tools provide a.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Use-case Modeling.
Chapter 15 Design, Coding, and Testing. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard.
Chapter 2 Accountants as Business Analysts
Software Design Processes and Management
Unified Modeling Language
Chapter 7 Structuring System Process Requirements
Karolina Muszyńska Based on: S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2.0 w modelowaniu SI”
Software Engineering EKT 420. What is Activity Diagram Activity diagrams are graphical representations of workflows of stepwise activities and actions.
USE Case Model.
Use Case Diagrams – Functional Models Chapter 5. Objectives Understand the rules and style guidelines for activity diagrams. Understand the rules and.
1 © 2005 course technology University Of Palestine Chapter 6 Storyboarding the User’s Experience.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 21. Review ANALYSIS PHASE (OBJECT ORIENTED DESIGN) Functional Modeling – Use case Diagram Description.
© 2005 course technology1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard Podeswa.
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Software Development Process and Management (or how to be officious and unpopular)
© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard.
Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 3rd Edition Copyright © 2009 John Wiley & Sons, Inc. All rights.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
1 © 2005 course technology1 1 1 University Of Palestine Chapter 5 (Cont.) Scoping the IT Project with System Use Cases.
1 © 2005 course technology University Of Palestine Chapter 6 (cont.) Storyboarding the User’s Experience.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1 Requirements Management with Use Cases.
1 Chapter 4 Analyzing End-to-End Business Processes (cont.)
1 Structuring Systems Requirements Use Case Description and Diagrams.
© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard.
© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard.
1 Chapter 4 Analyzing End-to-End Business Processes.
1 Chapter 4 Analyzing End-to-End Business Processes.
© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard.
Systems Analysis and Design in a Changing World, 6th Edition
UML as a Specification Language for Embedded Systems. By, Mir Ahmed Ali, Asst. Professor, ECM department, SNIST. By, Prof. Narsiah sir, Director of School.
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
1 Modeling System Requirements with Use Cases. 2 Why Do We Need Use Cases? Primary challenge in a system design process –ability to elicit correct and.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
CS212: Object Oriented Analysis and Design Lecture 34: UML Activity and Collaboration diagram.
A Student Guide to Object-Oriented Development
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
UML (Unified Modeling Language)
Chapter 3: Introducing the UML
UML - Development Process 1 Software Development Process Using UML.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th Edition Copyright © 2015 John Wiley & Sons, Inc. All rights.
Engineering Quality Software Week02 J.N.Kotuba1 SYST Engineering Quality Software.
General Cost Center Planning
Business Process and Functional Modeling
Activity Diagrams.
Chapter 4: Business Process and Functional Modeling, continued
Systems Analysis and Design in a Changing World, 4th Edition
Unified Modeling Language
Visit for more Learning Resources
Activity Diagrams.
Software Engineering Chapter 5 (Part 3) System Modeling Dr.Doaa Sami.
Asset Acquisition through Direct Capitalization
Other UML Diagramming Techniques
Project Management Process Groups
Software Design Lecture : 15.
Engineering Quality Software
Applied Software Project Management
Presentation transcript:

© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard Podeswa Instructor: Mr. Ahmed Al Astal Chapter 4(Cont.) Analyzing End-to-End Business Processes

© 2005 course technology2 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Business Case [Describe the business rationale for this project. This section may contain estimates on cost/benefit, ROI (Return On Investment), payback (length of time for the project to pay for itself), market share benefits, and so on. Quantify each cost or benefit so that business objectives may be measured post-implementation The estimates at this stage are ballpark only. Revise estimates periodically as the project progresses.]

© 2005 course technology3 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Business Case (Cont.)  Initial investment = 2 US$50,000/yr = $100,000. Hardware: Use existing PCs at office location.  Annual cost : 1 new half-time position, IT maintenance staff = US$25,000/yr  Annual benefits : Reduce administration staff by 2 due to automatic generation of reports to funders and increased efficiency of case tracking = US$60,000/yr  ROI (Return On Investment) = ([Annual benefit] – [Annual cost])/[Initial investment] = (60,000 – 25,000)/ 100,000 = 35%  Payback period = [Initial investment]/ ([Annual benefit] – [Annual cost]) = 100,000/(60,000-25,000) = 2.9 or approximately 3 years

© 2005 course technology4 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Timetable Only a ballpark timetable can be provided at this stage. Analysis: To begin 1 month after the project is approved to go beyond Initiation. Execution: To begin 3 months after the project is approved. Testing: Verification of requirements and planning of requirements-based testing to begin during Execution. Actual tests of software to be run as modules become available. Close-Out: To begin 6 months to 1 year after project is approved. Close-out to take 1 month.

© 2005 course technology5 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Business Use Cases [Complete this section if the project involves changes to the workflow of end-to- end business processes. Document each end-to-end business process affected by the project as a business use case. If necessary, describe existing workflow for the business use case as well as the new, proposed workflow.] Business Use Cases [Business use-case diagrams describe stakeholder involvement in each business use case.] Business Use-Case Descriptions [Describe each business use case with text and/or an activity diagram. If you are documenting with text, use an informal style or the use-case template, introduced later in this book, when system use cases are described.]

© 2005 course technology6 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Actors [Actors are people, organizations, or other entities that interact with a system. In this section, describe the actors that participate in the execution of business use cases. I have split these actors into the following: Workers: Parties who work within the business. Business Actors: External parties that interact with the business. Other Systems: Other IT systems that take part in the business use cases.]

© 2005 course technology7 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Workers List and describe stakeholders who act within the business in carrying out business use cases. Department/Position General Impact of Project Convener (Member of the CPP). Will use it to update cases and administer payments. CPP General Admin (Member of the CPP). Will use it to perform administrative functions, such as updating Peace Committees and members in the system.

Case Study D1: Business Use-Case Diagrams (Cont.) Business Actors [List and describe external parties, such as customers and partners, who interact with the business.] ActorGeneral Impact of Project Facilitator A member of the community trained to facilitate Peace Gatherings. Monitor A member of the community assigned to monitor parties’ compliance with plan of action agreed to during Peace Gathering. Current manual process will remain in place. © 2005 course technology8 University Of Palestine

© 2005 course technology Case Study D1: Business Use-Case Diagrams (Cont.) Business Actors (Cont.) ActorGeneral Impact of Project Peace Committee An organization set up within a community and consisting of local members of the community, trained by the CPP to assist in dispute resolution. Current manual process will remain in place. Will need to report to head office about any changes to the organization, membership, etc. Peace Committee Member A member of a Peace Committee. A local trained by the CPP to assist in dispute resolution. The IT system will send notification of payment for services. 9 University Of Palestine

© 2005 course technology10 Case Study D1: Business Use-Case Diagrams (Cont.) Business Actors (Cont.) ActorGeneral Impact of Project Government Body Represents any government organization that receives reports from the new system. Peace Committee Member. Funder Source of CPP funding. The IT system will send analytical reports. University Of Palestine

© 2005 course technology11 Case Study D1: Business Use-Case Diagrams (Cont.) Other Systems List computer systems potentially impacted by this project. SystemGeneral Impact of Project AP System Existing system for tracking accounts payable. This system must remain in place. Role Map [The role map describes the roles played by actors (users and external systems) that interact with the IT system.] TBD: This section will be completed later during Initiation. University Of Palestine

© 2005 course technology12 The resulting Business Use Case University Of Palestine

© 2005 course technology13 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) User Requirements [Describes requirements for automated processes covered by the project from a user perspective.] TBD: Portions of this section will be completed later in the Initiation; other portions will be added during Analysis, as described below. System Use-Case Diagrams [System use-case diagrams describe which users use which feature and the dependencies between use cases.] TBD: This section will be completed later during Initiation.

© 2005 course technology14 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) System Use-Case Descriptions [During Initiation, only short descriptions of the use cases are provided. During analysis, the following template is filled out for each medium- to high- risk use case. Low-risk use cases may be described informally. This template may also be used to describe the business use cases documented elsewhere in the BRD.] TBD: Later in the Initiation, short descriptions of the system use cases will be provided as well as detailed descriptions of selected high-risk system use cases, for example, those that are to be developed early because they involve new and poorly understood technology.

© 2005 course technology15 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) State Machine Diagrams [Insert state-machine diagrams describing the events that trigger changes of state of significant business objects.] TBD: This section will be completed during Analysis. Nonfunctional Requirements [Describe requirements not covered in the use-case documentation.] (TBD) Business Rules [List business rules that must be complied with throughout the system (for example, for a flight reservation system, the rule that the baggage weight on an aircraft must never exceed a given maximum). If an external rules engine is being used, this section should refer the reader to the location of these rules.] (TBD)

© 2005 course technology16 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) State Requirements [Describe how the system’s behavior changes when in different states. Describe the features that shall be available and those that shall be disabled in each state.] (TBD) Testing State [Describe what the user may and may not do while the system is in the test state.] (TBD) Disabled State [Describe what is to happen as the system goes down (that is, how it “dies gracefully”). Clearly define what the user will and will not be able to do.] (TBD)

© 2005 course technology17 University Of Palestine Case Study D1: Business Use-Case Diagrams (Cont.) Static Model [During Initiation, only strategic classes are modeled.] (TBD) …………………………….

© 2005 course technology18 University Of Palestine Step 1a ii: Scope Business Use Cases (Activity Diagram) Now that you have a business use-case diagram that matches up stakeholders with business processes, you can begin to plan the next stage of the interviews. Each interview should focus on a subset of the business use cases. The purpose of these interviews is to analyze the workflow of each business use case. Workflow means the sequencing of activities and (optionally) a clear designation of who carries out each activity.

© 2005 course technology19 University Of Palestine Step 1a ii: Scope Business Use Cases (Activity Diagram) (Cont.) You can Use formal Methods to describe the work flow like use-case template provided earlier. Or you can use informal methods like Diagrams that describes the work flow of the business use case (Activity Diagram,…..). The following table summarizes some of the diagrams commonly used to describe workflow.

© 2005 course technology20

© 2005 course technology21 University Of Palestine Activity Diagrams for Describing Business Use Cases: The activity diagram is the one most useful to the IT BA for depicting workflow. Activity Diagram without Partitions: Following we will show a diagram that describes the process Initiate Peace Gathering, a sub-goal of the business use case Manage case. Initiate Peace Gathering is the process of setting up a Peace Gathering to deal with a case (dispute).

© 2005 course technology22 University Of Palestine Activity Diagrams for Describing Business Use Cases: Activity Diagram Elements: Initial node: Indicates where the workflow begins. Control flow: An arrow showing the direction of the workflow. Activity: Indicates a step in the process. Decision: A diamond symbol, indicating a choice. Workflow will proceed along one of a number of possible paths, according to the guard conditions.

© 2005 course technology23 University Of Palestine Activity Diagrams for Describing Business Use Cases: Activity Diagram Elements (Cont.): Merge: Use this symbol if you wish to follow best practices when a number of flows lead to the same activity and your intention is that any of the flows would lead to the activity. Guard condition: A condition attached to a control flow. When the guard condition is true, workflow may flow along the control flow. Guard conditions are usually attached to control flows that come out of a decision symbol.

© 2005 course technology24 University Of Palestine Activity Diagrams for Describing Business Use Cases: Activity Diagram Elements (Cont.): Event: A trigger attached to a control flow. An event must occur for the flow to move along the control flow. Fork and join: Bars used to document parallel activities. A fork indicates the point after which a number of activities may begin in any order. A join indicates that workflow may commence only once the parallel activities that flow into it have all been completed. Final node: Indicates the end of the process.

Activity diagram describing workflow for the business use case Initiate Peace Gathering. See Book Page 72

University Of Palestine A diagram using fork and join

University Of Palestine A control flow labeled with an event

University Of Palestine Activity Diagrams for Describing Business Use Cases: Nested Activities UML also allows you to put an entire mini–activity diagram inside an activity symbol. In this Figure the initial node indicates the beginning of the activity, organize interviews, and the final node indicates its end.