{"id":1059,"date":"2023-07-25T14:13:30","date_gmt":"2023-07-25T19:13:30","guid":{"rendered":"https:\/\/rb-sns.com\/RB\/blog\/?p=1059"},"modified":"2023-07-25T14:13:31","modified_gmt":"2023-07-25T19:13:31","slug":"investing-in-requirements","status":"publish","type":"post","link":"https:\/\/rb-sns.com\/RB\/blog\/investing-in-requirements\/","title":{"rendered":"Investing In Requirements"},"content":{"rendered":"\n

Custom software can be very expensive and scary, but investing in requirements can help you improve the likelihood of success. However, we often want to see things being built rather than simply think about them. That creates two things that fight against each other (get it done or think it through) in many projects. Thus, we must consider early work on requirements and design as an investment. We pay for it in patience, but it saves us in almost every way down the road.<\/p>\n\n\n\n

Investing In Requirements Is An Easy Choice<\/h2>\n\n\n\n

There is so much value in thorough requirements gathering that it seems impossible for anyone to pass over this crucial step. Unfortunately, it is a common problem and one of the reasons many software projects fail. Yes, we want to see “work getting done,” but the only reason that is a problem is because we are not yet seeing the end product. I like to use the analogy of going on a road trip. You are not getting closer to the destination until you start driving. However, if you do not know where you are going or the obstacles on the way, it can be extremely costly. Those that use modern GPS maps or apps like Wayz often are redirected around problem areas and potentially save hours of drive time. That is the same with software development. We are not writing code but investing in requirements, so we have a better idea of the path ahead. That allows for proper estimates and planning.<\/p>\n\n\n\n

We Can Adjust As We go<\/h2>\n\n\n\n

One argument we fall prey to is that we can start building the software and easily adjust as we go. While there is truth in that, and we do not need to know the whole journey in detail, we do need to plan for each stretch. That is what the Agile approach embraces. It takes a bit from both worlds and gets us on the road faster while still ensuring we are planning enough to avoid major issues. When we use the road trip analogy, it is like planning the trip but then being open to adjusting due to construction or traffic delays. However, the key is that we need to know at least some of our path before we start. In a software project, this can be done via high-level requirements and core feature definition. Be warned that is a possible approach, but it can still suffer from wrong turns and proceeding down dead ends. <\/p>\n\n\n\n

Back On The Main Road<\/h2>\n\n\n\n

The discussion of Agile and its strengths and weaknesses<\/a> is for another article. Let us return to a focus on requirements that applies to any software project. Modern software systems are highly complex. There are tools that can help us to create or generate thousands of lines of code quickly. However, that speed can be just a faster way to create a big mess. I have seen many projects stumble and fall due to this issue. The problem may seem simple, but the details are highly complex.<\/p>\n\n\n\n

For example, let’s consider the simplest of problems to solve: keeping contact information for your customers so you can serve them. How hard can it be? There is a name and address and maybe a phone number or email. Oh wait, what if the customer needs a title, or is a company with multiple contacts? What if the billing contact is different from the key decision maker? Do we care if they have bought from us before, or do we track leads? Should we keep notes each time we talk to them? The list goes on and on. A simple problem can quickly become a complex maze of decisions. These can be very costly to make if we have already made a lot of progress on our software journey. Changes can require updates to code the database, the user interface, and even the partners or libraries utilized. Backing up is far more than that BEEP, BEEP, BEEP a large vehicle makes.<\/p>\n\n\n\n

How Do We Get The Requirements We Need?<\/h2>\n\n\n\n

Custom software development is just a way to solve problems on a big scale. Thus, we can use basic problem-solving techniques to guide us in creating a list of requirements that we can be confident in. Here is a short list of questions that you can use to take your requirements definition up to another level.<\/p>\n\n\n\n