Pragmatic Marketing has a training seminar called Requirements That Work. In support of that, they provide a list of 8 characteristics of good requirements. We change one and add two more to round it out to The Big Ten Rules. Combine this with Michael’s ten tips for writing MRDs, and we’ve got a good handle on how to create a great MRD.
Category Archives: Software requirements specification
Posted in Lists, Product Management, Requirements, Software requirements specification, Writing
Tagged business requirements documentation, good requirements, managing data, product requirements, requirements documentation, requirements specification, software requirements, writing business requirements, writing requirements
35 Comments
Requirements Documents – One Man’s Trash
…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.
Posted in Communication, Product Management, Requirements, Software requirements specification, Writing
Tagged FRS, functional requirements specification, managing data, market requirements document, MRD, MRD PRD, PRD, product requirements document, requirements documentation, requirements documents, software requirements specification, SRS
8 Comments
Joel Spolsky Speaks Specs
It seems that specs are like flossing: everybody knows they should be writing them, but nobody does.
Another for the wish I had said that list. Joel Sposky wrote a four part series on writing functional specifications in Oct 2000. Joel’s opening position is that all projects lasting more than a week, or with more than one developer, will be completed faster with specs than without them. He presents three giant reasons to use a requirements document as part of developing software
Three Giant Reasons
Posted in Requirements, Software requirements specification
Tagged creating time boxes, estimation, FDD, feature driven development, FRS, functional requirements, functional requirements specification, joel sposky, managing data, project estimates, software estimation, software requirements specification, SRS, timeboxes
Leave a comment
Passing the Wrong Whitebox Tests
We’ve talked about the value of using whitebox testing in our Software testing series post on whitebox testing. What we haven’t explored is how to make sure we are creating the right tests. We have to validate our tests against the requirements. This post shows where the flaw is in the typical whitebox testing process, and how to fix it.
A reader emailed us with the comment, “It’s been my experience that developers can’t test their own code.” Their problem was that they were missing a link in the software development chain (missing a step in the process).
Posted in Communication, Process Improvement, Requirements, Software development, Software requirements specification, Testing
Tagged managing data, PRD, requirements testing, requirements validation, software development process, testing process, testing requirements, white box, white box testing, whitebox, whitebox process, whitebox testing, whitebox testing process
Leave a comment
Product management success in the conceptual age
The information age is ending and the conceptual age is beginning. In A Whole New Mind, Daniel Pink proposes that six characteristics of right-brain thinking are key to success in the new economy. Nils Davis realizes that these characteristics are embodied by good product managers today. We will define the conceptual age, review the six characteristics, and see how this applies to product management.
Expert systems – do what I say, not what I should have said
We’ve studiously avoided talking about requirements for expert systems because it is such a small niche of software development. Please let us know in the comments on this post if this is an area you would like to read more about. This post is both a discussion of the main barrier to success for these systems and an introduction to future posts if you ask for them in the comments on this post. Expert systems, or AI programs can solve some of the hardest problems. Yet AI software has not dominated the software landscape, neither Heinlein’s nor Vinge’s fictions have become real. Why has AI software failed? It isn’t that the hardest problems are too hard to solve, it’s that they often don’t need to be solved at all.
Posted in Interaction design, Requirements, Requirements Models, Software development, Software requirements specification, UX, Use Cases
Tagged alan cooper, constraints, FRS, Interaction design, kano, karl wiegers, managing data, MRD, non-functional requirements, persona, personas, PRD, prioritizing software requirements, requirements prioritization, scenario, software requirements, SRS, structured requirements, Use Cases
4 Comments
How To Create Personas for Goal Driven Development
We mentioned the creation of personas in our overview of the interaction design process. In this post we will talk in more detail about how to create them. We will cover identification and prioritization of the personas, defining the corporate and personal goals for the personas, and creating the anecdotal stories that give each persona an identity against which we can make design decisions. Scenarios are also defined for the primary personas, which drive the creation of the functional requirements specification.
Posted in Interaction design, Prioritization, Software development, Software requirements specification, UX
Tagged functional requirements specification, goal-driven development, how to create personas, Interaction design, managing data, prioritization of requirements, prioritizing requirements
1 Comment
Interaction Design Process Overview
Interaction design, as described by Alan Cooper in The Inmates are Running the Asylum, is a process for designing software by focusing on the most important users. Unlike traditional requirements gathering and solution design processes, interaction design focuses on the goals of a specific class of users, represented as a persona. Those goals are considered when defining scenarios that represent how the primary persona will use the software. The combination of goals and scenarios leads to design artifacts and a functional specification. We will explore these steps in more detail in this post.
Interaction design explained by Alan Cooper
There’s a Clash of the Titans joint-interview posted at FTPOnline between Kent Beck and Alan Cooper called Extreme Programming vs. Interaction Design. It’s 10 pages of back and forth. In short, these icons agree on objectives, and disagree on how to achieve them. They also spend some time (mis)characterizing each other’s positions and defining their own. In this post we will look at how Alan Cooper explains Interaction Design. We would say that he defines interaction design more as a requirements than a design activity.
Posted in Agile, Interaction design, Requirements, Requirements gathering, Software requirements specification, UX
Tagged Interaction design, managing data, market requirements, MRD, PRD, product requirements, Requirements, requirements elicitation, requirements vs design, software requirements
2 Comments
Latest Articles
Comments on all Articles
