The intent of this section is to give you an idea of ​​the various requirements gathering tools available and the factors to consider when choosing which one to use for your project. You will need to be trained in the use of these tools before you master their use.

The nature of the software application or website that 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 representatives, and maintenance personnel and their locations. We will try to describe some of the tools available to you in this section and describe situations where it would be appropriate to use them.

The contract or statement of work

If your organization has contracted with a third-party vendor to develop the application, you will have a contract that sets out the features and functions that your application or website will have in general terms. If the contract is accompanied by a Statement of Work (SOW), the features and functions can be described in more detail. There will still be work to be done to refine the statements in the contract or SOW on requirements, but you should use them to define the limits within which the requirements definition must remain.

Brainstorming

Brainstorming is perhaps the most widely used tool for soliciting thoughts and ideas. It’s a technique that requires participants to be gathered in a room in order for it to work well (at least I haven’t heard of anyone having any success with brainstorming via audio or video conferencing). It also depends on the people involved having a common understanding of the problem or solution being discussed.

Your brainstorming sessions should focus on the number of ideas, so you should cultivate an atmosphere conducive to getting everyone in the session to express themselves. If some of the ideas raised in the session are not feasible or not covered by a contract or SOW, now is not the time to dismiss them. Let creativity flow. To set up the session, you will need to state the problem to activate creative thinking before people arrive at the session. You will need a problem statement for each of the groups that you will brainstorm with, and if the project has a contract or SOW, you will need to base your problem statements on these.

You should encourage the team to combine ideas or requirements that are related to each other; there is no point in capturing the same feature or function in 10 different requirements. The last step of the exercise should be to prioritize the characteristics, using cardinal or ordinal scores for this purpose. This is so that when it comes time to tailor your development to your available budget, you know which requirements to rule out first. You can try a brainstorming variation called the nominal group technique to accomplish this.

Brainstorming and nominal group technique are appropriate when multiple people with the same needs for the new app / website can be brought together in a room so that their creativity can stimulate each other. It could be used when you have a team doing the same work with the app, or are at least familiar with how others use it. It could also be used when you have several different functional groups (eg sales, customer service, support, etc.) so that you can brainstorm by functional group. Brainstorming is not appropriate when you have a small group of stakeholders with disparate needs or your stakeholders are geographically dispersed.

Interviewing

The interview allows you to meet with your stakeholders one on one and ask focused questions so that the requirements established during the interview are clear and address the stakeholder needs appropriately. The technical interview will also allow you to narrow down the scope of grandiose requirements when you are familiar with the nature of stakeholder needs and the cost of developing the functionality to meet a requirement. When you determine that a stated requirement would not be feasible due to the time and effort required for development, ask the interested party if “… is there an easier way to do it?”, Or “… would there be a feature that x, y, and z satisfied that need? “

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

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

Joint Application Development (JAD)

JAD uses workshops to solicit requirements from stakeholders much like brainstorming. However, there are several key differences, the main difference being the involvement of the 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 collecting the requirements and a recorder to capture the requirements (this is similar to brainstorming). Analyst participation in the workshops ensures that the compiled requirements will be feasible and will not be unreasonably costly in terms of development time or effort. Another advantage of having analysts in the shop will be their ability to offer alternatives that can address the same needs at a lower cost.

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

Surveys The survey is the same approach as the interview, except that surveys can be conducted remotely. The information that the requested stakeholders will require to enable them to establish their needs for their project must be communicated to them well in advance to allow them to respond intelligently. You must provide a response deadline to ensure that you receive responses before the planned end date, and you will have to perform the analysis, collection, and alignment of responses yourself. The survey will also require you to communicate the survey results to your stakeholders (similar to the technical interview).

This technique is appropriate when the stakeholder group being solicited is geographically dispersed or the number of solicited stakeholders is too large to employ the interview technique. The survey technique allows you to collect the requirements of a large number of stakeholders without the overhead that the interview entails. Be careful: to achieve any degree of success with this method, you will need to instill in your stakeholders the importance of your answer.

Storyboarding

The storyboard is a means of capturing the requirements on a graphical screen rather than in text. It borrows from the entertainment industry, where the technique was first used in the production of cartoons.

Using storyboards to capture requirements involves the recorder drawing screens on an easel or whiteboard. The screens will contain all the information that will be displayed on the screen, as well as the input fields necessary to collect information. The storyboard is used in a workshop setting with a facilitator and a recorder. The facilitator and the recorder will begin the session by creating a screen to express the first important need. It can be a login screen or some other screen that captures a critical function. The original screen can activate subsequent screens to complete the function. For example, the first order entry screen may capture information common to each order and require subsequent screens to capture information that is unique to different types of orders, for example, a screen for each software order, a computer order, and a operating manual request. . The storyboard will develop the screens as the group navigates through each feature or requirement.

Since the storyboard can only capture some states for each screen, it is important that the recorder captures the different states that each screen can have and the behavior of the screen on different inputs (how errors are handled, how information is verified from entrance, etc.).

An advantage of the storyboard is its ability to define the screens that will be a key feature of the application and to obtain consensus in a group environment for the appearance of each screen. This method is appropriate when the application being developed is GUI-based or website-based. It is also appropriate when the interested parties being requested are positioned so that they can participate in the workshop. It will not be appropriate when the stakeholders are geographically dispersed or the application being developed is not GUI-based.