Top 5 Problems When Writing Software Requirements

Software requirements are one way to transfer the ideas you have about your application from your mind to the minds of your software designers and developers. Here, at SOLTECH, our team loves to work with clients during this stage and look forward to working together to create the best software requirements possible. This stage is not only important for us as developers, but it’s extremely important for you and your peace of mind.

Being able to relay your ideas clearly is critical. When software is built, it starts in the conceptual realm and stays there until you start to see and use the code as it is written.

Even though some methodologies like Agile thrive on iteration and getting it ‘right’ after a couple of tries, the better your requirements are thought out and documented at the start, the smoother your project will go, and the cheaper it will be.

We know how difficult putting your ideas on paper can be so we’ve created this list to help you. Below are five common software requirements issues to think about as you write or review your software requirements.

Not Including Functional And Non-Functional Requirements

Software requirements are a checklist of what the application has to do in order to be successful. If it isn’t documented, chances are, it won’t get done.

Start with the basics and then drill down.  Who is every user of the system and what do they need to do with the system? Remember uncommon users like administrators or those with less permission like auditors.

Treat the system itself as a user. Does it do any processing or tasks in the background?  Write those down too.

Then think through the non-functional requirements – the stuff that the system overall needs to achieve that isn’t related to a user. This includes:

• Supporting a certain number of users at a time
• Storing or accessing a certain amount of data in an hour or day
• Security requirements
• Meeting compliance regulations like HIPAA, PCI, SAS70
• Logging and auditing events

Letting The Reader Make Assumptions

When we communicate, it is easy to assume that others who are similar to us understand what we mean without having to spell it out. We do this because being explicit is tiring and takes effort! Unfortunately, assumptions in software aren’t the best idea.

A similar example to illustrate assumptions is to think about writing requirements for a house. Stating that you need a door to go from the living room to the back deck is great!  But, do you want a double door or a single door?  Do you want it to swing out or it could swing in?  Should it be made out of metal or wood?

If having any door is good enough, then leave the decision up to your designers and developers, but if you have a preference, state it clearly.

Not Focusing On Your User

When you write your requirements, write them in the language of your user. Who is this user and what are they trying to do? What is important to them? What is their level of technical ability? What do they struggle with? Where are they wasting their time on currently? These become requirements.

Another tidbit of advice is to focus on the goal they are trying to achieve, not the steps they currently use to get to their goal. The great thing about writing new software is that you can do some things differently and achieve a better result.

Unless the detailed steps are critical to your business, stick with documenting the goal and the desired end result. You can work with your software designers later to come up with the most efficient solution for achieving this goal.

Be Thorough And Clear – But Not Verbose

Detailed requirements are great, but creating too much documentation can also cause an issue. Technical documentation is hard for anyone to read.  Keep it simple. Bullet lists are great.  You want to hit on all system requirements while being clear and avoiding ambiguity or assumptions.

If you find yourself writing pseudo code for your reader, you are probably starting to solve the problem rather than define the goals of the solution.  Stick to the goals and let your team create the solution.

Not Considering The Negative Scenarios

It’s easy to write what the solution should do when things go as they should, but take a moment to think through any possible issues that the solution should handle with grace.

If your system will be delivering emails in mass, what will it do if the network is down?  Will it retry to deliver the emails once every 15 minutes for a configurable number of attempts before it logs an error? This behavior is a requirement.

Summary

Getting your ideas from your head down on paper can be a challenge, but the act of writing them out will help clarify what you are thinking for the benefit of you and your software team.

When going through the exercise of defining system requirements, consider these five common issues to help your team create a great product for you!

If you’re ready to share your vision and get started, let us know! We’d love to work with you. Drop us a line at hello@soltech.net, share your ideas with us, and we’ll tell you how we can make them a reality.

Resource: The Checklist For Sharing Your Software Vision

Before you get started in developing your software app, your thoughts and ideas should be clarified and written down so they can be consistently and easily shared and understood. To help you get started on the right foot, we have created a checklist.

You can grab a copy of that checklist below and share it with your team!