How do you prevent requirements from getting out of control?

Question

I'm interested in data/information/knowledge management, so I am building an application for this purpose in an effort to understand the concepts better. However, since I'm building this for myself (and perhaps for others in the future), I have to play the role of customer/client as well as requirements analyst (in addition to software engineer, quality assurance, tester, and more). This is leading to some problems as there are a large number of features I want, and I'm not sure how to manage them.

Should I track all requirements, and then decide what order to do them in, perhaps breaking them up into several releases? Or should I treat every feature (each has its own set of requirements) as a separate application that will be integrated? Or is there a third (or forth, fifth, or sixth) alternative that I am missing?

Answer 1

Are you looking for rules of thumb, or a statistical standard?

As far as projects go, the further apart your milestones are, the more likely the project is to fail.

Try separating them by priority for an initial release. Match the main purpose of your app to the absolute die-hard features that support that purpose, and take the lesser features and 'put them in the parking log' (as read in Getting Real).

If those other features really matter, you can tell because the need for that feature will arise several times while it's been parked.

Create short milestones. Get something out fast, and iterate on that.

If its going to be just you, then track them in a text file, or a set of tadalists.

I've found that if you're missing anything on a project like this, it's the willingness to let go of a feature. Establish a meaningful purpose and stick to it!

Bad features are like terrorists who want to wreck your app! Don't negotiate! :)

---

[edit:] Ilya brings up a good point, too, about establishing requirements. User cases, and user stories are an excellent way to ground a concept in reality. +1 for him.

Answer 2

I would recommend using the concept of User Stories to keep track of your requirements.

You work alone so it's easy for you to use physical cards for them. Write down your ideas on the post-it notes. Use a whiteboard separated into areas to organise them.

When you plan to do a new release pick up the stories you want and move them to the 'release' area. When you're planning a new iteration pick the ones from the release and move them to the iteration. When you've done an iteration tear the cards.

You could do the same thing with software like VersionOne but it might be an overkill for you.

Alternatively use Trac ticketing system. You could setup an integrated Wiki/Repository and plan for your application growth in advance

Answer 3

Get all your features together and write them down.

Then group the features into groups and find out in which ways they depend on each other.

After that you should be able to make out the most important aspects of getting the application do what it needs to do. You know, the elementary thing without which it would be a broken app. Start with that, ignore everything else (but keep it in mind when making long-reaching decisions) until you finished this part.

Once you reached a stable v1.0, go through the priority list again and find the next three you want to be working on. These will be different items than you initially thought.

So, build it step-by-step and your first step is to just make the basics work. After each step re-prioritize. I think you can call this Agile Development even if you do all by yourself.

Answer 4

Here's what I do at my shop:

Determine what the customer really wants and needs based on the requirements.

Translate those requirements into a set of tasks to accomplish such that a working product (though not necessarily fully implemented) can be released at intervals. We use a 30 day iteration cycle typically. The tasks are mapped to an iteration.

When requirements change or new ones are added (and this will happen), we renegotiate the future iterations and determine the impact of X requirement and when the task that accomplish this will show up. The customer is free to make requirements changes as they see fit - it is, after all, their product. But they also are made to realize that requirements translate into change and change has to be managed.

We don't shy away from new requirements, but we don't let them become priority 1 simply because they are the newest desire of the customer. Communication is key.