UML Use Cases: Transforming Requirements into Context Maps

A working model using mission-driven measures in a team approach enables focus on effective solutions.
2.3 (25 ratings)
Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
189 students enrolled
$19
$50
62% off
Take This Course
  • Lectures 32
  • Length 1.5 hours
  • Skill Level Intermediate Level
  • Languages English
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
    Certificate of Completion
Wishlisted Wishlist

How taking a course works

Discover

Find online courses made by experts from around the world.

Learn

Take your courses with you and learn anywhere, anytime.

Master

Learn and practice real-world skills and achieve your goals.

About This Course

Published 5/2015 English

Course Description

This course provides you with the skills and knowledge to develop effective Requirements through Use Case Analysis and Design ...

Software is Magic from the Mind … it’s the Opposable Thumb for technical entrepreneurship, innovation & architecture … from the DNA Riddle, to television, computers, and the cell phone. Software is being used to develop solutions to our climate change problem with smart leaders like Steve Jobs, Bill Gates, & Barack Obama … Celebrating Christmas & what 2016 innovation can bring to our world!! Are you ready to begin your journey into the future?

In the development of modern business information systems, a growing list of acronyms seems to render the challenge seemingly all but unmanageable.

Please allow me to introduce myself, I'm Chuck Morrison, an MBA and PMP certified Senior Program/Projects Manager and Business Architecture Professional with extensive and diverse experience in Program/Project Management and Business Architecture.

Based on extensive related hands-on practical experience, this course provides you with the skills and knowledge to effectively and efficiently discover skills and knowledge needed to provide valuable solutions for business and IT.

Learn to Transform Requirements into UML Use Cases course authored by Chuck Morrison, MBA, PMP with over 25 years Program Management and Business Architecture experience in Silicon Valley California.

Frederick Brooks “Mythical Man Month", George Santayana “Reason in Common Sense", and Christopher Alexander “The Timeless Way of Building" each shared key insights into how a system, software, and projects should be conducted to capture and elaborate the critical needs and wants of any enterprise … business, public, or political. Scoping, capturing and developing the right requirements for the right solution in an ever-changing environment is just as important if not more so then when they wrote about information technology.

All affected stakeholders including sponsors, subject matter experts, and other resources must be involved in collaborative development of the functionality and constraints of workflow model needed to support business automation and related make-buy decisions. This requires the leadership, skills, and knowledge or experiences analyst and architects capable of supporting an effective business requirements model.

Use case analysis and design is an effect method for capture, analysis, and development of an effective and appropriate business model and required technical architectures and support. Major keys emphasized during the course are collaboration, listening, analysis, and modeling techniques needed for effective business requirements and supportive information technology solutions. This course is based on insights pioneer winners of the Turing Award to help you support effective solutions and decisions regardless of your role.

If during this course, or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancements and/or adjustments. I look forward to hearing your comments and suggestions.

Again! Please! You be the judge! If during this course or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancement and/or adjustments. I look forward to hearing your comments and suggestions.

I’m looking forward to sharing with you the skills and knowledge to effectively and efficiently develop and deliver requirements-based business workflows and deliverables solutions needed to support your programs and projects to make you and your organization more successful. And, I now encourage you to take full advantage of the learning opportunities this course offers.

And, please if you find my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Criteria for Writing a Review and Rating

Please remember my promise to you, if your have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

Thank You and Best Regards,

Chuck Morrison, MBA, PMP

What are the requirements?

  • Some technical experience desired.
  • Ability to collaborate and listen for business wants and needs
  • Capability to capture and define business and technical requirements
  • Interest in the fields of business analysis and information architecture
  • Ability to collect and organize tasks, activities and resources into diagrams and graphical models

What am I going to get from this course?

  • Decompose stories into requirement statements to identify Use Cases representing Functional and Non-Functional Requirements supported in a Work Breakdown Structure.
  • Give those responsible for designing, building, and/or buying the solution the kind of information they need to make the decisions right for the business.
  • Identify system behaviors actors, pre-conditions, post-conditions, relationships and constrains from base on well-defined use cases and user stories use to define functional and non-functional requirements.
  • Document and manage Business system, Stakeholder, Functional, Non-Functional, and data requirements.
  • Capture and clarify Business Rules and External Constraints that mandate limits to the delivered solution.
  • Develop measurable Solution Requirements that facilitate End-User Acceptance Testing and delivery.

What is the target audience?

  • Subject Matter Experts (SMEs)
  • Product Owners and Sponsors
  • Business Process Managers
  • Business Process Users
  • Product, Project, and Program Managers
  • Business Analysts & Architects
  • System & Software Developers

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.

Curriculum

Section 1: Why are Use Cases (User Stories) Needed?
00:41

Hello, I'm Chuck Morrison, an MBA and PMP certified Senior Program/Projects Manager and Business Architecture Professional.

My specialties are: Business Process Engineering, Software Systems Development, Cross-Functional Program and Change Management.

My significant skills and accomplishments include:

•Over 20 years of expansive and diverse experience as a Program, Project and Portfolio Manager, Consultant and Business Architect/Analyst working for companies such as VMware, HP Enterprise Services, Hawaiian Airlines and DIRECTV.

•Proven success in leading multiple, complex projects, process improvements and system migrations throughout the entire project lifecycle that generate cost savings of over $50M.

•Managed a total of 27 concurrent, highly visible CPUC Rule 20 projects according to schedule and timeline across multi-locations and sites with a total budget of $40M for Pacific Gas and Electric Company (PG&E).

•Extensive technology background with recognized business acumen to define and deliver small to large-scale, complex business process and systems infrastructure projects.

My significant accomplishments also include:

During my youth, I had the good fortune of calling home the awesome forests near Somersworth, New Hampshire, the exciting salmon runs of Adak, Alaska, and the beautiful mountains and beaches of California – from Eureka to Yosemite to San Francisco, Los Angeles, and San Diego. It was also to my good fortune in my learning experience to see and walk in every state in the United States at least once.

