Michael has posted five (plus five) tips on writing a market requirements document (MRD). Michael has written a good set of tips with detailed explanations and anecdotes. We have re-organized these tips into three general areas of guidance and provide our thoughts.
Software Requirements Specification Iteration and Prototyping
Developing great software requirements demands iteration
In our previous post of an example of the software development process, we showed a linear flow through the process, as depicted in several posts over a couple weeks. What we failed to show was any of the iteration cycles, as Deepak points out by asking a great question in the comments on that post. In this post, we will show a little more about how the process works by showing how iteration fits into the machinery of software development.
Software development process example
We’ve presented an example of the software development process across several posts over the last two weeks. In this post we tie them all together, showing the steps in process order.
Jargon gone amuck!
This video showing the abuse of jargon (2 minutes) is absolutely hysterical, and should be watched for humor alone. However, it also drives the point home about the effects of using jargon when writing requirements. When we write a PRD or SRS if we use the jargon of one domain, […]
Writing Requirements Unambiguously
Writing requirements without ambiguity
This is one of the harder parts of writing good requirements. Marcus tells us to avoid it with a good example here. Jerry Aubin at Seilevel has written an outstanding post on the subject, The art and science of disambiguation. Jerry starts his post with a gripping example from Weinberg and Gause:
Describing the Software Development Process
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.
How to manage data when writing requirements
Don’t trigger a data explosion with enumerated requirements. Managing requirements can be tricky when it comes to managing data (information). The difference between a good approach and a bad approach can add up to hundreds of hours of labor over the life of a project. In our picture, we show […]
Are people reading your requirements? A blogversation.
Tony just put up a post at Seilevel’s blog on making sure your spec is reviewed. Kent Newsome recently posted about starting cross-blog conversations here, possibly inspired by Amy Gahran’s post about it here. Tony’s post is a great topic to cross-blog about. Three easy steps to blogversation Post your […]
Readability and Requirements
Thanks to the download squad for pointing me at the Juicy Studio: Readability Test! You can go to Juicy Studio’s site, and calculate the reading level of any URL. You can also try the Readability Grader at Jellymetrics, for a modern take on it. Of the multiple analyses provided, the […]