Analyzing Requirements and Estimating Project Length
Being commissioned for the development of a large software system caused me to reflect on the sources of past software production faults. Three elementary sources of problems were minimal or unacceptable project visibility, compressed schedule, and incomplete requirements analysis and design. These elementary problems resulted in secondary problems such as faulty software implementation, seemingly endless rework and refactoring, late delivery, lack of team coordination, demotivation or demoralization of development teams, and departure of team members.
Time and time management are the biggest factors in the success or failure of most software development projects. Underestimating the time needed for a software project guarantees late project completion. Attempting to complete a project that is not allocated sufficient time also results in corners being cut: design is shortchanged, testing is inadequate, and quality is hampered. Overestimation may discourage potential clients from proceeding with software development.
Estimating the duration of a project is an early opportunity for increasing project visibility. It encourages communication within the development team and allows the team to produce a project artifact, a somewhat detailed estimation on the resources needed for the project, early in the project lifecycle. Having the team develop resource estimates allows these estimates to be visible to all team members. These estimates serve as early deliverables that are given to clients to enhance their view of the project.
Delivery of the project artifact to the potential client gives the client more information to decide on continuing with the project. A prospect’s reception of a thoughtful time estimate, which is supported by consensus among the development team, gauges the prospect’s expectations. Prospects with reasonable expectations tended to be content when software systems were delivered on time, and they also tended to be moderately ecstatic when projects were completed before their respectively scheduled completion dates. Prospects with unrealistic expectations usually turned out to become problematic clients who demanded more attention and technical resources, causing a reduction in the quality of service provided to other clients. Clients with unrealistic expectations also tended to be insensitive to increased developer efforts to deliver high-quality software systems within reasonable time frames.
Requirements analysis is an essential tool for formulating an acceptable time estimate. Analyzing the desired system’s functionality requirements provides a concrete basis for estimating project duration. The complexity and time required for the development of software systems within a software class vary widely. The variation is based primarily on the differences of requirements. Listing a particular system’s required functionality and summing the estimated times to fulfill each of the requirements provides a more accurate estimate than one that is based on the system’s software class. Deriving a project duration estimate from system requirements analysis is an alternative to the common practice of making educated or whimsical guesses.
Like other artifacts of the software development lifecycle, the project duration estimate is affected by the completeness of the requirements analysis. Pockets of required time are hidden by abstract requirements. “Web pages are ranked by popularity on the ‘popular web page’ results page” is an example of an abstract requirement. This requirement is incomplete without coverage on the basis of popularity. The software system may use services like ping-o-matic or rely on a system component that spiders the Internet for information to determine web page popularity. The time required to fulfill the requirement, “popularity of pages is determined purely on recency information provided by ping-o-matic with the most recent page being the most popular,” is significantly different than that used to fulfill the requirement, “popularity of pages is determined by the number of people that bookmark a particular page on the social bookmarking service with the most popular web page having the most bookmarks.” Not eliminating abstract requirements causes project estimates based on the requirements to be inaccurate. It potentially causes the project and the delivered system to overrun its allocated resources.
Acquiring the requirements from the prospect, analyzing the requirements with the developers, and reviewing the requirements with the prospect after receiving feedback from the developers is a good start for developing a complex system. Requirements determine the time frame and form the foundation for system construction. Solid requirements provide a solid foundation for successfully building complex software on schedule. Incomplete requirements provide a shaky foundation that causes efforts to build potentially late software to topple.