The 'GizmoService' is single threaded since it has to process the 'GadgetJobs' in sequence and order must be maintained.Ī description of the physical environments available (should be correlated with environments in the development view) and what they contain.ĭeployed to AWS EC2 instance, with ELB and CloudFront. Wiki for documentation, JIRA for issue tracking.Ī detailing of the execution model of the solution such as threading etc. We also call out to the CRM system when doing.
deployment process (build chain, ci/cd etc.)Ĭlassic three tier architecture, MVC pattern in framework X. development environment (tools, repository etc.) Processes: make a claim, close a claim, refute a claimĪ walkthrough of the functional view and the use case view with one or two typical use cases and also the more complex use cases that need to be explained in more detail.Īs a customer I can create a claim, list my claims, show claim etc.Įverything one needs to know to develop the thing: This includes the various business entities and the processes involved. Walkthrough of the conceptual model that is used in the solution. Our customers must be able to make 'claims' when they receive a defective gizmo from us. I've based it on architectural views as defined by Kruchten and others (C4 or some other scheme will work just as well).Īn overview of the major business cases that motivate the existence of the solution. All points are optional and users should strive for good enough.
At these times it can be good to have a checklist to go through. Every now and again you need to hand something over (code, thingamabobs, whatnot) to someone.
0 kommentar(er)
