The first step to comparing products is understanding your customers. This may seem counter-intuitive, but your product’s capabilities are meaningless unless you are comparing them from your customer’s point of view. This article is part 2 in a series on comparing products. Check out part 1, then continue with this […]
Business Analysis / Product Management / Product Strategy
Posted on:
Compare Products Not Specs – Comparing Products Part 1
Recently, the gadget-reviewer crowd has caught on to something we’ve known for a long time. Comparing products is not about comparing specs, it is about comparing how well the products solve problems that customers will pay to solve. That begs the question – how should you compare products? Read on […]
Business Analysis / Product Management / Requirements / Requirements gathering / Requirements Models / Software requirements specification
Posted on:
SRS Plan of Attack
How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? […]
Product Management / Requirements / Requirements Models / Use Cases
Posted on:
The Impact of Change and Use Cases
Market requirements change. These changes impact the use cases that support the changing requirements. Functional requirements change. These changes impact the use cases that they support. How can we leverage use cases to manage these changes? And how can we manage changes to use cases?
Communication / Product Management / Requirements / Software requirements specification / Writing
Posted on:
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.
Requirements / Software requirements specification
Posted on:
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
Communication / Process Improvement / Requirements / ROI / Software development / Software requirements specification
Posted on:
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.
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.
Requirements / Software requirements specification / Writing
Posted on:
Stop Wasting Your Time – Don’t Bother Writing Functional Specs
Don’t do it. Don’t use a functional spec to get superficial agreements and navigate the beurocracy that accompanies large projects. Don’t validate the specification trivially. Don’t deploy with a waterfall process (the spec is done, whew, now – on to design) and never revisit the spec. Don’t work with new developers, or remote developers, or anyone else who doesn’t have the context of direct eyeball-to-eyeball conversations with the customers. Also don’t hire any programmers without complete domain expertise in the customer’s business