Are you a requirements engineer but your main goal is to provide well organized documentation? Do you have a great knowledge about the industry, business analysis and systems but you are struggling with the shape and look of your documentation? Do you still hear, for instance, that the specification document is not easy to read and difficult to use?

Requirements first

Requirements are the starting point of all other activities in a project lifecycle. So the specification document is crucial for the project. The document has many audiences such us stakeholders, designers, verification engineers and other groups involved in the project. This forces the author of the document to take care of the structure and organization of the document. It is not a big deal to prepare such a document. The problem is that the document has to be modified many times. The requirements are constantly changing, with new features appearing, some being modified and some being removed. Reclassification and reorganization must be repeated many times. In which case, I am pretty sure you will be contending with issues such as auto numbering, indentation, paragraph styles as well as tables and drawings that just do not fit the page.

Another kind of trouble comes from collaboration. Requirements should be developed by more than one engineer but working together on the same document is really a challenge. Forgetting to enable Track Changes, using the wrong version of a document or even using different version of Office tools are the most common collaboration issues.

Finally, there may be a situation in which you focus on a document’s structure and aesthetics more than its content. In the end your document may be well prepared but there is a serious risk that the requirements will be ambiguous, incomplete and/or inconsistent. This can happen when huge amounts of energy are spent solely on keeping the document organized and current. For the rest of this article, visit the Aldec Design and Verification Blog.