“Keeping you up to date with everything software engineering!”

Managing Requirements in a Small Team

Question of the Week | September 20, 2004 | 14 comments

How do you manage requirements in a small development team? I am a one person team with no resources other then my trusty Powerbook (Apple laptop), Macromedia Dreamweaver, Notepad and Microsoft Office. How would you go about managing requirements?

Would you just keep a list of features/bugs in excel or would you use notepad? How about using a wiki? What information about each requirement would you keep? What happens when we add a person to the team... will your idea scale?

Maybe there is another solution I did not even consider. There must be. How do you manage your requirements?

----

If you have a problem that has been lingering in your mind and you would love to get feedback on it from your peers send it to john.kopanas [at] protose.org and we will feature it here.

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

September 21, 2004 09:56 AM | Ness commented:

Subversion/CVS && LaTeX.

You can build your output requirements file (pdf|ps|html|text) using the post-commit script in subversion so that after a commit you can publish the changed document right away online. You can also notify group members of changes to the document via automatically gennerated diffs.

The best part is being able to rollback without having the mess of multiple file names in some directory. It also tracks commits from multiple users.

This is what I plan on using for my 4th year project team. Try it out on a *nix system some time. You’ll never go back.

September 21, 2004 01:16 PM | John Jonathan Kopanas commented:

I can see how you would use Subversion/CVS & LaTeX to keep track of your development efforts i.e. what has been done. But how can you use it to keep track of what you plan on doing in the future including the priority of each feature/bug and who is responsible for it?

September 21, 2004 02:18 PM | Mark Pavlidis commented:

For feature/bug tracking Bugzilla (http://www.bugzilla.org) is ideal for groups small and large. It it easy to setup and runs on most platforms (some issues with Windows setups).

September 22, 2004 11:12 AM | John Kopanas commented:

I just received “Requiremetns-Led Project Management: Discovering David’s Slingshot” by Suzanne and James Robertson in the mail to review for Protose. Maybe I will get some good suggestions in there to write about.

September 22, 2004 11:23 AM | John Kopanas commented:

For my last project I maintained an Excel spreadhsheet with 3 sheets: To Do, Done, Future Versions. Anything I needed to do for the present iteration of the product I put on the “To Do” list, anything that was complete I moved to the “Done” sheet and anything that needed to be done but during a future iteration or was a good idea for a future version we put on the “Future Versions” sheet.

Each Excel spreadsheet had the following columns:

• Module
• Title/Description
• Priority (1-5)
• Assigned To
• Time To Complete (0D 0M)
• Status

It worked for me and looking back it did not have any major flaws that I could think of, the only feature that would of been nice was search and more detailed information when need be.

At the end of the day I would forward the excel spreadsheet to everyone so everyone knew exactly what has been done and what was left to do.

Does anyone else use any old school methods?

September 22, 2004 11:37 AM | Ness commented:

What if you are looking at a stale document? There appears to be only one update nightly of the document and only ONE person is able to make changes.

Any spreadsheet solution (excel, OOo, etc) does not seem to scale in my mind. It might work for 1-3 people, but after 5 people - all working on different parts of the project - I think the groups productivity is hindered as they must wait to take new actions as the document is updated.

September 22, 2004 11:50 AM | Ness commented:

lol… Old school methods would be updating your ~/.plan file. If you don’t know what that is, don’t worry about it.

September 22, 2004 06:13 PM | John Jonathan Kopanas commented:

I guess we have to ask ourselves first what are the requirements for a system that maintains your requirements :-)? And we also have to ask ourselves if each requirement makes managing of requirements better or worse?

Questions I ask myself:

• do we really need to have a real-time list of requirements?
• is being able to have more then one person able to manage requirements a good thing?
• by having a more scalable system that reduces the amount of communication that goes on between manager and implementer will that be a good thing or a bad thing?

Requirements to me have always been the part the worst managed of the software process. Part of me thinks it is because it is not just a technical problem but a social problem and we are just trying to solve the technical side of it without considering the social side.

September 24, 2004 04:26 PM | Baron Lam commented:

Sure version control, LaTeX, wiki’s, or any other pre-built technologies will scale and help you keep organized in a project. What you have to keep in mind though is costs versus benefits. John’s problem is that he’s working in a small (I define that to be ~5 people) team with limited resources on his Powerbook - teams are small, no box for using as a server, etc. Chances are, the projects that the team works on are not sufficiently large and may not need any fancy versioning system or real-time collaborative workspaces.

If every member of the team is not already familiar with the technologies you use, the time spent in setting up the system, training staff to use software clients and even forcing staff learn new processes and ditch their habits tends to cause lost productivity and more headaches for the team lead…

September 26, 2004 04:24 PM | John Kopanas commented:

I agree we have to choose solutions that the team can adopt that will not cost more then what is gained. But isn’t it the Team Lead’s job to make sure that processes are in place that will allow the team to perform to the best of their abilities? Also, is the claim that we can not put processes in place and do proper requirements gathering due to time contraints the common excuse people use a the beginning of a project that eventually fails? :-)

I also hope that any CASE Tool maker that offers a tool that is harder to use then the benefits that are gained from using them will go bankrupt.

I also wonder why people think Version Control is a tool for requirements engineers?

September 27, 2004 09:03 AM | Mark Pavlidis commented:

Version control is a form of tracability. Just like you need to trace a requirement to design to implementation, you need to track the changes of it as well because software is ever evolving. Traceability is a check for consistency, but if the consistency is broken were do you go? VC control lets you look back and roll back as necessary. This is a very powerful tool, regardless if you are writing requirements or code.

Formalized requirements can be looked at as another piece of code, only in another language that cannot (as yet) be completely interpreted by a computer. This parallel might make VC more attractive to those that do requirements but don’t see the benefit. Personally, whether you write code, requirements, or fiction, version control is a tool you need to use to increase the quality and productivity of your work.

September 28, 2004 09:12 AM | John Kopanas commented:

I knew I forgt about something. Traceability :-).

I definetly agree all projects should use VC (not venture capital but version control but venture capital can never hurt… well it can but I won’t get into that now). I think more universities should incorporate it into their labs. I know at my university we did not cover it at all. Did you guys use it at your university?

September 28, 2004 10:54 AM | mcs commented:

Old School method: Paper and pencil or if you are lucky,a white board.

Ness, your thinking big (which is not a bad thing), but in a IDEAL situation (as I see it), you should be able to havea mix of stale and ‘fresh’ requirements. The requirements should not change once you get through the discovery process, its alright for this list to be stale.

As Lam was getting too it all comes down to a management-trust philosophy. Where I’m working right now, they say ‘do this by this date’. And don’t ask for nightly checking.

And this concludes my ‘Me too’ post.

September 28, 2004 01:05 PM | Ness commented:

I even use version control when I am the only developer.

The log files (if they contain enough info) create a story about how the development of a project. It can remind you about design decisions. I have an old assembly project posted on my website. The logs help me walk through my development and refresh my memory, that would be if I had to maintain it.

We are using Subversion this year for our 4th year Digital Controls class. Thesis/Project Class allows you to decide what RCS you want to use, but encourages you do pick one.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)