Systems Analysis

After the solution was selected, verified, and confirmed with all stakeholders, the next step is preparing specifications for the implementation. So far, the analyst has been working with information that was detailed enough to outline the solution, to define its impacts, or to describe the main features to the potential software vendor, but the amount of information is not sufficient for the complete solution realization. There is no standard format for system analysis as describing different types of system changes requires using different techniques. As a result, a mix of textual descriptions, pictures, tables, models, or even code is typically used according to the target audience and the type of change.

System Specification

Although there still might be solutions that do not include any IT-related components, the current enterprises depend on IT to such an extent that most solutions do include some IT systems modifications. Systems analysis is hence becoming an essential part of most enterprise changes. Whatsmore, as the amount of tasks being processed by software grows, the complexity of enterprise systems grows too. To understand a new IT system, developers need to see the system from multiple views, each view requiring a different description approach. As a result, analysts must be able to describe a wide range of aspects of the system, such as usage scenarios, data structures, user interface, integrations with other systems, and so on. The way this information is presented to developers is highly dependent on the environment in which the analysis is performed. Some companies specify all changes in documents. Others store it in a database and generate the documents from it only if needed. And there are also agile teams that do not document the whole solution but produce only super lightweight documentation for the components which are about to be implemented. Regardless of the approach, there is always a need for some detailed specification of how the functions will be implemented in the actual system, usually called system or functional specification. Since its format varies a lot across the industry, the aim of this chapter is not to provide a template. It rather presents what is typically needed to describe the system from the implementation perspective and how to best structure the information.

System Analysis in Agile

There are several misunderstandings regarding agile and system specifications. Yes, agile teams do not create comprehensive specifications upfront as traditional waterfall projects do, but it is absolutely odd to think that developing software the agile way means only to elicit several user stories, sketch a couple of free-hand diagrams on the whiteboard and start coding. On agile projects, not all tiny details are known at the time the development starts, yet there are still areas which must be clarified before starting coding if the success of the project is important. The agile specification will certainly be more lightweight with more assumptions and gaps that will be ironed just in time, but the core pillars such as the main use cases and a basic overview of the system architecture are better to be clarified upfront to avoid rework and delays. This is why even agilists do preliminary analysis in the following areas:

1. Business requirements: Before starting implementing the system, it is essential to understand why the system is needed, what business goals it is expected to meet, and what is the scope of the system. This is no different from the traditional process, and the information is typically a part of the Business Requirements Document.
2. High-level software requirements: Despite detailed requirements will be elicitated incrementally throughout the whole project, in the beginning the team usually needs to be at least able to answer what is the scope of the solution (sometimes also how long the effort will take and what it will cost, but we all know this is impossible). It is also better to clarify important business questions with stakeholders to ensure the solution is not based on wrong assumptions and that the most critical business risks are covered. For these reasons, it is a good practice to do some initial requirements elicitation before the development starts. The goal of this initial phase is to discover the main capabilities the system must have (for example use cases may be used). The team should also understand the main business entities and the relationships between them (domain model can be drawn for this purpose), and it is usually beneficial to sketch a user interface prototype to help users visualize the solution. The amount of work within this activity really depends on the situation: whether it is a complicated area, if the team has already worked in this business domain or if the team is familiar with the proposed technologies. The output of this activity is often covered by the Solution description, but for smaller solutions, it could be incorporated into the System specification.
3. Architecture outline: Software development is not just about coding system features requested by stakeholders. To estimate the effort, to solve the most critical technical decisions, or to organize the teams, the high-level architecture should be outlined in the beginning to provide a rough idea about the technologies, hardware, security, etc. Again, this could be included in Solution description and elaborated deeper in the System specification, or it could be covered entirely in the System specification.

To sum it up, the system specification, as we present it here, is not tight to any particular software development approach. It does not represent a rigid artifact aiming to provide all information upfront. The information included in it is important irrespective of the approach. What is pliable to the approach is just the amount of detail, in a sense, the more agile process, the less information is included before the development starts.

One Specification per System

Implementing a solution could involve creating or modifying a single system. But it could also consist of multiple implementations, which means that multiple system specifications will be needed to describe the whole solution. As there is usually a dedicated team/vendor operating each system in the organization, it is convenient to create a separate specification for each system. This way, the team or the vendor gets only the information needed for the development of the particular system, yet still have the context provided by the overall solution outline.