Later, it was my good fortune to experience the world on a global scale from the breathtaking beauty and church bells of Frankfurt and Wurzburg Germany. Next, I found myself in experience evening sky of Tokyo, Japan and Mount Fuji for atop Tokyo Tower, followed by the bright red skies of Taipei in Taiwan and Manila Bay in the Philippines, then the busy international harbor of Kowloon near Victoria City, Hong Kong, and the intricate vistas on the Tonkin Gulf near Hai Phong as well as the rugged coastline near Ho Chi Minh City (formerly Saigon) Vietnam, and the exuberant beauty of the Sidney, Australia harbor.

And, please if you find my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Criteria for Writing a Review and Rating

Please remember my promise to you, if your have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

Are you ready to get started?

Thank You and Best Regards,
Chuck Morrison, MBA, PMP

02:44

Introduce self to class

Welcome and thank you for joining our course. Please take a moment to introduce yourself to me and the other students in our class using our Udemy Course Discussions to add then post your introduction.

Just include a little information about yourself including your name and location You don't have to be specific about location if you prefer … just include your state or city or country. Also, please let us know where you’re coming from.

Are you working full-time, is this your first time taking or creating and online course, are you working full or part? Is this your first time creating your own online business, or making money online. Do you have a website? If so, please include your website address so we can find out a little more information about you and start following you on your own channel. If you’re on Facebook, Twitter, LinkedIn, or other social media, please let us know your contact information if you want to share.

Please contact me with any questions or suggestions you may have about our course.

If during this or any other of my courses, or after you’ve completed any of my courses, you have any questions or related suggestions for improvement; please don’t hesitate to contact me using Udemy’s Instructor Messaging system.

Simply click the Blue “Add Discussion” button then add you information and comments to the dialog box. When finished click the Green “Post” button. That’s it … it’s that easy for communication with me and other student on Udemy.

Remember, you have my promise to work with you to find an answer for your questions and suggestions, which may include course enhancements and/or adjustments or reviews and ratings. I look forward to hearing your comments and suggestions.

And, please after completing any of my courses or if you find this course or any of my courses useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for any course then click and enter your review and rating.

I'm excited to meet you and just as I did in my “Welcome” video giving information about myself, I really am excited to get to know you better. Please take just 30 seconds to introduce yourself to the course; I will highly appreciate it. See you in the next video lecture.

Thank You and Best Regards, Chuck

05:03

In the development of modern business information systems, a growing list of acronyms seems to render the challenge seemingly all but unmanageable.

Further, the increasing adoption of virtualization with the continuous transition to Cloud Computing platforms, modern business information systems have become an increasingly complex and dynamic context. This raises the challenge of guaranteeing system performance, scalability, and reliability while simultaneously ensuring efficient resource usage. A model-based methodology is presented as needed to meet this awesome challenge. State-of-the-art predictive modeling, architecture, and management approaches for deriving effective solutions meet the challenge of providing high-level business services through proven methods and methodology in our modern business context.

According to studies performed by companies such as the Gartner Group, the Standish Group, and IDC, an astonishingly large portion of development projects fail to come up with anything useful at all. An even larger portion is challenged for reasons such as not supporting business needs. When businesses need to change fast to keep up with customer needs and with competition, software is often mentioned as the show stopper; the software used is often too complex and too unrelated to the business to allow the business to change as fast as necessary.

Business software exists for one reason only: to support the business and its activities, or to help change the way business is performed. There's no other reason for business software.

To support this need, this course introduces …

System Use Case/Requirements-Based Modeling … decision support approach

An Information System is as a set of interacting components providing a set of services. Component based modeling serves a methodology for capturing requirements of an Information System from a business and user perspective at various software development states. The methodology supports clarification of details through functional decomposition and creation of user and information system interactions using use case model context diagrams. System components and interactions are derived to reflect the business domain using model-view-controller framework of components and services provided for meeting the requirements of the business domain.

This course “UML Use Cases: Transforming Requirements into Context Maps” is designed to help you get past the acronyms of modern information systems by providing you with a methodology to answer the challenges you must face … the challenge of designing modern business information system requirements though an object-oriented workflow modeling architectural approach.

Successful completion of this course will help you manage the change needed to meet the challenges of bringing Requirements Order Out of Chaos solutions through Software Architecture derived from Use Cases Modeling.

Why are workflow models needed …
A working model using mission-driven measures in a team approach enables focus on effective solutions.

01:18

Discussion –

  • You and your team are responsible for safety and security of major business system deliveries and were just notified that one of your deliveries crashed and everyone is waiting for your next application delivery.
  • You're part of a team that must support the company's production control and logistics delivery operation for several critical customers with symptoms you and your team have never seen nor heard of before.
  • More precisely, customers are beating down your companies doors for must-have immediate delivery of products and services without a page written about processes or procedures and people you've never met who do not know what to do next and you haven't even a clue about what happened, when, or what's the impact on time or resources or security and safety related issues.
  • What do you do, where do you begin …

By completing this course, you will posses the set of tools and guidelines needed create your action plan and move forward to resolving business and technical problems and issues using Uniform Modeling Language (UML) Use Case related methodologies and processes to discover project requirements to ensure value of product and service delivery to customer with minimal time, costs and risks.

So, are you ready to get started?

01:25

Lecture 4 First, please allow me to share a few Related Quotes:

•The hardest single part of building a software system is deciding precisely what to build (… and, exactly where to begin). – Frederick Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering.”

•Those who cannot remember ( … learn from) the past are condemned to repeat it. – George Santyana, “The Life of Reason: Volume 1, Reason in Common Sense.”

•There is one timeless way of building. It is a thousand years old, and the same today as it has always been … – Christopher Alexander, “The Timeless Way of Building.”

Use Cases are an important requirement technique widely used in modern software engineering formally introduce by Ivar Jacobson in 1992.

Use case driven development is a key characteristic of process models and frameworks such as the Unified Process (UP), Rational Unified Process (RUP), and Oracle Unified Method (OUM). With its iterative and evolutionary nature, the use case is also a good fit for agile development.

01:08

Lecture 5 Why Are Use Case Workflow Models Needed? … to learn from the past and the unknown.

•Analyze What (Requirements – Scope, Context, Scenarios)

•Decompose Functional System Behavior – Value

•Divide Roles, Data, and Rules from System Behaviors

