Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

BAs in my company use Word, Excel and Visio for requirements definition reasonably well.

What are the key advantages and disadvantages of using a requirements tool instead?

share|improve this question

closed as too broad by gnat, GlenH7, MichaelT Nov 16 '15 at 16:43

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

I use a hammer for everything, reasonably well. What is the point of using other tools? – Piskvor Aug 9 '12 at 10:25
@Piskvor then maybe you can explain the key advantages you see in using those tools. – Simon Aug 9 '12 at 10:28
@Simon Piskvor already did … – Jarrod Roberson Aug 9 '12 at 12:01
use a common repository to access and version your requirements. TFS and SharePoint with visio in office suit should do be all you need for Microsoft shop. – Yusubov Aug 9 '12 at 12:30

I've found that you don't, to put it simply.

A requirements tool is a bit like a bug tracker for specification documents, instead of a spreadsheet of points, you'd store the excel rows in the tool instead. So far, you might as well use a big tracker for this!

Requirements tools then add a lot of complexity to the system, references between requirements are added that are supposed to help, but unless you only have a few, you quickly get into a mess. If you have a list of requirements in Excel then you're already managing requirements well, so the reference features of a req tracker is an unnecessary distraction for you.

What these things do for you that is useful is to allow modification and traceability of the implemented requirement through the software development/delivery cycle. So when software is written code checkins are associated with the requirement, when it is tested, it gets associated with the requirement, when software is built the list of requirements in that software is listed, etc. Obviously this means your workflow has to be much more rigorously controlled - you cannot do anything outside the process, or the whole point of using the tool is invalidated.

There are lighter-weight requirements trackers like Polarion, these are much better than the complicated old tools like doors which I would avoid like the plague - unless you have very expert analysts used to using such things.

The biggest disadvantage of a requirements tracker is that it stops your BAs from working with the requirements and makes them work with the tool instead. When we tried it, we went from a 2-man BA team to needing 10, the tool slowed things down so much we junked it. (mind you, this was an "enterprise" tool that was 100% pants).

share|improve this answer
"Having a list of requirements" != "managing requirements well". If you can't trace a requirement from analysis through design and down to the test plan, you can't prove you've actually implemented it. Many (most?) projects don't need that level of rigor, but please don't claim that collecting requirements in a spreadsheet or on a wiki constitutes "managing" them. You've corralled them, but until they're traceable they aren't managed. – TMN Aug 9 '12 at 11:50
I have seen spreadsheets with requirements listed, with columns for their current implementation status (eg config, dev required, not used etc), and other columns providing status of that requirement - eg, dev complete, test complete, delivery version, etc. A tool helps trace it, and provides granularity but often that granularity is a lot of trouble to maintain. If you need to do it, its part of why government and defence systems cost so much as it slows you down tremendously. – gbjbaanb Aug 9 '12 at 21:59

Requirement Management means mostly

  • tracking of requirements: what status has a certain requirement, who changed it? how did it look last week? who is the stakeholder?
  • tracing requirements: what results of this requirement? how is this requirement tested? what are the impacts, if we need to change this requirement
  • reviewing of requirements: who approved this requirement in which state?

For easy tasks you can use MS Office, but if you have more than a single specification and if documents tend to be larger than 10 pages, you should use a dedicated tool. no single question I noted above can be solved by using MS Office, also Office Documents are not searchable, you cannot refer to parts of other documents easily, no version control(baselining) and working in a team on a single document is more or less impossible.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.