diff --git a/docs/src/content/docs/arc42/01. Introduction and Goals.md b/docs/src/content/docs/arc42/01. Introduction and Goals.md index d230e79..c1c0ae2 100644 --- a/docs/src/content/docs/arc42/01. Introduction and Goals.md +++ b/docs/src/content/docs/arc42/01. Introduction and Goals.md @@ -3,7 +3,7 @@ title: Introduction and Goals description: Describes the relevant requirements and the driving forces that software architects and development team must consider. --- -Introduction and Goals + Requirements Overview --------------------- -**Contents.** +1. Implement the original CPU instructions +2. Implement the original memory layout +3. Implement a graphical user interface +4. Implement controls + + Quality Goals ------------- -**Contents.** +1. The instructions should not deviate from the original + + Stakeholders ------------ - + -| Role/Name | Contact | Expectations | -| ----------- | ------------------------- | ------------------------- | -| Role-1 | Contact-1 | *<Expectation-1*> | -| Role-2 | Contact-2 | *<Expectation-2*> | +| Role/Name | Expectations | +| ----------- | ------------------------- | +| Silke & Korf| Working end result, understandable architecture | diff --git a/docs/src/content/docs/arc42/02. Architecture Constraints.md b/docs/src/content/docs/arc42/02. Architecture Constraints.md index 1b80ff2..40fad08 100644 --- a/docs/src/content/docs/arc42/02. Architecture Constraints.md +++ b/docs/src/content/docs/arc42/02. Architecture Constraints.md @@ -3,7 +3,7 @@ title: Architecture Constraints description: Describes the constraints that software architects must consider. --- -Architecture Constraints + + +| Constraint | Description | +|------------|-------------| +| Deadline | The project must be completed by the end of the semester. | +| Budget | All developers have other classes to attend, this can't take too much of their time away | +| Programming Language | The project must be implemented in Rust. | +| Documentation | The project must be documented well. | +| Testing | The project must be tested well. | +| Every developers must have a good understanding of the project | The project must be implemented in a way that every developer can understand it for the final exam. | diff --git a/docs/src/content/docs/arc42/03. Context and scope.md b/docs/src/content/docs/arc42/03. Context and scope.md index edb478b..c66ded3 100644 --- a/docs/src/content/docs/arc42/03. Context and scope.md +++ b/docs/src/content/docs/arc42/03. Context and scope.md @@ -3,7 +3,7 @@ title: System Scope and Context description: Delimits your system from all its communication partners (neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces. --- -System Scope and Context + Business Context ---------------- + Technical Context ----------------- - + diff --git a/docs/src/content/docs/arc42/04. Solution Strategy.md b/docs/src/content/docs/arc42/04. Solution Strategy.md index 470b658..06b5181 100644 --- a/docs/src/content/docs/arc42/04. Solution Strategy.md +++ b/docs/src/content/docs/arc42/04. Solution Strategy.md @@ -3,7 +3,7 @@ title: Solution Strategy description: A short summary and explanation of the fundamental decisions and solution strategies, that shape the system’s architecture. --- -Solution Strategy + + +## Decisions + +### Bevy as the UI Engine + +We decided to use Bevy as the UI engine for the game. Bevy is a game engine built in Rust that is designed to be fast and easy to use. It is a new engine that is still in development, but it should serve our more simple needs well. diff --git a/docs/src/content/docs/arc42/05. Building Block View.md b/docs/src/content/docs/arc42/05. Building Block View.md index 4d2c664..d339c16 100644 --- a/docs/src/content/docs/arc42/05. Building Block View.md +++ b/docs/src/content/docs/arc42/05. Building Block View.md @@ -3,7 +3,7 @@ title: Building Block View description: Shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, datas structures, …) as well as their dependencies (relationships, associations, …) --- -Building Block View + Whitebox Overall System ----------------------- - + Level 2 ------- - + Level 3 ------- + diff --git a/docs/src/content/docs/arc42/06. Runtime View.md b/docs/src/content/docs/arc42/06. Runtime View.md index 52d0ee0..f3d8e47 100644 --- a/docs/src/content/docs/arc42/06. Runtime View.md +++ b/docs/src/content/docs/arc42/06. Runtime View.md @@ -3,7 +3,7 @@ title: Runtime View description: Describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas; important use cases or features, interactions at critical external interfaces, operation and administration, error and exception scenarios. --- -Runtime View + diff --git a/docs/src/content/docs/arc42/07. Deployment View.md b/docs/src/content/docs/arc42/07. Deployment View.md index 21508e6..0aaf654 100644 --- a/docs/src/content/docs/arc42/07. Deployment View.md +++ b/docs/src/content/docs/arc42/07. Deployment View.md @@ -3,7 +3,7 @@ title: Deployment View description: Describes the technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and the mapping of (software) building blocks to that infrastructure elements. --- -Deployment View + Infrastructure Level 1 ---------------------- + Infrastructure Level 2 ---------------------- + diff --git a/docs/src/content/docs/arc42/08. Crosscutting Concepts.md b/docs/src/content/docs/arc42/08. Crosscutting Concepts.md index 8b18352..3c5f33a 100644 --- a/docs/src/content/docs/arc42/08. Crosscutting Concepts.md +++ b/docs/src/content/docs/arc42/08. Crosscutting Concepts.md @@ -6,6 +6,7 @@ description: Describes the overall, principal regulations and solution ideas tha Cross-cutting Concepts ====================== + diff --git a/docs/src/content/docs/arc42/09. Architecture Decisions.md b/docs/src/content/docs/arc42/09. Architecture Decisions.md index 1e17f67..739e18c 100644 --- a/docs/src/content/docs/arc42/09. Architecture Decisions.md +++ b/docs/src/content/docs/arc42/09. Architecture Decisions.md @@ -3,6 +3,7 @@ title: Architecture Decisions description: Describes the important, expensive, large scale or risky architecture decisions including rationals. --- + + +Is this needed? \ No newline at end of file diff --git a/docs/src/content/docs/arc42/10. Quality Requirements.md b/docs/src/content/docs/arc42/10. Quality Requirements.md deleted file mode 100644 index 1f01151..0000000 --- a/docs/src/content/docs/arc42/10. Quality Requirements.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Quality Requirements -description: Describes the quality requirements and quality tree with scenarios that software architects and development team must consider. ---- - -Quality Requirements -==================== - -**Content.** - -This section contains all quality requirements as quality tree with -scenarios. The most important ones have already been described in -section 1.2. (quality goals) - -Here you can also capture quality requirements with lesser priority, -which will not create high risks when they are not fully achieved. - -**Motivation.** - -Since quality requirements will have a lot of influence on architectural -decisions you should know for every stakeholder what is really important -to them, concrete and measurable. - -Quality Tree ------------- - -**Content.** - -The quality tree (as defined in ATAM – Architecture Tradeoff Analysis -Method) with quality/evaluation scenarios as leafs. - -**Motivation.** - -The tree structure with priorities provides an overview for a sometimes -large number of quality requirements. - -**Form.** - -The quality tree is a high-level overview of the quality goals and -requirements: - -- tree-like refinement of the term "quality". Use "quality" or - "usefulness" as a root - -- a mind map with quality categories as main branches - -In any case the tree should include links to the scenarios of the -following section. - -Quality Scenarios ------------------ - -**Contents.** - -Concretization of (sometimes vague or implicit) quality requirements -using (quality) scenarios. - -These scenarios describe what should happen when a stimulus arrives at -the system. - -For architects, two kinds of scenarios are important: - -- Usage scenarios (also called application scenarios or use case - scenarios) describe the system’s runtime reaction to a certain - stimulus. This also includes scenarios that describe the system’s - efficiency or performance. Example: The system reacts to a user’s - request within one second. - -- Change scenarios describe a modification of the system or of its - immediate environment. Example: Additional functionality is - implemented or requirements for a quality attribute change. - -**Motivation.** - -Scenarios make quality requirements concrete and allow to more easily -measure or decide whether they are fulfilled. - -Especially when you want to assess your architecture using methods like -ATAM you need to describe your quality goals (from section 1.2) more -precisely down to a level of scenarios that can be discussed and -evaluated. - -**Form.** - -Tabular or free form text. diff --git a/docs/src/content/docs/arc42/11. Risks and Technical Debt.md b/docs/src/content/docs/arc42/11. Risks and Technical Debt.md index 65f4aed..1d43145 100644 --- a/docs/src/content/docs/arc42/11. Risks and Technical Debt.md +++ b/docs/src/content/docs/arc42/11. Risks and Technical Debt.md @@ -3,7 +3,7 @@ title: Risks and Technical Debt description: A list of identified technical risks or technical debts, ordered by priority --- -Risks and Technical Debts + + +## Risks + +| Risk | Description | Mitigation | Likelihood | +|------|-------------|------------|------------| +| Team member leaves | A key team member leaves the project | Knowledge transfer | Low | +| Technology risk | The selected technology is not mature enough | Proof of concept | Medium | +| Not fulfilling quality goals | The architecture does not fulfill the quality goals | Regular reviews | High | +| Deadline risk | The project deadline is not met | Regular monitoring | Medium | +| Unequal distribution of knowledge | Knowledge is not shared equally among team members | Pair programming | Low | +| Crunch | The project is not completed in time | Regular monitoring | High | + +## Technical Debts + +None so far. \ No newline at end of file