Assignment 6 SDDStructure Chart Emerald Bekoe

System Design
Specification (SDD)
DRAFT
for
Family Clinic Services

Version 1.0 approved
Prepared by Emerald Bekoe
American Public University System
February 04, 2024

Draft System Design Document for Family Clinic Services Page ii
Contents
1. Introduction.................................................................................1
2. Purpose........................................................................................1
2.1 Document Conventions...............................................................1
2.2 Intended Audience and Reading Suggestions.................................1
2.3 Product Scope...........................................................................2
2.4 References................................................................................2
3. System Overview..........................................................................3
3.1 Goals, Functionality and Architecture............................................3
3.2 Design Constraints.....................................................................3
4. System Architecture.....................................................................4
4.1 Architectural Design...................................................................4
4.2 Subsystem Decomposition...........................................................4
4.3 Access Control and Security.........................................................4
4.4 Design Rationale........................................................................4
5. File and Database Design..............................................................5
5.1 Database Design........................................................................5
5.2 Non-Database Management System Files......................................5
5.3 Corrections...............................................................................5
6. Software Design...........................................................................6
6.1 Structure Chart...........................................................................6
6.2 Structure Chart Discussion............................................................6
7. Human Interface Design...............................................................7
7.1 Functionality from User Perspective................................................7
7.2 Sample Mockups of Web Pages for the Case Study...........................7
8. Testing..........................................................................................8
8.1 Test Case TC001 Schedule New Valid Appointment..........................8
8.2 Test Case TC002 Cancel Scheduled Appointment.............................8
8.3 Test Case TC003 Schedule New Appointment without Data...............8
8.4 Test Case TC004 Schedule Appointment with Schedule Conflict.........9
8.5 Testing Types..............................................................................9
Appendix.........................................................................................10
Revision History
Name Date Reason for Changes Version

1. Introduction
The System Design Specification (SDD) identifies the architecture, software

elements, interfaces and data for FCS Appointment Scheduling System. It
offers technical details and specifications for the developer to follow
according to the needs defined in SRS.
The SDD covers:
- System architecture overview

- Description of software components
- Details on component interfaces
- Database design including schema
- Sample code snippets
- Architecture diagrams
- Interface layout specifications
- Infrastructure needs
- Security controls
- Testing and implementation plans
This document aims to provide all technical details needed by the

development team for successful implementation, integration and
deployment of the FCS appointment scheduling system in line with
requirements defined in SRS. It elaborates the what from SRS to emphasize
on the how for software development process.
2. Purpose
The Purpose section outlines the objectives and goals of the System Design
Specification.
This section will provide background to the FCS appointment scheduling
system project and the necessity of SDD.
It would establish that the purpose of this SDD is to:
- Create detailed technical requirements for the system development based
on approved needs.
- Allow designers and developers to comprehend the entire technical design
of system architecture, components, interfaces, data, infrastructure
requirements etc.
- Serve as a guide for the software development team in all stages of
coding, integration and testing.
- Make sure all stakeholders clearly understand the technical solution
including architects, developers, testers and infrastructure support staff etc.
- Record architectural decisions and directions so that conformity during
implementation can be maintained.
- Enable estimation, planning and tracking of technical work item.
In conclusion, this section would outline the SDD’s purpose to provide in-
depth technical specifications that control and guide the entire system
implementation according to the requirements baseline.
Draft System Design Document for Family Clinic Services Page 2
This System Design Specification (SDD) document covers version 1.0 of the
Family Clinic Services (FCS) Appointment Scheduling System software. The
scope of this SDD includes technical specifications for the complete FCS
Appointment Scheduling System, including:
- Patient, doctor, receptionist, and administrator modules

- Appointment scheduling and management functions
- Provider agenda and availability management
- Reporting and visibility features
- User account and profile management
- Administrative system configuration
- Database design
- System architecture and infrastructure needs
- Security controls and integration requirements
In summary, this SDD provides comprehensive technical system design

specifications for the full end-to-end FCS Appointment Scheduling System
referenced in the Software Requirements Specification (SRS). It does not
cover partial or limited scope, but rather includes the detailed technical
design for the complete system.
2.1 Document Conventions
Some of the standards and conventions followed in this System Design

Specification (SDD) document include:
- Section headers are numbered and in bold font
- Subsection headers are numbered by section and unbolded
- Requirements and specifications are not marked by priority - all are

assumed equally high priority
- Diagrams and models utilize standard UML notation
- Table headers are bolded while data is unbolded
- Code snippets use fixed-width font and syntax highlighting
- No special highlighting is used to call out requirements or specs
- Acronyms are defined at first use
- Terms are defined in a glossary section
- References to other documents are in italics
- Numbering follows an outlined structure for sections/subsections
Standard fonts, numbering, UML styles are used without priorities marked.
All requirements defined in the SDD are assumed critical and no
typographical callouts are made. Let me know if any other conventions need
to be followed.
2.2 Intended Audience and Reading Suggestions
This System Design Specification (SDD) is intended for the following reader
types:
- Developers - Will utilize the technical details for system architecture,

components, interfaces, data models, infrastructure needs, security controls,
code snippets etc. to implement the system.
- Project Managers - Will leverage the component diagrams, interface

specifications, infrastructure elements etc. to plan and track technical work.
- Testers - Will use the component and interface details to develop

integration and system test cases.
- Writers - Will reference architecture and component documentation to

create user manuals and technical guides.
The remainder of the SDD contains:
- System architecture overview

- Component design details
- Interface specifications
- Database schema
- Infrastructure needs
- Security controls
- Sample code snippets
- Deployment methodology
Suggested reading sequence:
- Developers - Read architecture overview then study component design and

integration details relevant to assigned work.
- Project Managers - Review architecture overview followed by component

diagrams to understand technical scope.
- Testers - Read interface specifications to build test cases, along with

component diagrams.
- Writers - Reference architecture overview, component diagrams, and

interface specifications to create documentation.
The overview provides context followed by implementation details for each

reader's focus area.
2.3 Product Scope
The software being specified in this SDD is the Family Clinic Services (FCS)
Appointment Scheduling System.
The purpose of this software is to enable patients to book appointments

