Let's look at how to deal with proposals that describe an app concept and how we can use them to extract the initial requirements. You may find yourself in this situation on a number of occasions.
Some common concerns include:
When it seems relatively simple and easy to grasp from the concept description what an app is supposed to look like and what functionalities it should have.
The concept description is in the very initial stages of development, the appearance and functionality aren’t completely set, and the plan is to work with other project participants to define the details along the way.
In either case, there are a couple stages of the concept description transformation we need to perform before we can start development:
Analyze the description and sketch out the interface and user flow. This may require collaboration with other participants and a couple of iterations.
Once the sketches are in, create mockups and proceed with the implementation.
Introducing the project
Concept description
In this course, we’ll work on “ListenUp!” which is an app that sources iTunes music in various categories. It will allow us to view the details of a selected item and redirect to iTunes for purchase if the user decides to explore more. It will also present the user with related swag for each music category and direct them to an external resource, should the user express interest.
Derived functionality
Let’s analyze the potential functionality starting with the interface and user flow:
As the app launches, we’ll display a list of music items and then let the user select a particular category.
Should the user want to know more about an item, we’ll display some details and present an option to navigate to iTunes.
And the last component - presenting related swag! We’ll develop a "smart" algorithm that will allow us to add a monetizing aspect to the app.
The look
Here's what it might look like:
Collaboration
While working through this process, remember to collaborate with other team members. Collaboration is more efficient when you offer proposed solutions and ask for feedback and advice.
Of course, it's not possible to know everything, and in fact, it's best to incorporate other peoples' skills and expertise rather than to avoid reaching out with a question for every shade of color or extra detailed functional description if it's easy to anticipate.
Use your common sense!
This is a good start - lots of new things to learn to accommodate these app requirements! We’ll continue in the next chapter!
Let's recap!
Requirements come in the form of description and mostly fall into two situations:
The concept is easy enough to interpret.
The design/development is in the very early stage, and the upcoming implementation is explorational and potentially temporary.
To interpret the requirements, use the following process:
Analyze the description and sketch out the interface and user flow.
Create mockups.
Proceed with the implementation.
Collaborate with other participants in the project, presenting your solutions and seeking feedback and advice.
