Balancing Act

Reduce project development time by effectively capturing and managing requirements

For the past 15 years or so, business software has continued to develop - and not much has changed. Clients still expect you to provide firm estimates of overall project costs before performing a rigorous analysis of requirements. Design tools tend to be bulky and arcane and leave much of the real work to developers. Development tools are still slow and immature and fail to expose the full power of underlying language engines. With a Web browser as the standard presentation manager, you are severely challenged to create user interfaces that provide effective support and feedback to users of moderately complex applications.

Among the most significant changes in software development are an emphasis on short delivery cycles and the expectation of extremely large user populations brought about by near universal access over the Web. These considerations are especially critical when developing software that will be delivered as a service through an application service provider (ASP). In particular, the scalability requirement has driven an increase in the complexity of the architectural foundation on which we are building applications that have relatively straightforward functionality. As I will argue below, effectively capturing and managing requirements is the key to reducing cycle times. The right approach to software architecture maps software components back to the requirements and reduces testing to an integration problem. Designing an architecture that cleanly partitions component functions and leverages standard models enables scalability and facilitates sharing processes and information.

While traditional enterprise software vendors are relatively familiar with this territory, heading in the ASP direction is a significant challenge for smaller application software vendors that serve the middle market. In the past, these smaller companies had products that could exist as islands and did not have to support extensive user populations. It was relatively easy to serve 5,000 businesses that had an average of 250 employees when you could require each of them to install a separate local instance of a client/ server product. As a service provider, that vendor is looking at a million-user system!

Team Dynamics

Taken together, these changes have made an impact on the composition of project teams, the ways in which team members have to interact, and the structure of the projects on which they are collaborating. To produce Web-based software of even moderate complexity requires a broad array of experts. Recruiting people with experience in larger corporate and consulting organizations has become extremely important to developers of ASP services. Today's effective project team needs at least the following members:

• Individuals with strong database design and administration skills (not necessarily the same person)
• Somebody who can select an appropriate technology platform
• A requirements team that can build a concise but comprehensive catalog of use cases that need to be supported
• A usability expert who can build information models that expose the product's functionality in a meaningful way to diverse user populations
• Developers who can write database-stored procedures, middle-tier business objects, and presentation code that includes or resolves to HTML
• An infrastructure expert who knows how to distribute all of these components in a manner that will maximize performance, scalability, and reliability.

It is no longer possible for one or two high performance individuals to build a product themselves. In fact, the market for those of us who made a living as knowledgeable generalists has tightened considerably!

Project Planning In Internet Time

When an organization launches a software project, the first thing it wants is a schedule. The first thing that your project team wants is a clear set of requirements - for team members, starting a project by working on a project plan is extremely frustrating. If you don't know what you are supposed to build, it is difficult to formulate a plan to build it. Conversely, management wants to know what the project is going to cost and see a plan that shows it will be delivered on time, regardless of what it is! Emphasizing the time constraint heightens this tension, because without analysis nobody really knows if it's possible to produce a meaningful set of functionality within the desired time frame.

In the "old" days, I was often able to structure engagements to include an analysis project and a subsequent development project. I could estimate the analysis project based on number of users and a rough count of function points and estimate the development project based on the results of the analysis. That approach no longer flies.

Just-in-Time Analysis

With the possibility of an infinite number of users, it's impossible to interview a representative sample. Nor can you build a product in four months if you perform an exhaustive requirements analysis before starting any development. Instead, my company, EC Wise Inc., has created a process in which we perform requirements analysis on a just-in-time basis, and have adopted an iterative project-planning model to manage this process.

Take a look at a summary view of our project model displayed in Figure 1. One of the significant departures from traditional project models is the extension of requirements analysis throughout the first half of the project cycle. In conjunction with analyzing requirements, we find it important to produce prototypes to serve as straw men for feature sets and provide a realistic simulation target for evaluating alternative deployment platforms. A second departure is the division of development work into between five and eight work packages, each scoped to run for about four weeks from design through unit test. Once we complete the Core Transactions work package scheduled for week 13, we have a product with sufficient functionality to support release to initial clients after another week or so of testing.