online with doctors and service providers at FCS clinics. Key benefits,
objectives and goals include:
- Improving patient satisfaction by reducing wait times through online

scheduling
- Increasing provider productivity and efficiency via optimized appointment

schedules
- Lowering administrative costs by automating manual appointment booking
- Providing flexibility for patients to book appointments 24/7
- Enabling better resource planning using real-time visibility into provider

schedules
This aligns with FCS' goals of delivering excellent patient-centered care while
reducing operating costs through digital transformation. It supports the
corporate strategy to invest in technologies that improve patient experience.
The Software Requirements Specification (SRS) document contains the

vision and scope for this project. This SDD focuses on the technical system
design given the approved requirements baseline.
In summary, this software aims to implement online appointment scheduling

to benefit patients and providers per FCS strategic objectives. The SRS
outlines the overall vision and requirements.
2.4 References
Microsoft. (2023). Cloud Computing Services | Microsoft Azure.
Azure.microsoft.com. https://azure.microsoft.com/en-us
Noumeir, R. (2018). Active Learning of the HL7 Medical Standard. Journal of
Digital Imaging, 32(3), 354–361. https://doi.org/10.1007/s10278-
018-0134-3
Oracle Corporation. (2019). MySQL :: MySQL 8.0 Reference Manual.
Mysql.com. https://dev.mysql.com/doc/refman/8.0/en/
React. (2020). React – A JavaScript library for building user interfaces.
Reactjs.org. https://legacy.reactjs.org/
3. System Overview
The System Overview section gives a broad summary of the architecture and
technical design components of the Family Clinic Services (FCS)
Appointment Scheduling System. This chapter provides a general overview
of the system before proceeding to further details in later sections. It seeks
to orient the reader and establish context for the whole document.
The overview will cover:
- A short story about the business drivers and objectives of the system
- An overview of the main system components and architecture
- Brief description of the technologies used.
- Diagram of primary interfaces and integrations.
- Data models and databases.
- Infrastructure platforms and needs
- Implementation and deployment approach summary
- Visual of maintenance processes and procedures
The objective is to create an overview and mental map of the technical

solution before details. It makes the reader ready to get into the details by
first outlining the general picture. This would be helped by diagrams of the
high-level architecture and component interactions. Breadth instead of depth
is given an overview.
3.1 Goals, Functionality and Architecture
1. Introduction
The System Design Specification specifies the core objectives, operational
process and structure of the proposed system. This document serves as a
source of detailed information for developers, stakeholders, and other
participants in the project.
2. System Design Goals

a. Reliability: Ensure the system works reliably under different settings.
b. Scalability: Develop the system that can manage higher load and large
data size.
c. Maintainability: Allow ease of updates, modifications and troubleshooting.
d. Performance: Make the system effective and responsive.
e. Security: Put in place stringent measures to protect data and ensure that
there is no intrusion.
f. Usability: Create an intuitive and user-friendly interface that provides
smooth user interaction.
3. System Functionality
a. User Authentication and Authorization: Implement secure user access
controls.
b. Data Processing: Offer efficient data processing and management
features.
c. Reporting: Create detailed reports for the users and administrators.
d. Notifications: Allow for timely notifications concerning relevant events.
e. Integration: Provide integration with external systems where necessary.
f. Logging and Auditing: Log activities in the record system for auditing and
problem solving.
4. System Architecture
a. High-Level Approach:
- Use a modular and scalable architecture.
- Use a microservices-based architecture for flexibility and maintainability.
- Adopt service-oriented architecture for easy integration.
b. Hardware Components
- Define server specifications in terms of CPU, RAM, and storage capacity.
- Reduce redundancy through load balancing and failover mechanisms.
- Define networking architecture in order to guarantee proper
communication.
c. Software Components
- Name programming languages, frameworks and libraries.
- Specify middleware and communication protocols.
- Define the application layer, business logic and presentation layer.
d. Database
- Choose an appropriate DBMS according to the needs.
- Specify the database schema, relationships involved, and indexing
approach.
- Introduce data backup and recovery processes.
e. Security Components
- Use encryption for data in transit and at rest.
- Implement strong user authentication and authorization procedures.
- Consider IDS and IPS.
5. System Testing
a. Unit Testing: Verify the functionality of each individual component.
b. Integration Testing: Facilitate smooth interaction between system
modules.
c. Performance Testing: Analyze the response of the system in different
loads.
d. Security Testing: Identify and address potential vulnerabilities.
6. System Deployment
a. Rollout Plan: Outline a phased deployment strategy.
b. Data Migration: Develop a strategy for seamless migration of data from
current systems.
c. Training: Train end-users and administrators.
7. Conclusion
System Design Specification is a basis for construction and implementation
of the suggested system. Constant updates and reviews will be carried out
during the development process to guarantee that the project objectives and
stakeholder expectations are met.
3.2 Design Constraints
Hardware Constraints
a. Limited Resources: Hardware resources such as processing power,
memory and storage may be limited which can affect the scalability and
performance of the system.
b. Legacy Systems: The choice of technologies and architecture may be
constrained by integration with current hardware, affecting the system
design as a whole.
Software Constraints
a. Third-Party Software: The use of external software components or
libraries introduces limitations in the system design due to compatibility
problems and licensing factors.
b. Operating System Limitations: Some design choices may be influenced
by specific requirements or restrictions that are imposed by the chosen
operating system.
Business Processes
a. Regulatory Compliance: Industry-specific regulatory and compliance
standards may impose limitations in respect of data management, security
measures, reporting as well as system design.
b. Workflow Dependencies: Existing business processes that need to be
incorporated or adjusted may serve as a restraint of the system design.
Organizational/Industry Standards
a. Interoperability: Industry standards and protocols should be adhered,
and failure to follow them may impair the system’s interoperability with
other systems or components.
b. Security Standards: Organizational or industry-specific security
standards may impose limitations on encryption methods, authentication
mechanisms, and overall system security design as well.
Budgetary Constraints:
a. Financial Limitations: The budget for the project may limit hardware,
software, and other resource choices in certain cases; therefore, scalability
as well as system features may be affected.
b. Cost of Technology Adoption: Costs associated with adopting certain
technologies or frameworks might impact choice and affect the overall
system architecture.
Time Constraints:
a. Project Timelines: Rigid deadlines can limit the thoroughness of system
design exploration and testing, which may cause tradeoffs between
functionality, reliability and time-to-market.
b. Rapid Changes in Technology: The speed of advancements in
technology might limit the system design because decisions must be made
taking into account the current technological state.
User and Stakeholder Expectations

