How to Avoid Problems When Creating Software Requirements

Software requirements gathering may be a hurried list of "must haves" or a long laundry list of everything the customer wants, needs and would like to have if money were no object.

How can you avoid problems when gathering and defining software requirements?

Do not let the person most familiar with the requirements mapping notation or requirements documentation software dominate the actual generation of requirements. Their job should be that of a secretary in an organizational meeting, collecting all inputs for group or management review, not acting as a gatekeeper as well as a court recorder.

Gather requirements from all stakeholders, such as software application support and view-only users, not just IT security, managers who use the tool for reports and task delegation and super-users.

Not every complaint will have a solution. Nor does every frustration someone have with the current software version need to become a software requirement for the next build. However, documenting all complaints and concerns reduces the resistance to the project in the future.

Ask context-free questions at the start of the software requirements process to gather global requirements, instead of diving into the weeds up front. Global requirements more easily flow down into detailed ones than pushing the discussion back up to a higher level.

Identify potentially conflicting software requirements up front. Resolve conflicting requirements before going past the requirements phase.

Label whether a software requirement is a "need" or a "want" when it is recorded.

Do not forget to add bug-fixes from the current software version into the requirements to be part of the next software build, unless the bug was fixed in an intermediate patch.

Pay attention to the assumptions behind your software requirements. If the assumptions change, such as the definition of your user community, some of the software requirements will change as well.

When developing requirements, do not necessarily mandate how the requirement is met. For example, creating a web-based version of a client-server application may be a requirement to move to a cloud based application. However, it does not necessarily have to be built with a specified software suite or run on a particular platform.

Remember the power of inertia. Making changes for the sake of changes or "looking new" alienates users. Only change the appearance of a tool and how one performs basic functions if it makes someone's job easier, whether it is simplifying the number of steps to complete a transaction in that one tool or standardizing the tool set. Software should not follow fashions like cars and clothing, changing interfaces to look like something new, cool or hot on the market today.

Track your software requirements and make sure none of them are redundant or conflicting before you start coding.

Gain consensus on requirements before moving forward with coding. However, it is important to realize that it may not be possible to satisfy everyone.

Determine if reported problems are technical in nature, a matter of perception or a need for user training before planning to write code. Requirements for software do not always necessitate rewriting the software, and other options should be explored before altering the software application.

Formally document all software requirements in applications like DOORS. Make the software requirements document a contractually required document to which customers must agree before you start coding. This ensures that customers have signed off on the project requirements before you start work. You gain a legal defense against an expanding scope and new requirements mid-stream, as well as protection against customers rejecting the project because it isn't what they wanted. If the software meets the requirements, they are contractually obligated to accept it.

If a software requirement is found to be too complex to implement as planned, determine if there are other ways to perform the task within the tool, use other available software tools to perform the same task or another way to complete the objective.

Bug-free should be a goal of all software projects. Strive to resolve all major software bugs and as many minor ones as possible during software development, coding and testing.

If mistake-proofing is built into a software application, such as the use of "masks" to enforce a particular data entry format, also include the ability to alter theses masks. For example, a data field format built to enforce American style phone number entries may fail if users try to enter international phone numbers. Ensure that the mistake-proofing is alterable in case it no longer fits the situation.

Review the requirements as new features or functionality are added. Ensure that the new functionality doesn't interfere with existing requirements or alter them, just as the new functions are tested to ensure that they do not interfere with other functions.