Slide 1: Title & Introduction "Good morning, everyone. I am John, and I will be discussing Case Study 5: Comprehensive Requirements Specification. I will be walking you through the software agreement between Company X, a software consultancy, and Company Y, a healthcare provider." Slide 2: Scope and Deliverables "To kick things off, let's look at the exact scope of this project. The contract has an Effective Date of September 18, 2026, with work officially starting on September 25, 2026. The Developer is required to build the system exactly as specified in Annex A, which serves as our ultimate project checklist. There are four primary feature deliverables required for acceptance: Records Storage: A secure digital storage system for patient medical records that meets local privacy laws. Calendar & Reminders: An appointment calendar complete with automated reminders. Billing & Claims: A module for processing billing and insurance claims. RBAC Controls: Role-based security to separate clinician views from front-desk views." Slide 3: In-Scope Constraints & Change Control "Because this project is strictly locked to its requirements, anything not explicitly written in Annex A—such as unspecified mobile apps or extra analytics—is excluded from the scope. If the client wants to add features, they must follow a strict Change Control process: First, the Client must submit a written request for the changes. Next, the Developer has five days to reply with the extra cost and a revised timeline. Finally, no work on these changes will begin until both parties sign a mutual agreement approving them." Slide 4: Milestone Payments "To keep the project on track, the payment schedule is tied directly to these deliverables. An upfront payment of 20% is due on the Effective Date of September 18, 2026. The next 30% is unlocked upon the completion of the database for patient records. Another 30% is paid when the scheduling, billing, and security features are finished. The final 20% is released only after final testing and Client acceptance." Slide 5: Liability, Ownership & Conclusion "Finally, dealing with healthcare data requires strict legal safeguards. The Developer must comply with local privacy laws, like the Data Privacy Act, and is prohibited from viewing or sharing real patient data during setup and testing. Once full payment is made, ownership transfers to the Client, including perpetual rights to any open-source components used. The contract also includes a 90-day warranty offering free fixes for major bugs, while capping overall liability and excluding indirect damages. Ultimately, this discipline of locking delivery strictly to the signed requirements protects patient privacy, budget, and timeline, anchoring accountability across product, legal, and engineering teams.
Slide 1: Title & Introduction "Good morning, everyone. I am John, and I will be discussing Case Study 5: Comprehensive Requirements Specification. I will be walking you through the software agreement between Company X, a software consultancy, and Company Y, a healthcare provider." Slide 2: Scope and Deliverables "To kick things off, let's look at the exact scope of this project. The contract has an Effective Date of September 18, 2026, with work officially starting on September 25, 2026. The Developer is required to build the system exactly as specified in Annex A, which serves as our ultimate project checklist. There are four primary feature deliverables required for acceptance: Records Storage: A secure digital storage system for patient medical records that meets local privacy laws. Calendar & Reminders: An appointment calendar complete with automated reminders. Billing & Claims: A module for processing billing and insurance claims. RBAC Controls: Role-based security to separate clinician views from front-desk views." Slide 3: In-Scope Constraints & Change Control "Because this project is strictly locked to its requirements, anything not explicitly written in Annex A—such as unspecified mobile apps or extra analytics—is excluded from the scope. If the client wants to add features, they must follow a strict Change Control process: First, the Client must submit a written request for the changes. Next, the Developer has five days to reply with the extra cost and a revised timeline. Finally, no work on these changes will begin until both parties sign a mutual agreement approving them." Slide 4: Milestone Payments "To keep the project on track, the payment schedule is tied directly to these deliverables. An upfront payment of 20% is due on the Effective Date of September 18, 2026. The next 30% is unlocked upon the completion of the database for patient records. Another 30% is paid when the scheduling, billing, and security features are finished. The final 20% is released only after final testing and Client acceptance." Slide 5: Liability, Ownership & Conclusion "Finally, dealing with healthcare data requires strict legal safeguards. The Developer must comply with local privacy laws, like the Data Privacy Act, and is prohibited from viewing or sharing real patient data during setup and testing. Once full payment is made, ownership transfers to the Client, including perpetual rights to any open-source components used. The contract also includes a 90-day warranty offering free fixes for major bugs, while capping overall liability and excluding indirect damages. Ultimately, this discipline of locking delivery strictly to the signed requirements protects patient privacy, budget, and timeline, anchoring accountability across product, legal, and engineering teams.
Created using ChatSlide
This project focuses on defining the scope and managing changes for the healthcare case between Company X and Company Y. It includes mapping four key deliverables and implementing a structured change control process. Additionally, it emphasises linking payments to assurance and accountability by tracking milestone payments and safeguarding data and ownership rights, ensuring that signed requirements are in place to protect the delivery outcomes.