What this resource covers
System analysis examines how work is performed, where information comes from, how decisions are made, and where problems occur. System design describes how the proposed solution will organize workflows, data, interfaces, and controls.
- Document current actors, activities, information, decisions, exceptions, and pain points
- Distinguish business needs from limitations of the existing system
- Model proposed workflows and responsibility boundaries
- Define system context, modules, external actors, and interfaces
- Describe data entities, movement, ownership, validation, and retention needs
- Validate models with users and technical participants before detailed build
Information to prepare
Collect current and target workflows, actors, rules, data, states, interfaces, exceptions, reports, volume, security, deployment constraints, and quality requirements.
- Discovery and approved requirements
- Current procedures, forms, reports, and systems
- User roles, business rules, and exceptions
- Data sources and integrations
- Security and operational constraints
Expected planning outputs
Produce process and domain models, system context, data and interface designs, state behavior, component responsibilities, design decisions, prototypes where needed, and traceability to requirements.
- Current-state and future-state process models
- System context and boundary definition
- Module and responsibility model
- Logical data and interface models
- Reviewed design decisions and open questions
Practical example
How it can be applied
For clinic operations, analysis may map registration, appointments, consultation, orders, results, billing, and follow-up across patient, provider, and administrative roles. Design then defines module boundaries, shared patient data, permissions, integration points, and audit events.
Common mistakes to avoid
- Automating a broken workflow without analysis
- Designing around one department while ignoring shared data
- Mixing logical needs with a premature technology choice
- Ignoring exception and recovery paths
- Proceeding without stakeholder review of the future state
FAQ
Common questions
What is the difference between analysis and design?
Analysis explains the problem, needs, rules, and context. Design describes how the proposed system will satisfy them.
Are diagrams required?
Use diagrams when they improve shared understanding. Clear text, tables, prototypes, and examples can complement them.
Can analysis continue during development?
Yes in iterative delivery, but near-term work still needs enough analysis to avoid preventable rework and unsafe assumptions.