If you haven’t already, check out the first three posts in this series: It’s easier than you think, lets build a web app
Aim for the goals
Every team has a different way of approaching requirements development. Traditionally, the requirements document forms the basis of the scope for an IT project. As a project matures over a number of iterations, it’s normal for the requirements to become more and more solution specific.
Continuing with the theme of not jumping into a solution, we’re going to follow the approach below, which involves spending some time to understand the business drivers for the project.
|Increase yearly profits by 25%||
This approach is not too dissimilar from something that you might see in a business case. After all, the more we understand about the business drivers, the more we can reduce assumptions, and focus on the real, underlying problems.
Looking at the above table, we can see that App-Makers really wants to make the most of their customer referrals, so that they can cut back their marketing budget, and also increase their profits.
Feasibility and Fit Gap
At this point, we can start to look into the feasibility of solving the identified problem, such as:
- How much of the problem should be computerised?
- What technology should be used?
- Should the solution be custom or off the shelf – are any suitable solutions readily available?
- Should it be based on internal infrastructure or ‘in the cloud’?
- Should it be based in a public cloud or private cloud?
Let’s assume that App-Makers have already looked into and tried out some available cloud based software, but they haven’t quite found anything that meets their needs. This is a really important point, because it should prompt you to start looking into the following questions:
- Is the solution practical (can the current technology support it?)
- Do you have access to the relevant technical staff/skills?
- Will the solution meet the defined requirements?
- How much of the requirements would be met?
- How would it effect the users?
- Is the estimated cost within a practical budget?
- How long would it take to implement?
- What are the risks involved in delivering the solution?
These are all great questions, and if you feel like we don’t really have enough information to look into the answers yet, you’re right! That’s why we need the requirements.
We’re going to transition from the pure analysis phase, and start considering that our solution will require computerised support. The point is to focus on ‘what’ is required, but not necessarily ‘how’ it will be done.
We’ll explore App-Makers’ requirements further in the next post.