•Measure/Validate Goals and Tasks in Context

•Estimate Project Build and Release Schedule and Resources

•Separate Function from User Interface and Technology

05:59

This course provides you with the skills and knowledge needed to:

Based on my extensive related hands-on practical experience in Silicon Valley high tech, this course provides you with the skills and knowledge to effectively and efficiently design and develop needed requirements-based business workflows and deliverables solutions needed to support your programs and projects for business and information technology organizations.

Recently, I've authored and published 6 Udemy courses and 6 Amazon Kindle books and am in the process of authoring several more, because as I've discovered teaching and writing are truly my passions.

The “UML Use Cases: Transforming Requirements into Context Maps” course is authored by Chuck Morrison, MBA, PMP with over 25 years Program Management and Business Architecture experience in Silicon Valley California. Also, authored and published Udemy professional training courses and Amazon Kindle books including: UML Use Cases: Transforming Requirements into Context Maps, Logical Troubleshooting & RCA: Learn What You Need to Know, Agile SCRUM: Learn Agile Development for Project Managers, Project Management Office: Learn How the PMO Functions, Safety and Security: Learn CISSP Domains for Project Managers, Workflow & WBS: Develop Requirements-based Deliverables …

Frederick Brooks “Mythical Man Month", George Santayana “Reason in Common Sense", and Christopher Alexander “The Timeless Way of Building" each shared key insights into how a system, software, and projects should be conducted to capture and elaborate the critical needs and wants of any enterprise … business, public, or political. Scoping, capturing and developing the right requirements for the right solution in an ever-changing environment is just as important if not more so then when they wrote about information technology.

Use case analysis and design is an effect method for capture, analysis, and development of an effective and appropriate business model and required technical architectures and support. Major keys emphasized during the course are collaboration, listening, analysis, and modeling techniques needed for effective business requirements and supportive information technology solutions. This course is based on insights pioneer winners of the Turing Award to help you support effective solutions and decisions regardless of your role.

Critical processes emphasized during this course are collaboration, listening, analysis, and modeling techniques needed for effective and efficient system operations solutions. This course helps you develop the skills and knowledge needed to support effective solutions and decisions regardless of your role.

All affected stakeholders including sponsors, subject matter experts, and other resources must be involved in collaborative development of the functionality and constraints of workflow model needed to support business automation and related make-buy decisions. This requires the leadership, skills, and knowledge or experiences analyst and architects capable of supporting an effective business requirements model.

As stated previously, “UML Use Cases: Transforming Requirements into Context Maps” provides you with the needed skills and knowledge to effectively and efficiently design and develop requirements-based business workflows and deliverables needed to support your programs and projects for business and IT organizations. During each lecture you’ll be presented with information and material found useful to others while developing workflows and deliverables for their own organizations. Remember, however, lectures and demonstrations can only help you so far. It’s up to you to learn then take advantage of the methods and tools presented.

If during this course, or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancements and/or adjustments. I look forward to hearing your comments and suggestions.

Again! Please! You be the judge! If during this course or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancement and/or adjustments. I look forward to hearing your comments and suggestions.

I’m looking forward to sharing with you the skills and knowledge to effectively and efficiently develop and deliver requirements-based business workflows and deliverables solutions needed to support your programs and projects to make you and your organization more successful. And, I now encourage you to take full advantage of the learning opportunities this course offers.

And, please if you find my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Criteria for Writing a Review and Rating

Please remember my promise to you, if your have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

Are you ready to get started!

Thank You and Best Regards,
Chuck Morrison, MBA, PMP

04:45

Discussion –

  • Learn to decompose stories into requirement statements to identify Use Cases representing Functional and Non-Functional Requirements supported in a Work Breakdown Structure

  • Give those responsible for designing, building, and/or buying the solution the kind of information they need to make the decisions right for the business

  • Identify system behaviors actors, pre-conditions, post-conditions, relationships and constrains from base on well-defined use cases and user stories use to define functional and non-functional requirements

  • Document and manage Business system, Stakeholder, Functional, Non-Functional, and data requirements

  • Capture and clarify Business Rules and External Constraints that mandate limits to the delivered solution

  • Develop measurable Solution Requirements that facilitate End-User Acceptance Testing and delivery

  • Provides functional requirements capturing tool.
  • Tool for decomposing system into manageable pieces (Work Breakdown Structure).

  • Enable collaboration of sponsors, users, & stakeholders about system functionality in business language.

Completion of this course enables identifying, assigning, tracking, controlling, and managing activities based on UML Use Case methodology.

Further, completion aids capture & development of portfolio/program/project scope, effort, risk, budget and schedule.

Skills and knowledge from this course aids capture & development of business information requirements through UML Use Case Analysis for effective portfolio/program/project delivery meeting scope, effort, risk, budgeting and scheduling requirements for your organization.

To achieve our course goals, the course is delivered using sections, lectures, quizzes, out-of-class exercises, and downloads. Also included with your course is a glossary and further reading references. As each section is presented, the section’s goals will be discussed and related lectures introduced.

During lectures, key concepts will be first presented then demonstrated as appropriate. Students are encouraged to use skills and knowledge discussed and demonstrated outside of class in their own work as much as possible to enhance learning success. During course lectures or outside lectures, students are further encouraged to ask questions or make comments and suggestions using Udemy’s Instructor Messaging service to contact me so I may do related research then get back to the student promptly with results.

And, please if you find my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Criteria for Writing a Review and Rating

Please remember my promise to you, if your have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

00:36

Lecture 8 –What are the course requirements? Intermediate technical level …

Discussion –

During this course you’ll gain skills and knowledge to develop and deliver requirements-based business workflows and deliverables solutions as you develop and enhance these core competencies based on our course goals…

  • Some technical experience desired.
  • Ability to collaborate and listen for business wants and needs
  • Capability to capture and define business and technical requirements
  • Interest in the fields of business analysis and information architecture
  • Ability to collect and organize tasks, activities and resources into diagrams and graphical models
00:24

Lecture 9 – Who’s the Target Audience?

Discussion –

