DEV Community: NDUNG?U JEFFERSON MARIRA

Task Final Documentation - System Requirements Specification

NDUNG?U JEFFERSON MARIRA — Wed, 20 Nov 2024 17:19:37 +0000

Systems Requirements Specification (SRS)## 1. Introduction

1.

1 Purpose
The purpose of this SRS is to provide a comprehensive description of the system requirements for [Project Name]. This document will serve as a guideline for developers, programmers, users, management, and contractors.

1.

2 Scope
This system aims to [briefly describe the system's objectives and functionalities]. It will enhance [specific business processes or user experiences].

1.

3 Definitions, Acronyms, and Abbreviations

SRS: Systems Requirements Specification
UI: User Interface
API: Application Programming Interface ## 2. Overall Description ### 2. 1 Product Perspective [Describe how the system fits into the current environment or integrates with existing systems.]### 2. 2 Product Functions
User authentication and authorization
Data management and storage
Reporting and analytics
User interface for interaction ### 2. 3 User Classes and Characteristics
End Users: [Describe user demographics and needs]- Administrators: [Describe responsibilities and access levels]### 2. 4 Operating Environment The system will operate on [specify hardware, software, and network requirements]. ## 3. Specific Requirements ### 3. 1 Functional Requirements
User Login: Users must be able to securely log in.
Data Entry: Users should be able to input and edit data. ### 3. 2 Non-Functional Requirements
Performance: The system should handle up to [X] concurrent users.
Security: Data must be encrypted and comply with [specific regulations]. ## 4. Assumptions and Dependencies
The system will rely on [specific technologies or platforms].
Users will have access to [necessary hardware/software]. ## 5. Approval This SRS is approved by:
[Name, Title, Date]- [Name, Title, Date]---This template can be customized further based on specific project needs and stakeholder input.

Technology Design

NDUNG?U JEFFERSON MARIRA — Fri, 01 Nov 2024 18:19:41 +0000

this guidance, or minimum viable product (MVP), covers governance, cybersecurity and zero trust, and API design and implementation principles. Future versions will include additional topics such as testing, development, security, and operations (DevSecOps), secure programming and error handling, performance optimization, and scalability.
This document includes use cases, lessons learned, and best practices from DoD and industry. Although other guides exist, this guide emphasizes the importance of enhancing and advancing
API TECHNICAL GUIDANCE
“a system access point ... accessible from application programs . . . to provide
well-defined functionality” (NIST SP 1800-21). APIs promote interoperability, security, and
scalability.
1

Introduction the DoD warfighting capabilities of the near future to support the Combined JADC2 (CJADC2) vision and to secure information interoperability across the DoD. (See also Appendix C: API Security Challenges for more detail about the CJADC2 vision.) The guide describes an API framework to help programs define their technical baseline for delivering future systems that support the DoD enterprise and warfighter mission requirements. Figure 1-1 illustrates the scope of APIs covered in this guidance from a system perspective. pg Figure 1-1. API Context Diagram from a System Perspective This figure views an API as a socket connection between two systems. In general, a socket (e.g., Web, Berkley, Windows, Unix, Linux, Java) is an abstract representation for the local endpoint of a network communications path. This perspective dichotomizes API ecosystems into those designed for the DoD and commercial industry. Four types of DoD-specific warfighting systems are non-real-time (e.g., intelligence analytics, logistics); real-time (e.g., networked weapons); back-end (e.g., order of battle); and capability development (e.g., wargames, modeling and simulation); however, the commercial API ecosystems such as business systems (e.g., paychecks); social networks (e.g., SIPR chat, other ChatOps); transport systems (e.g., Link 16); or other frameworks (e.g., Global Information Grid) are also partially in scope. Each such system contains one or more open or proprietary API socket interfaces connecting with other systems. The future design scope of APIs includes the four DoD systems and, in part, the four commercial systems. In the future, with the exception of proprietary APIs, any API developed for or used by the DoD will be considered within scope. API TECHNICAL GUIDANCE Future Purchasing\Use Scope Rule: Any future framework, system, software, or application for purchase or use by the DoD should be considered within scope of this guidance. Future Design Scope Rule: The design of APIs are considered within scope of this guidance when the framework, system, software, or application using the APIs are are primarily designed or specified by the DoD and services. DoD, Joint and Service Designed Systems Commercially Designed Systems Backend Warfighting Systems (e.g. battle order of battle databases) Non Real-Time Warfighting Systems (e.g. Intelligence analytics, logistics) (e.g. Paycheck, housing) (e.g. Bank transfers, CAD) Social Network (e.g. Sipr Chat) Real-Time Warfighting Systems (e.g. Networked weapon system) Warfighting Capability Development Systems (e.g. wargames, modeling & simulation) Business Systems Transport Systems (e.g. JTTRS Link 16) (e.g. USB ) Systems (e.g. FaceBook, Zoom ) (e.g. Global Information Grid) (e.g. Data Fabric ) Frameworks Socket API 2

The scope of APIs also can be seen from a data perspective as shown in Figure 1-2.
Source: (NATO 2023)
Figure 1-2. API Context Diagram from a Data Perspective

Introduction This figure views an API as an automated data standard between two services. In general, a data standard is any documented agreement on the representation, format, definition, structuring, tagging, transmission, manipulation, use, and management of data (EPA 2023). An automated data standard or API can reside at various levels including between autonomous decision-making and data insight/analytic services (e.g., reporting, machine learning, statistical analysis); analytics services and storage services (e.g., data warehouse, data lake); data integration and interoperability services (e.g., batch or stream processing or data visualization) and community of interest services; or data management and governance and the management plane (e.g., data quality and security). Thus, any API in use by, designed by, or specified by the DoD, Joint, or Services is considered within scope of this guidance. The following items will be reserved for a future release: • Testing • APIs and DevSecOps • Secure Programming and Error Handling • Performance Optimization and Scalability API TECHNICAL GUIDANCE

Task for Thursday Oct 17 - Analysis of Job of SA

NDUNG?U JEFFERSON MARIRA — Fri, 18 Oct 2024 01:15:38 +0000

Here's a structured analysis of a job advertisement for a System Analyst position in a Kenyan public institution. For the purpose of this example, let's assume we found a job advert from a Kenyan government agency.

Job Advert Summary

Position: System Analyst

Institution: National Transport and Safety Authority (NTSA)

Location: Nairobi, Kenya

Analysis Report

Aspect	Details
Key Responsibilities	- Analyze user requirements and business needs.
	- Design and implement system solutions to meet business goals.
	- Collaborate with stakeholders to gather and document requirements.
	- Perform system testing and validation to ensure quality and functionality.
	- Provide ongoing support and maintenance for existing systems.
	- Prepare technical documentation and user manuals.
	- Stay updated with industry trends and emerging technologies.
Required Skills	- Strong analytical and problem-solving skills.
	- Excellent communication and interpersonal skills.
	- Proficiency in programming languages (e.g., Java, Python).
	- Knowledge of database management systems (e.g., SQL).
	- Familiarity with software development methodologies (e.g., Agile, Waterfall).
	- Ability to work collaboratively in a team environment.
Tools/Technologies	- Programming tools: Eclipse, Visual Studio.
	- Database tools: MySQL, Oracle.
	- Project management tools: Jira, Trello.
	- Testing tools: Selenium, Postman.
	- Version control systems: Git, GitHub.

Conclusion

This analysis provides a concise overview of the key responsibilities, required skills, and tools relevant to the System Analyst role in a Kenyan public institution. This format allows for quick reference and helps in identifying the core competencies needed for the position.

Task 6: Database Design

NDUNG?U JEFFERSON MARIRA — Tue, 15 Oct 2024 20:55:06 +0000

Objective:
To design the database for the case information system.

Task:
Using your knowledge of database systems design the required database design for the proposed information system.

Kenyatta University Teaching, Research & Referral Hospital (KUTRRH) is a major healthcare facility in Kenya, affiliated with Kenyatta University. It serves as a teaching hospital for medical students and healthcare professionals, providing a range of services, including specialized care, research opportunities, and community health programs.

A detailed process specification

NDUNG?U JEFFERSON MARIRA — Thu, 10 Oct 2024 20:01:04 +0000

To create a detailed process specification, follow this structured outline for a key process identified in your Data Flow Diagrams (DFDs). Here’s a general template you can use:

Process Specification Template

Process Name: [Name of the Process]

Process ID: [Unique Identifier]

Purpose:

Describe the main objective of the process and its significance in the overall system.

Inputs:

List all inputs required for this process, including sources and formats.
Include any data, documents, or information needed to initiate the process.

Outputs:

List all outputs generated by the process, detailing their format and destination.
Specify any reports, documents, or notifications produced.

Process Description:

Provide a detailed step-by-step description of the process, including:

Step 1: [Description of the action taken]
Step 2: [Description of the action taken]
Step 3: [Description of the action taken] (Continue as necessary)

Business Rules:

Detail any rules or guidelines that govern the process. This could include policies, regulations, or specific constraints.

Actors:

Identify the roles or individuals involved in the process, along with their responsibilities.

Exception Handling:

Outline how exceptions or errors are managed within the process. Include steps for troubleshooting or escalation.

Frequency:

Indicate how often the process is performed (e.g., daily, weekly, monthly).

Tools/Technologies:

List any software, tools, or technologies used to facilitate the process.

Dependencies:

Describe any dependencies on other processes or systems that may affect the execution of this process.

Example Process Specification

Process Name: Customer Order Processing

Process ID: CO-01

Purpose:

To efficiently manage and fulfill customer orders while ensuring accuracy and timely delivery.

Inputs:

Customer Order Form (online or physical)
Payment Information
Inventory Data

Outputs:

Order Confirmation
Invoice
Shipping Notification

Process Description:

Receive Order: Capture customer details and order specifics.
Verify Payment: Check payment status and process payment.
Check Inventory: Confirm product availability in the inventory system.
Prepare Order: Package items for shipping.
Ship Order: Generate shipping labels and dispatch the order.

Business Rules:

Orders must be confirmed within 24 hours.
Payments must be processed before order fulfillment.

Actors:

Sales Representative: Takes orders and communicates with customers.
Inventory Manager: Oversees stock levels and order fulfillment.
Shipping Coordinator: Manages shipping and delivery processes.

Exception Handling:

If payment fails, notify the customer and request a different payment method.
If an item is out of stock, inform the customer and suggest alternatives.

Frequency:

Performed daily as orders are received.

Tools/Technologies:

Order Management System
Payment Gateway
Inventory Management Software

Dependencies:

Relies on accurate inventory data and payment processing systems.

By using this template, each group member can create unique process specifications for different key processes identified in your DFDs, ensuring comprehensive documentation.

Project

NDUNG?U JEFFERSON MARIRA — Wed, 09 Oct 2024 20:42:07 +0000

Here are five key points regarding school projects:

Planning and Organization: Effective planning helps manage time and resources, ensuring that all aspects of the project are addressed.
Collaboration: Working in teams fosters communication and diverse perspectives, enhancing the overall quality of the project.
Research Skills: Conducting thorough research is crucial for gathering accurate information and supporting your project's objectives.
Presentation: Developing strong presentation skills is essential for clearly conveying ideas and engaging the audience.
Reflection and Feedback: Analyzing the project outcome and incorporating feedback helps improve future projects and personal growth.

"the diagram below shows lower level details for process x1 of the y1 system".

NDUNG?U JEFFERSON MARIRA — Sat, 05 Oct 2024 20:42:06 +0000

To proceed with the assignment, follow these steps:

Select a Process: Choose one core process from the Top Level DFD submitted in Project 5a. Ensure it's a significant process that represents the core functionality of the system.
Identify Sub-Processes: Break down the chosen process into no more than three sub-processes. Ensure each sub-process logically represents a part of the core function.
Documenting the Process:
- Create a new page in your DFD documentation.
- Title the page appropriately, indicating it contains details of the exploded process.
- Include a one-liner description, such as: "The diagram below shows lower level details for process X1 of the Y1 system."
Maintain Consistency: Use a consistent format for all exploded processes throughout the documentation. This includes similar styles for diagrams, descriptions, and any accompanying text.
Collaborate with Group Members: Coordinate with your group to ensure that each member selects different processes and maintains a unified document style.
Final Review: Once all processes are documented, review the consolidated document for coherence and completeness.

Example Submission Structure:

Page Title: Exploded Process for Process X1

Description: "The diagram below shows lower level details for process X1 of the Y1 system."

[Insert Exploded DFD Diagram Here]

Sub-Processes:

Sub-Process A: Description of sub-process A.
Sub-Process B: Description of sub-process B.
Sub-Process C: Description of sub-process C.

Conclusion

This approach will help in creating a clear, organized, and cohesive documentation for the final system project.

Draw context diagram and top-level data flow diagram for the group project

NDUNG?U JEFFERSON MARIRA — Fri, 04 Oct 2024 20:07:25 +0000

To create context and top-level data flow diagrams (DFDs) for the Kenyatta University Teaching, Research, and Referral Hospital, let’s outline their purpose and components first.

Context Diagram

Purpose: A context diagram provides a high-level view of the system and its interactions with external entities. It identifies the system's boundaries and shows how data flows between the system and external actors.

Components:

System: Kenyatta University Teaching, Research, and Referral Hospital
External Entities:
- Patients
- Healthcare Providers
- Insurance Companies
- Regulatory Bodies

Diagram:

[Patients] ---> (Kenyatta University Teaching, Research, and Referral Hospital) <--- [Healthcare Providers]
               ^                                              |
               |                                              |
          [Insurance Companies]                              |
               |                                              |
               v                                              v
          [Regulatory Bodies]

Top-Level Data Flow Diagram

Purpose: The top-level DFD provides a more detailed view of the system, showing the main processes and data stores. It illustrates how data moves within the system.

Components:

Processes:
1. Patient Registration
2. Appointment Scheduling
3. Patient Care Management
4. Billing and Insurance Processing
5. Reporting and Compliance
Data Stores:
- Patient Records
- Appointment Logs
- Billing Information
- Compliance Reports

Diagram:

                             +------------------+
                             |   Patients       |
                             +------------------+
                                     |
                                     v
                             +------------------+
                             | 1. Patient       | 
                             |    Registration   |
                             +------------------+
                                     |
                                     v
                             +------------------+
                             | 2. Appointment    |
                             |    Scheduling      |
                             +------------------+
                                     |
                                     v
                             +------------------+
                             | 3. Patient Care   |
                             |    Management      |
                             +------------------+
                                     |
                                     v
                             +------------------+
                             | 4. Billing and    |
                             |    Insurance      |
                             |    Processing      |
                             +------------------+
                                     |
                                     v
                             +------------------+
                             | 5. Reporting and  |
                             |    Compliance     |
                             +------------------+
                                     |
                                     v
                             +------------------+
                             |   Data Stores     |
                             +------------------+
                             |  Patient Records  |
                             |  Appointment Logs  |
                             |  Billing Info      |
                             |  Compliance Reports |
                             +------------------+

Summary

Context Diagram: Illustrates the hospital's interactions with external entities.
Top-Level DFD: Breaks down the internal processes and data flows within the hospital's system.

These diagrams help visualize how data moves through the hospital's operations, enhancing understanding and communication among stakeholders.

Comparison of System Development Methodologies

NDUNG?U JEFFERSON MARIRA — Thu, 03 Oct 2024 11:50:30 +0000

Here’s a comparative analysis of the five major System Development Methodologies based on Purpose, Target Applications, and Industry Practices, presented in a matrix format.

Methodology	Purpose	Target Applications	Industry Practices
Waterfall	Sequential model for clear project phases	Large-scale, well-defined projects	Government, construction, and manufacturing sectors
Agile	Iterative development for flexibility	Dynamic projects with changing requirements	Software development, startups, and tech companies
Rapid Application Development (RAD)	Fast prototyping and iteration	Applications needing quick delivery	Software startups, web applications, and consumer software
DevOps	Continuous integration and delivery	Continuous software development and deployment	Tech companies focused on collaboration and automation
Extreme Programming (XP)	Enhance software quality through practices	Projects with high risk and frequent changes	Agile software development environments

This matrix provides a concise overview, highlighting the unique characteristics of each methodology.

Draft System Specification Documentation

NDUNG?U JEFFERSON MARIRA — Thu, 03 Oct 2024 11:47:03 +0000

Systems Requirements Specification (SRS) Document

Introduction
- 1.1 Purpose
- 1.2 Scope
- 1.3 Definitions, Acronyms, and Abbreviations
- 1.4 References
- 1.5 Overview
Overall Description
- 2.1 Product Perspective
- 2.2 Product Functions
- 2.3 User Classes and Characteristics
- 2.4 Operating Environment
- 2.5 Design and Implementation Constraints
Specific Requirements
- 3.1 Functional Requirements
- 3.2 Non-Functional Requirements
- 3.3 Interface Requirements
Use Cases
- 4.1 Use Case Diagram
- 4.2 Use Case Descriptions
Acceptance Criteria
Appendix
- 6.1 Glossary
- 6.2 Document History

1. Introduction

1.1 Purpose

This document specifies the requirements for the [Project Name] system. It is intended for stakeholders including project managers, developers, and end-users.

1.2 Scope

The [Project Name] system aims to [briefly describe the purpose and goals of the system]. It will provide functionalities such as [list key features].

1.3 Definitions, Acronyms, and Abbreviations

SRS: Systems Requirements Specification
API: Application Programming Interface
UI: User Interface

1.4 References

[Reference documents, if any]
[Standards relevant to the project]

1.5 Overview

This document is structured to cover overall system requirements, detailed functional and non-functional specifications, and use case scenarios.

2. Overall Description

2.1 Product Perspective

The system will be a standalone application with web-based capabilities, designed to integrate with existing systems via APIs.

2.2 Product Functions

User authentication and management
Data input and retrieval
Reporting and analytics
Integration with third-party services

2.3 User Classes and Characteristics

End Users: Require intuitive UI for daily tasks.
Administrators: Need advanced functionalities for user management and data handling.

2.4 Operating Environment

The system will operate in a cloud environment, supporting major browsers (Chrome, Firefox, Safari).

2.5 Design and Implementation Constraints

Must comply with GDPR and relevant data protection regulations.
Must be scalable to accommodate growing user demands.

3. Specific Requirements

3.1 Functional Requirements

User Registration: Users shall be able to register with email and password.
Login: Users shall authenticate using email and password.
Data Management: Users shall create, read, update, and delete data entries.

3.2 Non-Functional Requirements

Performance: The system should support 100 concurrent users with response times under 2 seconds.
Security: Must implement data encryption and secure API access.

3.3 Interface Requirements

User Interface: Must be responsive and accessible.
API Interface: Must expose endpoints for third-party integration.

4. Use Cases

4.1 Use Case Diagram

[Insert use case diagram here]

4.2 Use Case Descriptions

Use Case 1: User Registration

Actors: End User
Preconditions: User is not logged in.
Postconditions: User is registered and can log in.

Use Case 2: Data Entry

Actors: End User
Preconditions: User is logged in.
Postconditions: Data is saved in the system.

5. Acceptance Criteria

All functional requirements must be met and validated through user testing.
Performance criteria must be achieved under load testing conditions.

6. Appendix

6.1 Glossary

Authentication: The process of verifying user identity.

6.2 Document History

Version 1.0: Initial draft
Version 1.1: Incorporated feedback from review sessions

This draft outlines the comprehensive requirements for the [Project Name] system and incorporates feedback from previous tasks to ensure clarity and completeness. Further refinements will be made based on ongoing stakeholder discussions.

Use Case Models for KUTRRH(Kenyatta University Teaching Research and Referral Hospital) UML

NDUNG?U JEFFERSON MARIRA — Tue, 01 Oct 2024 18:41:45 +0000

To create a use case model for a referral hospital, you can follow these steps:

1. Identify Actors:

Patients
Doctors
Nurses
Receptionists
Billing Staff
Administrators

2. Identify Use Cases:

Patient Registration
Schedule Appointment
Refer Patient
Conduct Consultation
Manage Medical Records
Billing and Payment
Discharge Patient
Order Tests
Access Test Results

3. Draw the Use Case Diagram:

Using UML notation, represent the identified actors and use cases.

Example Structure:

Place actors outside the system boundary (a rectangle).
Draw ovals for each use case within the system boundary.
Connect actors to the use cases they interact with using lines.

Sample Diagram (Textual Representation):

          +-------------------+
          |  Referral Hospital |
          |                   |
          |   +-------------+ |
          |   | Patient     | |
          |   +-------------+ |
          |   +-------------+ |
          |   | Doctor      | |
          |   +-------------+ |
          |   +-------------+ |
          |   | Nurse       | |
          |   +-------------+ |
          |   +-------------+ |
          |   | Receptionist | |
          |   +-------------+ |
          |   +-------------+ |
          |   | Billing Staff | |
          |   +-------------+ |
          |   +-------------+ |
          |   | Administrator | |
          |   +-------------+ |
          |                   |
          +-------------------+

          Use Cases:
          - Patient Registration
          - Schedule Appointment
          - Refer Patient
          - Conduct Consultation
          - Manage Medical Records
          - Billing and Payment
          - Discharge Patient
          - Order Tests
          - Access Test Results

4. Describe Interactions:

Patients interact with registration and appointment scheduling.
Doctors refer patients, conduct consultations, and access medical records.
Nurses assist in patient care and manage records.
Receptionists handle patient registration and appointment scheduling.
Billing Staff manage billing processes.
Administrators oversee the overall functioning of the hospital system.

Conclusion:

This diagram serves as a foundation for understanding how different roles interact with various functionalities within a referral hospital. You can use UML software (like Lucidchart, Visual Paradigm, or draw.io) to create a polished version of this diagram.
+-------------------+
| Referral Hospital |
| |
| +-------------+ |
| | Patient | |
| +-------------+ |
| +-------------+ |
| | Doctor | |
| +-------------+ |
| +-------------+ |
| | Nurse | |
| +-------------+ |
| +-------------+ |
| | Receptionist | |
| +-------------+ |
| +-------------+ |
| | Billing Staff | |
| +-------------+ |
| +-------------+ |
| | Administrator | |
| +-------------+ |
| |
+-------------------+

      Use Cases:
      - Patient Registration
      - Schedule Appointment
      - Refer Patient
      - Conduct Consultation
      - Manage Medical Records
      - Billing and Payment
      - Discharge Patient
      - Order Tests
      - Access Test Results

Task for Thursday

NDUNG?U JEFFERSON MARIRA — Thu, 26 Sep 2024 16:04:55 +0000

You are required to research and find as much information about the Agile Methodology, especially from industry practices
State eight(8) salient points about the Agile Methodology

Note

• Write one-liner statements that are factual, clear and require no explanation
• Write insightful statements that demonstrate you have done some research
• Avoid vague statements e.g. Agile is flexible or Agile encourage quality
• Avoid text book material e.g. the principles or the steps of Agile
• This is an individual task to be done during (or lieu of) the class session

You are required to research and find as much information about the Agile Methodology, especially from industry practices
State eight(8) salient points about the Agile Methodology

Note

Agile methodologies, such as Scrum and Kanban, emphasize iterative development, allowing teams to adapt to changing requirements throughout the project lifecycle.
Continuous integration and continuous deployment (CI/CD) practices are commonly employed in Agile environments to enhance software delivery speed and reliability.
Agile encourages frequent stakeholder collaboration, ensuring that customer feedback directly informs product development and prioritization.
Teams often utilize velocity metrics in Scrum to measure work completed in each iteration, aiding in future sprint planning and estimation.
The concept of "technical debt" is actively managed in Agile practices, promoting regular refactoring to maintain code quality and system maintainability.
Agile frameworks typically promote cross-functional teams, combining diverse skill sets to increase team autonomy and innovation.
Retrospectives at the end of each iteration are standard practice in Agile, fostering a culture of continuous improvement and team reflection.
Many organizations implement Agile at scale using frameworks like SAFe (Scaled Agile Framework) to coordinate multiple teams working on interconnected projects.

DEV Community: NDUNG?U JEFFERSON MARIRA

Task Final Documentation - System Requirements Specification

Systems Requirements Specification (SRS)## 1. Introduction

1.

1.

1.

Technology Design

Task for Thursday Oct 17 - Analysis of Job of SA

Job Advert Summary

Analysis Report

Conclusion

Task 6: Database Design

A detailed process specification

Process Specification Template

Example Process Specification

Project

"the diagram below shows lower level details for process x1 of the y1 system".

Example Submission Structure:

Conclusion

Draw context diagram and top-level data flow diagram for the group project

Context Diagram

Components:

Diagram:

Top-Level Data Flow Diagram

Components:

Diagram:

Summary

Comparison of System Development Methodologies

Draft System Specification Documentation

Systems Requirements Specification (SRS) Document

Table of Contents

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

1.5 Overview

2. Overall Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Classes and Characteristics

2.4 Operating Environment

2.5 Design and Implementation Constraints

3. Specific Requirements

3.1 Functional Requirements

3.2 Non-Functional Requirements

3.3 Interface Requirements

4. Use Cases

4.1 Use Case Diagram

4.2 Use Case Descriptions

5. Acceptance Criteria

6. Appendix

6.1 Glossary

6.2 Document History

Use Case Models for KUTRRH(Kenyatta University Teaching Research and Referral Hospital) UML

1. Identify Actors:

2. Identify Use Cases:

3. Draw the Use Case Diagram:

Example Structure:

Sample Diagram (Textual Representation):

4. Describe Interactions:

Conclusion:

Task for Thursday