Project design / specification critique, is this the right idea?

Question

Hi,

Say we are creating Acme CMS. This CMS web application will allow you to create an unlimited number of categories with sub-categories (unlimited depth), and each category can have 0+ content pages associated with it.

So this project, at a high level will have:

Front End 1. index page 2. category page with list of content pages 3. content page

Admin Control Panel 1. categories (add/update/delete) 2. pages (add/update/delete/)

Schema design 1. tables 2. stored procedures 3. data access layer

Questions: I am using a bug tracker and Wiki, so how should I break this project down?

I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme).

When I have the user stories completed, I will then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one.

Am I breaking down this project properly? Any major gaps in planning that will make this project fail (in theory anyway!)

Please provide a detailed answer, maybe a general idea of what I should do, with a detailed example explaining it and why etc.

Answer 1

The "unlimited" part is broken... even GMail has an upper limit...

Edit: Although my answer got downvoted I think it is right. As soon as you talk with non-programmers the "unlimite" parts become very dangerous, and will likely stab you in the back. Also you can't really have a scalable data schema for unlimited nesting... but that should be obvious.

Answer 2

"I am thinking of breaking each section (front end/ admin panel) down into individual pages, then writing simple user stories for each page (or theme)."

Pages don't have stories. Users have stories. Pages are a thing you build to implement the user story.

The Theme -- if there is one for something this small -- is "managing content". Perhaps there are two themes: the collection of stories about writing/editing and the story(s) around browsing/reading.

Some users ('editors'?) want to create, organize, update and remove content so they can something [the question doesn't say]. You force them to use web pages because it's better - cheaper - faster than 5x8 cards and markers.

Some users ('readers'?) want to examine content and navigate so they can -- who knows? -- be happier and more productive at something. You force them to use web pages because it's somehow better than 5x8 cards held to a whiteboard with magnets.

You have stories about the theme of creating and managing content.

"then create a list of cases in my bug tracker representing features that I have to develop, along with an estimate for each one"

Right. And the features have to begin with data model first, then presentation in some useful form. Perhaps on pages. Indeed, once you have a model that satisfies the use cases in a broad way, you can fine-tune the presentation to make the model more usable.

"business layer & presentation is what I need to detail"

Model == business layer. They're the same thing.

Pages == presentation. Note. This is last. Once you have use cases and a model that supports those use cases, you can present your stuff to people so they can interact with the model.

Answer 3

As far as I can see you've got a few glaring gaps in your design, part of the features is implied (linking of categories and pages) and some are left out altogether (login for administrators, user management, preview etc). These are going to make up about half of your small application, and you better include them into the initial outline. Perhaps you may want to take a more systematic approach to designing the CMS. And there are at least three general routes you could take:

1. Design a domain model first, and then design business layer, then UI and data model.

2. Start with data model and build business layer and UI on top of it.

3. Model the UI first, then everything else.

Regardless of which path you would prefer to take (or combination of) there are some general guidelines:

1. Start with a big picture of work you want to automate. This is called “work scope”. “Big picture” here can be meant quite literally and although it can be a just a story describing the process, it is best to visualise using a rich picture that includes actions, artefacts, other applications, users etc. As for the “big” part of the equation the picture needs to encompass more than the intended product, be bigger than the segment of work you want to automate.

2. Then outline what specific work you want your product to take care of. This is usually referred to as “product scope”.

3. Make a list of user roles (or profiles) for your application, list of inputs and outputs, list of external interfaces.

4. Now you may want to start writing some user stories. You’ll need at least one per user profile, since you need to provide an illustration of all user perspectives.

5. At this point there going to be just enough information at your disposal to start a more precise modelling of the problem using either domain model, or UI model or data model, whichever you fancy or feel more comfortable with.

All of the steps are very much iterative. Once you understand a bit more about the application, its wider context and have a list of features that need to be implemented to meet the requirements you’d be in the position to give some very rough estimates and then go through a prioritisation process.

Needless to say that this is just a simplified framework and many software developers would take a different approach to designing an app, depending on their skills, needs, preferences etc. But it could be a good starting point to a more systematic evaluation of the problem you want to solve.