This repository showcases my work in CS 255: System Analysis and Design at Southern New Hampshire University. Through the DriverPass case study, I applied systems analysis and design principles to translate stakeholder needs into documented requirements, process models, UML diagrams, and a proposed system design.
The coursework demonstrates my ability to analyze business requirements, model system behavior and structure, evaluate technical constraints, and communicate design decisions to both technical and nontechnical audiences.
DriverPass is a driver-training company seeking a web-based information system to improve how customers purchase training packages, access online learning materials, take practice exams, schedule driving lessons, and monitor their progress.
As the systems analyst, I analyzed stakeholder interviews and business needs to define functional and nonfunctional requirements and develop models for the proposed system. The design also accounts for multiple employee roles, role-based access, security, system availability, and the maintenance of current training content by authorized staff.
This portfolio features two major deliverables from the DriverPass system-analysis case study.
| Artifact | What It Demonstrates |
|---|---|
| Project One: Business Requirements Document | Requirements gathering, stakeholder analysis, process modeling, system constraints, and recommendations based on the client's business needs. |
| Project Two: System Design Document | The translation of approved requirements into process, structural, and behavioral models for the proposed system. |
- Stakeholder analysis and business requirements gathering
- Definition of functional, nonfunctional, and user-interface requirements
- Process modeling and data flow analysis
- Object-oriented modeling with use case, activity, sequence, class, and object diagrams
- Project planning and scheduling with Gantt charts
- Evaluation of system constraints, security, availability, and performance
- System design documentation and model consistency review
- Communication of technical concepts and design decisions to nontechnical stakeholders
| Area | Tools and Methods |
|---|---|
| System modeling | Lucidchart for process models, UML diagrams, and project scheduling |
| Documentation | Microsoft Word for developing business requirements and system design documents |
| Portfolio management | GitHub for version control, artifact organization, and professional presentation |
| Analysis and design | Systems Development Life Cycle principles and object-oriented analysis and design |
| Validation | Requirements review and comparison of written requirements with system models |
One of my strongest contributions to the DriverPass project was organizing information from the client interview into clear system requirements. The interview included business goals, user expectations, technical preferences, and operational concerns. Separating those details into functional and nonfunctional requirements made the proposed system easier to evaluate and reduced ambiguity before design work began.
I also considered the needs of multiple user roles instead of treating every user the same. Customers, secretaries, driving instructors, administrators, and information technology staff require different permissions and system functions. Accounting for those differences supports a more secure and practical design.
I would strengthen the connection between the written requirements and the system diagrams by adding a formal requirements traceability matrix. This would make it easier to confirm that each approved requirement appears in at least one design element and that every modeled feature has a documented business purpose. I would also continue refining diagram labels and layouts so that relationships remain readable when the models are viewed outside the original design tool.
I interpreted user needs by identifying each stakeholder, the tasks that person must complete, the information required to complete those tasks, and the constraints that could affect the experience. For example, the client's need for convenient training access became requirements for browser-based availability, online practice exams, and scheduling. Concerns about employee responsibilities became role-based permissions and administrative controls.
Considering user needs is essential because a technically functional system can still fail if it does not support the way people actually work. Connecting each design decision to a stakeholder need helps prevent unnecessary features, missing workflows, security gaps, and costly redesign later in development.
My design process begins with the business problem rather than a preferred technology. I first identify the stakeholders, goals, constraints, and required outcomes. I then classify the requirements, model the system from multiple perspectives, and compare the models for consistency. Process models explain how information moves through the system, structural models define the system's objects and relationships, and behavioral models show how the system responds over time.
For future projects, I will continue using iterative modeling, stakeholder feedback, requirements traceability, and early validation. These techniques make assumptions visible, reveal conflicts before implementation, and create a stronger foundation for software development.
This repository contains my original portfolio artifacts and reflections. Course-provided templates, assignment instructions, rubrics, interview transcripts, and instructor feedback are not included.