“UML Use Cases: Transforming Requirements into Context Maps" provides you with the skills and knowledge to effectively and efficiently develop requirements-based business workflows and deliverables solutions needed to support your programs and projects.

  • Subject Matter Experts (SMEs)
  • Product Owners and Sponsors
  • Business Process Managers
  • Business Process Users
  • Product, Portfolio, Project, and Program Managers
  • Business Analysts & Architects
  • Quality Assurance
  • System & Software Developers

Note: "UML Use Cases: Transforming Requirements into Context Maps" is an intermediate level course.

What are Use Cases?
3 questions
Section 2: Use Case Modeling ... What Is It?
05:35

Discussion –

To achieve our course goals, this course is delivered using sections, lectures, quizzes, out-of-class exercises, and downloads. Also included with your course is a “glossary” and “further reading references”. As each section is presented, the section’s goals will be discussed and related lectures introduced.

During lectures, key concepts are first presented then demonstrated as appropriate. Students are encouraged to use skills and knowledge discussed and demonstrated outside of class in their own work as much as possible to enhance learning success. During course lectures or outside lectures, students are further encouraged to ask questions or make comments and suggestions using Udemy’s Instructor Messaging service to contact me so I may do related research then get back to the student promptly with results.

What is a Requirement? “The Swing” … Anonymous …

  • How the customer explained it
  • How the Project Leader understood it
  • How the Analyst designed it
  • How the Programmer wrote it
  • How the Business Consultant described it
  • How the project was documented
  • What Operations installed
  • How the Customer was billed
  • How it was supported
  • What the customer needed!

A requirement is a measurable action or set of actions that a system must do (behaviors and functions). It may also be a measurable quality or property that a system must have (attributes and persistence). Requirements must capture what is needed to satisfy the client's business processing needs and expectations in the delivered system. Requirements are categorized as three types: Functional, Non- functional (Performance), and Constraints. Issues are used to define risks involved in meeting requirements

Functional

A functional requirement is a service or set of services that provide value to a system's users and other stakeholders. Functional requirements:

•Define actions a system must do to provide value for its clients

•Are event-driven (Business Events, Business Rules)

•Are role-based system behaviors (Use Cases)

•Define the essence of a delivered system i.e., the system's reason for existence.

Collectively, functional requirements set the scope and context (bounds-of-automation) for a given application or component.

Example: The system must be capable of generating a return material authorization (RMA) and replacement gateway release for shipment to the customer using a single transaction.

Non-Functional

Non-functional requirements are characteristics (features), or qualities, that a system must have and are often critical to its success. Non-functional requirements are often “attached” to the system's functional requirements i.e., usability, robustness, maintainability, portability, scalability, configurability, extensibility, security, capacity, measurability, consistency, resilience, etc. Collectively, the non-functional requirements provide the features needed in the system's infrastructure.

Example: The system must provide defect-free (less than 1% defective serial-number captures), gateway serial-number recording for RMA replacement gateway shipment.

Constraints

Constraints are global requirements. Constraints are externally imposed limitations on system requirements e.g., maintenance of access/connectivity with a legacy system, use of a specific platform such as MS NT, UNIX, VMS, use of a specific language such as JAVA, C++, MS Visual Basic, use of a specific persistence mechanism such as MS SQL Server, Oracle, Informix, DB2, use of a specific transport protocol/format such as HTTP(S)/XML(DTD), CORBA, Vitria, STC SeeBeyond, or use of a specific framework such as Seibel CRM or SAP ERP. Constraints limit technical decision-making and problem-solving capabilities.

Example: Address Information must be scrubbed using Code 1 before each RMA replacement gateway submission to 3rd party database.

Issues

Issues are potential constraints on the success of a project and may include associated benefits, risks, costs, delays, and resources. Issues define constraints on user documentation, testing, training, deployment, and related system releases.

Example: Code 1 must be available prior to RMA replacement gateway shipment transaction testing.

01:30

Provides functional requirements capturing tool.

Tool for decomposing system into manageable pieces (Work Breakdown Structure).

Enable collaboration of sponsors, users, & stakeholders about system functionality in business language.

Enables identifying, assigning, tracking, controlling, and managing system development activities.

Aids capture & development of project scope, effort, and schedule.

Support of test planning and test cases definition.

Supports user documentation baseline.

Provides requirements traceability tool.

Determine identification of data objects or entities starting point.

Supports specification of user design and system interfaces.

Supports definition of database access requirements.

Enables framework/model for system development project.

02:09

Object Oriented Systems Workflow Context Model Views Architectural Framework

Discussion –

In this lecture we’ll discuss the object oriented use case modeling context. The modeling context is about how to review the architectural framework and that’s what we’ll be setting up after we moved through into actual physical use case development.

As you can see the object oriented systems context workflow model view’s architectural framework contains five different views.

Views

  • User
  • Structural
  • Behavioral
  • Implementation
  • Environment


The first is the user view containing your use case diagrams. It’s basically the top of the chart. That's going to be the first thing we capture and decompose.

Next we can dissect and decompose into the structural view. This section contains the can composite structural diagram, our package diagrams, our object diagrams, and our class diagrams. These represent containers and packages we’ll use for programming and development.

Next we decompose the implementation view shown in the blue area. And as you can see in the implementation view we capture component diagrams. Component diagrams will be a part of what we assemble for the services and software to support the use cases.

In the bottom left quadrant we discover the behavioral view which provides activity diagrams, sequence diagrams, collaboration diagrams, state machine diagrams, and interaction overview diagrams. These and the objects seen in the previous quadrants you will normally think of as components of an object-oriented architectural framework.

In the lower right or pink quadrant, we represent the environmental view. This is where we contain all of our deployment diagrams.

Overall, this is a Venn diagram referred to as the workflow framework model for our object-oriented architectural framework model context.

02:37

Discussion –

In the roadmap diagram there are two axes. One is the horizontal axis which shows the PMBOK process groups including the initiation phase. Also, on the landscape diagram image you see initiation is referred to as the inception or discovery phase. This can also be referred to as the PMBOK planning phase.

System Landscape (Roadmap) Diagram

Process Groups

•Initiating (Inception (Discovery))

•Planning (Elaboration (Analysis/Design))

•Executing (Develop)

