Vision

You cannot solve a problem until
you know what the problem is to solve!
- Tim Ackroyd

PREFACE: The parenthetical references (e.g., e1, e5, etc.) represent Episodes in specific Playlists for UML Operator Channel. If you see duplicates, this represents locations in different Playlists. These videos assume you are familiar with Sparx EA and/or modeling techniques.

Requirements

Every time, I mean EVERY TIME, I enter arrive to support a project or delivery team having trouble delivering, I find they are missing requirements and/or have an 80% Defect Injection Rate (DIR) starting their effort. IT's frustrating. Engineering or Developing Requirements and/or Scope should not be difficult or complicated. No matter what the PM certification is, or the scholastic achievement through schooling in Business, Computer Science, whatever, their effort is stalled because they don't understand the Requirements (Present Mode PMO or Future Mode FMO). Here we show you how to best do Requirements Development.

(e1) In "Requirements Engineering for SUCCESS" we get into Requirements, where in system and software are the abilities to do things. The Requirements Engineering (RE) process is a critical step in the software development life cycle as it helps to ensure that the software system being developed meets the needs and expectations of stakeholders, and that it is developed on time, within budget, and to the required quality. While Requirements Development is essential to  RE, Requirements Elicitation is the most important consideration for all  efforts and delivery SUCCESS!

(e5) In "Requirements Development Through Activities - Part 1" we start our next multi-part series which has 8 parts. As a very long series of videos, we attempt to break down one of the most important subjects in delivery...Requirements! We will touch on starting Scope Development, using Activities to drive elicitation, and Simulation to support validation (Closing & Next)

(e6) In "Requirements Development Through Activities Part 2" we will pick up where we left off in Requirements Development Through Activities - Part 1. Now with starting scope and Activity Diagrams, we can start to run simulations and collaborate to find gaps in requirements between Current Mode and Future (target) Mode. In a Sparx EA Cloud and/or SQL environment, the Team can work together 24x7x365 on delivery using these Mode-Driven-Delivery capabilities (Outro).

(e7) In "Model-Driven Requirements Development" is Part 3, we pick up where we left off in Requirements Development Through Activities - Part 2. Here we extend from Collaboration and Review of Activity Diagrams to Use Cases. This exercise sets up for the most productive approach to Requirements Engineering, and will support more effective Requirements Development, Solutioning, and Design as we continue in this series. Using such Model-Driven techniques, can save you time and money in your delivery and support time-to-market objectives (Wrap and Next).

(e8) In "Model Driven Requirements Development Through Activities Part 4" we will pickup where we left off in "Requirements Development Through Activities Part 3". This is part 4 of a multi-part series and Requirements Engineering using Sparx Enterprise Architect (EA) and the Unified Modeling Language (UML). We will use Model-Driven Requirements (MDR, MDD) and Test-Driven Design (TDD) techniques to support our delivery (Wrap up and Next).

(e9) In "Requirements Development Through Activities Part 5" we pickup where we left off in Requirements Development Through Activities - Part 4. We will introduce Cover Pages to make navigating your models for all stakeholders easier, plus these will render in your Web implementations. We will touch on Diagram Locking, Faster Requirements Development, Extended Requirement Types, and Auto-Naming. These practices and techniques are essential to better Requirements Engineering and achieving faster time-to-market (Outro).

(e10) In "Requirements Development Through Activities Part 6" we will pick up where we left off in Part 5, and start with connectors to tell your stories through the proper associations. Another view of "connections" is "relevance", in particular, data relevance. We are going to expose the power of Sparx Enterprise Architect (EA) and how it extends UML to more productive and effective modeling-driven delivery (Outro and Next).

(e11) In "Requirements Development Through Activities Part 7" we are going to touch on Teams working the same Models at the same time. This will include some tips/tricks on coordinating between each other while working in the same spaces. This will also touch on Locking Packages, Diagrams, and Elements (Wrap Up and What's Next).

(e12) In "Requirements Development Through Activities Part 8" we will talk about Team Reporting in Sparx Enterprise Architect (EA). Reporting, in project delivery, refers to the process of collecting, analyzing, and presenting information about an Effort's progress, performance, and status. As part of Model-Driven Delivery, each Team Member (stakeholder) may be responsible in delivering various reports for the Effort, Project, and Delivery at various points. You will take what you learned in previous Reporting Videos and start sharing with other team stakeholders. You will get started on using the Sparx Model Library which can be accessed and used by separate project SQL instances (Outro).

Project Delivery

During the start of initial project or effort delivery we are working in iteration, collaborating, and continually pushing work forward. With the proper processes in place, especially quality assurance, we may be returning to previous work.

(e3 from Series 2 - Sparx Basics) Now let's show "Our First Sparx Project  Ideation (e3)". In this session we are going to carry on with our series on using Sparx Enterprise Architect to build and deliver a real project, starting with Ideation. We will introduce Requirement Element Types and Concepts. We will customize the Requirement Element, start a Kanban, and set up our proof-of-concept tooling (Closing).

(e14) In Domain Driven Design (DDD), we have something called Ubiquitous Language. This is where having a good Dictionary or Glossary is critical. In "Sparx EA Glossary" we will touch on the Glossary capabilities and dialog where you can manage definitions of terms used in your delivery, as a Glossary. When reviewing the Glossary terms, you can filter the list to display terms of a specific Type. Your terms are now represented in your models, reporting, and efforts. The Glossary can be shared across projects as a reusable asset. Most importantly, you can build a ubiquitous language to promote the use of a shared language between your stakeholders.

More to come...