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 / Requirements Models / Software development / Software requirements specification / Use Cases / Writing
Posted on:
Writing Functional Requirements to Support Use Cases
Background:
In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project.
Requirements / Requirements Models / Test Automation / Testing / Use Cases
Posted on:
Sample Use Case Examples
We talked about informal use cases a while ago in our use case series. Over a series of posts, we are demonstrating the process of defining a software product. The next step, and subject of this post, is the creation of informal use cases to support the defined goals for the software.
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.
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.
Communication / Software development
Posted on:
Outside reading: Enterprise versus consumer software
Cote’ recently posted a good comparison of the features of Enterprise Software versus Consumer Software. Although we may not agree with all the items in his lists (consumer software can have a login, and very often does have upgrade paths), we do appreciate the general classification. And we really like his insight:
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.
Marketing / Testing
Posted on:
Software Testing Series: Top Three Measurements of Quality
The three most important things to understand about the quality of your software are the three things most relevant to your business and your stakeholders (and arguably, your boss).
Top three measurements of software quality
1. How do people perceive our quality?
2. How big of a problem is our quality?
3. How bad is our software, really?
Process Improvement / Software development
Posted on:
Why Incremental Delivery Is Good
Incremental delivery is a key component of most software projects today – it allows us to deliver the most valuable elements of a system first, which allows our customers to start getting benefit from the system earlier. As additional features are developed, and additional use cases are enabled, they are delivered to the customers, who get incremental value from those features. This can have a significant impact on ROI projections for a project – and can be the difference between getting the deal and losing it.