I wrote previously about an approach that I have used to manage requirements. Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…
As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders. Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.
So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3). You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others). Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.
In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time. A document management system (such as Alfresco) is an ideal tool for this purpose.
You may ask — “but why not use a source code control system like Subversion or CVS?” The simple answer is “they are not the right tools”. Source code control systems are designed to help multiple people work on source code files that often overlap with one another. Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together. In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases. In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.
By contrast, a document management system is designed for editing, sharing, and managing “documents”. It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach. A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others. (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person? If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)
In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”. (Apologies if this seems redundant.)
You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements. You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature. You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.
You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons: (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later. You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.
You could plan each software release using a spreadsheet — but why would you want to? Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs? And even if you want to operate this way — do you really have the time? Or are you assuming that you will get each release planned perfectly the first time?
This is where an issue tracking system (such as Jira) can (help) keep you sane. You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system. You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system. So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.
You are almost done — all you need now is a “plan” for this release. If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker. Update it regularly (I suggest weekly) and provide copies to all team members. (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)
If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.
That’s all for now. I hope this has been helpful. As always, comments or questions are welcome.