a. User Skill Levels: Limitations may come from the need to create a
system that is consistent with the users’ skill level, and therefore should be
as simple or complex depending on how much expertise one would require.
b. Stakeholder Preferences: The design decisions for the user interface,
features and overall system behavior can be limited by preferences and
expectations of stakeholders.
Environmental Constraints
a. Geographical Considerations: Hardware selection choices, data center
locations, and disaster recovery plans may be constrained by physical
location and environmental conditions.
b. Climate and Infrastructure: Local climate and infrastructure constraints
may interfere with hardware reliability and maintenance.
The ability to appreciate and control these constraints is fundamental in
achieving successful system design because ultimately, the end product
should answer not only functional needs but also the broader contextual
limitations imposed by external factors.
4. System Architecture
The System Architecture section elaborates the high-level design and

structure of the Appointment Scheduling System. It outlines the main
structural aspects and connections between components.
The components of this section will be:
- The rationale for the architectural style used (layered, SOA or
microservices).
- Logical architecture diagram with the main components and interconnects.
- Detailed description of each architectural layer including presentation,
business logic, data and infrastructure etc.
- Major technologies used in each layer.
- Core integration patterns and data flows explanation.
- Quality attributes such as security, scalability, availability etc. are
addressed in the discussion.
- Third party software components utilized
- Physical deployment topology and options overview.
The aim is to present a general picture of the strategic technical design

decisions and high-level system structure. It provides basis for lower-level
component design details discussed in other sections.
UML diagrams, component models, and tables provide visual representations
of the core architecture components and their interrelationships. Breadth is
prioritized over depth.
4.1 Architectural Design
4.2 Subsystem Decomposition
User Management Subsystem:
Responsibilities:
User Authentication: Authenticates users, allowing them secure access to the
system through mechanisms such as username/passwords, MFA and OAuth
2.0.
User Authorization: Defines what actions and data each user or group can
perform within the system by managing user roles, permissions, and access
controls.
User Profile Management: Keeps profiles of users complete with personal
information, preferences, and settings.
Data Processing Subsystem:
Responsibilities:
Data Validation: Verify the incoming data to ensure that it is correct,
complete and conforming with given data standards prior processing.
Business Logic Execution: Implements the business logic of the system,
including order processing, transaction management, and other domain-
specific operations.
Error Handling: Error and exception handling is done in a very polite fashion
as it provides the right response to the users while saving relevant
information of errors for troubleshooting.
Reporting and Analytics Subsystem:
Responsibilities:
Report Generation: It provides detailed reports in response to user requests,
system events or schedules that show what has happened and how the
system is performing.
Data Analytics: Analyze data that has already been collected to produce
patterns, trends and KPIs so as to inform decision making.
Visualization: Facilitates data visualization of insight in the form of charts,
graphs and dashboard for easy interpretation by users and administrators.
Notification Subsystem:
Responsibilities:
Event Monitoring: It observes system events, user activities and pre-defined
triggers to track the detection of occasions requiring notifications.
Notification Generation: Provides notifications in a timely manner with alerts,
emails or in-app messages that let people know about important events.
Notification Delivery: Offers the secure and reliable delivery of notifications
to end users via multiple channels.
Integration Subsystem:
Responsibilities:
External System Integration: Simplifies seamless interoperability with other
systems, services or APIs, ensuring compatibility and data transmission.
Data Mapping and Transformation: Data conversions from one format to
another as well as the data structures between the internal system and
external entities.
API Management: API management that involves versioning, documentation
and security in order to provide a common interface for external
communication.
Logging and Auditing Subsystem:
Responsibilities:
Event Logging: Logs records system events, user activities, and error
conditions to audit, monitor, and analyze.
Audit Trail Generation: Offers detailed audit trails for changes to critical
data, user actions, and system settings.
Log Analysis: Uses tools and procedures to analyze logs, search for patterns,
and identify anomalies that could indicate security threats or system issues.
Security Subsystem:
Responsibilities:
Encryption and Decryption: Controls the encryption and decryption of data in
both transit and at rest, ensuring that security is upheld and maintained.
Access Control: User access to data and functions are restricted by roles and
permissions.
Security Monitoring: Oversees the security of the system, identifies and

responds to threats or vulnerabilities as well as compliance with security
guidelines.
These top-level subsystems comprise the core of the system, each with a
key function in meeting particular obligations. They work together to ensure
the full functionality, security and overall performance of the system
according to users and stakeholders’ needs.
4.3 Access Control and Security
One of the important aspects of system design is assuring a strong security

measure. This section covers security concerns such as choosing an
authentication, encryption usage, and key management.
1. Authentication Mechanism:
Selection Rationale:
Multi-Factor Authentication (MFA): MFA was selected to strengthen
authentication security by obliging users to submit several kinds of
confirmation. This increases the level of protection even if credentials are
compromised.
OAuth 2.0 for External Authentication: Third-party integrations and single

sign-on (SSO) use OAuth 2.0. This protocol is an industry standard and
guarantees secure authentication and authorization between systems.
Trade-offs:
User Convenience vs. Security: Although MFA improves safety, it may create
a degree of inconvenience for users. Finding a proper balance between
security and user experience is essential to achieve significant adoption.
Integration Overhead: The OAuth 2.0 implementation for external

authentication involves a thoughtful integration with the external identity
providers. Here, the trade-off is that of managing these integrations and the
overhead versus streamlining authentication processes.
2. Encryption:
Selection Rationale:
TLS/SSL for Data in Transit: It is TLS or former SSL that encrypts data in
transit. This guarantees the security and protection of information sent
between the client and server.
Data-at-Rest Encryption: The system uses encryption algorithms to encrypt

