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.
Lists / Software development / Software requirements specification / Test Automation / Testing
Posted on:
Software Testing Series: Organizing a Test Suite with Tags Part Two
This is the second in a three-part post about using tags as a means to organize an automated test suite.
Part 2 of this post can be read as a standalone article. If it were, it would be titled Top five problems with test automation suites. If you’re only reading this post and not parts 1 and 3, pretend that this is the title.
Process Improvement / Software development / Software requirements specification / Test Automation / Testing
Posted on:
Software Testing Series: Organizing a Test Suite with Tags Part One
This post is a follow-up to our previous case study on incorporating unit testing into an existing team’s development environment. The case study is based on a real solution that has already started reaping rewards for our client, and is gaining momentum. We’re now looking at making it easier for the development team to maintain this test suite, and proposing some extensions – including a form of tagging.
Prioritization / Project Management / Requirements / ROI / Software requirements specification
Posted on:
Using ROI For Requirements Is A Risky Business
We’ve talked repeatedly about using ROI to drive prioritization of requirements based upon value. ROI can be used as the basis for prioritization for all decision making.
If we fail to take risk into account, our calculations will certainly be wrong, and we may make a poor decision. When we talk about accounting for risk in this context, we mean that we are accounting for the unlikely, undesired, or unintentional outcomes. We use the term expected value to refer to the risk adjusted approximation of the outcome. In financial circles, this is also called discounting.
The most common mistake people make when calculating ROI is failing to take into account the expected value of the return or the expected value of the cost of a project.
Austin TX / Process Improvement / Requirements / Requirements management software / Software development / Software requirements specification / UX
Posted on:
iRise – software prototyping tool
We received a comment from Tom Humbarger at iRise on an earlier post, which led us to take a look at their site. iRise provides a tool for rapid prototyping of web-based applications, and there’s an overview of the products available. They have iRise Studio which allows people to create […]
Requirements / Software requirements specification
Posted on:
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 […]
Lists / Polls / Requirements / Requirements Models / Use Cases
Posted on:
Top Ten Use Case Mistakes
The top ten use case mistakes We’re reiterating the top five use case mistakes from Top five use case blunders and adding five more. For details on the first five, go back to that post. There’s also a poll at the end of this post – vote for the worst […]
Requirements / Software requirements specification / Writing
Posted on:
A requirements documentation mistake
Learn from an early mistake of mine At a previous employer, the first time I played the role of requirements manager (technically, program manager – with responsibility for the functional spec), I made a bunch of mistakes – this post is about one of them. The setup We were engaged […]
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 […]