Gathering requirements is the first step in building any kind of app, from a single desktop app to web apps to complex software packages used by thousands of users at a time. There are as many different methods and techniques to gathering requirements as there are days in the year. I’m not an advocate of any one method over another — different techniques are suitable to different problems.
There is no one right way to gather requirements – don’t ever let anyone tell you otherwise.
I’ve used many different techniques over the years, as methodologies evolved over time and I dealt with different types of customers. The right way to gather requirements is less about technique and more about the interaction between the developer, the customer, and the end user. The proper technique is the one that allows the customer and end-user to communicate what they want built to the developer(s) who will actually be building the software.
For our purposes, we’re going to use a straightforward approach to identify our requirements:
1. Identify the problem to be solved by our app.
2. Identify activities that need to be managed by our app.
3. Identify the data that needs to be managed by our app.
4. Identify the views of the data we need to support the activities.
5. Create our requirements matrix.
The Problem – Running a Golf Tournament
We start with a high-level description of the problem to be solved. At this point, we don’t know how we’re going to solve it, what reports we are going to build or screens we are going to design. In its simplest form, a problem definition describes what users want to do with the app.
Running a golf tournament isn’t a single day event. Planning starts months in advance. Marketing activities advertise the tournament in the weeks ahead of the big day. In the days before, donations, sponsorships, and player registrations will hopefully be pouring in. On tournament day, registrations have to be captured, money tracked, results tabulated, prizes awarded, raffles drawn. After the tournament, thank you letters and donation receipts need to be sent.
While golf tournaments take many forms, since this app is going to be used to run our tournament, we’ll use that as the basis for our requirements. Our tournament is a one-day, two-flight (AM and PM), four-person scramble, in support of the Alzheimer’s Association. We have been fortunate to fill the course the past three years, which means eighteen four-person teams play in both the AM and PM flights. Prizes are given for both the AM and PM flights. We have two types of competition — scratch and non-scratch — so for scratch players we need to capture their handicaps. We have several different raffles for both flights (this is Alabama, so we have an Alabama raffle separate from an Auburn raffle, and another for general prizes).
After tournament day, we continue to receive funds from sponsors who didn’t pay their sponsorship fees before the event and from good samaritans who want to donate to the cause. We generally write four checks per tournament: the sign maker, the golf club, the donation to the charity, and the tax accountant (our tournament is a 501(c)(3) non-profit, but we still have to file with the IRS).
Finally, after tournament day, we go to some island in the Caribbean for a month to recuperate (ok, maybe that’s just wishful thinking, and certainly not covered by our app!)
Now that we’ve identified the problem, our next step will be to break the problem down into the activities the app has to support to solve the problem. See you next week!
First post link – Links to all Simple FileMaker posts can be found on this page.
These are some of the better books to introduce you to software requirements. See here for full disclosure on Amazon links.
Project Connections – A site that has hundreds of project planning and management templates.
TutorialsPoint – This site has tons of tutorials on a variety of topics. This is the link to the software requirements tutorial.
Requirements Blog – This blog by Seilevel is devoted to software requirements.