information that is stored on databases or other persistent storage. This
should safeguard against intrusion in the event of physical or digital
breaches.
3. Key Management:
Management Strategies:
Key Rotation: One of the key management best practices is to update

encryption keys regularly. The system has automated key rotation processes
to limit the risks associated with long-term use of keys.
Secure Storage: Keys are kept safe, using either HSMs (hardware security
modules) or secure key management services. This limits unauthorized keys
access and guarantees their confidentiality.
Access Control for Keys: Putting in place strong access controls guarantees
that only authorized individuals will have access to the encryption keys. This
reduces the possibility of key compromise.
Trade-offs:
Usability vs. Security: Some complexity may be introduced by introducing

strong key management practices for administrators. Balancing usability and
security has a crucial role to play in ensuring efficient key management
without diminishing operational performance.
Key Recovery vs. Security: The introduction of key recovery mechanisms for
lost or compromised keys offers some security concerns. Serious attention is
paid to the balance between critical recovery requirements and security
actions.
Overall, the choice of authentication methods, encryption policies and key

management procedures is driven by a focus on protecting system data.
Achieving the perfect compromise between security measures and
operational feasibility is critical to establish a strong yet usable security
architecture. Security protocols will be updated and regularly audited to
adjust for changing threats and the new industry standards.
4.4 Design Rationale
Another important system element is the selected architecture, which

greatly affects the system performance, scalability and maintainability. The
justification for the choice of this architecture arises from a detailed analysis
of critical issues and trade-offs in accordance with project goals and
constraints.
1. Microservices Architecture:
Reasoning:
Scalability: The microservices architecture was selected to improve

scalability through granularity of the system into deployable and scalable
services. This strategy ensures effective resource utilization and enables the
provision of additional or reduction of services based on demand.
Maintainability: Microservices ensure maintainability by the independent
development, testing, and deployment of services. This modular structure
allows for updates and bug fixes without disrupting the entire system.
Flexibility: Microservices allow for the choice of technology stacks when it
comes to individual services. This means that the use of tools suitable for
specific functionalities is possible, making it easier to accommodate diverse
needs within the system.
Trade-offs:
Increased Complexity: Implementing a microservices architecture also
brings with it the added complexity of service orchestration, inter-service
communications and difficulties in managing distributed systems.
Operational Overhead: Running a larger number of services may require
more operational work, such as monitoring, logging and deployment
coordination.
2. Cloud-Native Approach:
Reasoning:
Scalability and Elasticity: Cloud services provide easy scalability and

elasticity, which ensures a smooth adaptation of the system to different
workloads. This is more so in the case of handling variations in user activity
or data processing demands.
Resource Efficiency: With the on-demand provisioning of resources, cloud
native architectures ensure to optimize costs based on what is used at any
given time.
Fault Tolerance: Cloud services tend to have redundancy and fault-tolerant
features built in, which increases the reliability of the system.
Trade-offs:
Vendor Lock-in: Relying heavily on specific cloud providers may lead to
vendor lock-in, the inability of switching service providers effortlessly.
Data Security and Compliance: Implementing data security and compliance
requirements in the cloud requires meticulous configuration and monitoring
that ensures regulatory needs are satisfied.
3. RESTful APIs for Communication:
Reasoning:
Interoperability: RESTful APIs provide a broadly accepted and standardized
means of communication between the services. This helps in interoperability,
thus enabling easy integration of the system with other applications and
services.
Simplicity: RESTful APIs are relatively simple and stateless, which makes it
easy to implement and understand them. This simplicity helps in fast
development and minimizes the number of potential failure points.
Trade-offs:
Overhead for Real-time Communication: In case of real-time communication
needs, RESTful APIs may not be that efficient as compared to other
protocols such as WebSocket. The compromise in this case is the limitations
of REST to achieve simplicity and widespread use.
4. Database Choice:
Reasoning:
Data Model Requirements: The DBMS selection depended on the particular
data model requirements of the system. For instance, the relational
databases are used for structured data and NoSQL for unstructured data.
Scalability: The chosen DBMS is consistent with the scalability objectives of

the system. Distributed databases may be used because they allow for
horizontal scaling and handle massive amounts of data.
Trade-offs:
Consistency vs. Performance: A trade-off between strong data consistency
and performance may be present, depending on the selected database type
(e.g., SQL versus NoSQL). Decisions are made based on the nature of the
system.
Overall, the choice of microservices architecture, cloud-native approach,
RESTful APIs, and specific database technologies is based on an appropriate
trade-off between scalability needs, maintainability goals, flexibility
requirements as well as performance concerns. Trade-off is also considered
and the chosen architecture is aligned with overall project objectives and
constraints. Regular reviews and flexibility will be necessary to address
changing challenges as well as dynamic project needs.
5. File and Database Design
This section covers the design of files and databases for the Family Clinic Services (FCS) system.
It includes:
Database Architecture: Overview of the chosen DBMS, database model, and configurations.
Database Schema: Presentation of the database structure and relationships.
File Organization: Discussion of file types, storage, and access mechanisms.
Data Integrity and Security: Measures for ensuring data integrity and security.
Backup and Recovery: Procedures for data backup, storage, and recovery.
Performance Optimization: Strategies for optimizing database performance.
Scalability and Extensibility: Considerations for system scalability and future enhancements.
Documentation and Maintenance: Practices for maintaining system documentation and version
control.
5.1 Database Design
D1
Entities
Patient Entity
Represents individuals who are seeking medical services.
Attributes include PatientID (Primary Key), Name, Address, ContactNumber,

and other relevant patient details.
Doctor Entity
Represents medical practitioners providing services.
Attributes include DoctorID (Primary Key), Name, Specialty, ContactNumber,

and other relevant doctor details.
Appointment Entity
Represents scheduled appointments between patients and doctors.
Attributes include AppointmentID (Primary Key), Date, Time, Purpose, and

foreign keys PatientID and DoctorID linking to the respective entities.
Relationships
Patient-Appointment Relationship
One patient can have multiple appointments (One-to-Many).
Represented by the relationship between Patient.PatientID and

