Conventions, Rules

Analysis is a very creative, sometimes nearly detective activity, which is more of an art than a science. Since each analysis is different, nobody could predict what outputs the particular analysis will produce, and it cannot be easily standardized. This is different from the software development, where the only output is code, for which formal rules conventions could be created prescribing how the code should look like and how it should be processed. Analysis produces anything from plain text to pseudo-code, so it is harder to set strict rules defining the outputs. But it is definitely not impossible…

Standardized Outputs

Standardized Outputs If we look at today's information systems, it is evident their complexity increases. What is more, a typical organization uses more systems than in the past, which together requires analysts to be able to quickly get more information from more systems. This is a tough job when the systems are not documented consistently, and the quality of documentation differs. No matter if the documentation describes what should be built (specification for development) or what has already been built (post-release documentation), the goal is to present the information in a unified form to make it easily manageable, maintainable, and searchable.

The amount of information describing the business domain and IT ecosystem of an average organization has become so big that it is no longer possible to manage it as we used to do it in the past. The information must be logically structured, must have formal rules, and must be automatically checked and updated. Software development teams realized this a long time ago and came up with rules, techniques, and tools that help them manage large codebase so that their work is efficient, even when the systems are complex. Analysts deal with the same amount of information, yet we rarely see them follow any rules, which makes reading the documentation very hard. The outputs should follow a similar structure, store similar types of information in standard places, and should preferably use unified artifacts to describe the common parts of the systems and applications. This all makes navigating through the documentation easier, which improves productivity and lowers frustration. Generally, the goal is to standardize analysis and post-release documentation outputs as much as possible.

Conventions

What analysts could also take a leaf from software development teams, is using conventions. Conventions are rules that enforce standardization. For example, the naming conventions create a set of rules defining how various entities should be named. If the documented parts of the system or domain are named according to a standardized pattern, the documentation is more consistent, and it is also easier to find the required information. If a one use case is labeled "Customer searches meals - use case" and another is called "Show meal list", it is not very convenient, puzzles readers, and makes searching hard. Naming should be consistent, following general patterns. Here are a few examples of labeling use cases and screens: "UC Search Meals", "UC Add Contact", "SCR Show Meal List", "SCR Update Client".
Another example is modeling conventions. Modeling conventions describe how specific models should look so that models are as unified as possible. This supports collective ownership of the models and makes the maintenance of them easier. Some modeling conventions also make the models easier to read, for example, the rule to avoid crossing lines.