•Monitoring & Controlling (Configuration, Deployment, Transition, Change Control)

•Closing (Closure)

Knowledge Areas

•Integration

•Scope

•Time

•Cost

•Quality

•Human Resources

•Communication

•Risk

•Procurement

Next to initiation in the landscape diagram, you'll see the elaboration also referred to as analysis and design which follows and extends planning.

The third box is construction also referred to as executing or development. This is where developers get involved during initiation of the project.

The next group is monitoring and control which includes QA and UAT also referred to as configuration, transition or deployment, and change control. These groups and sub-groups are where you control what's going on in the process, making sure everything is happening at the correct time, resources are in place, and that the process moves go through configuration deployment transition and change control. Procurement may also be included within these groups.

These groupings are where you manage the project. The final group is where you close the project. Closure is the last group at the top of the horizontal axis of the landscape diagram.

Going down the left side of the diagram you'll find a list of who all the sponsors and stakeholders involved in the project. For example, you view the executive sponsors, the product owner, the DSG, the project manager, business analyst, technical leads, developers, QA, Configuration Control Board, and the technical writing team, the SMEs, and the users.

And, you'll notice the vertical axis is also part of the PMBOK knowledge groups. Knowledge groups contain information from integration through scope, resources, and time management. The knowledge groups are where we’ll discover and control integration, scope, time and cost management, quality control, human resources, communications, risk assessments, and project procurement.

02:56

Discussion –

System Architecture Analysis and Design Process – Decomposition

In this lecture we’ll learn about system architecture analysis and design process. You'll notice in the image on the screen that the top left section illustrates the use case diagrams and descriptions and the inputs are requests, interviews, JAD or Joint Application Development Sessions, and Standards coming into the system.

Refer to the System Architecture Analysis & Design Process drawing …

1-5 – Requests, Interviews, JAD, Standards

Use Case Diagrams & Descriptions

Activity Diagrams

Interaction Diagrams

Class/Object Diagrams & Descriptions

State Diagrams

6 – Dictionary/Repository

Deliverable Artifacts

7-8 – User Requirements Automation Bounds Test Plans Models

Prototype Models

9 – Training

10 – Technical Requirements

Construction Models

11 – Test Plan & Integration Plan

Deployment Models

12 – Release

From this what we do is we generate the use cases and descriptions and the working scenarios we use for agile, RUP or Rational Unified Process, or SDLC or System Development Life-cycle. We can also use this to generate activity diagrams and to show behavior of how the system is going to work in the workflows and participants. We’ll also look at the class and object diagrams internally for how how the system actually behaves it when the user presses a button or interacts with our user interface.

There are interaction diagrams and show what the sequence of events are and the messages returned that occur. There is a section to provide for the data structure and objects called class diagrams.

And we have what are called state diagrams or state machines that show the logic of the system and how it make decisions internally.

Also, once you put together all this information you then are able to generate user requirements, the bounds of automation or scope, the test plans and models. You can see that as number seven on the diagram. Also from here we go into the prototyping of models and packages so that we can develop our training models, our technical requirements, and our interfaces with the responsibilities collaborations and patterns.

From that we will then generate construction models to tell us how the packages and components will be assembled and the interfaces to the deliverables and artifacts so that we goes can go into our a dictionary or repository.

Then from there we also can go in and start building our test plans and our integration plans.

And finally we developed and deployment model and the release model so that we have services, the configurations, the profile nodes, and the bandwidth that are involved in the system.

So this actually shows you how everything it is combined from a structural perspective to process perspective enabling us to come up with solution requirements and enable traceability of requirements for the system solutions model.

01:47

Use cases are a powerful technique for capturing and communicating functional requirements for software development. Prior to the advent of use cases, functional requirements were typically captured by a long list of declarative statements. A typical Software Requirements Specification (SRS) used language such as “The system shall <insert requirement>...” in a long list of discrete requirements. The SRS was written from the perspective of the system. Functional requirements written in this manner lack the context and perspective for what the user actually wants to do with the system.

Use cases are written from the perspective of the user as a flow of events. The user is called an “actor” and the narrative of the flow of events between this actor and the system is called the “use case.” Use cases are literally the specific “cases” for which the actor wants to “use” the system. Use cases differ from declarative statements in two primary ways. They describe functional requirements from the user perspective rather than the system perspective, and they provide a coherent goal focused flow of events rather than a set of discrete declarative statements. A fully described use case will have a main or basic flow as well as alternate flows. The alternate flows describe regular variants to the main flow as well as error handling or unusual situations.

Use Case Models describe proposed functionality of a system. A Use Case represents a coherent, discrete unit of interaction between users (human or machine) and the system. This interaction is a single, coherent unit of meaningful work, such as Create Account or View Account Details.

Each Use Case describes the functionality needed to build in the proposed system, which can include another Use Case's functionality or extend another Use Case with its own behavior. A collection of Use Cases may be loosely coupled within a coherent component (container) of related services to facilitate effective, efficient release and delivery of functionality for achieving user goals and business value.

00:40

Discussion –

Simple Use Case Model

  • Actors (Roles)

  • Behaviors (Scenarios)

  • System (Context)

Well, if you look at the drawing on the screen, you'll see that a use case associates with things called actors, other use cases or behaviors sometimes referred to as scenarios. And, we break associations down into preconditions, post-conditions, and assumptions. The actor’s role represents people, places, things, or events. We also have what we call the system context also referred to as scope or bounds of automation.

It should be noted, that use cases may result in either physical IT solutions or simply as business policies, procedures, or processes needed to support business operations including forms as user input.

This is what we’ll talk about in the next series of lectures and slides. We’ll put this all together for you so you can see how use cases work internally and together to support your business system solution requirements.

3 questions

Are related processes performed at your organization? If so, describe the process; if not, why not?

Section 3: When Do We Use Use Cases?
00:49

Lecture 17 – When do we start use case analysis?

Discussion –

· When do we start use case analysis?

· When do we stop doing use case analysis?

During requirements elicitation (e.g., JAD, Brainstorming, …)

· Obtain agreement on major concepts – Actors, system boundaries, business use cases, Business Rules

· Make a sketch … transfer to tool later

