Secrets Of Successful Software Requirements

Although most companies do some form of requirements, there is often a lack of understanding as to exactly why the requirements need to be created and the level of detail that should be included in the requirements.

Software is always created to solve a need for a client. The client may be an internal client, an external client, or even the general public. Detailed requirements are important to ensure that a program correctly and fully addresses client’s needs.

Detailed requirements make initial development easier and faster because the developers know exactly what should be developed and do not need to make their best guess at the functionality to be implemented or delay development by creating requirements during development. Giving the developers accurate requirements will also result in less rework at the end of development because the stakeholder’s requirements will have been implemented correctly initially and will not be arrived at through trial and error.

A project manager can use the detailed requirements to create accurate timelines and give correct estimates to the client. This ensures that stakeholders are completely aware how long development will take so they can adjust the scope of a project or proactively add resources if necessary.

Finally, testers can use the requirements to create test plans while development is ongoing rather than waiting until development is complete. The requirements give them information about what the program will do so there cannot be disputes between developers and testers as to what the program functionality should be. High quality requirements also describe problem paths that may need additional testing.

Even though highly detailed requirements make development easier in future phases, this is not always possible due to time constraints imposed by the client or market conditions. With this in mind, let’s look at some secrets to improve your requirements process even under tight deadlines.

Secret #1 – Include Use Cases

Use cases look at the requirements from the standpoint of an end user working with the program and how the program responds to the user’s inputs. At its simplest level, a use case can be thought of as a play where the end user is one actor and the program is another actor. These two actors then have dialogs which explain the interactions between the actors. More complicated scenarios can have additional actors including other programs, other types of users, and even hardware. Use cases have proven to be very easy to read and understand even for non-technical clients.

Each use case explores what happens when something goes wrong in addition to the “normal” interactions. The exploration of these failure conditions is very important because these cases are the most difficult to code and can cause the most amount of testing. Traditional requirements often ignore these cases. It can be helpful to have developers and testers both think of additional possible failures in a use case so they can be fully documented in the requirements.

Use cases do not provide a complete picture of the system though. A technical specification should also be included in the requirements to detail formulas and routines that take place behind the scenes.

Secret #2 – Prototype Screens with a Design Tool

A user of the program only interacts with a program through the user interface so it makes sense to spend a significant amount of time during requirements to ensure that the user interface makes sense, that all functionality is included, and that the most commonly used functionality is easily accessible. The easiest way of doing this is using a screen prototype.

There are a variety of methods of making screen prototypes which range from simply drawing the interface with a pen and paper to building “working” prototypes in a higher level language like Visual Basic which allows rapid screen design. However, each of these extremes has serious drawbacks. A pen and paper prototype does not allow users to interact with the prototype and it is more difficult to change. A “working” prototype done in a programming language like Visual Basic can lead the client to believe that the program is nearly complete and that development should not take very long or it can lead the client to believe that changes to the prototype will be costly making them reluctant to make necessary suggestions to improve the program.

Between these two extremes lies screen design applications which allow you to draw the screens and model interactions between screens. High quality prototyping tools allow you to enter sample data and allow users to move between screens by pressing buttons so they can easily understand the interface and its functionality. Most prototyping tools produce the final output in an HTML format so they can be easily shared even if a client is not in the same office where requirements are being developed.

When looking for a prototyping tool, make sure to select a tool which is easy enough to use that you can easily prototype screens while your customer is in the room. This will allow you to brainstorm and make changes to the screens without delays. A prototyping tool should already have common controls already defined to maintain design standards and improve the appearance of your screens. Being able to enter sample data in each screen can allow the customer to pinpoint areas that may be incorrect.

Secret #3 – Work Directly with End Users

When designing a new application or making revisions to an existing application, there is no substitute for the direct experience that end users have. An end user can give immediate feedback on your design to point out awkward or incorrect functionality. They also help to ensure that all controls are logically placed for the most efficient use of the system.

Using an interactive prototyping tool allows you to walk a user through the interface or even allow them to work directly with the prototype so they can quickly suggest improvements. As use cases are being developed, it is a good idea to walk users through the use case to ensure that the use case is well thought out and that all functionality is captured both in the use case and the prototype.

Secret #4 – Do Iterative Requirements Development

When you create requirements, it is important to develop the requirements in multiple stages. For example, you may want to do a general layout of the program and create higher level use cases in the first session to get a feel for the overall requirements. In the next session(s), you can focus on each key feature to ensure that the normal paths are all defined in the use cases and further refine the prototypes. In the next session(s), you can attempt to define all of the error conditions which can occur and update the prototypes as necessary. The final sessions should review all work previously done to ensure that all requirements are clear and complete. At each stage, you should not be afraid to revise work done in a previous step because getting the requirements correct will ultimately save time in the more costly development and testing stages.

Secret #5 – Place Requirements Documents under Change Control

With all of the time spent on generating clear requirements, it is very important to make sure that all of the requirements documents are included in your change control system. This includes use cases, screen prototypes, technical specifications, and any other documents used to define the requirements.

Conclusion

In this article, we have explored various secrets to make your requirements process successful and ensure that your clients are satisfied with the resulting program even under tight deadlines. At the start of your next project, make sure you have the proper tools in place for a successful requirements iterations including a prototyping program, a tool to write use cases, and a version control program. These tools do not have to be expensive, and they will help to get your requirements right and schedule under control.