Cauvin

Requirements traceability refers to the ease of tracking the relationship of artifacts to product requirements throughout the development process. One form of requirements traceability involves slavishly documenting each design decision and precisely which requirement(s) it addresses. There's got to be a better way. And there is. If your team isn't communicating well and your process is broken, you are likely to have some of the following problems: Features that are "neat" but don't address requirements. Designs that don't address requirements. Difficulty adjusting to changing requirements, priorities, and scoping. QA that doesn't know what to test. For this reason, some managers are enamored with the concept of requirements traceability. An untrusting manager tries to impose some heavyweight processes to ensure these problems don't occur. Usually, the process usually involves some huge, complicated spreadsheet with all sorts of links be...

In a Q&A over at Functioning Form, Tom Chi gave us this nugget: Usually when a group of smart people is at an impasse for a long time, it is because the problem is poorly framed, not because their solutions are not good. Unfortunately, it is par for the course in the tech industry to try to bowl headlong into solving things even before we know what the problem is, or the criteria for success. Defining a problem is also an extremely creative activity. If you are falling back to the same lame problem statements and measures of success, then you aren’t really trying. And there are a ton of reasons to try. The most important is that a well defined-and exciting problem (and its associated constraints) is the catalyst that makes design go. By not drawing a clear and compelling problem, you are cheating your team out of an incredible unifying and driving energy.

Having trouble getting responses to your survey? In a MarketingProfs.com article , Dean Wiltse tells us seven rules for achieving higher online survey response rates. One of the rules is: Rule #4: More is not always better Many organizations believe the more questions they ask, the more measurable the results will be. However, the reality is the exact opposite. The more questions asked, the less focused and thoughtful survey responses are and the more survey takers rush to exit. Instead of asking every possible question under the sun, survey designers should keep the survey focused and to the point. Survey administrators should bear in mind that to get a solid response rate the number of questions should not exceed 30. I'm even more radical. I recommend limiting the number of questions to 12 in most cases.