Today’s short blog, the first for 2024, derives from recent work in which I required a classic Table of Contents (TOC) for a Solution Design( SD ) Document/ Artefact. To create this TOC, I began by listing elements one would expect to see in the artefact i.e. primary section headers, which is challenging when you consider the ‘ purpose’ of the document, and the target audience both of which impact the overall structure of the document. For most artefacts, it would be prudent to tailor the SD to meet the needs and challenges of the specific problem. For example, a basic SD for a new in-house development may be very technical, especially when the target audience may be the Systems Community ( Developers, Testers, Service Management etc.) and resulting in an artefact with the content and focus on Component Views(Building Module Blocks) , Deployment Views and the Runtime Operations . So, when I considered the elements for the SD Artefact I wanted...
The following appeared on my previous blog site on January 6th 2014 and received in excess of 16K hits per annum - so reposting on new site. Earlier today, while reviewing a document I produced some time ago, I discovered a useful Non-Functional Requirements (NFR) checklist and thought I would simplify , ‘repackage’ and share via this blog. NFR checklists are not unique products, they are easily found on the web with numerous examples available for reuse, one such example can be found at the Open Group’s website under the ToGAF Requirements Management section. Most of you are probably familiar with NFR’s – However if not, you can consider them a set of requirements/criteria used during the run-time operation of a system and not the specific behaviours that the system must exert. The NFR’s vary in importance and are usually aligned to the context of the system e.g. Operational Safety could be classed as a NFR, especially when working in hazardous conditions (...
Let me start by apologising, as todays blog can be considered, by some , as content of little value to support macro EA views and a topic where information can be sourced easily via the web or by using AI tools (fast becoming everyday tools). However I felt I would share this reference type material, as error codes are always required for those building information systems. FYI recently I had to examine various http error codes used in a Cloud based API management system in respect of the flows of message exchanges and conduct analysis of non-typical scenarios e.g. a missing authentication token resulting in an invalid exchange between the backend and the API Gateway. Under normal operational conditions, interactions between two or more system will result in the exchange numerous codes which notify each system of task status e.g. a 200 return code will represents that all is well and allows the process continuation of further orchestration of a workflo...
Comments
Post a Comment