General discussion


Requirements management best practices

By hoghat ·
I work for a large company with a fairly informal software development process, especially in the area of requirement gathering/management. I would like to hear how others perform their requirements management. I would appreciate any information about how you gather requirements, how they are maintained & tracked, how they relate to the project development lifecycle, and any tools you might use for requirements management.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Borland's ALM Solution

by acoomer In reply to Requirements management b ...


I would simply like to route you to the ultimate solution to your problem. Please take the time to look at and read on Borland's tools for Requirements Definition Management and Requiremenmts Management.

If you have any questions in this regard, feel free to contact me as your problem is one of our focus areas of expertise.

Collapse -

Take a look at Compuware's Optimal Trace

by sparma123 In reply to Borland's ALM Solution

Borland ALM the Ultimate!? I am consultant in Telco programmes & ahve review the leading players including Doors, Niku, IBM Requisite Pro & Borland Steel Trace Compuware's Optimal Trace. The clear winner was Compuware's Optimal Trace / Steel Trace Reasons: best Micrsoft integration, easy of use, testing integration, MDA based code generation (we were able to generate Java code straight from the final MDA process models. Most important for us our analysts were able to operate in the field the business without being down to the network. As for Borland it's better than average but how just long will it be around? Borland look like they are verging on going bust.

Collapse -

Requirements Management Practices

by mehale In reply to Requirements management b ...

Hi. Here's how I've done requirements gathering and management in the past, for some fairly large claims-taking and claims-processing systems in eight different U.S. states. I've based my approach on the Rational method but have never found it necessary to actually use Rational Rose. That tool, I feel, is better used by the software development force. My end has always been just requirements so neither I nor anyone who's worked with me has found the expense of Rational Rose to be justifiable.

The requirements approach I've used has three phases. The first phase is intended to define the scope of the effort. It's very important to baseline the scope so the deliverable from this phase, which the Rational appraoch calls the "Vision Document" is something customer and consulting project managers sign. The document is then placed under a formal change control program. I've used a relatively simple Access database to record requested changes in scope and the decisions on them.

The second phase is more detailed requirements planning. The deliverables are almost always a use case model, a supplemental specification that addresses technical architecture issues, and a project glossary that defines critical business and technical terms that will provide the common vocabulary for the development effort. Sometimes, other deliveables include a high-level entity-relationship or data model, a simple prototype that does no more than document user interface requirements and allows simple navigation between screens, and supporting documents for those items. To keep track of the data requirements, I've used (again) a relatively simple Access database.

It's very important to keep in mind that the detailed requirements are the decisions made, by consulting and customer project managers for the next phase of the project: development. The objective of the next phase can be a prototype, the first iteration of the total system, or if the project is relatively small, the entire system. The second phase is controlled by the decisions made in the Vision Document. It can reflect changes (which are inevitable) but these should be documented by the change control process. At the end of the second phase, all of the deliverables are baselined and placed under change control. To reiterate: change control is supported by a relatively simple Access database.

The third phase is really the beginning of system development. Requirements will be refined as necessary, changes documented as required, and the project managed according to the successes or failures encountered along the way.

Here's how the first phase begins. I begin by drawing a box for subject matter experts who will convey their business and technical needs. The box symbolizes the system being designed (or the "system under consideration). I then lead a discussion about the high-level functional requirements for the system.

The set of high-level functional requirements become candidates for further development using the use-case modeling approach. How much detail will go into each use case model will depend on a variety of factors but the most important are project scope and project funding.

It's very important not to to try to define everything for the perfect system if your budget will only allow an incremental approach, something I've always understood to be a best-practice anyway. Also, the objective of the first phase is to scope the second phase.

A really great book to consult for help on doing use cases is Alistair Cockburn's "Writing Effective Use Cases". It's short, lucid, and packed full of practical advice on how to do this. I can't recommend that book highly enough. Pay attention to Mr. Cockburn's methodology for determing the correct level of detail for each project, as well.

I've done projects with hundreds of use cases. I've kept track of them using (there's a pattern here) a relatively simple Access database that contains high-level information about each use case and gives the status of each use case. The database has some built-in reports so status reporting is simplified.

How long phase two will take depends on project scope and project funding. The only useful benchmark I ever heard about use case modelling is, plan for about a use case a week. I've done more than that per week but it's largely a function of the level of detail being sought, the willingness of the group to make decisions, and how much money is really available.

Be prepared to deal with process change issues. I can just about guarantee you'll run into the need to address business process change on day one of the project. To prepare for that, ascertain ahead of time how much latitude the project will have to recommend something that could change existing business practices. Nothing stops a project faster than an idea whose time has not yet come--in the opinion of stakeholders. These issues are almost always never technical. Instead, they relate to uncertainty, spill-over effects of the project on external stakeholders, and perceptions that people have on the value of existing processes.

Finally, there will always be a bad day for the project. Requirements-gathering is mainly about making decisions in my experience. For a variety of reasons, people are either unable or unwilling to document specifications to the level where developmental risk is zero (or somewhere close to zero). The group will get frustrated. So, don't make the effort a dreary thing. It should be about planning innovations and becoming the most educated people in the company about how things are being done now, and how they may be done in the future.

Hope this helps.

Collapse -

some suggestions

by maggiewong In reply to Requirements management b ...

On the deliverables, we have a Requirement Specification to define customers' requirement and a Requirement Traceability Matrix to map contractual requirements, users requirements and later on, add the functional or design and testing items for traceability purpose.

Use Case modeling is a way capture user requirements.

Refer to CMMI's 2 process areas: requirement management and requirement development could help.

Collapse -

Optimal Trace UML

by sparma123 In reply to some suggestions

I think you are absolutely right, the use case architecture (if OMJ MDA compliant)provides a key to interlock development to business objectives. I have just posted my thoughts on the marketplace elsewhere in this discussion and integrated UML capabilities were high on our agenda and with Optimal Trace we were able to automatically convert Use Cases into Java code using OptimalJ and have traceability all the way back to end user business requirements.

Collapse -

Re: Requirements management best practices

by jblack In reply to Requirements management b ...

If you are looking for more information on Requirements Management, try this link:

Related Discussions

Related Forums