Choosing the Right Tools

The intent of this section is to offer you some insight into the various requirements gathering tools available and the factors you need to consider when choosing which to use for your project. You’ll need to take training in the use of these tools before becoming proficient in their use.

The nature of the software application or web site your project will deliver will influence your decision on which requirements gathering tools to use. Other factors that will influence your decision are the number and type of business users, customer service reps, and maintenance people and their locations. We’ll attempt to describe some of the tools available to you in this section and describe situations where they would be appropriate to use.

The Contract or Statement of Work

If your organization has contracted with an external vendor to develop the application you will have a contract that sets forth the features and functions your application or web site will have in broad terms. If the contract is accompanied by a Statement of Work (SOW), the features and functions may be more fully described. There will still be work to do to refine the statements in the contract or SOW into requirements but you must use them to define the boundaries that requirements definition must remain within.

Brainstorming

Brainstorming is perhaps the most commonly used tool for soliciting thoughts and ideas. It’s a technique that requires the participants to be gathered in one room to work well (at least I’ve not heard of anyone having success with brainstorming via audio or video conferences). It is also reliant on the people participating having a common understanding of the problem or solution being discussed.

Brainstorming sessions should focus on quantity of ideas so you must cultivate an atmosphere that is conducive to everyone in the session speaking up. If some of the ideas raised in the session aren’t feasible, or aren’t covered by a contract or SOW, now isn’t the time to discount them. Let the creativity flow. To set up the session, you’ll need to state the problem to trigger the creative thinking before people arrive at the session. You’ll need a problem statement for each of the groups you’ll brainstorm with and if the project has a contract or SOW, you’ll need to base your problem statements on these.

You should encourage the team to combine ideas or requirements which have an affinity for each other – there’s no point in capturing the same feature or function in 10 different requirements. The last step in the exercise should be to prioritize the features, using either cardinal or ordinal scores for the purpose. This is so that when it comes time to fit development into the available budget you’ll know which requirements to toss overboard first. You might try a variation of brainstorming called the nominal group technique to achieve this.

Brainstorming and the nominal group technique are appropriate where you can put several people with the same needs for the new application/web site in a room together so that their creativity will stimulate one another. It could be used where you have a team who would all perform the same work with the application, or at least are familiar with each others’ usage of it. It could also be used where you have several different functional groups (e.g. sales, customer service, support, etc.) so that you could conduct one brainstorming session per functional group. Brainstorming is not appropriate where you have a small group of stakeholders with disparate needs, or your stakeholders are geographically dispersed.

Interviewing

Interviewing allows you to meet with your stakeholder’s one on one and ask focused questions so that the requirements drawn out during the interview will be clear and will address the stakeholder’s needs adequately. The interview technique will also allow you to de-scope grandiose requirements when you’re familiar with the nature of the stakeholder’s needs and the cost of developing functionality to meet a requirement. When you determine that a stated requirement would not be feasible because of the time and effort required for development, ask the stakeholder if "….there’s a simpler way of doing that?”, or "….would a feature that did x, y, and z satisfy that need?”

The analysis, combination of similar requirements, and alignment of requirements to the contract or SOW will be performed by you and you’ll have to feed the results back to the interviewees.

This method can be used where you have a relatively small group of disparate stakeholders to solicit requirements from. The advantage of this method is your control over the requirements given, your ability to influence expectations, and your ability to ensure the requirements are captured accurately. It would not be appropriate for projects where you have a large number of stakeholders to solicit.

Joint Application Development (JAD)

JAD uses workshops to solicit requirements from stakeholders much like brainstorming. There are several key differences however, the principal difference being the involvement of systems analysts in the requirements gathering process. The workshops require a facilitator to keep the discussions on track and focus the team’s efforts on the task of gathering requirements and a recorder to capture the requirements (this is similar to brainstorming). The involvement of the analysts in the workshops ensures that the requirements gathered will be feasible and not have an unreasonable cost in terms of development time or effort. Another advantage of having the analysts in the workshop will be their ability to offer alternatives that can address the same needs for less cost.

JAD will work in the same situations where brainstorming is appropriate and, like brainstorming, will require the team to be collocated.

Surveys

Surveying is the same approach as interviewing, except the surveys can be done remotely. The information that your solicited stakeholders will require to enable them to state their needs for your project must be communicated to them with sufficient lead time to allow them to respond intelligently. You should provide a response deadline to ensure you receive responses by your planned end date and you’ll have to do the analysis, collation, and alignment of the responses yourself. Surveying will also require you to communicate the results of the survey to your stakeholders (similar to the interview technique).

This technique is appropriate where the stakeholder group being solicited is geographically dispersed, or the number of solicited stakeholders is too great to employ the interview technique. The survey technique allows you to gather requirements from a large number of stakeholders without the overhead entailed in interviewing. Be forewarned: in order to achieve any degree of success with this method, you’ll have to impress upon your stakeholders the importance of their response.

Storyboarding

Storyboarding is a means of capturing requirements in a graphical display rather than in text. It borrows from the entertainment industry where the technique was first used in cartoon production.

Using storyboards to capture requirements involves the recorder drawing screens on an easel or white board. The screens will contain all the information to be displayed in the screen as well as the input fields required to gather information. The storyboard is used in a workshop setting with a facilitator and recorder. The facilitator and recorder will start the session by creating a screen for the first major need to be expressed. This might be a log in screen, or some other screen capturing a fundamental function. The original screen may trigger subsequent screens to complete the function. For example, the first order entry screen may capture information common to every order and require subsequent screens to capture information that is unique to different types of orders, for example one screen each for a software order, a computer order, and an operating manual order. The storyboard will develop the screens as the group navigates through each function or requirement.

Since the storyboard can only capture a few states for each screen, it is important for the recorder to capture the different states each screen may have and the behavior of the screen upon different inputs (how errors are handled, how input information is verified, etc.).

One advantage of storyboarding is its ability to define the screens that will be a key feature of the application, and get consensus in a group setting for each screen’s look and feel. This method is appropriate where the application being developed is GUI based, or for web sites. It is also appropriate where the stakeholders being solicited are collocated so they can participate in the workshop. It will not be appropriate where the stakeholders are geographically dispersed, or the application being developed is not GUI based.