During requirements analysis

· Ensure the right questions are asked and answered

· Supplement complex text with pictures (… worth a thousand words)

· Disambiguate text with precise models

00:20

Lecture 18 – When do we stop doing use case analysis?

Discussion –

  • When the use cases meet communication/expectation needs
  • Stakeholders reach consensus
  • Less is more
02:52

Discussion –

General comments and notes describing the use case.

Requirements – formal functionality a Use Case must provide for users to achieve goals e.g., ability to add, review, update, or delete (CRUD) an order. Requirements correspond to functional specifications found in structured methodologies i.e., “Waterfall”, and form a “contract” that the Use Case must perform specified action of value to the system (goals).

Constraints - formal rules and limitations a Use Case operates under, defining what can and cannot be done including:

•Pre-conditions – must have already occurred or be in place before the use case runs; e.g., <create order> must precede <modify order>

•Post-conditions – must be true once the Use Case is complete; for example, <order is modified and consistent>

•Invariants – must evaluate as true throughout the Use Case scenario; for example, an order must always have a customer number.

Scenario – formal, sequential description of the steps taken to carry out the use case flow of events that occur during a Use Case instance. Includes multiple scenarios needed to control exceptional circumstances and alternative processing paths resulting from decisions; i.e., textual representation of the Sequence Diagram.

Activity diagrams – activity diagrams depict workflow; similar to Scenarios but graphically portrayed.

Additional attributes – e.g., implementation phase, version number, complexity rating, stereotype (<<Include>> or <<extend>>) and status.

Use Case Analysis Effectively Supports –

•Iterative, Incremental Process (RUP, Agile) – Time-Boxed, Cross-Functional (SCRUM)

•Use Case Driven Requirements (Scope) – Discovery, Planning, Analysis, Design, Monitoring, Control: UML

•Architecture, Infrastructure Centric Development

•Flexible Guideline/Framework Adaptable to Project Needs

00:52

Lecture 20 – Use Case Analysis Effectively Supports ...

Discussion –

Decompose stories into requirement statements to identify Use Cases representing Functional and Non-Functional Requirements supported in a Work Breakdown Structure.

  • Iterative, Incremental Process (RUP, Agile) – Time-Boxed, Cross-Functional (SCRUM)

  • Use Case Driven Requirements (Scope) – Discovery, Planning, Analysis, Design, Monitoring, Control: UML

  • Architecture, Infrastructure Centric

  • Flexible Guideline/Framework Adaptable to Project Needs
02:33

Use Case Basics (toward Collaborative Conversation & Consensus)

Discussion –

Use case (UC) – visual and narrative description of a sequence of actions (story – scenario) providing measurable value to an actor – “What NOT How” – drawn as horizontal ellipse in “Verb/Object” form.

Actor – person, places, thing, time, or external system that plays a role in one or more interactions (associations) with your system; drawn as stick figure.

Association – An association exists whenever an actor interacts with a use case; indicated in use case diagrams by solid lines. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. An arrowhead indicates directionality of initial relationship invocation or indicates a use case 's primary actors; arrowheads are often confused with data flow.

System Bounds (Domain, Context, Scope) – dashed rectangle surrounding the use cases; called the system bounds box. The box represents functionality within scope or context; anything outside the box is out of scope (context). System bound boxes identify which use cases will be delivered as component packaged services in each major release of a system.

Packages (optional) – UML constructs (containers) enabling modeling of elements (such as use cases) into deliverable groups. Packages are depicted as file folders used in any UML diagrams, including use case, activity, sequence, class, or other diagrams. Use packages to organize large diagrams into smaller ones.

01:26

Use Case Relationships (Extend, Include, Generalization) …

•Include – one use case includes another; “… a Directed Relationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case“ [OMG 2008] i.e., the outcome of a given use case depends on the outcome of the included use case; useful for containing common behaviors from multiple use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label "«include»".

•Extend – one use case (the extension) extends another. The behavior of the extension use case is inserted into the extended use case under some conditions. The notation is a dashed arrow from the extension to the extended use case, with the label "«extend»". Notes or constraints are associated with this relationship to illustrate conditions when this behavior is executed. Modelers use the «extend» relationship to indicate use cases that are "optional" to the base use case.

•Generalization – A given use case may have common behaviors, requirements, constraints, and assumptions with a more general use case.

01:34

Lecture 23 – Use Cases Context Diagram… Use Case Context Diagram.png

Discussion –

Use Cases Context Diagram…

•Actors

•Context

•Use Cases

•Parking Lot

In your handout for this lecture, you'll see there is a use cases context diagram. The use cases context diagram contains actors, context, and use cases as well as a parking lot.

In the use cases diagram, you'll see that the actors are identified as entities such as the core team, organization, and system support. You'll also see there is are PD's and PMs as well as developers, BAs, and Facilities as well as a security team, QA team, and a DBA.

Also you'll notice within the context diagram, there are five contexts. One is initiated training project, one for analysis and documents requirements. Another for implementing training program materials and logistics, another for delivery of training as well as transition and close training.

Within each of those context you'll find use cases such as the constraints training audience. And you’ll find that there are established training facilities, setting high-level expectations, research project related information and so forth. So, if you would, please review the hand out and see how all context information fits together and comment make suggestions for enhancing this context diagram.

List what a Use Case description includes ...
1 question
Section 4: Activity Diagram Basics
02:39

Lecture 24 – Use Case Levels … Alistair Cockbrun “Humans and Technology” … Use Case Levels.png


Discussion –


The Use Case reveals a hierarchy of goals – the ever-unfolding story. There are many ways to write a use case in text, from use case brief, casual, outline, to fully with varied templates. Writing use cases in templates is a common industry practice to get high-quality functional system requirements. The template defined by Alistair Cockburn in Writing Effective Use Cases is a widely used writing style for use cases.


User Goals

Refer to the Use Case Levels diagram. The diagram show five levels of Use Case Goal levels suggested by Cockburn.

  • White Cloud Level – Very High Summary
  • Clear Sky Kite Level – Summary
  • Waves at Sea or Blue Sea Level – User Goal … this is the preferred level for writing use cases
  • Indigo Fish Level – Subfunction
  • Deep Indigo Clam Level – Too Low

