Assignment 6 SDDStructure Chart Emerald Bekoe
Assignment 6 SDDStructure Chart Emerald Bekoe
Specification (SDD)
DRAFT
for
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
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:
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.
Draft System Design Document for Family Clinic Services Page 3
This System Design Specification (SDD) is intended for the following reader
types:
The software being specified in this SDD is the Family Clinic Services (FCS)
Appointment Scheduling System.
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.
Azure.microsoft.com. https://azure.microsoft.com/en-us
018-0134-3
Mysql.com. https://dev.mysql.com/doc/refman/8.0/en/
Reactjs.org. https://legacy.reactjs.org/
Draft System Design Document for Family Clinic Services Page 5
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.
- 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
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.
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.
Draft System Design Document for Family Clinic Services Page 6
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.
Draft System Design Document for Family Clinic Services Page 7
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.
Draft System Design Document for Family Clinic Services Page 8
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.
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.
Draft System Design Document for Family Clinic Services Page 9
4. System Architecture
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.
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.
Draft System Design Document for Family Clinic Services Page 11
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.
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.
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.
Draft System Design Document for Family Clinic Services Page 12
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.
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.
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.
3. Key Management:
Management Strategies:
Draft System Design Document for Family Clinic Services Page 13
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:
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.
1. Microservices Architecture:
Reasoning:
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:
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.
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.
Draft System Design Document for Family Clinic Services Page 15
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.
Draft System Design Document for Family Clinic Services Page 16
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.
D1
Draft System Design Document for Family Clinic Services Page 17
Entities
Patient Entity
Doctor Entity
Appointment Entity
Relationships
Patient-Appointment Relationship
Doctor-Appointment Relationship
Attributes
For example, the Patient entity has attributes like Name, Address, and
ContactNumber.
Primary Keys
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
Draft System Design Document for Family Clinic Services Page 19
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
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.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:
6. Software Design
Structure Chart
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.
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.
Actual Results: [To be filled during testing]
Test Case Status: [To be filled during testing]
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.
Actual Results: [To be filled during testing]
Test Case Status: [To be filled during testing]
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.
Actual Results: [To be filled during testing]
Test Case Status: [To be filled during testing]
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.
Draft System Design Document for Family Clinic Services Page 33
<Insert your completed TC001: Schedule New Valid Appointment test case
in this section.
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
Draft System Design Document for Family Clinic Services Page 34
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.
Draft System Design Document for Family Clinic Services Page 37
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.
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:
Draft System Design Document for Family Clinic Services Page 38
Appendix.