When writing requirement documents it is often the case that they have a very rigid structure and normally consist out of many repeating structural elements but also have free text elements and pictures. The idea behind defining modules is to ensure a certain structural quality that makes maintaining, synchronising and reading the document easier. Normally a module consists out of a title, description, priority, other relevant modules and many more fields. While there are specialised tools to create the requirements there is no modern tool that enables you to create the whole document in a structured way. Further these documents are a collaboration of many authors. Different parts might be written by different people, there might be some proofreading or validation process. And in the end you will want to ask your client for some feedback while erasing all those little errors and give the document some extra polish. Unfortunately word processors are mostly used for the whole process which creates loads of problems as they are generally not designed for this type of task.

When we were approached to write a requirements document for a fairly large system we used excel and word to create our documentation. After writing about 200 pages we started running into loads of errors, we spent nights merging different versions, trying to format it nicely and all sorts of things that actually stopped us from doing “real” work. At some stage I noticed, that basically all we needed was a relational database with some input fields and a nice output filter. All the fields we had in our module structure mapped pretty much 1to1 to a RDBMS and so I went to work writing a very simple database that fitted our needs. It was multi user, with different roles, logged a complete history of every edit, had various outputs like HTML, PDF or DOC, could visualise the dependencies between the modules and was all web based and written, so that it could be used on various devices like a tablet or mobile phone. This very simple database frontend instantly made our life far easier. We could all work on the document at the same time, we could see who had done what, by adding states to the modules we also saw how much we still had to do. And we wrote better requirements as the structure was fixed. Using the tool made us think why had we ever tried to do this in something as old fashioned as a text editor. The project became more on focusing on the content and what requirements we still needed to specify than on how to lay out certain things and worrying about the process of writing.

After the successful completion of the project we continued to use this very simple tool for more projects till we realised that we could not be the only people that had these problems and that if we managed to generalise our software this could be used for various use cases. The result can be seen under DBook.org

For an invite code send us a message:
Email : invite@dbook.org
Facebook: https://www.facebook.com/dbook.org
Twitter: https://twitter.com/dbook_org