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 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?
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.
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.
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.
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.
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.
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.
Yogita works as a QA/testing professional with Mindfire Solutions, and has written a number of articles on QA and testing strategies. Yogita is currently exploring thoughts of beauty as an area of testing and its relation to usability. Her role at Mindfire has been to implement Quality processes throughout the organization and build a dedicated testing team. The team recently published a White Paper “Porting projects: Test techniques,” downloadable from www.mindfiresolutions.com. Yogita can be reached at [email protected].