Automation

From time to time, we compare analysis and documentation activities to software development, and the automation topic makes us do it again. In extreme cases, software could be developed just using Notepad to write the code and a compiler to build the actual application. But nobody does that. Instead, developers have an arsenal of tools such as Integrated Development Environments, debuggers, profilers, screen designers, etc. These tools help them automate repetitive tasks such as organizing the code or perform regular quality checks.

It is interesting to see that a lot of analysts still use "Notepad and compiler" and carry out common tasks manually. For example, they capture requirements in Excel, copy them to Word, attach some models from Visio, and exchange the final document with others via email. Not only is this approach inconvenient, it is also error-prone and extremely ineffective. Analysts should get inspired by developers who try to save as much time as possible by automation. It does need to be a critical point in small companies, but when it comes to enterprises operating dozens of systems, the time such load of information could be managed "manually" is drawing to an end. Companies should start using tools that help them automate creating, managing, and quality-checking their analysis and documentation outputs.

What we typically see analysis teams doing manually and what where we see a potential for automation is summarized in the following list:

1. Generate specifications stubs
   • Creating 20 use case specifications manually from scratch is boring. It is more convenient to let a tool automatically create stubs so that the analyst then only creates the content, which is important.
2. Update models
   • Every time a model is changed, it must be updated in all documents. This is frustrating and error-prone as there is always an occurrence that was not updated. Effective analysts do not waste updating models, and their models are always up to date.
3. Detect changes and regenerate specifications
   • Big part of analysis outputs are free text which cannot be processed automatically, however, most specifications contain "data" which could be automatically generated. For example, a list of use cases specifying a new system should be regenerated automatically when a new use case is introduced.
4. Check conformity with rules and conventions
   • People will inevitably make mistakes but there should be a safety net to discover and correct them. For example, if there is a convention to call all use cases "UC Name" there should be an automated way to discover violations to this rule.

The above points are illustrated by the following schema. It shows that the specification page is created automatically for the CRM system. Also, a component model is included, and the list of CRM modules is automatically updated when it changes.

Example

Such automation streamlines repetitive steps, ensures the specification is correct, up to date, and conforms to the set rules and conventions. In Part III, a concrete example, a reference implementation, is introduced, presenting how this automation could be achieved with concrete tools.