Crafting Software

Lessons Learned : Software Dev As a Process

Requirements Dream, Becomes Nightmare

Requirements are not code.  Thus, requirements are boring.  That’s how real devs feel about requirements.  We devs did not choose a life of Business Analysis because we like creating code, not gathering requirements.

I’m a developer too and since most of you who will be reading this will be developers here are three promises for this chapter:

  1. It will be as short as possible
  2. I will provide new material in a new way -- this is not rehashed info about requirements
  3. I will provide you with a specific process that you can use on all of your projects.

The Requirements Dream Quickly Becomes a Nightmare

As devs we would love it if a BA (Business Analyst) would go out, investigate the manual process and return to us with a list of requirements we could use to build the software.

That’s the dream.

Then, if we had any questions about those requirements we would just go to the BA and ask him for the exact details so we can move on.  Unfortunately, this is rarely how it works in the real world.

Often, the process starts with the BA (or any other role) coming to the dev and saying, “Hey, the system needs to store customer information in the database, so go ahead and make it do that.”  

Does that sound ridiculous, as if it would never happen in real life?  Well, I took that example from a real life situation when a BA came to me while I was working at a large mortgage bank.

I simply asked him.  “Do you have any use cases for how the data will be used?”

“Uh, no.  We don’t do that here,” he said.

Right.  As if a good and necessary practice such as creating use cases has to be mandated from above.  It does not.  

Since we devs are going to be expected to build the right thing we have to somehow convince those around us to do the work that will give us the best chance of creating the correct system.

It goes back to our second tenet of Software Development:

Everything the program is supposed to do must be known by the software developer.

I continued the conversation with the BA.

“Well, do you have a list of data elements that describe the customer information?”

“What do you mean?  Just put customer information in the database,” he said.

I took a deep breath trying to slow myself down because I felt so frustrated.

“For example, what elements would make up a customer info record in the database?  Would it be just first name and last name?”

“Of course not. You’re going to need street address, city, zip and all the rest.”

“That’s what I need from you.  Gather up those details and send them to me.  And, you see the other problem right?”

“Other problem?”

“Well, how is the data going to get into the system?  Where will it be entered?”

“You’re going to create a new form in the application,” he said.

“Now we are getting somewhere.  Did you remember that when you arrived you just said that we just needed a table in the database? Now there’s an entry form.  Will the user be able to edit a customer info record once it’s in the database or just create a new one?  Will the user be able to delete customer records?  Will different users have different rights such as read, or add and delete?’

At this point the BA looked annoyed. “Whoa, whoa.  Hold on.  I just wanted to get this new customer info thing set up.  Are you trying to be difficult?”

That is the reality of how poorly requirements are often created in the real world of IT.

Creating Software Is Easy

Every developer can create software.

However, creating software which creates a solution to the proposed problem is far more difficult. That's because the proposed problem is often not defined very well, if at all. Different roles end up having different ideas about what the completed product will really do.

Capturing Requirements

However, creating software which creates a solution to the proposed problem is quite a bit more difficult. That's because the proposed problem is often not defined very well, if at all. Different roles end up having different ideas about what the completed product will really do.

The problem is how to capture the things which describe the system in way that allows everyone on the team to actually know what we (the devs) believe the system will do.

We'll continue this conversation next time.