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.
Communication / Presentation / Requirements / Software requirements specification / Writing
Posted on:
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, […]
Communication / Requirements / Software requirements specification / Writing
Posted on:
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:
Communication / Requirements / Software development / Software requirements specification
Posted on:
Software Requirements – Process and Roles
Our previous post, Requirements vs design – which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.
In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.
Austin TX / Requirements / Software development / Software requirements specification
Posted on:
Requirements vs Design – Which is Which and Why?
A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. We can’t let the other folks have all the fun, so we’ll chime in too.
Requirements / ROI / Software requirements specification / Testing
Posted on:
MRD to PRD Requirements Conversion
A real world example of converting from an MRD to a PRD. This is the process of translating from a market-requirements view of the product to a product-requirements view of the product.
Design / Process Improvement / Requirements / Software development
Posted on:
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.
Marketing / Process Improvement / Requirements / Requirements gathering / Software requirements specification
Posted on:
From MRD to PRD: The key to defining a spec
They key to writing a great spec is knowing how to specify software that mets our customers’ needs. It can be a daunting task. First, we have to define what our customer needs. High level requirements are just requirements that are too vague or high-level to be directly actionable. “We […]
Communication / Requirements / Requirements management software / Software requirements specification / Writing
Posted on:
Requirements Document Proliferation
Too many companies don’t document their requirements.
Worse still, too many companies over-document their requirements.