Writing For The Purpose of Reading

Posted on:

The reason we write is so that someone can read it in the future. Duh. When we’re writing requirements documents, or documenting processes, how often do we stop and think about who will be reading our documents? We need to make sure our writing will be easy to read for our audience.

Alphabet Soup – Requirements Documents

Posted on:

This is my requirements document. There are many like it, but this one is mine. My requirements document is my life. [Kubrick, with some editing]. Michael provides a comparison of requirements documentation formats seen in the wild. A good companion to our earlier piece, Michael provides some “what to expect” guidance about how different companies use the different documentation formats. Check it out.

Requirements Documents – One Man’s Trash

Posted on:

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents – MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

Describing the Software Development Process

Posted on:

Software development involves determining what to develop, documenting this decision, determining how to develop it, and actually developing it.We present a framework for describing this process in terms of layers of activity. Many people use pyramid analogies, which show the magnitude of effort in each layer (lines of code versus lines of requirements, for example). Many other people use inverted pyramids to reflect the importance (or impact) of work done at different layers (a sentance defining a strategy has more impact than a line of code). Some people show PERT diagrams of waterfalls or pretty circular arrows charts showing iterative lifecycles, or any of many good analogies.