K V Durga Prasad

5 habits that will make you healthier than 98% of your peers:

How do you begin to describe a System Architecture? By the domain obviously. In form of an overview of the requirements. Provide a concise overview of functional requirements, driving forces, and a brief extract or abstract of requirements. Include links to existing requirements documents with information on their location. The system is developed or modified with the goal of enhancing support for business activities and/or improving overall quality, considering the perspective of end users. Short textual description, probably in tabular use-case format. If requirements documents exist this overview should refer to these documents. Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents. A possible second step is to define some quality goals valid for the general architecture. Specify the top three (up to five) paramount quality objectives for the architecture. It's essential to differentiate these from project goals, as they may not be entirely synonymous. The emphasis is specifically on articulating quality goals for the architecture itself. From the arc42 documentation. The ISO 25010 standard provides a nice overview of potential topics of interest: Familiarize yourself with the quality objectives of your key stakeholders, as they will shape crucial architectural decisions. Ensure a high level of specificity regarding these qualities and avoid using vague or trendy terminology. As a final part of your introduction it is worth to mention the principal stakeholders. It is a good way to know which person is in which position and who can decide what. I will do a series of posts about documenting system architecture effectively. Bookmark and like this post if you found it useful. Follow me, If you are interested in more Software system architecture topic.