In our article, The 8 Goals of Use Cases, the first goal is that our use cases must support requirement-completeness validation. In this article, we explore how to address this goal and how use cases can help. There are many pieces to this puzzle, and this article is one of them.
Make Your Meetings 60% More Effective
While effective meetings may not be the key to success, ineffective meetings are inarguably one of the largest time wasters in corporations. Applying these tips before, during, and after meetings will make us much more effective.
Challenging Requirements
The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.
Scheduling requirements changes – part 2
This process goes against agile principles on paper, but makes teams more agile in practice. Scheduling delivery of a project is an exercise in managing complexity. Scheduling changes to the requirements on the fly is really only marginally more difficult. The key to managing changes is to set expectations with our stakeholders. By defining rational deadlines for change requests, we assure ourselves that we can manage the changes. We also demonstrate responsiveness to our stakeholders. Rational deadlines are not arbitrary deadlines nor are they unreasonable deadlines. Deadlines that vary with the complexity of the changes are rational, easy to communicate, and easy to manage.
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).
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 […]
Agile Requirements
One of the key points that enables James’ approach is “tight collaboration†between the program manager and the developers. He talks about the miracles that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on.