I was curious what tools you’ve used. I’ve used all but #5 on different projects with different companies. And from my experience too, something like #5 would be ideal. Also completely agree about process approach, and would add that even if all companies used that magic tool, each team/company would need a different process.

I don’t know of a solution that has all the elements of #5 either. I’m hoping someone will chime in… I don’t have time to build it at the moment.

The ideal tool that you describe sure sounds like the right one. I am not aware of such a tool and will be interetsed to learn if one exists. But I do want to emphasize that, IMHO, the tool alone is not enough – not even your ideal tool. Two more major factors must be taken care of:

1. Put the right process around the tool. Without the process, the tool will be used in an uncontrolled way, resulting in chaos.
2. Get all team memebers into the habit of using the tool routinely according to the process. Without that, the beautiful tool will be there to collect dust…

Sounds like a good approach. I’ve been on a couple projects where the “our dev team is idle” pressure continues to bear down on the requirements team. It would have been great to have a PM on that project who served to keep the prioritization as you have.

Having the implementation team “in the loop” about the SRS definitely helps too, and allows people to get started. It introduces a risk, but that risk is easily mitigated with either experienced developers/testers, or coaching from someone experienced. In my experience, it has only been an issue when folks were brand new (“But the spec used to say….

How do you keep the implementation team informed on the doc as it is under development? I’ve seen a few different approaches:

1. Central, versioned doc server like sharepoint
2. Source control, like subversion
3. Central file location (shared drive) and ideally file versioning
4. Distributed file ownership and emailed “fyi” versions
5. Alternative, collaborative presentation (online, multiuser docs)
6. Structured requirements repository like CaliberRM

I believe any team can make any of the approaches work, but with tradeoffs. I’d like to have a collaborative online/offline available solution, with RSS updates to stakeholders (instead of “hey, I updated this” emails) and integrated approvals. Anyone know of something that has all of that?

Thanks again,
Scott

In answer to your question, yes, it is possible that the implementation team will start implemetation while the first version is being written.

The most important thing here is to manage the inherent risk in this approach, namely, that the engineers will implement something that will later conflict with the SRS. To minimize the risk, I try to do the following:
* Make sure that writing of the SRS is not delayed because everybody is “busy implementing”. In other words, although implementation starts while the SRS is still being written, the SRS is the higher priority, not the other way around. This ensures that the SRS will become available ASAP, hopefully before the engineers have moved to far ahead.
* Make sure that the implementors are closely involved with the SRS development from the start. That is, the engineers participate in the development of the SRS. This way they know early on what the SRS is going to say so that they already know what to implement even though the SRS is not yet “released”.

Cheers.

Thanks very much for reading and commenting!

I think your idea, get something, then make it good, is a good one. I think the dynamic that affects writers with a blank sheet of paper is the same one that affects people new to writing requirements / specs. More experienced people can immediately start jotting down an outline that captures elements of the SRS and then fill it out. “Getting started” can definitely be overwhelming for folks who are less comfortable writing specs.

A question – when scheduling the activities of the rest of the team, specifically the implementation team and other stakeholders of the SRS – do you get them started on the “something” version, allowing them to work in parallel with the revision/improvement of the SRS? Or do you wait until there SRS is “ready?” Or something in between?

Thanks again,
Scott

The problem that I encounter a lot in my experiemce as a SW PM is that the people who need to write the SRS are not at all skilled at it. It is a struggle to even get them committed to do it and when they do, the quality is usually poor.

I found it useful to work with them in 2 stages: 1. Start with something minimal. 2. Evolve the doc over time to a full, formal spec. For this 2nd part, your article is very useful and I will direct my team members to it.

I have just written about this topic is my blog: (http://mosgot.blogspot.com/2006/11/software-requirements-specification-is.html).

Thank you.

If the alleged requirement does anything more than state the goal, it is always logically possible to satisfy the goal in another way. Yet if it is possible to achieve the goal without the alleged requirement, it isn’t a requirement. Therefore, the requirement isn’t something that achieves the goal, it is goal.

(We could get into dicey issues about nomological and other forms of possibility, but I think the practical conclusion will end up being the same.)

That’s why I define “requirement” as the least stringent condition that must hold to solve or avoid a prospect problem. The goal is to solve or avoid the problem. Nothing more. The goal is the requirement.