Appointment.PatientID.
Doctor-Appointment Relationship
One doctor can have multiple appointments (One-to-Many).
Represented by the relationship between Doctor.DoctorID and

Appointment.DoctorID.
Attributes
Attributes provide details about each entity.
For example, the Patient entity has attributes like Name, Address, and
ContactNumber.
Primary Keys
PatientID, DoctorID, and AppointmentID serve as unique identifiers for each

record in their respective entities.
Foreign Keys
PatientID and DoctorID in the Appointment entity are foreign keys linking back
to the primary keys of the Patient and Doctor entities, establishing connections
between them.
Multiplicity Notation
The 1 on the patient side and the asterisk * on the appointment side represent a
"One-to-Many" relationship. It signifies that one patient can have multiple
appointments, but each appointment is associated with only one patient.
The 1 on the doctor side and the asterisk * on the appointment side similarly
indicate a "One-to-Many" relationship between doctors and appointments.
This ERD illustrates how patients, doctors, and appointments are related in a
healthcare system. It's a visual representation of the structure of the database,
showcasing the entities, attributes, and relationships involved
5.2 Non-Database Management System Files
The system incorporates the use of non-DBMS files to handle various types
of data and information that do not fall within the scope of the primary
database management. These non-DBMS files serve specific purposes and
complement the functionality provided by the database.
5.2.1 Log Files

Log files are essential for maintaining a record of system activities, errors,
and transactions. These files capture relevant information such as user
actions, system events, and error messages. The log files aid in
troubleshooting, auditing, and monitoring the system's performance.
5.2.2 Configuration Files

Configuration files are used to store settings and parameters that define the
behavior of the system. These files are separate from the database to allow
for easy customization and modification without impacting the core database
structure. Configuration files are typically in plain text or XML format for
simplicity and readability.
5.2.3 External Data Files

The system may interact with external data sources or APIs, necessitating
the use of non-DBMS files to temporarily store or cache data retrieved from
these sources. These files facilitate seamless integration with external
systems and improve the efficiency of data retrieval processes.
5.2.4 User Uploads

In cases where the system allows users to upload files, such as documents,
images, or spreadsheets, non-DBMS files are utilized to store these user-
uploaded files. This approach helps in managing binary or multimedia data
efficiently.
5.2.5 Backup Files

Backup files are crucial for ensuring data recovery in the event of system
failures or data corruption. Non-DBMS files, often in compressed or archived
formats, store periodic backups of the database. These files play a vital role
in disaster recovery and system reliability.
The use of non-DBMS files complements the database-centric approach,

providing flexibility, efficiency, and enhanced system performance. Careful
management and organization of these files are maintained to ensure data
integrity and optimal system functioning.
5.3 Corrections
Section 5.3 of the Software Design Document (SDD) typically addresses any
corrections or updates made to the previous SDD. It provides a clear and
organized list of corrections, ensuring that stakeholders are aware of
changes to the initial design. Below is an example of how you might
structure this section:
5.3 Corrections to Previous SDD

The following corrections have been identified and addressed in this version
of the Software Design Document. These corrections are based on feedback,
revisions, or improvements to the initial design. It is crucial to review these
changes for a comprehensive understanding of the system's current design.
5.3.1 Correction #1: Data Flow Diagram (DFD) Adjustments

In the previous SDD, the Data Flow Diagram (DFD) did not accurately
represent the flow of data between certain processes and entities. The
revised DFD provides a more precise depiction of data interactions, ensuring
consistency with system requirements.
5.3.2 Correction #2: Modification to Entity-Relationship Diagram (ERD)

The Entity-Relationship Diagram (ERD) has undergone modifications to
enhance the representation of relationships between entities. The changes
aim to improve the clarity of the data model and maintain alignment with
the conceptual design.
5.3.3 Correction #3: Refinement of System Architecture

Upon further analysis, adjustments were made to the system architecture to
optimize performance and resource utilization. These refinements are
detailed in Section 4.1.1 System Architecture.
5.3.4 Correction #4: Clarification of Security Measures

Additional details have been included in Section 8 Security Design to provide
a clearer explanation of the security measures implemented in the system.
This clarification ensures a comprehensive understanding of the security
aspects.
5.3.5 Correction #5: Update to Class Diagram

The Class Diagram has been updated to reflect changes in class relationships
and attributes. This modification ensures that the representation of classes
aligns with the system's object-oriented design principles.
5.3.6 Correction #6: Inclusion of Non-DBMS Files Section

Section 5.2 Non-DBMS Files has been added to the SDD to address the need
for files outside the scope of the Database Management System. This
addition provides a comprehensive overview of file management in the
system.
Stakeholders are encouraged to review these corrections to stay informed

about the evolving design decisions and enhancements made to the system.
6. Software Design
In this section of the Software Design Document (SDD), the focus is on

providing a detailed design of the software, outlining the structure and
components that will implement the system as specified in earlier sections.
The key components of Section 6 include:
Structure Chart
Purpose: Illustrate the hierarchical structure of modules and their

interactions.
Content: Diagram showcasing the relationships between different modules,
data flows, and control flows.
Connection to Previous Work: Builds upon the Data Flow Diagram (DFD)
from Assignment 3.
Discussion of Structure Chart:
Purpose: Provide a narrative explaining the decisions made in creating the

Structure Chart.
Content: Explanation of data and control couples, loops, conditions
(decisions), and any other design considerations.
Human Interface Design:
Purpose: Address the user experience by discussing the general

functionality from the user's perspective.
Content: Descriptions of how users will interact with the system,
emphasizing ease of use and user satisfaction.
Mockups: Visual representations of sample user interfaces using tools like
draw.io.
This section essentially bridges the conceptual design from earlier sections to
a more concrete and detailed representation of the software architecture and
user interface design. It serves as a guide for developers to implement the
system as per the specified requirements..
6.1 Structure Chart.
The Structure Chart visually represents the architecture and organization of

