Architecture Review 1: Team 13 Feedback

Questions and Expected Answers

Question	Expected Answer	Criticality	Team 13 Response
Are all the stakeholders covered?	Yes/No	For determining if the progress on the software architecture document is progressing correctly and/or if it needs refinement.	Yes
Is every stakeholder and every concern covered by at least one viewpoint?	Yes/No	To ensure concerns are adequately addressed.	Yes, but remove views specific to users of the application (patient, ED, nurse, chemist, admin, and clinic).
Is there a view for each viewpoint?	Yes/No	To confirm the completeness of the architecture views.	Views are hardware integrated; more views are needed to show implementation.
Is the set of viewpoints both complete and minimal?	Yes/No	To ensure the architecture is comprehensive yet not overly complex.	AWS Database is repeated. Add mapping for new views.
Is the set of stakeholders and concerns complete?	Yes/No	To confirm all relevant stakeholders and concerns are included.	Yes, this is done.

---

Architecture Review 2: Team 2 Feedback

Supporting Development

Question	Expected Answer	Criticality	Response
Can you identify the full set of implementation units (elements to be implemented)?	Yes/No	To ensure that all required units are identified and ready for development.	Yes, the elements to be implemented are clear from the diagrams, and all additionally needed context is provided through additional details labeling diagrams in all three views.
Can you determine which units require development (and integration and test) resources?	Yes/No	To determine which units need development resources and which testing is required.	Without inspecting current code, I cannot tell exactly which units currently require development. However, each unit should have at least unit tests, and there should be some overall integration testing. The primary focuses for integration testing should be log-in functionality, test user flows on the live website, and the API module. The primary focus for unit testing should be around the API and within each individual module.
For each unit requiring development, can you make predictions in terms of the use of development resources, variance, and risk?	Yes/No	To identify resource requirements and potential risks associated with each unit.	N/A
Can you determine development dependencies between implementation units?	Yes/No	To identify dependencies between units and ensure integration strategy is clear.	Mostly answered in (2) & (5), yes, the dependencies are very clear.
Can you identify runtime dependencies between units?	Yes/No	To ensure runtime dependencies are clear, especially for integration and runtime performance.	All units will depend on internal APIs, external APIs, and especially the database.
Can you lay out a schedule for this development?	Yes/No	To have a clear understanding of the timeline for development.	N/A
Can you lay out a schedule for an architectural prototype?	Yes/No	To have a timeline for the architectural prototype's development.	N/A

---

Identifying Architecturally Significant Requirements

Question	Expected Answer	Criticality	Response
Are specific architecturally significant requirements (i.e., the sub-set of functional, quality attribute, and business requirements that “shape” the architecture under consideration) identified?	Yes/No	To ensure key requirements that shape the architecture are addressed.	N/A
Are there remaining requirements that could come up later and have a significant impact on the architecture? (e.g., names of classes or actors)	Yes/No	To identify any potential requirements that might affect future architectural decisions.	Interaction between different healthcare professionals is not particularly fleshed out, and could have issues or conflicts down the line if not planned for.
Is there a mapping between decisions and requirements?	Yes/No	To ensure that decisions are aligned with the requirements.	N/A