Many project owners and even development agencies focus on functionality and technology when gathering requirements for a custom web or mobile application. The problem with technology driving the requirements is that it often results in user goals being implemented differently to conform to some requirement or lack of feature in the chosen technology.
A better approach is to focus on users first. What do the users want to achieve? Once all the user requirements have been established you can make technology choices to best meet those requirements.
Average Joe/Jane
First step is to establish who your average user is. For an eCommerce project you would likely have a specific demographic in mind that will be interested in your product. This will be the “visitor” and the “customer” user. You might be managing the platform from the admin interface for the application so you will be the “admin” user.
Put together a profile of your average users first, who are they, what are they looking for and why. This will help focus your research. Then you need to reach out to these kind of people. How you reach out will depend on your demographic. A web survey might work, an email, letter or even inviting a group of them to your office for 1 on 1 interviews. Whatever works best for your project and demographic.
Some key questions to consider for your target group:
- Would you use a service like X?
- Would you pay for it?
- Can we add your email to our invite list so we can give you early access?
- Are you currently using anything similar?
- What do you love/hate about that similar service?
- What is a must have feature for a service like X?
Most of these are typical marketing questions with the goal of validating your service first. Once it is validated (or if you have already done market research) you can focus on what a user expects from your platform.
User Requirements
Make sure to keep discussions with your users goal-oriented and not functional. It is perfectly acceptable for you to suggest requirements and then discuss with your target users. As long as you discuss and get confirmation. An assumed requirement is a bad requirement until it is validated.
Follow this format for your user requirements to ensure consistency and completeness:
As a [type of user],I want [a goal] so that [their reason].
Some examples for an eCommerce platform:
- As a visitor, I want a search to quickly find a specific product that I am looking for so that I don’t have to browse through lists of products I am not interested in.
- As a customer I want to be able to check-out quickly without registering so that I don’t want to have to create a new account for another website.
- As an admin i want to be able to export all sales so that I can import then into my accounting software.
Note that each requirement focusses on just 1 action or result. These are not long explanations that go over an entire page of features and breaking it down action by action helps to avoid missing anything. They also don’t need to go into too much detail, the goal should be clear as well as the reason but not every field and attribute needs to be included at this point.
Once you have collected, confirmed and documented all the user stories you will have a fairly strong big-picture view of the entire application. With these requirements you can make now make informed decisions on the best approach, platform and technologies for your project.