There is a set of SW practices that I consider non-negotiable, and they begin with 2 that are requirements-related:
1. Written, reviewed, approved requirements
2. A requirements baseline, implemented with a requirements management (RM) tool
In my last company, getting these done in a way that was accepted by engineers and management alike did require a pinch of “writing the requirements spec ourselves” and a dash of “entering the spec into the RM baseline and doing the updates ourselves”. That the CTO and I (the VP) were willing to do that work shows how important we deemed it as well as how easy our RM tool was to use (we used DOORS®).
Many companies assign the spec writing task to Product Marketing (PM), and this is a fine place for it if there is someone there committed to do it “right”. We often had good specs from PM at our company. But sometimes there was information needed by engineering that was more easily discovered and input by one of us. This partnership between PM and the CTO/VP served us well.
The fact that our engineers wouldn’t work on a requirement until the spec was updated in the DOORS® baseline is testament to how important the engineers felt this practice was (whether for the project or for themselves is almost irrelevant) and how well they bought in.
Management too (including Marketing, Sales, everyone) accepted this process and knew that there was no way any feature would be implemented unless it appeared in the DOORS® baseline, either initially or by the formal change process.
These requirement practices were made easier by the use of a formal RM tool, and I can’t stress enough the importance of having one of these. Yes, RM tools can be expensive, but if you do the cost/benefit tradeoff, buying one will win. There are open-source tools that might take more staff-power to implement than a commercial one, but that would still be preferable to trying to manipulate a word-processing or spreadsheet application into serving this role.
The primary reason you need a formal RM tool is its ability to create attribute categories and assign attribute values for individual requirement objects. We created attributes for the assigned release, test information (needs testing, was tested, when tested, etc.), and change tracking (links into our change tracking tool). The release assignment (per requirement object) meant that we could maintain a single spec for a feature or product and not spec fragments per release. This might not seem important as you create version 1 and even version 2 of your product, but when you get to version 5 or 6, trust me, you’ll wish you had some single requirements document that described the whole product.
A second important benefit of an RM tool is the history it keeps (per requirement object). Tracing back the reason for changes can save tons of time later in research.
But, if you are just starting out with a tiny team and don’t have the time, energy, focus, money, etc. to acquire and use a formal RM tool, more important is to get the requirements written, in something, and stored away somewhere accessible to everyone but changeable only by you. An RM tool can come later. You’ll know when you need it, and remember, it’s never too late to move to it.
These 2 requirement practices passed the “practicality” test. Everyone understood their value, everyone bought into them, they had evangelists, and we made it all easy to implement.
Anita Wotiz
www.duckpondsoftware.com (see the Consulting tab)
Instructor, UCSC Extension in Silicon Valley
Software Requirements Engineering and Management (next class Aug 2009)
Software Project Planning, Monitoring, and Management (next class Oct/Nov 2009)
I agree with Anita, but a RM tool doesn’t have to be expensive. You don’t need a heavyweight tool like Doors to achieve the capabilities outlined above. I work with Artifact Software, (http://www.artifactsoftware.com/products/Requirements-Management.html), and we have an affordable web-based tool that delivers the above capability, but there are also others in the marketplace.
Maybe several years ago your only alternative was to spend five or six figures on a RM tool. However, with affordable alternatives available I don’t see why anyone would still be using Word and Excel to manage requirements when there is such a great benefit to having change requests, history, and requirements in a structured format. Is there anything more painful than trying to achieve traceability with “integrated” Word docs and spreadsheets…
Thanks for the article,
-Derek
Yes, I love that there are cost-effective alternatives out there now. Thanks for the reference to this product.
You’re right – there’s really no reason to use Word or Excel, except inertia.
Personally I wouldn’t go that far to treat “baseline, implemented with a requirements management (RM) tool” as non-negotiable practice. While of course change management is crucial to project success in small projects it can be done on a whiteboard or project manager mind.
Personally I’ve seen pretty big projects which did well in terms of change management with no support from dedicated application whatsoever. The key to success was there was a project manager who went deep into details of project scope. She was able to instantly answer questions what has been changed and more or less when. Being a project manager she was also in charge of making decisions about scope change so she could discuss subject with the client with practically no support from other team members.
Of course it’s not very common to see so deep engagement into the project even from project managers but that makes me considering RM tool not as a non-negotiable but rather as an team-specific.
Certainly I’ve been on teams that succeeded because of the team members. But I believe that a purpose of project management is to put predictability into software development, and relying on a single person doesn’t give you that.
I was also a one-member team on an IT project when I was very young that involved a modification to a device driver. I implemented and tested the change, and commented the code. Two years later I was asked about it because they needed to upgrade the driver again. I wasn’t much help. I hadn’t written down the rationale for my decisions in the comments.
If the product’s lifecycle or its development spans any reasonable amount of time at all, the whiteboard information should be placed in a Word processing application and changed as the requirements change. I believe that is the most important thing that a project manager can do.
I don’t say that having a team member who knows everything is (or should be) an excuse to leave documentation aside. In mentioned project we had a very extensive documentation but actually detailed change tracking wasn’t covered very well.
From a perspective of time it’s not so important how requirements changed during project but what’s their final status. When people came back to a driver you had worked on earlier they didn’t care much what has been before your era I guess.
Don’t get me wrong – I don’t try to discourage anyone from change management (hell no!) or using RM tool. I just say that for me personally having a dedicated RM tool isn’t so important as I can see a couple of other good enough ideas which deal with the problem