Week 8 Status Update

This week, we contacted our project stakeholder to review our SRS and use cases. We collected his feedback on these artifacts, discussed it as a group and updated our SRS and use cases to reflect his input. We also identified a lack of requirements to address the business needs of faster information turnaround and customer-facing services and discussed this with our stakeholder to come up with some new requirements for our application which would meet these needs. We then added these new requirements to our SRS.
Additionally, we wrote a postmortem analysis of the first stage of the project and discussed our project's feasibility for the next stage. We decided that our project was architecturally complex enough to be a good candidate for the next stage and decided to keep using it for the architecture phase of this class. We discussed and listed the architecturally significant requirements of our project.
Next week, we will begin work on our architecture. At this time, we have not studied the architecture process enough to know exactly how to begin, but we hope to learn more in next week's classes. We will probably begin by making more detailed class and sequence diagrams.

Week 7 Status Update

This week, we have been working to complete the final draft of our Software Requirements Specification document, This has involved finalizing our requirements and quality attributes, writing and modelling use cases and determining any remaining uncertainties. Our SRS is currently about 90% complete, as there are only a few uncertainties remaining and we have completed all sections of our SRS template. However, we have not yet had our SRS reviewed by the project stakeholders, which needs to occur before we submit it.

Project Plan:

10/1: finish first draft of SRS

10/11: finish final draft of SRS

Defects List:

• Are the customer satisfaction surveys associated with the patient who completed them or are they anonymous?

• What protocols shall our application use to communicate with the back-end servers? Is there an API it should use?
• Our requirements list could be higher level and less detailed, but then they would match our vision and scope document.

Risks:

1. We still do not know the structure and design of the remote server’s api.
2. We do not know whether the customer satisfaction survey is considered “sensitive” information or not.
3. Our SRS document has not been reviewed yet.
4. We will not have time for an in person review, so our feedback may not be as robust as it could be.
5. The due date for the Final SRS document is approaching and our sponsor, Brian, may not get back to us before we have to submit.

Week 6 Status Update

We were held up by exams and career fair and got very little work done. Now that they are over we will resume our use case document and refining our SRS document.

Next Steps:

• We will continue writing our use case document
• We will continue refining our SRS document into its final version

Week 5 Status Update

We wrote the Draft of our SRS document. All sections of the template were filled out. The document has been submitted.

Next Steps:

• We will write our use case document
• We will refine our SRS document into its final version