Assuming you have a basic target format for your requirements (a template or structure in a tool), you need to decide how you are categorizing the information within that format. For example, you might be grouping requirements by feature, by use case, by sub-system, etc. In Part 1, I discussed an approach for this, to organize information that feels like complete chaos.
Now, let’s say you now have contained your chaos to a document (more or less). This most commonly looks like one or two sets of notes that just need to be massaged into true requirements. The following steps outline an approach to handle turning your notes into requirements. For the moment, I’m going to assume we are moving requirements to a template before moving importing them to a tool.
1. Categorize the information in your notes
First, you need to step through your notes, putting each of the pieces into the appropriate section of the document based on your categorization of information. This works for input sources other than just your notes also.
You have a couple choices here about how you get the information into the final format. If you are moving to a template, you can either put your notes in the template and work on them inside it, or you can move the notes into the template, working on them as you insert them.
If you are working in the document, you can cut and paste the content blocks to move them around in a logical fashion. Delete any obviously extraneous information at this point.
If you are moving content to a new document, then use a virtual highlighter to highlight things that have been moved into the actual document in one color, and use a different color to indicate things that you’ve decided not to use.
In all cases, be sure to save your raw notes off before you start this process, so you can get them back later if needed.
2. Log open issues
As you process the notes, put any open issues into the issue tracking system for further tracking.
3. Revisit the categories again
Take a step back to review your categories within the document for overall completeness. You should be able to apply some high-level models to do this. For example, you could use a high-level process flow to validate you have all process areas represented. You might use a system context diagram to validate you have all components covered. In general, verify that you have covered people, systems and data models. If you use models to validate the high-level categorization, you should typically include those in the overall requirements.
4. Complete known models
Since your document is physically grouped now, you can work within each content block to address the completeness. Again, you will use models to complete the content. Complete diagrams that were started in your notes. For example, often in a requirements session you will draft a process flow. This is the time to clean up the process flow diagram, including appropriate branching. If you drafted use cases in a requirements session, you would now formalize those to the degree necessary.
5. Create individual requirements
You probably have a lot of text from your notes. You should take a pass through the word content to separate out individual sentences as requirements. Each line should be just one requirement when you complete this.
6. Clean up the requirements
Take a pass on the individual requirements to formalize them, including adding IDs to requirements. Make sure they are each individually written well – good English, sensible, clear, etc. Remove duplicate requirements.
7. Find the gaps
This is the hard part – find and insert missing requirements – easier said than done. You will likely need to apply new models, using the requirements that you do have. For example, you might realize in your notes you have a list of system states and descriptions. This would prompt you to create a state table so that you can identify the transitions and missing states. While this post will not go into the use of models, we have many other posts on the blog that you can search and read about this.
Finally, if you are working with a requirements management tool and want to put your notes directly into the tool, this is more complicated because you have to simultaneously analyze, process and move – for each piece of content. I would encourage you to apply some of these techniques in your notes before you start putting them in the tool. But for example, you can do steps 5 and 6 while you move the individual requirements to the tool.
