Software Requirements Analysis — The Key to Developing Great Software

Over the years, software engineers have debated the merits of different programming theory, programming languages, and even different development models. From debates about separation of application and data modules to the merits of Java vs. .NET to Agile vs. the Structure Software, user experience, and user interfaces, UX/UI engineers all over the world seek to find the ‘holy grail’ of rapid development tools to give their customers the most useful and intuitive software possible.

Except for Agile development principals, most of these discussions and debates miss their mark. They start in the middle of the development process and focus on the hardcore technical issues. What is missing in many software development efforts are substantial efforts to nail down user requirements and optimize the entire UX at the very beginning of the development effort. Agile methodologies attempt to get at this problem through the development of user stories, product backlogs, and rapid prototyping. These methods are helpful, for sure — especially rapid prototyping. But even using Agile technologies, I have seen frustration with prototyping, because critical requirements were missed at the beginning of the project.

I have had the great fortune of leading some talented developers for about six years, and have seen some great applications developed in very short order. Our small team of four developers developed over 30 enterprise-level applications in those six years, for a 10,000+ user base. Our average development time was 120–150 days per application (from requirements analysis to deployment), and our software acceptance rate has been over 90 percent. Our team’s production statistics were way above industry standards, and the rapid prototyping was a crucial part of our success. But even more critical to the success of the team was the ability to quickly nail down user requirements at the very front end of the project.

This wasn’t always the case. When I took over the team, the development focus was on getting the technical aspects of the software correct. The team had endless debates on the programming languages to use, application theory and procedures, and even the database design. The focus was on the technical aspects of software development, and the end-user was almost an after-thought. Having spent a lot of my time in the operational business community before getting involved in software development, I thought something was seriously amiss. I was intent on changing that. I needed my developers to start developing their requirements analysis skills — to think about the ultimate end-user experience.

What I insisted the developers learn over the next couple of years was the ability to interact with clients and draw out their requirements. It’s arguably the hardest task in the entire software development process, but the better this task is accomplished, the more chance that the end product will be successful.

It starts with having a sponsor, a champion for the entire development effort. This is a lot harder to do when you are developing software for the general public. Developing for the general marketplace takes a lot of research, marketing, and some good luck along the way. You’re trying to determine requirements without having a built-in base of users telling you what they want. But in developing software for organizations, things are a little easier because you are developing software based on demonstrable needs. But without a champion or sponsor in the C-Suite, your best development efforts may never see the light of day, because the operational side of the organization doesn’t see a real need for the entire development effort.

Once you have a project sponsor, it’s essential to identify a project or product champion. On small development teams, this is usually one person, and they wear many hats. As the development lead for a small team of four developers, I rarely had any time to do any programming — that wasn’t my role anyway. My job was to be the ‘conductor’ — to facilitate the overall effort where ever the team needed help. I made sure that my team received all the training they needed, be it learning a new program, brushing up on data design methodologies, or learning more about the user interface (UI) and the entire user experience (UX) efforts. No matter what type of training my folks needed, it was my job to make sure they got it — even in times of constrained budgets (a yearlong subscription to any of the best online training sites is only $200–400. That cost is easy to justify.)

As the team lead, I took all the mundane management responsibilities away from the team — I wanted them to focus purely on the development effort. I also performed important marketing and stakeholder engagement tasks. I wanted to make sure that our stakeholders knew the value we added to the organization. It was also essential for me to manage customer expectations — making sure we didn’t promise features and timelines that were unrealistic.

But perhaps one of the most essential tasks that I insisted my programmers learn how to do well was performing robust up-front requirements analysis. I had learned over many years in development, that most of our customers and stakeholders start their projects out with only vaguely knowing how to automate their processes. Vague statements like “we need solid management reports” or “we’re not sure who should get access to the data,” or “We need quick input,” are far too simple for programmers. There is no way they can make enough sense of these statements to write any meaningful software that would help end-users perform work. Lest you think I exaggerate about these statements, let me assure you, these vague examples have all come from real customer engagement meetings.

A good requirements analyst knows how to flesh out these vague statements by asking the right set of questions. Requirements analysis is all about a path toward self-discovery by the customer.

It starts by asking the key stakeholders what I call ‘vision’ statements. What is their end-game? How does automating any process help them achieve the end goal of the business or organization? It could start by having the customer identify that the goal is to provide service faster than their leading competitor. Perhaps the goal is to minimize inventory or some other manufacturing costs. Whatever tasks the software performs, they have to be in line with some big overarching goal of the organization. That’s how decision-makers will ultimately determine the value of your team.

Next, and perhaps the most challenging part, is nailing down specifics. What processes or workflows is the organization trying to automate? What are the inputs? Where do these inputs come from? What does the incoming data format look like? Does it have to be compatible with any existing data formats?

How does the process work? What are the specific steps of each phase of the process? What output products does the organization need and who is the target audience (this is essential — if your target audience is top-level execs, they need a much more summarized level of information)? What is the output data format?

Who gets access to the information? What are the levels of access? Will the user administration of the software be required?

These are just some of the many questions that a good requirements analyst will ask at the beginning of the project. At this stage, the technical specifics of how to engineer the software are almost irrelevant. The importance at the front end needs to be almost laser-focused on understanding current operational processes. The more a requirements analyst understands these operational processes, the quicker they will be able to identify process improvement areas and make real improvements by coding these improvements into the software.

This focus on clearly understanding an organization’s operational process, why they are doing things the way they do, and what are the goals of the process requires quite a shift in the mindset of a typical developer. Many programmers are used to receiving clear requirements documents from someone else in the organization. But with small, agile development teams, this isn’t possible. Small teams of developers almost always have to do a fair about of their own requirements analysis. From my experience, however, it’s not something a lot of programmers are very good at. Especially when the requirements analysis means dealing directly with the stakeholders in the information-gathering stages of the project.

But it’s a skill that is crucial for small teams to learn. From my 15 years in the software development business, I have seen great project successes and massive failures. A good majority of both successes and failures can be traced back to the quality of the up-front requirements process.

The proper requirements analysis is a vital aspect of any development process. As a team lead or manager, it’s critical that your software engineers know how to perform proper functional and user-experience requirements analysis. Your team’s success and value to the organization depend on it.