Improving Custom Software
This quarter, Entrance is making quality a focus for improvement, both for custom software development and our software consulting efforts. Although we always strive to deliver the best possible result to clients, we know that we can always implement new techniques that will make these results even better.
Over the next few weeks, Entrance consultants will share some thoughts on what this looks like for the company. Hopefully this will help clients to see the value they get from hiring a company filled with consultants that really care about the business problems we are solving for our customers.
Requirements Gathering
To get us started, I’d like to cover how our thought process surrounding requirements gathering. At the beginning, I always try to stop and refresh my 
thoughts on, “What am I building to and how does this piece help that goal?”
Often, I get into the mode of attacking symptoms instead of the issues, which usually causes quality to degrade due to a larger footprint for the product. To minimize this, I try and follow the approach of asking the five W’s:
- Who
Who is this for? Who does this affect?
- What
What am business problem am I solving?
- Where
Where does this occur?
- When
When does this occur? How long is the solution valid?
- Why
Why is this process the way it currently is?
All of these questions help me determine and constrain the how, so that my solutions don’t get too over-architected or expansive.
A Common Business Understandng for Custom Software
Another item that usually causes requirements quality pain is not having a common understanding of definitions of business terms. The quick fix is to get in the habit of spelling out each of the five W’s for a given project.
To take a basic example, a clerk at a school comes and says, “I need a way to print attendance records for every classroom, every period, every day”
Who: Clerk.
What: Ability to bulk print reports by classroom and period.
Where: In the main office.
When: Daily.
Why: Because she needs to file this.
What becomes clear during this process is that the why needs more definition. With more examination, we see that the report gets used in the future. So while the who and the where stay the same, the what, when, and why need to become more specific.
What: Review information on this report.
When: In subsequent school years.
Why: Because the data is not available after the current school year.
As we think about this a bit more, this was an assumed limitation of the system due to the clerk’s knowledge of the system.
By drilling down to this, we were able to show that the current system would hold all historic data in the system and there would be no reason to print every attendance report every day, thereby saving trees and keeping my custom software solution lean.
For more on this topic, check out our blog on creating custom software solutions that meet your business need.