Fully Dressed Use Case

Cockburn also describes a more detailed structure for a use case, but permits it to be simplified when less detail is needed. His fully dressed use case template lists the following fields -

  • Title: "an active-verb goal phrase that names the goal of the primary actor”
  • Primary Actor
  • Goal in Context
  • Scope
  • Level
  • Stakeholders and Interests
  • Precondition
  • Minimal Guarantees
  • Success Guarantees
  • Trigger
  • Main Success Scenario
  • Extensions
  • Technology & Data Variations List

Many of these fields are presented in greater depth in both Cockburn’s publication and in courses and eBooks written by me. Also note, according to Martin Fowler, "There is no standard way to write the content of a use case, and different formats work well in different cases."

03:20

Lecture 25 – Activity Diagram/Use Case Scenario – Diagram, Narrative …

Discussion –

Use Case Scenario – Diagram, Narrative …

  • Initial node – solid circle indicates starting point of the diagram.

  • Activity – represented by a rounded rectangle. Activities are physical, such as “Audit Record”, or electronic, such as “Display Policy Coverage”.
  • Flow/edge – arrows on the diagram.
    • Fork – black bar with one flow going into it and several leaving it. Denotes the beginning of parallel activity.
    • Join – black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue; denotes the end of parallel processing (concurrency).
  • Condition – text such as [Invalid Record] on a flow, defining a guard (pre-condition) which must evaluate to true in order to traverse a node.
  • Decision (Business Rule) – a diamond with one flow entering and several leaving. The exiting flows include post-conditions although not indicated if obvious.
  • Merge (Business Rule) – a diamond with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards (post-conditions) on the outgoing flow.
  • Swimlane (Domain, Context) – optional vertical or horizontal partitions, also called swimlanes, indicating who/what (Actor – Role) is performing the activities and decisions (either the Actor or System) in the Use Case scenario.

  • Flow Final – a solid circle within a circle indicates the scenario stops at this point.

  • Business Rule – statement defining or constraining some aspect of a business; intended to assert business structure or to control or influence the behavior and of the business. Business rules describe the operations, definitions, persistence (data, structures), and constraints associated with Actors in achieving goals.
01:24
  • Lecture 26 – Activity Diagram/Use Case Scenario – Diagram, Narrative …

Discussion –

Capture and clarify Business Rules and External Constraints that mandate limits to the delivered solution.

As you can see in the activity diagram, each set of activities is contained in a swimlane such as configure schedule, spider crawl or indexer, protected logon, user search, and other activity swimlanes as needed.

Each swimlane initiates with an initial node and may contain several connected activities or tasks. Each swimlane may also require decisions and/or loopbacks, merges, forks and/or joins to connect activities to other activities within each swimlane scenario. Upon completion of a set of swimlane activities, the sequence is terminal with as a flow final. Business rules within each decision determines the direction of flow from decisions and activities in the activity diagram.

Activity diagram symbols:

  • Initial Node(s)
  • Activities (Tasks)
  • Decisions/Merge (Loopbacks) – Forks/Joins
  • Swimlanes (Domain/Context/Scope)
  • Flow Final
  • Business Rules
List what an Activity Diagram generally includes ...
1 question
Section 5: Use Case Narrative …
03:09

Lecture 27 – What Does a Use Case Look Like?

Discussion –

Each Use Case Narrative consists of the following fields

  • Use Case Name – Action Verb/Object pair – Use Cases are triggered by events that occur NOW!!! ... not the past nor future tense.
  • Use Case Name – Unique Use Case identifier
  • Author – Who wrote the Use Case
  • Last Update – date the use case was last updated
  • Use Case Description – Describing a use case requires that we both frame the context of the use case and describe the dialog between an actor or another use case and the general sequence within the scope of a given Use Case.
  • Assumptions (Constraints) - Conditions that must evaluate as true to use a specific use case action flow. Validating these conditions (business rules) is outside the scope of a use case (contrast this with the pre-conditions and post-conditions ... or guard conditions) e.g., consider authentication or authorization-- these functions are typically handled by a standard security feature e.g., the user has provided a valid card and password.
  • Pre-Conditions - Conditions that must evaluate as true to initialize a use case. Unlike assumptions, these conditions are validated by this use case before entry into an action sequence. If the conditions are not true, the actor or other use case is refused entry.
  • Post-Conditions – Conditions that must evaluate as true when the use case ends. You may never know what comes after the use case ends, so you must guarantee that the system is in a stable state when the use case ends e.g., upon successful completion of an ATM withdrawal.
  • Use Case Dialog - A step-by-step description of the dialog between a use case (the system) and the user (actor or other use case). Very often it is helpful to model this sequence of events using a flowchart or activity diagram just as you might model a communication protocol between two business units e.g., the system asks for the withdrawal amount.
02:09

Lecture 28 – What's a Use Case Narrative Example?

Discussion –

Name: Withdraw Cash from ATM

Assumption: User provided valid ATM card and password.

Pre-Condition: The User has an Account with this Bank

Main Dialog:

  • The user selects an amount for withdrawal.
  • The ATM verifies that amount entered is within the predefined policy limits and is an amount divisible by the defined denomination, for example, multiples of $20.00.
  • If the funds are available, the ATM gives the user their money and prints a receipt.

Alternative Dialogs:

  • If the amount fails at main step 2, an error message is displayed
  • If funds not available, the user gets an error message.
  • System displays a message that it cannot connect to the bank
  • User cancels the transaction.

Termination:

  • The system dispenses the specified cash and prints a receipt.
  • The system displays a message that the entered amount is invalid.
  • The system displays a message that it could not connect with the bank.
  • The user cancels the transaction.

Post-Conditions:

  • System prints the final outcome on the receipt.
  • User account is updated.
  • Transaction logged
  • Upon error condition, ATM returns to initial state.
  • Upon receiving Cancel, ATM returns to initial state.
Section 6: Conclusion
03:31

Lecture 29 – UML Use Cases: Transforming Requirements into Context Maps - Conclusion…

Congratulations! You’ve made it! … You’ve completed all Course Goals …

