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 / Slightly off-topic
Posted on:
Dilbert does product managers
http://www.dilbert.com/comics/dilbert/archive/dilbert-20060129.html We won’t copy the image of the cartoon – but we’ll tell you that it opens with Alice: “I’ll need to know your requirements before I start to design the software.” ObRelatedTopic: How to interview when gathering requirements Great Dilbert products The latest book (Nov 2005) from Scott Adams, […]
Consulting / Lists / People management / Requirements
Posted on:
Five Measures of Product Manager Performance
Joy posted a really good article last week at Seilevel’s requirements defined blog, Measuring product manager performance on internal system products. Her post is a followup to an extensive and heated debate that happened last fall on the Austin PMM forum. It’s a great forum to subscribe to – a […]
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.
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 […]