Planning the functionality of a new project before beginning

Question

I'm starting to learn more about software development, I'm still learning it, so some things are still difficult for me. Also, just to put in context, most (or basically all) of my projects are online projects (WebApps, e-commerce, crm, etc ...).

I was reading more about how to plan a project before starting it but I had some doubts and did not find an answer. First of all, I know we should not spend too much time planning, or planning too deep on the project, because things can (and will) change during the development phase, but at least the core concept of the project must be well defined.

So, basically my doubt is about breaking and planning these core concepts of the project. On the subject I was reading, it was recommended to create some apps within the big scope of the project, eachapp representing an individual area of the main project. Then, for each app I should start breaking it intostories, which represent basic functionality that users can perform within that app.

Sorry if I'm missing any term or getting it completely wrong, this is why I'm asking.

So, to give an example, let's say I have a delivery website, so I would have these apps:

• User information;
• User address;
• User favorites;
• User purchase history;

Then for a single app I would have some stories, for example, on the address:

• Add address;
• Get location from postal code;
• Get GoogleMaps coords based on full address;
• Edit address;
• Remove address;

These would be the functionalities I would need to develop for this app.

---

This whole concept seems a little redundant for me, as it's quite obvious to be a reason to spend some time planning. But also I see why it's important to guide thoughts during the development process.

But is this thinking correct? I'm following the correct path? Or is there something I'm missing/or should be considering when planning a new project?

Answer 1

It almost always depends on the project.

In a well scoped out library, say a parser. It would be a huge help to think out every single part of the library, going real deep into "How would the parser track lines/columns and how would a scope be able to access it" don't just sit down and start typing, you would spec the thing to death, doing it this way is really fun and easy to program(all you have to do is type, no thinking on the fly).

However in a website or app you really can't do this because like you said it always changes, and unless your on a team, laying out each feature and sub function(apps, and stories?) is just a reminder of what do to. What you really should plan out is a non changing generic foundation functions or rule sets. For instance in an e-commerce site, you have the basic intuitive things like, user addresses, credit cards, shipping trackers, etc, but what you should plan out is how these details work, like what would happen when a shipping address was wrong but the item was already shipped out, or if an item detail was wrong, now you have to have your system check for any orders that happened before the detail fix and send an email to the customers. Things like these need to be examined and sorted before you start your system because sometimes something you think wont matter if you add it in later will end up making you change the entire thing.

Now of course this is all based on my experience and opinion, but from the times I applied this simple planning, it made the development process much smoother, far from perfect but far fewer bugs and rethinks.

Hope this helps.

Answer 2

You seem to be confusing requirements with design. You do not plan for requirements, you look at requirements (wishes, demands, needed features) and then make up a technical plan that addresses those requirements.

You do not make an 'app' or whatever technical unit to implement a requirement. You try to recognize the bigger logic behind the loose collection of requirements and then build something. Like when many requirents are about user data, you probably want to maintain a collection of user objects and be able to store them somehow. Then you make your user data store. This will lead to a design that fits your problem domain. Surprises may still pop up, forcing you to rethink your design, but with a few requirements you should be able to answer the question "what are we talking about here" and start working with that.

Answer 3

While the level of detail varies from project to project a specification and a road map are to my mind essential. This can be very formal or less so but should always follow a structure to ensure steps are not missing, as they are in your e-commerce example.

1. Statement of what the project is to fundamentally do: In the case of an e-Commerce Site this is to sell a commodity - Missing in your example
2. What must it do to achieve the above? Top level.
3. What must it not do, any regulatory constrains, etc.

Even at this level we can spot some things that your example misses like to sell something we need to have it available so we need a stock control module, if we are trading in goods that are restricted to specific ages or locations or forbidden in some we need to handle this, we need security to ensure we are not stolen from and that users data is safe - this will come out of step 3 in fairly short order.

This can be iterated over the desired number of times to get the required level of detail.

One we have decided what we need we are some way to defining acceptance criteria and we can start splitting the required and desired functionality into what we must have for a first release and what can be done later and we have both a specification and the beginnings of a plan.

Notice that a plan is not a schedule they are very different things despite what every project manager I have ever met says. From the plan and the specification estimation and scheduling can be generated but that is a very different skill set.