Systems Analysis

Once a solution has been selected, verified, and confirmed with all stakeholders, the next step is preparing specifications for implementation. Up to this point, the analyst has worked with information detailed enough to outline the solution, define its impacts, or describe main features to a potential software vendor—but this level of information is not sufficient for full implementation. There is no standard format for system analysis, as describing different types of system changes requires different techniques. Consequently, a mix of text descriptions, images, tables, models, or even code snippets is typically used depending on the target audience and the type of change.

System Specification

While some solutions may not include IT components, modern enterprises depend on IT to such an extent that most solutions require modifying IT systems. Systems analysis is therefore becoming an essential part of most enterprise changes. Moreover, as the number of tasks handled by software grows, the complexity of enterprise systems increases as well. To understand a new IT system, developers need to see it from multiple perspectives, each requiring a different descriptive approach. As a result, analysts must be able to describe a wide range of system aspects, such as usage scenarios, data structures, user interfaces, and integrations.

How this information is presented to developers depends heavily on the development environment. Some companies specify all changes in documents. Others store information in a database and generate documents only when needed. There are also agile teams that do not document the entire solution upfront, producing only lightweight documentation for the components about to be built. Regardless of the approach, there is always a need for a detailed specification of how functions will work in the actual system, usually called a system specification or functional specification. Because its format varies widely across the industry, the goal of this chapter is not to provide a rigid template. Instead, it presents what is typically needed to describe a system from an implementation perspective and how best to structure that information.

System Analysis in Agile

There are several misunderstandings regarding agile methodologies and system specifications. While agile teams do not create exhaustive specifications upfront like traditional waterfall projects do, it is a misconception to think that agile development means simply gathering a few user stories, sketching whiteboard diagrams, and jumping straight into coding. On agile projects, not every tiny detail is known when development begins, yet core areas must still be clarified to ensure project success. An agile specification will certainly be more lightweight, leaving room for assumptions and gaps to be ironed out just in time, but core pillars—such as main use cases and a basic architecture overview—should be clarified upfront to avoid rework and delays. This is why agilists still perform preliminary analysis in the following areas:

1. Business requirements: Before building a system, it is essential to understand why it is needed, what business goals it must meet, and what its overall scope is. This is no different from traditional processes, and this information typically resides in the Business Requirements Document.
2. High-level software requirements: Even though detailed requirements are elicited incrementally throughout the project, the team initially needs to know the scope of the solution (and sometimes timelines and costs, though we know this can be incredibly difficult to lock down). It is also best to clarify critical business questions with stakeholders early on to ensure the solution is not built on wrong assumptions. For these reasons, conducting initial requirements elicitation before development starts is a good practice. The goal of this phase is to discover the main capabilities the system must have (for example, using use cases). The team should also understand core business entities and their relationships (domain models work well here), and sketching a user interface prototype often helps users visualize the solution. The volume of work required depends on the complexity of the area, the team's familiarity with the business domain, and the technologies used. The output is often covered by the Solution Description, though for smaller solutions, it can be integrated directly into the System Specification.
3. Architecture outline: Software development is more than just coding features requested by stakeholders. To estimate effort, resolve critical technical decisions, or organize teams, a high-level architecture should be outlined early on to provide a rough idea of technologies, hardware, and security. Again, this can be included in the Solution Description and detailed further in the System Specification, or covered entirely within the System Specification itself.

To sum up, the system specification as presented here is not tied to any single software development approach. It does not represent a rigid artifact intended to lock down all information upfront. The information it contains is important regardless of the methodology. The only thing that changes with the approach is the level of detail: a more agile process simply means less information is documented before development starts.

One Specification per System

Implementing a solution might involve creating or modifying a single system, or it could require multiple implementations across different systems, meaning multiple system specifications will be needed. Since a dedicated team or vendor usually operates each individual system within an organization, it is practical to create a separate specification for each one. This way, a team or vendor receives only the information required to develop their specific system while still retaining the context provided by the overall solution outline.