Some people dismiss words such as skill, diversity, problems, and mission as being too ambiguous to be useful. But one tester's ambiguity is another tester's gauge for assessing consensus on a project and how to achieve that consensus.
Drawing on real events from the authors' combined experience, this story picks up where it left off in the November 2007 issue and follows a fictional team as it encounters some of the pitfalls of using test-driven development.
While "testing" is part of its name, many TDD pundits insist TDD is not a testing technique, but rather a technique that helps to focus one's design thinking. Drawing on real events from the authors' combined experience, this story follows a fictional team as it encounters some of the pitfalls of using test-driven development.
Everyone knows the importance of well-defined functional requirements. We want our products to work, don't we? But how many of us are paying as much attention to defining our non-functional requirements? In this historically focused feature, we learn from past mistakes the potentially disastrous results of inadequately tested NFRs.
The requirements process is not a linear one. In this article, Michael Bolton helps you get in the game by showing how the elements of the requirements process–reference, inference, and conference–interact and influence each other.
Grandma cooked her roast a certain way, and now you're repeating the process without knowing why you have to trim the ends off an uncooked roast even though the pan is adequately sized. Relic processes in many organzations fall trap to this mindset since the reason behind the action lost its meaning long ago. Lee Copeland calls these "IF ..., THEN ..." processes. When the organization loses sight of the IF responsible for the action, then you're left with what Lee describes as "a process without a context; a rule without a reason."
Writing requirements purely top-down or only bottom-up is risky to say the least. The devil's in the details, and those details are likely to be missed when working from a single direction. What if you could tackle your requirements from both directions by incorporating use cases and user centered design? Learn how balancing your approach to writing requirements can result in more detailed, pragmatic documentation.
Once upon a time there was an Agile requirements process and an ugly stepsister project. This might sound like the beginning of a fractured fairy tale, but it's a reality for many projects that don't fit the criteria for an efficient, effective requirements process. Language barriers, large teams, and tunnel vision are all things that can turn your project from Cinderella to stepsister. Find out how you can overcome these obstacles and get your team back to "happily ever after."
Trying to communicate with businesspeople about requirements can make you feel like you're from another planet. Using concrete examples expressed as storytests to drive the development of a system can help bring you back into the same orbit. Discover ways to introduce this process on your next project.