the software, depicting how different modules or components interact with
each other. In the context of the Family Clinic Services Appointment
Scheduling System, the Structure Chart includes components such as
patients, doctors, receptionists, administrators, appointment requests,
appointment details, account data, availability data, and schedule data. The
interactions among these components are illustrated through data and
control couples, loops, and conditions.
6.2 Structure Chart Discussion
In this section, the discussion of the Structure Chart involves providing a

detailed explanation of the key components, relationships, and
functionalities represented in the structure chart. It serves as a narrative to
complement the visual representation of the structure chart created based
on the Data Flow Diagram (DFD).
Structure Chart Discussion
1. Main Modules
Patient Interface Module
Handles interactions related to patient appointments.
Submodules include appointment requests, details, and history.
Doctor Interface Module
Manages the doctor's schedule, patient information, and availability.
Submodules include schedule management and patient information.
Receptionist Interface Module
In charge of handling appointment requests and managing schedules.
Submodules include appointment requests and schedule management.
Administrator Module
Responsible for system configuration and user account management.
Submodules include account data, availability data, and schedule data.
2. Data and Control Couples
Data Coupling
Interaction between patient and doctor interfaces for appointment details.
Information exchange between the receptionist and administrator for
schedule updates.
Control Coupling
Patient interface controlling the flow for appointment requests.
Administrator controlling user account data updates.
3. Loops and Conditions
Appointment Request Loop

Patient interface loop for continuous appointment requests.
Conditional statements to check appointment availability.
Schedule Update Condition
Receptionist interface condition for schedule updates.
Administrator's role in deciding user access conditions.
4. Key Functionality
Appointment Request Flow
Patient initiates an appointment request.
Receptionist checks availability and processes the request.
Schedule Management Flow
Doctor updates availability.
Administrator manages user accounts and configuration.
5. Error Handling
Invalid Appointment Request
Patient interface provides error messages for unavailable slots.
Receptionist interface handles errors in schedule updates.
6. Integration Points
External Systems Integration
Interaction with the administrator module for account data.
Exchange of information between the receptionist and administrator.
This discussion provides a comprehensive overview of the structure chart,
explaining the interconnected modules, coupling types, conditional flows,
and key functionalities. It ensures that stakeholders and developers
understand the logic and interactions within the system's structural design.
7. Human Interface Design
Human Interface Design is a crucial aspect of software development that

focuses on creating user interfaces that are intuitive, user-friendly, and
efficient. In this section, you will discuss the general functionality of the
system from the user's perspective and create mockups of web pages for the
Case Study. The primary goal is to design interfaces that enhance the user
experience and meet the needs of different user classes within the Family
Clinic Services Appointment Scheduling System.
7.1 Functionality from User Perspective
User's Perspective Overview

The Family Clinic Services (FCS) Appointment Scheduling System is
designed to offer a streamlined and user-friendly experience for different
user roles, including patients, doctors/providers, receptionists, and
administrators.
User Roles and Responsibilities
Patients
Schedule, modify, and cancel appointments.
View upcoming and past appointments.
Access and update personal account information.
Doctors/Providers
View their schedules and upcoming appointments.
Manage appointment availability.
Access patient details and appointment history.
Receptionists
Manage appointment schedules for doctors/providers.
Handle patient check-ins and updates.
Assist in appointment-related tasks.
Administrators
Manage user accounts and permissions.
Configure system settings.
Oversee the overall system functionality.
User Interfaces
The system will provide role-specific user interfaces
Patients: Web-based interface for appointment scheduling and account

management.
Doctors/Providers: Web-based interface for schedule management and
patient information.
Receptionists: Web-based interface for appointment scheduling and
administrative tasks.
Administrators: Web-based interface for system configuration and user
management.
System Navigation
Patients: Intuitive navigation for appointment scheduling, viewing, and
account management.
Doctors/Providers: Easy access to schedule management, appointment
details, and patient information.
Receptionists: Streamlined navigation for appointment scheduling, check-
ins, and administrative functions.
Administrators: Efficient navigation for system configuration, user
management, and overall system oversight.
7.2 Sample Mockups of Web Pages for the Case Study.

Patient's Appointment Request Page:

Doctor's Schedule Management Page
Administrator's Account Management Page:

8. Testing
In this section, we will map the use cases outlined in the System Design
Document (SDD) to specific test cases and create detailed test scenarios to
ensure the proper functionality of the Family Clinic Services (FCS) system.
The testing process involves multiple iterations, where we identify different
aspects of the system to be targeted and perform various tests accordingly.
Automated testing tools may also be utilized to streamline the testing
process.
For instance, focusing on the "Schedule Appointment" use case, we can
develop several test cases to validate different scenarios:
1. TC001: Schedule Valid Appointment
 Description: Test the functionality of scheduling a valid
appointment with all required information provided.
 Test Data: Valid patient, available doctor, available room, and
time slot.
 Expected Results: Appointment scheduled successfully.
 Actual Results: [To be filled during testing]
 Test Case Status: [To be filled during testing]
2. TC002: Cancel Scheduled Appointment
 Description: Test the functionality of canceling a scheduled
appointment.
 Test Data: Scheduled appointment to be canceled.
 Expected Results: Appointment canceled successfully.
3. TC003: Schedule New Appointment with Missing Data
 Description: Test the system's response when attempting to
schedule an appointment with missing patient, doctor, room, or
time slot information.
 Test Data: Missing patient, doctor, room, or time slot
information.
 Expected Results: System should prompt for missing information
or display an error message.
4. TC004: Schedule Appointment with Schedule Conflict
 Description: Test the system's handling of scheduling conflicts
when attempting to book an appointment overlapping with an
existing one.
 Test Data: Appointment conflicting with an existing one.
 Expected Results: System should display a conflict message and
