System Analysis & Design — Takeaway Coffee Shop

The problem: before writing a single line of code, the system has to be properly understood

As required by the course, the team analyzed and designed a management system for a takeaway coffee shop following a standard software development process. A takeaway coffee shop needs a system to manage orders, products, customers, and staff in a unified way. Before any development begins, a business needs a rigorous business analysis and system design process to ensure the resulting system actually meets real needs, reduces implementation errors, and lays a solid foundation for future development.

The project started with surveying and analyzing the business, then building requirements documentation, UML models, a data model, and an interface prototype before moving into development. While this wasn’t a project with a fully implemented system, it gave the team full practice with the System Analysis & Design process — from understanding the business problem through to designing the models that support software development.

Role: Requirements Engineering and UML Modeling

Within a 5-person team, led most of the work related to Requirements Engineering and UML Modeling:

• Conducted interviews and business analysis within the assigned scope
• Analyzed the system using the BACCM (Business Analysis Core Concept Model)
• Built the Functional Requirements and Non-functional Requirements
• Designed the Use Case Diagrams
• Designed the Activity Diagram
• Designed the Sequence Diagram
• Designed the interface prototype in Figma
• Designed part of the Entity Relationship Diagram (ERD)
• Finalized the documentation and edited the report

The process: revise, cross-check, refine, repeat

The workflow followed these steps:

1. Survey and research the business problem
2. Interview the stakeholders
3. Analyze using the BACCM model
4. Build the Business Requirements
5. Build the Functional and Non-functional Requirements
6. Design the Functional Decomposition
7. Design the Use Case Diagram, Activity Diagram, and Sequence Diagram
8. Design the data model (ERD)
9. Design the interface prototype in Figma
10. Finalize documentation and present

Most of the time during this project went into building and revising the UML models after every instructor review, to make sure the models accurately reflected the business and stayed consistent with the requirements documentation. Nearly every Use Case, Activity Diagram, and Sequence Diagram went through multiple revisions. Some days, the whole team met from morning to evening just to review every actor, every lifeline, the right level of Use Case decomposition, or each processing flow in the Activity Diagram.

Results

• Completed a full system analysis and design documentation set following standard practice
• Built complete Functional and Non-functional Requirements
• Designed UML models including Use Case, Activity Diagram, and Sequence Diagram
• Completed the data model and the interface prototype
• Ensured consistency across Requirements, Business Process, UML, and the UI Prototype

What I’m proudest of

This was the course that drove the most growth in UML and systems analysis thinking. That continuous cycle of revising, cross-checking against the business, and refining the documentation built a much deeper understanding of how to turn a business requirement into consistent analysis and design models. It also built much stronger fluency with Draw.io, Figma, and the standard rules of UML construction.

The biggest takeaway

The project taught how to translate Business Requirements into Functional Requirements, how to correctly scope and decompose Use Cases, how to design an Activity Diagram that accurately reflects the business process, and how to build a Sequence Diagram with correct actors, lifelines, and messages. Most importantly, it clarified the chain: Requirement → Use Case → Activity → Sequence → UI Prototype — a tight logical sequence where each layer has to be correctly derived from the one before it — and built a systems analysis mindset before ever starting implementation.

Limitations

The project stayed at the analysis and design stage and wasn’t implemented as a real system. Some business requirements were built from academic-style surveys, so they didn’t fully reflect the situations that arise in a real operating environment. Non-functional requirements like performance, scalability, and security weren’t evaluated at the implementation level.

If I did it again

• Conduct more real surveys and interviews to gather fuller requirements
• Standardize the documentation following BABOK and IEEE Software Requirements Specification (SRS)
• Design additional State Machine and Communication diagrams to model system behavior
• Build an interactive prototype instead of a static interface
• Directly link Requirements to User Stories and Acceptance Criteria to better support a development team
• Implement a Proof of Concept to validate the designs before moving into development