Software Engineering Project Take Two:

A lot of the costs for any software project are associated with post-delivery maintenance. This really shouldn’t come as a surprise. However, what might come as a surprise is just how much of the costs — seventy-five percent! So what’s the best way to mitigate the amount of post-delivery maintenance? How about we do things right from the start.

As Project GOOB continues to move forward I have been preparing our requirement/specification document for review. The more I work on it the more I come to realize how easy it is to think like a developer and not as a client without these documents.

The purpose of a requirements document is to provide a bridge between the client and the developer. Our goals are to understand the client’s business model, discern their needs versus wants, and express in a natural language what we as developers need to design to in order to integrate them. In short, we’re building a road map between our client’s business and the software that will help make it more productive.

Functional requirements are the things that our application must be able to do in the most simplistic terms possible. For example, with Project GOOB one of the functional requirement is to create a new alarm. Another functional requirement is to modify an existing alarm. We use these functional requirements to build use cases which graphically represent scenarios where agents (i.e.: users, databases, or even other systems) interact with the system and model behavior from the agents point of view.

Drawing some simple graphical representation to create a new alarm or modify an existing alarm should be simple right? Not exactly. Both of these functional requirements seem to have very similar use cases. Namely: set time, set date, set sound, and set challenge type. But, this is the beauty behind representing functional requirements as use cases. It allows us to spot and redesign potential pit falls, or redundancy, very early in the development process.

You might be thinking, so what. How important is identifying things like this early on? Well, look back up at the staggering statistic: 75% of all project costs are associated with post-delivery maintenance. So, let’s all take a moment, step back from the code we are all so eager to dive into, and think about exactly what it is our client really needs and how we can actually help them do so.

“Code and fix is bad, mmk.” — Some Professor


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: