Business Process Analysis

Course Description

Business Process Analysis enables students to work effectively with stakeholders to define business requirements, shape the output of projects, and drive successful business outcomes. It also prepares students for the Project Management Institute's Professional in Business Analysis (PMI-PBA) certification examination.

Within the SCNS taxonomy, MAN is the Management prefix. Daytona State publishes this at 3 credits, with GEB4930, GEB4931, or GEB4932 as prerequisite or corequisite, offered fall and spring, giving approximately 45 contact hours — the value carried by the published MAN3025 and MAN4720 at the same college.

Business analysis exists because of a well-documented and expensive problem: projects fail far more often from misunderstood requirements than from technical failure. Software gets built correctly to a specification that described the wrong thing; processes get automated without being fixed first; stakeholders agree to a document nobody actually read the same way. The business analyst is the role that sits between what people say they want and what would actually solve their problem — and the discipline is largely about extracting the second from the first.

Learning Outcomes

Required Outcomes

• Describe the business analysis role and its relationship to project management and delivery.
• Identify stakeholders and analyze their influence, interest, and needs.
• Develop a stakeholder engagement and communication approach.
• Define a business need and distinguish it from a proposed solution.
• Conduct root cause analysis and problem definition.
• Develop a business case and describe expected benefits.
• Apply elicitation techniques, including interviews, workshops, and observation.
• Facilitate a requirements workshop effectively.
• Distinguish business, stakeholder, solution, functional, non-functional, and transition requirements.
• Write clear, testable, unambiguous requirements.
• Write user stories with acceptance criteria.
• Model processes using standard notation, including flowcharts and BPMN.
• Produce as-is and to-be process models and identify improvement opportunities.
• Apply use cases, data models, and other analysis models appropriately.
• Prioritize requirements using recognized techniques.
• Verify and validate requirements with stakeholders.
• Manage requirements traceability from need through solution.
• Manage requirements change and describe its impact.
• Describe solution evaluation and benefit realization.
• Describe process improvement approaches, including lean and Six Sigma concepts.
• Measure process performance and identify waste and bottlenecks.
• Describe business analysis in predictive, agile, and hybrid delivery approaches.
• Manage conflict among stakeholders and negotiate agreement.
• Communicate analysis results to technical and non-technical audiences.

Optional Outcomes

• Use business analysis and modelling software tools.
• Describe data analysis and reporting requirements definition.
• Describe automation, workflow, and process mining.
• Describe organizational change management.
• Describe vendor selection and package software requirements.
• Prepare specifically for the PMI-PBA examination.

Major Topics

Required Topics

• The business analysis role
• Stakeholder identification and analysis
• Stakeholder engagement and communication
• Business need versus solution
• Root cause analysis
• Business case development
• Elicitation techniques
• Workshop facilitation
• Requirement types
• Writing clear and testable requirements
• User stories and acceptance criteria
• Process modelling and BPMN
• As-is and to-be analysis
• Use cases and data models
• Requirements prioritization
• Verification and validation
• Traceability
• Change management for requirements
• Solution evaluation and benefit realization
• Lean and Six Sigma concepts
• Process measurement, waste, and bottlenecks
• Predictive, agile, and hybrid contexts
• Conflict and negotiation
• Communicating to mixed audiences

Optional Topics

• Business analysis tooling
• Data and reporting requirements
• Automation and process mining
• Organizational change management
• Vendor and package selection
• PMI-PBA examination preparation

Resources & Tools

• PMI's Business Analysis for Practitioners: A Practice Guide and the PMI-PBA Examination Content Outline — the operative documents given this course's stated certification alignment. The content outline is free from pmi.org.
• IIBA's BABOK Guide (iiba.org) — the other major body of knowledge in this field, and the basis for the ECBA, CCBA, and CBAP credentials. See the credential flag below, because ECBA is the one most students can actually get.
• Business Analysis (Debra Paul, BCS) or Seven Steps to Mastering Business Analysis (Barbara Carkenord) — practical and readable.
• User Story Mapping (Jeff Patton) — the best book on requirements in an agile context.
• The Lean Startup and Learning to See (Rother & Shook) — for the validation and value-stream-mapping content respectively.
• BPMN 2.0 specification (bpmn.org) — free; the standard process notation.
• Lucidchart, draw.io (diagrams.net), or Visio — process modelling tools; draw.io is free and entirely adequate.
• Jira, Azure DevOps, or Trello — requirements and backlog tools; free tiers exist and the vocabulary matters in interviews.
• Excel and SQL — genuinely core. Learning enough SQL to query a database yourself is one of the highest-return skills a business analyst can add.
• IIBA and PMI local chapters — Florida has active chapters in Orlando, Tampa, Jacksonville, and South Florida; meetings are cheap and are where people get hired.

Career Pathways

• Business analyst — the direct destination; SOC 13-1111 Management Analysts and 15-1211 Computer Systems Analysts both apply depending on the role's technical depth.
• Systems analyst and IT business analyst — the largest hiring segment.
• Product owner and product manager — a common progression, and better paid.
• Process improvement analyst — with lean or Six Sigma credentials.
• Project manager — the adjacent discipline; the PMP is the credential.
• Data analyst and reporting analyst — with SQL and visualization skills.
• Management consultant.
• Operations analyst.
• Healthcare business analyst — Florida's hospital systems and health insurers are large employers, and clinical systems work pays well.
• Financial services and insurance analyst — a substantial South Florida and Jacksonville sector.
• Government and defence analyst — Florida state agencies, and the Orlando simulation and training cluster.
• Business analysis is one of the more accessible well-paid roles for a business graduate without a technical degree, and remote and hybrid work is common in it.

Special Information

⚠⚠ PMI-PBA requires documented work experience — you cannot sit it as a new graduate

