Prompt:
The architecture diagram is first and foremost, a picture... an image, a diagram, that gives us a common very high-level view of the system.
If the architecture of your system has a "name" in software development practice, use it. Is it a client-server system (like most websites)? Is it event-driven? Is it real-time? Is it a standalone program that runs on a single computer to serve a single user at a time?
The diagram should show the major components of the system... the main collections of software that logically serve one purpose. It should show how those components relate to each other... how data flows into, and out of each component. It shows where that data comes from (and goes to). It shows not only software collections as components, but also data repos, and special hardware or other non-software items the system interacts with.
Does your system interact with pre-existing software, data, or hardware? Show those... indicate that they are in existence (and not your work) but that your work must adapt to it. Use color or labels or surrounding blobs to clearly show your work vs. items you inherit and adapt to.
Does your system use the Internet (or other communications frameworks to share data and messages among the components)? Then show it. Indicate is some way where information flow among components is over such connections (as opposed to internal on one computer). These connections are orders of magnitude slower than internal communications and so do have an impact on system design decisions.
Does your system use multiple computers? Show that. For example, client-server systems clearly have two (at least) main loci of computation (and an internet connection between).
Make it clear where your users live. Make clear the boundary between your system and "out there".. the outside world from which controlling signals come (user commands) and/or input data and results.
Acceptance Criteria:
Includes all the pieces of software we are going to use (user, Angular, NativeScript, Firebase, Receipt Parser API, etc.)
Prompt: The architecture diagram is first and foremost, a picture... an image, a diagram, that gives us a common very high-level view of the system.
If the architecture of your system has a "name" in software development practice, use it. Is it a client-server system (like most websites)? Is it event-driven? Is it real-time? Is it a standalone program that runs on a single computer to serve a single user at a time?
The diagram should show the major components of the system... the main collections of software that logically serve one purpose. It should show how those components relate to each other... how data flows into, and out of each component. It shows where that data comes from (and goes to). It shows not only software collections as components, but also data repos, and special hardware or other non-software items the system interacts with.
Does your system interact with pre-existing software, data, or hardware? Show those... indicate that they are in existence (and not your work) but that your work must adapt to it. Use color or labels or surrounding blobs to clearly show your work vs. items you inherit and adapt to.
Does your system use the Internet (or other communications frameworks to share data and messages among the components)? Then show it. Indicate is some way where information flow among components is over such connections (as opposed to internal on one computer). These connections are orders of magnitude slower than internal communications and so do have an impact on system design decisions.
Does your system use multiple computers? Show that. For example, client-server systems clearly have two (at least) main loci of computation (and an internet connection between).
Make it clear where your users live. Make clear the boundary between your system and "out there".. the outside world from which controlling signals come (user commands) and/or input data and results.
Acceptance Criteria:
Helpful Links: Team Site Link Examples