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 receive training in the use of these tools before you become proficient in their use.
The nature of the software application or website your project will deliver will influence your decision about 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 in this section and describe situations in which 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 outlines the features and functionality 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 into requirements, but you should use them to define the boundaries within which the definition of requirements should remain.
brainstorming
Brainstorming is perhaps the most widely used tool for soliciting thoughts and ideas. It’s a technique that requires participants to gather in a room to work well (at least I haven’t heard of anyone having success brainstorming via audio or video conferencing). It also depends on the people involved having a common understanding of the problem or solution being discussed.
Brainstorming sessions should focus on the number of ideas, so you should cultivate an atmosphere that is conducive to everyone in the session talking. If some of the ideas raised in the session are not feasible or are not covered by a contract or SOW, now is not the time to discard them. Let the creativity flow. To set up the session, you’ll need to state the problem to trigger creative thinking before people even arrive at the session. You will need a problem statement for each of the groups you will be brainstorming 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 have an affinity with each other; it doesn’t make sense to capture the same feature or function in 10 different requirements. The last step in the exercise should be to prioritize features, using cardinal or ordinal scores for this purpose. This is so that when it comes time to fit development within the available budget, you know which requirements to drop first. You can try a variation of brainstorming called the nominal group technique to accomplish this.
Brainstorming and the nominal group technique are appropriate when you can get several people with the same needs for the new app/website together in one room to stimulate each other’s creativity. This could be used when you have a team doing the same job with the app, or are at least familiar with each other’s use of it. It could also be used when you have several different functional groups (for example, sales, customer service, support, etc.) so you can have one brainstorming session per functional group. Brainstorming is not appropriate when you have a small group of stakeholders with disparate needs, or your stakeholders are geographically dispersed.
interview
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 stakeholder needs appropriately. The interview technique will also allow you to de-scope grand requirements when you are familiar with the nature of stakeholder needs and the cost of developing functionality to meet a requirement. When you determine that an established requirement would not be feasible due to the time and effort required for development, ask the stakeholder if “….is there an easier way to do this?”, or “….would this be a feature that Did x, y, and z satisfy that need?”
You will perform the analysis, matching of similar requirements, and aligning the requirements with the contract or SOW, and you will need to send the results to the interviewees.
This method can be used when you have a relatively small group of disparate stakeholders requesting requirements. The advantage of this method is your control over the given requirements, your ability to influence expectations, and your ability to ensure that the requirements are accurately captured. It would not be appropriate for projects where you have a large number of stakeholders to request.
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 systems analysts in the requirements gathering process. Workshops require a facilitator to keep discussions on track and focus team efforts on the task of gathering requirements, and a recorder to capture requirements (this is similar to brainstorming). Analyst participation in the workshops ensures that the collected requirements will be feasible and not unreasonably costly in terms of development time or effort. Another benefit of having analysts on the shop floor will be their ability to offer alternatives that can address the same needs at lower cost.
JAD will work in the same situations where brainstorming is appropriate and, like brainstorming, will require the team to be co-located.
Surveys The survey is the same approach as the interview, except that the surveys can be conducted remotely. The information that solicited stakeholders will need to allow them to express their needs for your project must be communicated early enough to allow them to respond intelligently. You must provide a response deadline to ensure you receive responses by your planned end date, and you will need to do 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 interview technique).
This technique is appropriate when the stakeholder group being requested is geographically dispersed, or the number of interested parties requested is too large to employ the interview technique. The technical survey allows you to gather requirements from a large number of interested parties without the overhead of interviews. Be warned: to achieve any degree of success with this method, you will need to impress upon stakeholders the importance of their response.
Graphic script
Storyboarding is a means of capturing requirements on a graphical screen instead of 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 registrar drawing screens on an easel or white board. The screens will contain all the information that will be displayed on the screen, as well as the input fields needed to collect information. The storyboard is used in a workshop setting with a facilitator and a recorder. The facilitator and recorder will start the session by creating a screen to express the first major need. This could be a login screen or some other screen that captures a fundamental function. The original screen can trigger 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, one screen for each software order, one computer order, and one order. Operation manual request. . The storyboard will build out the screens as the group navigates through each feature 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 can have, and the behavior of the screen on different inputs (how errors are handled, how input information is checked). input, etc.).
An advantage of storyboards is your ability to define the screens that will be a key feature of your application and gain consensus in a group setting for the appearance of each screen. This method is appropriate when the application being developed is GUI-based or for websites. It is also appropriate to locate the requested stakeholders 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 based on a GUI.