The most important practical caveat in this guide, given that the catalog names the certification explicitly.

• The PMI-PBA has substantial experience requirements in addition to education and training hours — several thousand hours of business analysis experience, with the amount depending on your degree level. The catalog description itself notes the examination is "based on experience."
• A student completing this course is therefore prepared for the content but generally not yet eligible to sit the examination. That is not a criticism of the course; it is a sequencing fact students should know before they build a plan around it.
• IIBA's ECBA has no work experience requirement and is designed for people entering the field — this is the credential most students can actually obtain now, and it demonstrates commitment on a résumé while you accumulate the experience for the higher ones.
• IIBA's CCBA and CBAP, and PMI's PMI-PBA, all require documented experience, so plan them as three-to-five-year goals rather than graduation goals.
• Log your experience as you go. Certification applications require hours by knowledge area with project detail, and reconstructing three years of work from memory is miserable. Start a simple log in your first job.
• PMI and IIBA are different frameworks with different vocabulary for substantially overlapping practice. Employers rarely care which you hold; be aware that terminology differs between them and that this course follows PMI's.
• Rule 11 applies — certification requirements, examination content outlines, and eligibility rules change. Verify directly with PMI and IIBA before paying for anything.

⚠ Requirements elicitation is not order-taking

• Stakeholders describe solutions, not needs. "I need a dropdown here" is a proposed solution; the analyst's job is to find out what problem it would solve, because there is frequently a better answer — or the problem turns out to be somewhere else entirely.
• Ask why repeatedly. Root cause analysis exists because the presenting complaint is rarely the actual problem, and automating a broken process just makes it fail faster.
• People cannot fully articulate what they do. Expert practitioners have automated most of their knowledge and genuinely cannot describe it. Observation beats interviews for understanding how work actually happens, and the gap between the documented process and the real one is usually large.
• Talk to the people who do the work, not only to their managers. These produce different and equally necessary pictures.
• Look for the workarounds. Spreadsheets maintained on the side, sticky notes on monitors, and steps done "off system" are where the real requirements hide.
• Elicitation techniques suit different situations — interviews for depth, workshops for shared understanding and conflict surfacing, surveys for breadth, observation for reality, document analysis for the existing rules, and prototypes for anything people cannot imagine in the abstract.
• Prototype early when the solution is visual. A rough wireframe extracts more accurate requirements in ten minutes than an hour of discussion, because people react to something concrete far better than they specify in the abstract.
• Silence in a workshop is not agreement. Facilitation skill — drawing out quiet participants, preventing the loudest voice from setting the requirement, and surfacing disagreement early — is what separates a good analyst from a note-taker.

⚠ Ambiguous requirements are the defect — write for testability

• A requirement that two people read differently has already failed, and the cost of that failure grows enormously the later it is discovered.
• Write requirements that can be tested. If you cannot state how you would verify it, it is not a requirement — it is a sentiment. "The system shall be user-friendly" is untestable; a specified task completion time is not.
• Eliminate weasel words — "fast," "easy," "appropriate," "as needed," "etc." Each is a place where someone will later insert a different meaning.
• Non-functional requirements are where projects quietly fail. Performance, capacity, availability, security, accessibility, and retention are usually unstated and then discovered to matter in production.
• Acceptance criteria make a user story real. The story states who, what, and why; the criteria state how you will know it is done.
• Model it as well as writing it. A process diagram exposes gaps, exceptions, and decision points that prose glides over, and stakeholders spot errors in a diagram they would never find in a document.
• Chase the exceptions. The happy path is easy and the edge cases are where the effort is. "What happens if it is rejected?" is the most productive question an analyst asks.
• Traceability is not bureaucracy. Being able to link a requirement to the business need it serves lets you defend it, and lets you delete it when the need disappears.
• Prioritize honestly. When everything is a must-have, nothing is, and the prioritization conversation is where the analyst delivers most of their value.

⚠ The soft skills are the hard part — and this is why the job resists automation

• Business analysis is mostly about people, and students who expect a technical discipline are frequently surprised. The documents are the artefact; the understanding is the work.
• Stakeholders disagree, and the disagreement is information. Two departments wanting incompatible things usually reflects a genuine organizational tension, and surfacing it early is far better than discovering it at user acceptance testing.
• You will have responsibility without authority. The analyst rarely has the power to decide, so influence, credibility, and clear communication are the working tools.
• Translate in both directions. Explaining technical constraints to business stakeholders and business context to developers is a large part of the role, and doing it without condescension in either direction is the skill.
• Change is threatening. Process improvement often implies that someone's job changes or disappears, and people who feel threatened withhold information. Acknowledging that honestly gets better requirements than pretending it is not happening.
• Write for the reader. An executive wants a page; a developer wants the exception handling. The same analysis needs different presentations.
• Follow through to outcomes. Solution evaluation — did the change actually deliver the benefit claimed in the business case? — is the most-skipped and most valuable part of the discipline.
• On automation: tools increasingly generate documentation, summarize meetings, and draft user stories. What does not automate is sitting with a group of people who disagree and working out what they actually need — which is most of the job, and a reasonable answer to whether the role has a future.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement.

MAN4535 is 3 credits and approximately 45 contact hours, offered fall and spring, with a capstone or seminar course as prerequisite or corequisite — so it sits at the end of a bachelor's programme and may run alongside a capstone project it can feed.

Expect process models, a requirements document, and probably a facilitated workshop or elicitation exercise. Keep the artefacts. A complete requirements package with process models, traceability, and acceptance criteria is genuinely persuasive in a business analyst interview, and it is the kind of evidence very few new graduates can produce.

As a 4000-level course it belongs to an upper-division programme and lower-division credit will not substitute for it.