Value of Scoping and Requirements: A Developer’s Point of View

Tyler Throckmorton

Software Developer, Healthcare Leader, Golf Enthusiast, Foodie

Stereotypes are very often not representative of the truth or the majority of a population. In that instance, software developers hold a stereotype of being reclusive, mushroom-like, loving of the dark individuals. Over the last decade of working as a software developer, I can assuredly say that this is quite often the furthest from the truth. I know many developers who are often the first individuals to go outside in the morning for a run. Or aren’t available on a Saturday afternoon because they’re playing golf, soccer, or some other recreational activity. In fact, most developers seem to recognize that since we spend so much of our time sitting and looking at a computer screen, that we need to get out and do other things. This actually benefits us more often than not. Development, despite it’s adherence to logic and reasoning, is much more creative and art inspired than many give it credit. Yes, you need to know the basics and have an understanding of some complex reasoning sometimes. However, you need to be able to be creative and think outside the box to find solutions to problems that many people often struggle with. Despite my argument that software developers have an inaccurate stereotype, I can say that this stereotype is true for some – myself being one of those. I love playing golf and soccer and going to a bar with a friend. However, I also love turning the lights off, sitting in the dark, and staring at my computer screen digging into a problem that is stumping myself or others.

If you read my last article about The Importance of Prototyping, you’ll know that a client or a stakeholder often has a vision of what they’re wanting the project to look like. When you have a developer that may sometimes prefer to not interact with other people or has some peculiarities that you may not want to expose to a client or stakeholder, the role of a business analyst becomes paramount. These individuals are the people that translate normal speaking language into the nonsense and random repeating characters that we, the developers, understand.

As discussed previously with prototyping, it’s easy to get this translation wrong. Let’s think about it from a very basic level. You want a button on the screen that when clicked displays a popup yelling “Surprise!!! Happy Birthday!!!” In your head, you envision this button being a neutral color so not to give away what’s going on before someone unknowingly clicks it. However, the developer comes back with a button that is neon green. It’s too bright! Then when you click it, it’s the just message that appears as we said above. Now you wonder, where’s the confetti cannons? The balloons? The tooting of a celebratory horn? This was your vision, but, the analyst and developer didn’t get it. That’s where the requirements, the scoping, the prototype, all of these come together to define your vision into the terms and principles that the developers will comprehend and be able to create for you.

Understanding how this works for simple task like described above, how do you think this would play out for our telecommunications and CRM system integration we talked about last time? What do the developers need to know about to make this work? How does the system need to look and behave? How fast should different steps or processes respond? These are only a few of the questions that need to be asked and answered to define the expectation of what is needed. From here, the vision can be broken down into individual elements that make up the entire solution. Maybe you decide that we can’t keep a customer on the phone waiting for longer than 5 seconds, so the CRM system has to respond with the requested information in 2 seconds to give the agent time to read it and know how to answer. Maybe the agent needs to know how the customer’s mood or behavior might be before they answer the call, so we need to implement a way of tracking the individual’s response to previous interactions with us.

At the end of the day, we as software developers are much the same as you. We want to make you happy about the solution we’ve built for you. We don’t want to throw it away and start over because we didn’t deliver what you wanted. That’s the value scoping, requirements, and prototyping give. They inform us about what the expectation is, what the outcome should look like, and what we need to do to accomplish our goal and your goal.