|
The Innovative Tester Historically, the development team considers themselves the creators of the system and the QA community is considered as a necessary evil, more so when there is an independent testing group. Since test engineers sometimes work in a hostile atmosphere, they need to equip themselves with more knowledge in both functional and testing skills. This article discusses the importance of developing those skills.
|
|
|
Give 'em the Business Miscommunication is at the heart of most software defects. Being knowledgeable about a company as a whole, and not just about the specs of a particular project, is just one more way to safeguard against failures. Read on as Elisabeth Hendrickson explains the importance of technical people staying informed about business strategies.
|
|
|
Requirements Workshop Agenda (template) This template for a requirements workshop includes preparation tasks and, a place for listing workshop tools and participants.
|
|
|
Assuming the Worst about Requirements Requirements are under suspicion. Read between the lines of software and project management journalism and you'll hear nearly everyone lamenting the sad state of requirements. Managers plan only eight percent of project time for requirements. Developers worry about Zen-like requirements that lack sufficient detail to produce serviceable code. Testers think they have to backfill requirements. So, what were the analysts doing?
|
|
|
Taking the Mystery out of Requirements Ambiguity, false assumptions, theories, and red herrings. These basic elements of a good mystery story are also encountered in software requirements gathering. And just as the detective has his bag of tricks for solving the mystery, you can learn a few things about uncovering elusive requirements in this column from Becky Winant.
|
|
|
You Can't Fight Change We can probably agree that, for the most part, change is good. But it is also disruptive, and can even create chaos. In this column, Becky Winant explains a familiar model of the change process, and offers some ways to acknowledge and cope with change in the workplace.
|
|
|
Modeling Practice and Requirements Models are useful in different settings in different ways. Models can test facts, ideas and understanding, simulate operation, and aid coordination between systems and people. In this column, Becky Winant lists six model patterns she has seen in practice in software development organizations, talking about where each is appropriate, and the strengths and weaknesses of each.
|
|
|
A Systematic Approach for More Effective Communication of Functional Requirements and Specifications The communication of functional requirements and specifications is the most difficult, critical, and error-prone task in IT projects. Research has shown that projects that proceed to the construction and coding phase with missing or wrong functional requirements and specifications are almost certain to fail. To avoid missing or misunderstanding the requirements for a solution, and to avoid the development of systems to incorrect specifications, we need a systematic approach to capturing, organizing, and validating the functional requirements and specifications. In this article, Bill Walton offers such an approach.
|
|
|
Charting a Course for Requirements Most of us wouldn't think of launching on a critical journey without some forethought about destination, route, and risk. Why would software projects launch with anything less? In this column, Becky Winant explains how and why to create a project charter.
|
|
|
Requirement #1: Ask Honest Questions To get good requirements, you have to ask good questions. But what makes good questions, and how can you use them to systematically uncover requirements? In this column, Becky Winant shares the art and science behind asking questions that work.
|
|