Why are workflow models needed? …

Software is Magic from the Mind … it’s the Opposable Thumb for technical entrepreneurship, innovation & architecture. A working model using mission-driven measures in a team approach enables focus on effective solutions … the result? Workflow mapping is the 1st step toward enhanced Software as Magic using the Opposable Thumb of your Mind.

Course Goals

•Decompose stories into Requirement statements to identify Use Cases representing Functional and Non-Functional Requirements supported in a Work Breakdown Structure

•Learned to assign and track those responsible for designing, building, and/or buying the solution the kind of information they need to make the decisions right for the business

•Identify system behaviors actors, pre-conditions, post-conditions, relationships and constrains from base on well-defined use cases and user stories use to define functional and non-functional requirements

•Document and manage Business system, Stakeholder, Functional, Non-Functional, and data requirements

•Capture and clarify Business Rules and External Constraints that mandate limits to the delivered solution

Software is Magic from the Mind … it’s the Opposable Thumb for technical entrepreneurship, innovation & architecture. A working model using mission-driven measures in a team approach enables focus on effective solutions … the result? Workflow mapping is the 1st step toward enhanced Software as Magic using the Opposable Thumb of your Mind.

Thank you and congratulations for taking this opportunity for yourself to expand your skills and knowledge. Thank you for your decision to complete this course successfully.

And, please, if your have any questions about any part of this training or any related questions to this course or Udemy please ask. You have my promise to find you an answer.

If you found my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Criteria for Writing a Review and Rating

Please remember my promise to you, if your have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

Have a Great day and thank you so much for being a student in my online classroom. If you would like to receive inspirations, useful articles, free tutorials, observations and more, please –

Follow me on Facebook,

Subscribe to my Youtube Channel,

Connect via Twitter.

Thank You and Best Regards,

Chuck Morrison, MBA, PMP

11 pages

For definitions of terms used in this course, please see downloadable Glossary …

3 pages

Lecture 31 – For Further Reading …

OO UML developed by “The 3 Amigos” - Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software during 1994–95 with further development led by them through 1996. … Rational Software transferred to IBM … OO UML accepted by OMG & ISO

References:

A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition, Project Management Institute, 2008

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), 2ed, International Institute of Business Analysis, 2009

A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition, Project Management Institute, 2008

Advanced Use Case Modeling: Software Systems (v. 1), Frank Amour, Addison Wesley, 2001

Getting It Right: Business Requirement Analysis Tools and Techniques, Kathleen B. Hass, Management Concepts, 2007

Mastering the Requirements Process (2nd Edition), Suzanne Robertson, et al, Addison-Wesley, 2006

Object-Oriented Analysis and Design with Applications (3rd Edition), Grady Booch, Addison-Wesley, 2007

Patterns for Effective Use Cases (The Agile Software Development Series), Alistair Cockburn, et al, Addison-Wesley, 2002

Practice Standard for Work Breakdown Structures, 2ed, Project Management Institute, 2006

Professionalizing Business Analysis: Breaking the Cycle of Challenged Projects, Kathleen B. Hass, Management Concepts, 2007

Seven Steps to Mastering Business Analysis, Barbara A. Carkenord, J. Ross Publishing, 2008

The Art and Power of Facilitation: Running Powerful Meetings, Kathleen Hass, Management Concepts, 2007

The Business Analyst as Strategist: Translating Business Strategies into Valuable Solutions, Kathleen Hass, Management Concepts, 2007

The Elements of UML(TM) 2.0 Style, Scott Ambler, Cambridge University Press, 2005

The Unified Software Development Process, Ivar Jacobson, et al, Addison-Wesley, 1999

The Unified Modeling Language Reference Manual (2nd Edition) (The Addison-Wesley Object Technology Series), James Rumbaugh, et al, Addison-Wesley, 2004

Unified Modeling Language User Guide, The (2nd Edition), Grady Booch, et al, Addison-Wesley, 2005

UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition), Martin Fowler, Addison-Wesley, 2003

UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition), Jim Arlow, et al, Addison-Wesley, 2005

Unearthing Business Requirements: Elicitation Tools and Techniques, Kathleen Hass, Management Concepts, 2007

What Not How: The Business Rules Approach to Application Development, C. J. Date, Addison-Wesley Professional, 2000

Writing Effective Use Cases, Alistair Cockburn, Addison-Wesley, 2000

Students Who Viewed This Course Also Viewed

  • Loading
  • Loading
  • Loading

Instructor Biography

Chuck Morrison, Program/Project Manager & Business/IT Architect (MBA, PMP)

“A working model using mission-driven measures in a team approach enables focus on profitable customer-driven solutions."

With extensive Program Management and Business Architecture experience in Silicon Valley California it's been my good fortune and opportunity to experience working with many Fortune 500 companies. Workflow modeling is my expertise, joy and passion. As a seasoned professional my enjoyment is using and sharing the skills and knowledge with others through teaching and writing. Chuck has also authored and published other Udemy courses, Amazon eBooks, Linked SlideShare, and YouTube videos.

PMI PMP certified: Principal Strategist, Architect, and Leader with MBA and extensive experience in business and technology consulting, planning, designing, mentoring, negotiating, and delivering project, product, program, and process solutions. Successful track record planning, managing, and leading small to multi-site, concurrent, complex cross-functional projects and portfolios requiring business process engineering, Internet and information technology, quality management, instrumentation, and training.

Specialties: -Programs/Projects Management (PMI PMP): Program, Product, Project, and Process (SDLC, Agile, PMBOK, DMAIC, RUP, ITIL, InfoSec, NetSec, CISSP)-Business/Technical Process/Systems Modeling, Analysis, and Design (UML, OOA/D, BRD, MRD, FRD, HLD, ERD)-Web Portal Planning, Design, Documentation, and QA (Web 2.0, HTML, TCP/IP, HTTP, B2B, B2C)-Client/Team-Focused Consultant, Mentor, and Communicator-Inventory/Supply Chain Modeling/Management (APICS CPIM)

Thank You and Best Regards,
Chuck Morrison, MBA, PMP, CPIM, WWISA

Ready to start learning?
Take This Course