Writing and Prioritizing Requirements and Features to Realize Your Vision

We’ve reached the final step in your software discovery process! Have you found a way to quantify where you are now and where you’ll be once you’ve reached your vision? How far are you from reaching it? You have your vision, you’ve completed your Information Gathering, now it’s time to pull it all together and define your requirements. To do that, you’ll need to think about what it will require for you to get from here to your vision.

You may be wondering when we’re going to get to the “software” part of your software discovery. The truth is, the best software solutions are built around your business’ unique requirements. They’re meant to provide your business with exactly what it needs, so as you figure out your business’ requirements, the features your software needs to meet them will begin to fall into place.

For example, a requirement for your business may be that salespeople need to know who to visit, as well as when and where to meet them. To meet this need, a feature of your software may be a CRM that displays the day’s appointments and has GPS integration. To reach this level of clarity for your entire system, you’ll need to list out all the requirements your business needs.

You want to write a solid set of requirements to help produce software that is beneficial for the long term health of your business. So, how do you start writing good requirements?

Writing Good Requirements

A crucial element to writing your software requirements is being mindful that you’re never too vague or too specific in your wording. If you’re too broad in defining what your business needs, it can be difficult to narrow down what you need your software to do. Conversely, if you’re too specific, you may focus on one thing while omitting other, equally important aspects of what you want your software to do. You want to maintain some flexibility so when the time comes to decide on features, you have a little wiggle room.

Another thing to keep in mind are anti-requirements. These are processes or solutions you may have tried in the past that caused bottlenecks or poorly affected your core processes. You’ve tried them already, and you know they don’t work, so it makes sense to put these in as definite “no’s” for your requirements.

You’re going to be drawing heavily from everything you’ve learned in the first and second phases of your discovery process. Using the insight you’ve gained so far, start thinking about your “need-to-have” requirements. These are the things that you know will affect your business daily, your core processes.

Using the same trusted sources who assisted in your Software Needs Discovery, you’ll want to ask for insight and other perspectives. Make sure that your “need-to-have” requirements really are requirements that you need to have.

You don’t want to focus your “need-to-have” requirements on rare occurrences or exceptions.

Focusing on What’s Important: The 80/20 Rule

As a general rule, you want to think 80/20. You want to focus on requirements which cover the top 80% of what your business does every day. These percentages are flexible (your business may need to take a 90/10 approach, for example.) The important takeaway, however, is to remember that you can’t cover everything, and some of your business needs will be more important or more utilized than others.

If you were to attempt to cover 100% of your business needs with your software, it would only lead to slow, inefficient core processes, effectively eliminating the entire purpose of why you’re seeking new software in the first place.

Spend some extra time figuring out which requirements could actually help your business run significantly better for that 80% of the time. These are the requirements you want to prioritize.

Increasing the efficiency of your core processes is the only way you will start to see real, quantifiable impacts to your bottom line.

Only your most important requirements should be true, “need-to-have” requirements. They’re the things that your business absolutely needs to operate properly and will lead you to bringing your vision to life. The rest of your requirements list should be categorized into your “nice-to-have” components.

When you think of less-common problems or exceptions to the way things run, try to find other solutions to these problems. Anything that falls into this category will be one of your “nice-to-have” requirements. Look outside of your software for solutions to these exceptions. Are there manual solutions that could be implemented to combat rare occurrences? It may be worth putting in a little extra effort for those 20% exceptions to allow your 80% core processes to run as smoothly as possible.

Don’t Build for Rush Hour

Put another way, you don’t want to build a highway for rush hour.

Creating the optimal highway for that specific time of day may require twenty lanes to accommodate such a high volume of traffic. Rush hour only makes up a small part of the day though, so how effective is your highway the rest of the time?

A twenty lane highway uses up a tremendous amount of time and resources and wouldn’t be beneficial or efficient the majority of the time. Your cost/benefit ratio simply wouldn’t make sense.

Now, when designing your highway, you don’t want to completely omit the complications of rush hour. You need your highway to be able to handle the congestion when necessary.

It’s the same concept for your exceptions and infrequent problems. We’re not asking you to develop selective amnesia for these exceptions. It’s important to keep these in mind without making them the sole focus of your requirements.

Ideally, you should consider your problems and exceptions, but your focus should be on your most-used functions, your core processes.

Remember: maintain a good understanding of your exceptions, but focus most of your energy on writing requirements for your necessities and core processes.

Creating a Features List

Now you’ll start determining your software’s features based on your requirements.

As you work through your requirements and begin writing a features list, a key element to consider is that you should be able to easily test whether or not your software meets your requirements.

Take a look at your requirements list. You have options on how to best solve your problems based on your required timeframe, budget, and how close you want your software to match your ideal.

Once again, let’s say your requirement is that salespeople need to know when and where to meet customers. You’ve decided on a CRM to display the day’s appointments, but instead of a built-in GPS system, you might have your CRM pass the address information along to another existing GPS program. Your timeframe, budget, and the efficiency for the people using your software will all factor into what features you ultimately decide on.

Think about how your software will ultimately be used. Its design is meant to make things work easier, so it’s important that your requirements and features encompass things that will make your processes run smoother and more efficiently for the people using them.

When designing a features list, similar systems can be an excellent source of inspiration. Look for features you like that can be modified and incorporated into your software design. While it can be tempting to want exciting or innovative features, it’s important to remember that a feature may be good, but not necessarily right for your business. If it doesn’t satisfy any of your requirements, it’s unlikely it will be helpful in accomplishing your vision.

Finally, you want to make sure you’re consulting. Consult with your team, consult with a software specialist, and see how far you can take your software. Using your requirements and the help of consultants, see what other ideas you can dream up for features that will aid you in achieving your vision.

Designing with the End in Mind

Once you have both your requirements and features lists fully realized, it’s time to finish prioritizing your “need-to-haves,” and “nice to haves.” Your “need-to-have” features are the things that will have a major impact on your business and should be included.

Remember, when it comes to reaching your vision, not all of your needs will be as important as others. Look for the ones that will have a substantial impact on your business, provide the soonest return on your investment, and lead you towards your vision.

Prioritizing these aspects will help you design and build “Version 1” of your software in accordance with your budget and timeframe. This isn’t just valuable for providing solutions short-term; developing prioritized features and requirements lists will set you up for an easy transition when your business has fully adopted Version 1. You will immediately be ready to continue evolving the software and your business closer to your ultimate vision by moving on to Version 2.0 and beyond.

Ready to start talking software solutions? Still have questions about the discovery process?  Talk to an expert!