Initial Planning – requirements

During the initial idea gathering process before Christmas, it became apparent that the project wouldn’t just be some JavaScript linked with a Watson Visual recognition service, in a simple web-page. In particular, there were several areas we would need to research before beginning development –

• Initial planning and Use-Cases – how will users actually use the application?
• Front-end Design and Framework
• Image Classification and getting a trainer data-set
• Node-RED and how the components will communicate

What does the application need to do?

The first thing we had to do before we even started anything else was think about how users will actually use our application. This would then define what the application needs to do – since ‘front-end application that allows users to input an image and see whether it has habitation or not’ is a bit vague.

However, who are the users? IBM Employees? Missing Maps volunteers? We also had many other questions, such as:

• Where are the images from? Are they from OpenStreetMap, or somewhere else?
• What sizes are the images? Is there some standard size?
• What level of detail should our classifier classify? E.g. should the classifier draw outlines of buildings, or even identify what type of building it is?

In total we had a lot of questions so we met with John, who had come forward from IBM with the project call, and he answered all of them.

The users were members of the public, so anyone could be using our application to classify images. With the rest of the information from the questions, we set about to develop some use-cases – how those members of the public may typically use the application.

Use-Cases / User Stories

For an agile methodology, which is what we are employing for the development of our project, Users Stories are a pretty standard way of getting the requirements for a system.

They should be short, simple, and easily testable. We started out by defining some epics some as:

As a user, I can click on a button to upload an image to the application, through choosing an image from my file-system. A loading bar tells me how long the image will take to upload. Once they are uploaded and I am sure I have chosen the right image, I click the submit button to submit it to the image classifier.

And then broke it down into smaller stories such as:

I can press the “Upload image” to open a pop-up window that allows me to navigate through my file system.

When it comes to testing the application later down the line, we can just press the upload image button and if it does what it says here then we’ve fulfilled 1 requirement. That way its easier to know when the application actually works as intended.

Since we used a more agile methodology, later down the line we didn’t really stick to rigorous requirements, just a well-defined idea of what the project should do.

Setting up other things

Part of the initial planning stage was also to set up things like a document respository, a version control repository etc. These things we had learned last term as part of a module, so we were better prepared when it came to this stuff.

We chose Github to host our repository, which is widely-used and we had prior experience with. Google Drive as a document repository is pretty good, since we can also edit documents at the same time, and is easy to navigate. Furthermore, to set up this blog, John suggested WordPress. There’s also Blogspot, but I opted against it since WordPress just seemed better and more suitable for the project.

With the repositories all set up, and the requirements for the application better defined, we set about to determine other important parts, such as the interface design, what JavaScript framework we would use, etc, which I will detail in the next post.

Thanks for reading 🙂