prevent the scheduling of the conflicting appointment.
These test cases cover a range of scenarios, including valid data,
cancellation, missing data, and scheduling conflicts, ensuring comprehensive
testing of the "Schedule Appointment" functionality. Additional test cases
can be developed based on other use cases and system functionalities
outlined in the SDD and related documentation.
8.1 Test Case TC001 Schedule New Valid Appointment
<Insert your completed TC001: Schedule New Valid Appointment test case
in this section.
Remove these directions after completing the section.>
8.1.1 TC001 Discussion.
Test Case TC001: Schedule New Valid Appointment
Test Test
Expected
Case Description Test Data Actual Results Case
Results
Steps Status
The option to The option to
Select the add new add new
Step option to add appointment appointment
N/A pass
1 a new appears with appeared with
appointment calendar as calendar as
selected selected
Navigate the
calendar and Use
Step Day appears
click on the 12/17/2020 Day is selected pass
2 as selected
day for the Thursday
appointment
Click on the
Step option to Dialog box Dialog box
N/A pass
3 choose appears appeared
patient
Navigate the
Patient name
Step patient list John Patient name
appears as pass
4 and choose Murphy appeared
selected
patient
Navigate the
Service
Service
Provider list Service
Step provider's
and choose Dr. Bryant provider's name pass
5 name appears
available appeared
as selected
service
provider
Room number Room number

Choose
Step 6 Room 4 appears as appeared as pass
available room
selected selected
Start 9:20
Choose Start and end
am Start and end
Step 7 appointment time appear as pass
End 10:00 time selected.
start/end time. selected
am
Dialog box
Dialog box
closes,
closed, schedule
Step Save start and schedule
N/A refreshed with pass
8 end time refreshes with
the new
the new
appointment
appointment
8.2 Test Case TC002 Cancel Scheduled Appointment
Test Case TC002: Cancel Scheduled Appointment

Test Case Steps:
Test
Actual Case
Step Description Test Data Expected Results Results Status
Select the scheduled Appointment is
appointment to Scheduled selected for
1 cancel. appointment cancellation.
Choose the option to
cancel the Confirmation dialog
2 appointment. N/A box appears.
Appointment is
Confirm the canceled
3 cancellation. N/A successfully.
Appointment status
Verify the changes to
4 appointment status. N/A canceled.
The purpose of this test case is to verify the functionality of canceling a

scheduled appointment within the Family Clinic Services (FCS) system. By
selecting a scheduled appointment, the user initiates the cancellation
process, which prompts a confirmation dialog. Upon confirmation, the

appointment should be successfully canceled, and its status updated
accordingly.
Cancellation of appointments is a critical feature in the system, allowing
patients to manage their schedules effectively and ensuring that unused
appointment slots can be made available for other patients. Testing this
functionality helps ensure that appointments can be canceled without any
errors or inconsistencies in the system.
During testing, it's essential to verify that the cancellation process is smooth
and intuitive for users. Any issues or unexpected behaviors encountered
during testing should be documented and addressed to improve the overall
reliability and usability of the system.
Overall, TC002 aims to validate the reliability and accuracy of the
appointment cancellation feature, ensuring a seamless user experience
within the FCS system.
8.3 Test Case TC003 Schedule New Appointment without Data
Test Case Steps:

Test
Test Actual Case
Step Description Data Expected Results Results Status
Navigate to the option to New appointment
1 add a new appointment. N/A form is displayed.
Proceed with scheduling Error message
without selecting a prompts user to select
2 patient. N/A a patient.
Attempt to choose a Error message
doctor without any indicates no available
3 available options. N/A doctors.
Error message
Select a room without any indicates no available
4 available options. N/A rooms.
Choose an appointment Error message
time without available indicates no available
5 time slots. N/A time slots.
Attempt to save the Error message
appointment without prompts user to
6 required information. N/A complete all fields.
This test case is designed to evaluate the system's behavior when

attempting to schedule a new appointment without providing essential
information. By intentionally omitting data such as patient selection,
available doctor, room, and appointment time, we aim to verify that the
system appropriately handles missing data and prompts users to provide
required information.
The primary objective of TC003 is to ensure that the system effectively
communicates any errors or missing information to users during the
appointment scheduling process. By presenting clear and concise error
messages, users can understand what information is missing and take

appropriate action to complete the scheduling process successfully.
Testing this scenario is crucial to guaranteeing the system's usability and
user-friendliness. By identifying and addressing any issues related to data
validation and error handling, we can enhance the overall user experience
and minimize potential frustration for users attempting to schedule
appointments.
During testing, it's essential to verify that the error messages displayed are
accurate and informative, guiding users towards completing the required
fields accurately. Any inconsistencies or unexpected behaviors encountered
during testing should be documented and addressed to improve the
system's reliability and usability.
In summary, TC003 focuses on evaluating the system's ability to handle
appointment scheduling scenarios with missing data, ensuring a seamless
and error-free user experience within the Family Clinic Services (FCS)
system.
8.4 Test Case TC004 Schedule Appointment with Schedule Conflict
Test Case Steps:

Test
Expected Actual Case
Step Description Test Data Results Results Status
Navigate to the option to New appointment
1 add a new appointment. N/A form is displayed.
Select a date and time for
the appointment that
conflicts with an existing Date: Time: 9:00 AM -
2 schedule. 02/18/2024 10:00 AM
Choose a patient, doctor,
and room for the Patient: John Room:
3 appointment. Doe Doctor: Dr. Smith Room 3
Error message
Attempt to save the indicates a
appointment with the scheduling
4 conflicting schedule. N/A conflict.
Test case TC004 aims to evaluate the system's behavior when a user
attempts to schedule an appointment with a time slot that conflicts with an
existing schedule. The scenario involves intentionally selecting a date and
time that overlaps with an existing appointment, simulating a scheduling
conflict.
The primary objective of this test case is to ensure that the system
effectively detects and communicates scheduling conflicts to users during
the appointment scheduling process. By presenting a clear and informative
error message, users can understand the nature of the conflict and take
appropriate action to resolve it.
During testing, it's essential to verify that the system accurately identifies
conflicting schedules based on the selected date and time. The error
message displayed should provide relevant details about the conflicting
appointment, such as the patient's name, doctor, and room, enabling users
to make informed decisions about rescheduling or adjusting the
appointment.
Additionally, the system should prevent the user from saving the
appointment until the scheduling conflict is resolved. This ensures data
integrity and prevents the creation of conflicting schedules within the
system.
By testing TC004, we can validate the system's ability to handle scheduling
conflicts effectively, thereby enhancing the overall reliability and usability of
the appointment scheduling feature within the Family Clinic Services (FCS)
system. Any issues or inconsistencies encountered during testing should be
documented and addressed to improve the system's performance and user
experience.
8.5 Testing Types
Testing Types
During the software development life cycle (SDLC), various types of testing
are conducted to ensure the quality, reliability, and functionality of the
system. Each stage of testing serves a specific purpose and targets different
aspects of the software. Here are the testing types for different stages of
testing:
1. Unit Testing:
 Purpose: Unit testing focuses on testing individual components
