Comment:     by Clare Roberts 11/26/2004 Excellent comments - particularly those advocating a combination of searchable, traceable requirements held in a requirements tool supported by diagrams which set them in context. I can count many high profile projects where I as test manager have had wade through pages of text requirements and then have to ask the question: so is there a big picture of how the whole system hangs together and where the areas of functionality sit within it ? The reply all too often is 'no'. I then ask: If you don't have the big picture, then how should I (the test manager) check that nothing has been missed that the system will deliver what is needed ?...Read On
	Comment:     by Erik Petersen 10/13/2002 David, while you have now mentioned agile software development, it is clear that many of the system requirements discussed here are orders of magnitude beyond the "write-it-on-an-index-card" and Alistair Cockburn's "two-people-at-a-white-board" agile approach. If you were to undertake these projects on an agile basis, the little-step-by-little-step approach would very possibly be completely inadequate to handle the innate complexities of these larger systems. Also no one seems to have mentioned that market pressures and other forces can now mean that software may need to be delivered much earlier than intended, so the concept of testing to...Read On
	Comment:     by Malcolm Stenning 10/11/2002 David, As you know (from RESG, University College London, Oct-2002), over the last few years I have been developing hierarchical event driven use case modelling techniques for capturing requirements. Each use case having a clear goal with a scenario detailing how that goal must be met, avoiding solutions if at all possible (as that bits called design). I have found that using a hierarchy, does make the task of managing a large amount of requirements much more manageable. The decision on the use of databases or documents is from my point of view very simple, the database wins every time. If you want a hardcopy of all or some of your...Read On
	Comment:     by Robert E. Lee 10/11/2002 David, I think the volume of response and the desire for some give and take discussion suggest that this should be turned into a Roundtable discussion. The mechanics of the weekly column actively prevent a person from responding more than once to the article, so John Daugherty can't respond to your response with clarifications. The lifecycle and media of requirements seems particularly fruitful these days. Thanks! Bob Lee
	Comment:     by Judy Murphy 10/10/2002 I spent years developing 1000s of requirements for the space program. We had volumes of data and many requirements documents. All were created and managed manually - including traceability. That was all I knew until I left the space program. What I found in the business world horrified me. Forget requirements documents; forget requirements! I now work exclusively with Rational's RequistePro and I love it. It allows me to create requirements documents or requirements that reside only in a database. In either case, the requirements are in a database that can be sorted and filtered and reports can be generated. However, where organizations are...Read On Author's Response: 10/10/2002     Judy: You are clearly right that content quality matters much more than volume or packaging. A choice between a few good requirements in a document and many poorer requirements in a database is not really a choice at all. David Gelperin
	Comment:     by Joseph Dubowski 10/9/2002 Very good ideas floating around here. I am not at all familiar with the requirements tools (automated) on the market. I would like to say, though, that the attributes I would be looking for in a tool would facilitate ease of use, searchability along the lines that David brought up, traceability, redundancy checking, and change control. As any automated solution is going to, by nature, force a formal schema on the requirements, I suggest that the Planguage authored and championed by Tom Gilb in his book Competitive Engineering might be a helpful framework for writing requirements that can be supported by such a tool. - JB Dubowski
	Comment:     by Mahendra Gupta 10/8/2002 David, Certainly voluminous documentation for REQUIREMENTS generally arent of much help. But if we look back to the very purpose of documentation; it is to STREAMLINE the development process. Therefore, as an organization matures in terms of PROJECTS, these REQUIREMENTS documents also need to relooked & revised based on the types of Projects undertaken. Therefore documents can be categorised based on the type of projects undertaken. One of the other factors that affects these documents are the awareness of these documents that the end-user who is going to use it. Therefore, it makes more sense to draft these documents based on the end-users...Read On Author's Response: 10/10/2002     Mahendra: I am currently reading Alistair Cockburn's "Agile Software Development". As usual he writes beautifully and has many important things to say. If you are not familiar with the Agile Philosophy, I recommend this book. You may find some things difficult to accept, but I think this philosophy should be understood more widely. I bring all of this up because you comment that the purpose of documentation is to streamline the development process. Those in the Agile school would disagree. They would say that documentation slows down development. Important issues should be researched and debated and the appropriate role of documentation is one such issue. Thanks for your comment. David Gelperin
	Comment:     by April Anderson 10/8/2002 We recently used an Access database (customized and used on other projects) and utilized the Word Merge function to export the Requirment text fields into a Word document template. Once it was set up, some minimal configuration by some developers, it was great for updates and reviews. There were some limitations with several users acessing the same database, used a Microsoft share function to help eliminate that issue, but the database still needed to be locked for mass updates or creating new tables. Another limitation was version control. We have also tracked Requirement changes in a bug tracking tool which allowed us to follow through to...Read On Author's Response: 10/10/2002     April: Thanks for sharing the details of your experience. David Gelperin
	Comment:     by John Daughety 10/8/2002 Having worked in some companies with long, painful requirements documents and others with none at all, it seems I have constantly been thinking at some level about how to solve the problem of documenting them. While my tool of choice has ended up being a database, or Excel with hyperlinks when time is very short, the more important thing to me has been what to document. Many requirements documentation efforts become massive, time-sucking monsters because this question never gets asked. In my last company we were defining requirements for a feature in our product that supported DWDM Optical networking equipment. There ended up being...Read On Author's Response: 10/10/2002     John: Great comments. You provide so many insights, that I have attempted to summarize them below. Please straighten out my misunderstandings or omissions. 1) Concentrating on project objectives along with good judgment are necessary for developing just the right requirements. 2) Too many "requirements" can be worse than too few. 3) Some requirements information is best presented by diagrams. 4) Databases can be dangerous by inviting much more information than is necessary. 5) On the other hand, databases can be useful in hiding the total volume of information thereby aiding the iterative reviews used to validate the developing set of requirements. David Gelperin
	Comment:     by Diane Evans 10/8/2002 Ofer prat asked, " There are several requirements management tools in the market (e.g. Caliber RM). Does anyone has experience with these tools?" I can't imagine doing requirements analysis without the use of a requirements tool. Our company is currently evaluating CaliberRM and Rational RequisitePro. I really love CaliberRM. It allows me to define a requirement, show its relationship to other requirements, create attributes for requirements, and print out wonderful reports in Word. Let me give you an example: At a former company, we were evaluting two programs that were very different. For each requirement that we had gathered, I...Read On
	Comment:     by Peter Cornish 10/8/2002 David is baiting us on this one. As soon as requirements get somewhat complicated there are a number of other trends often associated. 1) Rate of requirement changes increases; 2) Number of authorized updaters increases. Both of these situations point towards a managed solution. If only we could all afford the cost of purchase, maintainance and training!
	Comment:     by Laura Murphy 10/8/2002 You are right about documents scaling up to spreadsheets and up from there to databases. We tried using full requirements management tools such as Rational's Requisite Pro when we were still too small a company to capitalize on its strengths. If the project and project team are too small, the labor involved in creating and maintaining a requirements database is disproportionate to the project budget and timeline. Also, unless all project disciplines are utilizing the database's capabilities, it is not cost effective. We downgraded to using straight word processing documents and found that worked better within the constraints of our company...Read On
	Comment:     by Clay Givens 10/8/2002 This is an interesting article about requirements aggregation and long windy documents. I totally agree that big unruly requirements doc's are a management nightmare. In my experience, 100+ page test requirement documents in word that frame the application under test into a very tight little box tend to be extremely time intensive for the benefit they provide. The problem is the requirement creep that is constantly occurring. The document maintenance is a total chore. I'm inherently lazy myself, so I like to rely on human intuition for much of my testing, but that's not all, I use a spreadsheet as a guide/checklist for things that require...Read On
	Comment:     by Andrew Raybould 10/8/2002 David, When any body of knowledge becomes too large to be held in the head at one time, it needs to be organized. A spreadsheet may be appropriate in some cases, but I have found that hypertext (which is itself a sort of database management system) to be very effective, especially for tracability (including to the design and implementation) and for capturing dependencies and other relationships.[para] The common idea (repeated below) that diagrams always beat text is simplistic. Diagrams are a good way to illustrate relationships, but they lack the expressive, explanatory, and (unless you are using existential graphs) reasoning power of...Read On
	Comment:     by Sam Shober 10/8/2002 While I was hopeful that the article would present a feasible method of displaying requirements data in a visual format, or possibly a process for documenting requirements without cumbersome documentation at all (pipedream), I think the concept of using a spread sheet or relational database is a wise one. It is prudent anytime you need to document functionality that involves multiple subsystems and their boundaries. By filtering based upon relationships you can identify issues earlier. You can also more thoroughly assess the project and hopefully you and the developers can better estimate the time it will take to get all those new features...Read On
	Comment:     by ofer prat 10/8/2002 Hi. There are several requirements management tools in the market (e.g. Calibar RM). Does anyone has experience with these tools?
	Comment:     by Daniel SUCIU 10/8/2002 The answer to David’s question seems very obvious to me: Requirements management tools. The key word is “management”. I think it better describe all actions performed on the initial requirement during the project life cycle. A tool can solve all the problem that David have mentioned (queries on different criteria, different formats/templates for different purposes, calculations capabilities) and many others, especially used in parallel with other tools for version control, change management, design, automated testing. Anyway, even alone, a requirement management tool combine the advantages of the database, with the capabilities of word...Read On
	Comment:     by Hans Thelosen 10/8/2002 Managing requirements differs from publishing requirements. We like to publish requirements in a document (easy to use). However if you manage requirements (create, change, discuss, postpone) it just a question of manipulating the attributes related to the requirements. For this purpose a document is error prone. So why don't use a repository. Some tools are able to use a repository for managing the requirements and at the end a document can be generated.
	Comment:     by sameer nigam 10/8/2002 Do you think using Business Process Model and Business Function Model in Designer could help you capture your requirements in a meaningful way.
	Comment:     by Alberto López Navarro 10/8/2002 I found the column really interesting, as one of those simple things that it's surprising it wasn't thought of before. I work in a rather big telecom company where projects have a very wide scope and must be broken into pieces to be defined/implemented by groups specialized in each of the areas. The process works, but it is really cumbersome as all involved people (>80) have to 'fish' for requirements through the whole document even when only a small part affects their area, not to mention the overhead associated with changes after document approval. The issue at question might seem trivial, as it is only a matter of technology/tools and the...Read On
	Comment:     by Fiona Williams 10/8/2002 I have to say that the best help I have EVER had for writing requirements (or any other documentation) was from a course in Information Mapping. It has really focused the way I write things, and has made the documents so much quicker to read. Its designed to make it quick to scan and therefore incredibly quick to find the information that you need. I'd really recommend it. For more information on the method and process (and some examples) please see: http://www.infomap.com/
	Comment:     by Sandy Flann 10/7/2002 Definitely! What a fantastic definition of a common problem. I've always found this to be a difficulty, but never was able to articulate it this way. Thank you for putting the right words out there. I wish I had a good solution to offer. The best template for Requirements that I've seen comes from RUP. Everything is numbered and categorized. But, that's still a "text" document. And I can see the probs that using a spreadsheet may cause. Hmmmm... maybe it's time for someone to come up with something REALLY innovative - maybe even SEARCHABLE. They might make themselves a million bucks!
	Comment:     by Kevin Priest 10/7/2002 Whether one uses word processors, spreadsheets, or databases, one ultimately writes (“to set down in writing”) requirements. From the column title, I expected a proposal such as "drawing" requirements, i.e., graphical rather than textual representation of requirements. After wading through pages of a requirements specification describing shifts between modes of the application, drawing a state-transition diagram greatly simplifies the requirements -- and usually exposes inconsistencies and errors. As a tester, how many times have you drawn a picture to clarify a narrative specification? How many times have you found the developer did the...Read On Author's Response: 10/10/2002     Kevin: I should have mentioned diagrams (state transition, split activity, and essential class) as they are the best way to present important forms of requirements information. But, they are not always the best as you probably know since there is no one best specification method. For example, at a summary level, most non-functional requirements need narrative text descriptions. At a detail level, these requirements are best specified by acceptance/system test procedures. Another example is the detailed definition of composite states e.g. the client is eligible for a particular type of insurance policy. "eligible" is a composite state defined by a logical expression composed of basic states (attribute values) of the client object. The policy may be restricted by any combination of age, sex, marital status, home ownership, etc. etc. Neither diagrams nor narrative text is an effective way to specify logical expressions --- that's why we have mathematics. Effective requirements specification requires a heterogenous strategy that finds the clearest method of expressing each of the diverse forms of requirements information. That said, we all have our favorites. Thanks for you comments. David Gelperin
	Comment:     by Gene Fellner 10/7/2002 You're getting off pretty easy, David. The usual flood of comments is off to a slow start. Probably because what you say is dead on. Recording the requirements of a million dollar project in a flat file is just one more example of the shoemaker himself, not his children, going barefoot. The popular project management software tool that I use doesn't even have a place to list requirements, much less manage them. Just as the "requirements" driving early MIS projects were simply models of the clerical processes they were to replace, so have our project management tools merely facilitated our continued inattention to the early phases...Read On
	Comment:     by Chris DeNardis 10/7/2002 I was first surprised by the title “Maybe We Shouldn’t "Write" Requirements” ?? Maybe the title should be changed to various methods for capturing requirements or something else, as in the article you do say – requirements should be there, however the tool used to document what they are may differ from Excel to Word, or maybe even power point as more of a conceptual picture that leads down to the requirement. We use Word as our form of requirements document. But inside word there are tables – sometimes embedded Excel sheets, as well as pictures, either from Visio or Power point to get the point across. When we begin testing these...Read On Author's Response: 10/10/2002     Chris: Thanks for pointing out that there is another point on the recording spectrum. We have (1) word processors, (2) spreadsheets, (3) the enriched combination that you describe,(4)databases and (5) requirements management platforms (which can be viewed as enriched databases). David Gelperin

Back to Top