Professional Business Systems Analysis and Modeling

Professional business systems analysis and modeling is the craft of turning business needs into data, process, use case and rule models, tying them together with the Architecture Framework and writing specifications that designers and testers can build from. This 1-week course is for working analysts who already gather requirements, and you leave with a Business Requirements Specification Pack. This professional business systems analysis course is delivered by Mercury Training Center.

About This Course

Many system projects fail on requirements that were gathered but never modeled, so gaps and conflicts surface only in testing. You should already take part in requirements work on IT or business change projects. You practice each model on a shared case system, then apply it to a system from your own work.

Who It Is For

• Analysts who elicit and document requirements for new or changed information systems.
• Systems and solution staff who turn business needs into designs and test cases.
• Product and process owners who sign off scope, models and specifications.
• Project staff who manage scope and change on system delivery projects.
• Data and reporting staff who define the information a system must hold.

This course is not for newcomers who have not yet worked on requirements, who will get more from an introductory business analysis course, nor for software developers who want programming or database design skills, who suit a technical development course.

Competencies You Will Build

• Scope and Business Case: you set clear system boundaries and justify the project in business terms.
• Data Modeling: you draw entity-relationship models that capture what the business needs to know.
• Process and Use Case Modeling: you show how work flows and how users interact with the system.
• Framework-Based Analysis: you use the Architecture Framework to check that no view of the business is missing.
• Requirements Elicitation: you choose and run interviews, questionnaires, observation and JAD sessions.
• Specification Writing: you write verifiable functional and non-functional requirements that teams can build and test.

What You Will Be Able to Do

By the end of the course you will be able to:

• From a project request, draw a context diagram and stakeholder register that fix the system scope.
• Given interview notes, build a data model and a business process model and reconcile them.
• Using the Architecture Framework, map requirements to the data, activity, location, people, time and motivation views.
• Given a business scenario, write use case specifications and a business rules catalog.
• From a set of raw requirements, sort functional and non-functional items and rewrite them to be testable.
• Using a validation checklist, review a peer's specification and record the defects found.

Course Content

Day 1: Analyst Role, Scope and Business Case

• Business Systems Analyst Role Across the SDLC
• Business Systems Analysis Process From Request to Specification
• Stakeholder Register for System Users and Sponsors
• Context Diagram for Defining System Scope and Boundaries
• Business Case Structure for a Systems Project

Day 2: Architecture Framework and Data Modeling

• Modeling Concepts and Levels of Abstraction
• The Architecture Framework Views of Data, Activity, Location, People, Time and Motivation
• Entity-Relationship Modeling of Data Requirements
• Business Process Modeling of Current and Target Activities
• Cross-Checking Data and Process Models for Gaps

Day 3: Use Cases, People, Locations and Rules

• Use Case Diagrams and Written Use Case Specifications
• Location Modeling for Multi-Site Operations
• Organization, People and Role Modeling With Responsibility Matrices
• Business Event and Time Event Analysis
• Business Rules Catalog and Motivation Modeling

Day 4: Elicitation Techniques

• Communication Strategies for Analysts Working With Users
• Structured Interviewing for Requirements Discovery
• Questionnaires for Gathering Data From Large User Groups
• Document Analysis and Observation of Current Work
• Joint Application Design (JAD) Sessions for Collective Requirements Capture

Day 5: Specification Practice

• Exercise: Sorting Functional and Non-Functional Requirements for a Case System
• Exercise: Writing Verifiable Requirements From Interview Notes
• Exercise: Requirements Validation Review With Peers
• Business Requirements Specification Components and Layout
• Completing the Business Requirements Specification Pack for Your Own System

Case Studies and Exercises

These are suggested activities.

• Case study: a bank replaces its loan application system; you set the scope and build the data and process models for the new system.
• Case study: a hospital moves patient booking online; you write the use cases and business rules for booking and cancellation.
• Exercise: a retail chain wants stock visibility across stores; you model locations and events and list the reporting requirements.
• Exercise: a public service agency runs a JAD session for a permit system; you capture and validate the agreed requirements.

What You Take Back

You return with the Business Requirements Specification Pack for a system you are working on. In your first month back, use it to confirm scope with the sponsor, walk developers and testers through the models and run a validation review before design starts.

• Context diagram, stakeholder register and business case outline.
• Data, process and use case models mapped to the Architecture Framework.
• Business rules catalog and event list.
• Functional and non-functional requirements with validation notes.

Quick Answers (FAQ)

What should I know before professional business systems analysis training?

You should already take part in gathering or documenting requirements on system or change projects. Basic familiarity with the SDLC helps; no programming knowledge is needed.

How does professional business systems analysis differ from an introductory business analysis course?

An introductory course explains the analyst's role and basic requirements gathering. The professional level assumes that experience and spends the time on data, process and use case modeling, the Architecture Framework and writing specifications that teams can design and test from.

Why do business systems analysts model requirements instead of only listing them?

Models show how data, processes, people and rules connect, so missing steps and conflicting requirements appear before design. A list alone hides these gaps until testing, when fixing them costs far more.

What do I take back from business systems analysis and modeling training?

You take back the Business Requirements Specification Pack: scope and business case, data, process and use case models, a business rules catalog and validated requirements, built for a system you work on.

For Your Manager

After the course, the analyst can set system scope, build data, process and use case models, apply the Architecture Framework and write testable requirements. They return with a Business Requirements Specification Pack for a current system, first used to confirm scope with the sponsor and hand clear models to the design and test teams.