Transitioning from Analysis to Design


The step between specifying requirements to working on a system design can be tricky. Fortunately, the basis on which the step is made can be calculated. Paul Reed thoroughly explains how the transition should progress and offers some instructions on how to move properly through this phase.

One of the bigger challenges facing software projects is determining when and how to begin the transition from specifying requirements to working on a system design. Questions arise during this phase, such as: "I'm on an Agile project-what design artifacts should I produce and when?"; "My project creates use cases; do I detail all the use cases first and then jump into design?"; and "Which requirements should I tackle first in design?"

First Thing's First
To think about design implies the project team has given thought to the requirements and their associated priorities and has generally accepted architectural principles. The first element, requirements and their priorities, is unique to each project. The second, architectural principles, has likely been considered within your organization many times and has been used to implement other software applications into production.

I am continually amazed at how organizations harvest few assets (both software and architectural patterns) from prior projects for the benefit of those yet to come. In my experience, large organizations have a difficult time harvesting existing architectural patterns. Smaller organizations more commonly leverage their software architectures horizontally across projects. The larger organizations that I work with have fragmented the architectures. Projects will find that just a small amount of design modeling early in the project's lifecycle will afford greater identification of patterns, leading to more sound solutions.

To transition from analysis to design, the team needs to understand the project's quality attributes (e.g., security, maintainability, usability, and reliability) as well as design and implementation constraints (e.g., a delivery platform). These nonfunctional requirements (quality attributes and design and implementation constraints) should be elicited in consort with functional requirements (e.g., stories, use cases, and data models). Some teams define these early in their project charter or software requirements specification, if one is used. (Agile projects tend to shun full-blown specification documents where possible.) In any case, these nonfunctional requirements must be defined and are necessary for a safe and sound transition from analysis to design.

Given the delivery platform per design and implementation constraints, quality attributes, and any existing architectural standards; the design staff can-in tandem as requirements are elicited-work on the design. Priorities count, because without the prioritized requirements and prior knowledge of delivery platform, the bare minimum the design team could produce is an analysis-view class diagram, which isn't enough to say the team has a sound design or has thought about any difficult architectural decisions. So, the design team also needs to understand the customer's priorities.

What Maps to What?
In her two-part series on, Ellen Gottesdiener makes the excellent point that the "pressure" your project finds itself under will drive what models the requirements team produces. In my experience as an architect on numerous projects, I've found the same three design models-software architecture schematic, class diagram, and sequence diagram-regardless of what the requirements team delivered.

I'll illustrate in the following sections how the team can utilize these three design tools in the project's lifecycle.

Architecture Schematic
The simplest of the three models, but the one that usually surfaces the greatest amount of debate, is the overall view of the system's proposed architecture. This may include a visual picture of the hardware and perhaps where the various software components and subsystems will reside and run (e.g., database, middleware). It will also show the "layering" approach that should be taken on the project with respect to the software's design. Software layers are typically the user interface, business logic, and data access.

These documents usually get packaged as part of a software architecture document. Regardless of the document or style you follow, enough can't

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.