Okay, let’s start by reading a few statements and count how many you’ve experienced before.
- Working past the budget limit
- Missing a deadline
- Seeing a developer complain, maybe be depressed or even leave the company
- The final app is not how you wanted/imagined it.
- Feeling cheated by your own developement team
- Asking for a bug fix, being told it’s a change request / new feature.
Alright, pretty straightforward. The number of items that apply to your past experiences, even the slightest, is the number of times you should read this article. Let’s get right into it and talk about why you need an analysis ; and you do, trust me.
As a general rule, think of yourself wanting to build a house. If you say “Yeah, I’d like a bathroom, two bedrooms, one office and a huge living room alright?”, don’t expect anything to be like you imagined it. When you build a house, you plan it. You and your architect want to be on the same page, as well as the architect and the builders, pipers, electricians, and so on and so forth.
When and only when everyone agrees and understand what you want, written and drawn on paper, only then will you start laying down bricks. Why not plan an actual software development the same way ?
There are software architects, analysts and developers for a reason.
You’ll avoid surprises
Imagine an app that displays a contact list. Do you have an index on the right side? Is it scrollable so you can swipe really fast through the different letters? Does it always show the 26 letters or just the ones that hold contacts? It might come as a surprise to you, but if you did not ask for it, it’s not gonna be done. It’s considered a feature, it requires time to implement (wether it’s 5 minutes or 30 days is irrelevant), and you can not assume that it’s standard, ever. You must decide beforehand if it has to be implemented or not. Once you have everything defined in the analysis, there can be no surprise, because the feature was either there or it wasn’t.
In software development, every feature is custom.
It will decrease overhead and confusion (time and cost)
Knowing what you want is nice, but the developer you talked to probably imagined something slightly different. The more you speak with each other, the more the developer understands exactly what you want. The analysis is the ultimate (written) version of your app, and not some distant cousin of it. This is why it will take days, if not weeks depending on the complexity of the app. During those days, you and the analysts will spend a lot of time writing down details, sending them back for approval/questioning, then do it again until everything is covered. It’s a lot of back and forth that is useful for you to make sure everything is clearly defined. It’s not only helpful to the developer, but also to you, and really get your head around every detail of your app.
He who is failing to plan, is planning to fail. –Winston Churchill
Without the analysis, you would spend a huge amount of overhead time arguing what should be done and what shouldn’t. That time should be spent before development, with a clear state of mind, and a much less stressful environment. Not having an analysis means everyone will undoubtably end up angry and unhappy! Don’t forget that the closer you get to the release, the more stressful everyone feels ; don’t add another layer of unplanned stress on top of that.
Most (or all) the scenarios are known
In an ideal world, once the analysis is written, the developers could finish the app without asking a single question. But everything is not always covered, it’s a best effort to get as close as possible to the 100% possible scenarios, and there always is something that everyone misses. It’s okay, if we all missed it it’s probably a very specific scenario that is easily overlooked, but just as easy to adapt to.
Let’s imagine we’re building a simple chat app. Here are some questions that I would ask right away :
- Do you want url formatting in your chat (color urls and make them clickable) ?
- Can we send to multiple contacts?
- Do we allow attachments?
And I can go on, and on, and on. Just because you asked for a “standard messaging system”, I came up with about 30 questions, just of the top of my head, and that doesn’t even cover half of it. It actually covers basically nothing if you consider all the technical questions one could ask. It’s of paramount importance to have a precise analysis of every feature, scenario, and possible outcome and situation the user can experience.
An analysis gets things done faster, better, stronger, just by taking the time needed before the development instead of after. We’re not talking about a short bullet-point list of the 4 features you want, but a multi pages document that has every answer to every question about your app. You will be told, with some level of accuracy (as accurate as the analysis is), that the project will take X weeks to develop, so you can expect a beta on your phone between week X and Y. Awesome.
It’s far cheaper and faster to change the analysis rather than rewriting code.
This step is just one step of a project, which you can look up on our blog, and is very important. The project is much more than just the development ; its analysis is as important and cannot be ignored. It’s a mandatory step that requires focus, discipline, and time.