or units of the software in isolation.
 Types of Tests:
 Functionality Testing: Ensures that each function or
method performs as expected.
 Boundary Testing: Tests the boundaries of input
parameters to identify any boundary-related issues.
 Exception Handling Testing: Verifies the system's ability
to handle exceptions and error conditions gracefully.
 Relation to the Case Study: In the context of Family Clinic
Services (FCS) system, unit testing can be performed on
individual modules or components, such as appointment
scheduling, patient management, and doctor availability, to
ensure that each unit functions correctly.
2. Integration Testing:
Purpose: Integration testing focuses on testing the interactions


and interfaces between different modules or components of the
system.
 Types of Tests:
 Interface Testing: Verifies the communication and data
exchange between interconnected modules.
 Integration Flow Testing: Tests the flow of data and
control between integrated components.
 Compatibility Testing: Ensures that the integrated
system is compatible with external systems or interfaces.
 Relation to the Case Study: In the FCS system, integration
testing can be conducted to validate the seamless integration of
various modules, such as appointment scheduling, patient
management, and doctor availability, ensuring smooth
interaction between different components.
3. System Testing:
 Purpose: System testing evaluates the system as a whole to
verify that it meets the specified requirements and functions
correctly in the intended environment.
 Types of Tests:
 Functional Testing: Tests the system's functionality
against the defined requirements.
 Performance Testing: Assesses the system's
performance under various conditions, such as load,
stress, and scalability.
 Security Testing: Identifies and mitigates security
vulnerabilities and ensures data protection.
 Relation to the Case Study: System testing in the FCS system
involves validating the overall functionality, performance, and
security aspects of the software, including appointment
scheduling, patient management, and system administration
features.
4. Acceptance Testing:
 Purpose: Acceptance testing evaluates whether the system
meets the acceptance criteria and satisfies the stakeholders'
requirements.
 Types of Tests:
 User Acceptance Testing (UAT): Conducted by end-
users to validate the system's compliance with business
requirements.
Alpha and Beta Testing: Involves testing the software in

real-world scenarios before and after release to gather
feedback and identify any remaining issues.
 Relation to the Case Study: Acceptance testing for the FCS
system involves validating the usability, functionality, and overall
satisfaction of stakeholders with the implemented features,
including appointment scheduling, patient management, and
system administration functionalities.
By conducting these various types of testing throughout the SDLC, the
Family Clinic Services (FCS) system can ensure the delivery of a high-
quality, reliable, and user-friendly software solution that meets the needs of
its users and stakeholders.
Appendix.
<Add other relevant sections here.
Remove these directions after completing the section.>

Assignment 6 SDDStructure Chart Emerald Bekoe

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Assignment 6 SDDStructure Chart Emerald Bekoe

Uploaded by

Copyright:

Available Formats

System Design

Family Clinic Services

Prepared by Emerald Bekoe

American Public University System

February 04, 2024

Name Date Reason for Changes Version

The System Design Specification (SDD) identifies the architecture, software

The SDD covers:

- System architecture overview

This document aims to provide all technical details needed by the

- Patient, doctor, receptionist, and administrator modules

In summary, this SDD provides comprehensive technical system design

Some of the standards and conventions followed in this System Design

- Section headers are numbered and in bold font

- Subsection headers are numbered by section and unbolded

- Requirements and specifications are not marked by priority - all are

- Diagrams and models utilize standard UML notation

- Table headers are bolded while data is unbolded

- Code snippets use fixed-width font and syntax highlighting

- No special highlighting is used to call out requirements or specs

- Acronyms are defined at first use

- Terms are defined in a glossary section

- References to other documents are in italics

- Numbering follows an outlined structure for sections/subsections

2.2 Intended Audience and Reading Suggestions

- Developers - Will utilize the technical details for system architecture,

- Project Managers - Will leverage the component diagrams, interface

- Testers - Will use the component and interface details to develop

- Writers - Will reference architecture and component documentation to

- System architecture overview

Suggested reading sequence:

- Developers - Read architecture overview then study component design and

- Project Managers - Review architecture overview followed by component

- Testers - Read interface specifications to build test cases, along with

- Writers - Reference architecture overview, component diagrams, and

The overview provides context followed by implementation details for each

The purpose of this software is to enable patients to book appointments

- Improving patient satisfaction by reducing wait times through online

- Increasing provider productivity and efficiency via optimized appointment

- Lowering administrative costs by automating manual appointment booking

- Providing flexibility for patients to book appointments 24/7

- Enabling better resource planning using real-time visibility into provider

The Software Requirements Specification (SRS) document contains the

In summary, this software aims to implement online appointment scheduling

Microsoft. (2023). Cloud Computing Services | Microsoft Azure.

Noumeir, R. (2018). Active Learning of the HL7 Medical Standard. Journal of

Digital Imaging, 32(3), 354–361. https://doi.org/10.1007/s10278-

Oracle Corporation. (2019). MySQL :: MySQL 8.0 Reference Manual.

React. (2020). React – A JavaScript library for building user interfaces.

The overview will cover:

The objective is to create an overview and mental map of the technical

3.1 Goals, Functionality and Architecture

2. System Design Goals

3.2 Design Constraints

User and Stakeholder Expectations

The System Architecture section elaborates the high-level design and

The aim is to present a general picture of the strategic technical design

4.1 Architectural Design

4.2 Subsystem Decomposition

User Management Subsystem:

Data Processing Subsystem:

Reporting and Analytics Subsystem:

Logging and Auditing Subsystem: