added recommended links

added few more diagrams

Author: wer32dr

README.md

@@ -4,9 +4,22 @@ This document contains Solution Architecture Process and Solution Architecture D
 Basically the SA working process consist of the main phases:
 - [Requirement gathering](requirements.md)
   - [Stakeholders](./requirements.md#stakeholder-list-creating)
-  - [Stakeholders](./requirements.md#stakeholder-list-creating)
+  - [Functional requirements](./requirements.md#functional-requirements)
+  - [Non Functional requirements](./requirements.md#non-functional-requirements)
+  - [Constraints](./requirements.md#constraints)
+  - [Assumptions](./requirements.md#assumptions)
 - [Solution Architecture Design](solution-architecture-design.md)
+  - [Quality Attributes](./solution-architecture-design.md#solution-architecture-quality-attributes)
+  - [Architecture Significant Requirements](./solution-architecture-design.md#architecture-significant-requirements)
+  - [Current Architecture](./solution-architecture-design.md#current-architecture)
 - Time estimation and WBS
 - PoC creating
 - Development
 - Migration
+
+##### Recommended links/books
+
+- [The 4 + 1 View Model of Software Architecture by Philippe Kruhten](https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf)
+- Rational Unified Process
+- [Software Engineering Institute](https://www.amazon.com/Documenting-Software-Architectures-Views-Beyond/dp/0321552687/ref=sr_1_2?crid=3QJBR916FNGJU&dchild=1&keywords=documenting+software+architectures+views+and+beyond&qid=1601614456&sprefix=documenting+softwa%2Caps%2C174&sr=8-2)
+- [C4 model by Simon Brown](https://leanpub.com/software-architecture-for-developers/read#c4)

images/combined-style-diagram.png

@@ -1,6 +1,6 @@
 There is no good or bad solution architecture in general. Architecture can just more or less fit for the purpose it was designed for. And if the particular architecture fits a customer needs so we can say that this solution architecture is good. So the bottom line is - you can evaluate solution architecture only in the context of particular declared goals.
 
-# Solution Architecture Quality
+# Solution Architecture Quality Attributes
 The goal is to convert all Functional Requirements (FR), NFR, Constraints, Assumptions to Quality Attributes. More importantly, you should define measurable metrics for those quality attributes.
 
 A quality attribute is a measurable or testable property of the system that is used to indicate how well the system satisfies the needs of its stakeholders.
@@ -45,7 +45,7 @@ Metrics:
 - Miss rate
 - etc.
 
-# Architecture Significant Requirements (ASR)
+# Architecture Significant Requirements
 This kind of requirement has a profound effect on architecture. ASR can be collected from FR, NFR, Interviewing Stakeholders, by understanding Business Goals, by conduction Quality Attribute workshops. Based on this document you should create a Utility Tree with ASRs.
 ![Image of UtilityTree](images/UtilityTree.jpg)
 [Utility Tree gathering process in details](https://arnon.me/2010/05/utility-trees-hatching-quality-attributes)
@@ -58,7 +58,13 @@ This part must be implemented after you have all requirements and you have alrea
 - Solution cross-cutting concerns
 
 #### High-level solution structure
-SEI has the recommendation to document it with one or multiple the next views: Module style, Component-and-connector style, Allocation style, Combined-style, and any other notations
+High-level solution structure - SEI has the recommendation to document it with one or multiple the next views: Module style, Component-and-connector style, Allocation style, Combined-style, and any other notations. 
+This is a high-level map of the solution. The layers can be used for introduction tiers.
+All solution components must be shown: services, applications by nature, data storages, buses, caches and etc.
+
+In a diagram can be described the next:
+- solution components
+- 
 
 ###### module style diagram [source](https://www.researchgate.net/figure/Module-Diagram-of-the-System_fig2_331662435)
 
@@ -72,6 +78,10 @@ SEI has the recommendation to document it with one or multiple the next views: M
 
 ![Image of UtilityTree](images/Example-Function-Allocation-FA-Diagram.png)
 
+###### Combined style diagram [source](https://www.researchgate.net/figure/ALEF-components-overview-three-tiers-architecture-data-application-and-presentation_fig5_283412581)
+ 
+![Image of CombinedStyle](images/combined-style-diagram.png)
+
 #### Structure of the solution components and their technology stacks
 Can be represented as a table under a component diagram with the list of components and technology stack used for those components
 
@@ -133,6 +143,6 @@ For simplicity, you can create a table with a list of stakeholders and diagram v
 |Product owner                  |Decompositions View |N/A                       | Deployment View      |
 |Maintenance engineer           |Decompositions View |N/A                       | Deployment View      |
 |End User                       |Shows users list    |N/A                       | N/A                  |
-|Developer                      |Decompositions View |N/A                       | Deployment View      |
+|Developer                      |Class View          |Component View            | Deployment View      |
 |QA                             |Decompositions View |N/A                       | Deployment View      |
 |PM                             |N/A                 |N/A                       | Work assignment view |