There’s an interesting thread on Seilevel’s requirements forum about why developers don’t read the specs and how to fix this problem. Sometimes the developers throw away the requirements. And that’s bad. But it is a symptom. Something is broken at a higher level.
Gadgets And Goals
What makes the best gadgets great? An understanding of goals and attention to design details. When we take a step back from writing requirements about software, and think about gadgets and goals – the perspective can help us write better requirements and make better prioritization decisions.
Change is Bad? Mistakes are Worse
CNET ran an article about a month ago about how Microsoft Live Hotmail – the upgrade/replacement of Hotmail failed to win a lot of converts. Microsoft ultimately had to deliver a “classic” version of the new code base to mimic the behavior of the old software. CNET’s analysis, while accurate, […]
Nexus – Use Case Definition for Bundles
Yesterday, we identified the high priority goal for the third release of nexus to be supporting creation of bundles of articles. In this article, we will define the use cases we need to support.
Nexus – Third Alpha Release Prioritization
The second release of nexus went live today (build 127). It included the top features from our prioritized list published yesterday. This enabled the next use case from our first prioritized list of use cases – searching the articles. We also took this opportunity to refactor part of the user […]
Nexus – Next Round of Prioritization
The next build of nexus starts today as our agile project continues. Let us know what stuff you think is most important for this release, as part of our prioritization.
APR: Process Deviation?
Rolf presented a valid critique and some questions on our previous article announcing the launch of nexus. I started writing a long response, and realized it would work well as an article for analysis of our process over the last month. Here it is.
APR: Updated Domain Model
More iteration in our agile project. In this article, we make several updates to the domain model (UML class diagram) based upon discussions on all of the articles in the series. More than a couple dozen in the last day. Thanks to everyone who has helped with feedback and encouragement […]
APR: Domain Model – UML Class Diagram
Along with design sketches and requirements, as part of the concurrent design and requirements development for our agile project, we have created a UML class diagram representing the domain. This iterative process allows us to incorporate the benefits of each perspective rapidly with the others in our race to prototype […]