First Step

My way of translating a manual into requirements is to create a spreadsheet and copy every heading and subheading into the spreadsheet, keeping all the heading numbering intact. The more heading the better and clearer are the requirements. Then, within the paragraphs you will find additional requirements that need to be included in the spreadsheet. You do so by inserting rows after the heading of the paragraph or section and write up a one line sentence and number it. The numbering is important so here's an example:

Here's the first few heading starting in Section 3.0 of the manual:

3.0 Creating and Maintaining Catalogs........................3-1
      3.1 Opening a catalog..................................3-2
      3.2 Creating a Catalog................................ 3-4

and here's the corresponding clip from the spreadsheet:

What we've done is extract additional requirements from the 3.0 preface material and numbered it using additional decimal places avoiding interfering with the 2 place format of the guide. Then added additional requirements under each of the headings, maintaining the extended numbering format.Extracting requirements is as much art as it is science and is beyond the scope of the blog entry. What's important is that we've capture all the functional aspect and features of the application into a document that we can use for going forward to estimate the time to implement and upon delivery demonstrate tracability.

The layout of the spreadsheet

Filling out this spreadsheet is a 3 step process, 1st fill out the 'Heading or Fragement' column with the heading as indicated above. Add more rows, numbered accordingly, to fill out the requirements. This is art and science rolled together but anyone should be able to do it using this example as a starting point.

Second, determine when is to be implemented, what is duplicated or implemented elsewhere and what is not implemented. Not all headings in the guides or documents are functional, some headings/paragraphs are informational, some are not necessarily related to the project like historical perspective. The only thing of importance is that which is implemented. Why include all headings, even the ones that are not implemented or implemented elsewhere? For you and for your client, you need to identify all sources of requirements and rule-in and rule-out each. Only recording the ones you rule-in leaves you open to overlooking something and does not confirm for your client that you've considered everything. Always include all functional and non-functional requirements as best you can.

Third, determine the effort required to implement each requirement. Include in your consideration all the activities required for any requirement. You have to design the code, code it up, build it, test it, and integrate it into the whole package. An hours worth of coding can be 4 to 8 hours when you consider all the work. Consider all the work. Then use a "block of time" reduction to fill out numbers in the "Planned Units of Time" column. I use 4 hr. blocks of time. A requirement that I judge will be 2 hours of work is one-4 hr. block of time. 5 hours is 2 blocks of time. 12 hours is 3 blocks. Pick a number of hours / block and stick to it.

Accurate estimating

To accurately estimate a block of time, you need at least one other opinion and several other opinions if you can get them. You fill out the spreadsheet's "Planned" column and everyone else fills if out too. Then compare and discuss and argue to arrive at the correct number. You will be surprised how accurate it is. Try it, you'll like it!

Next entry - rounding out the engineering...