requirements

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?

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.

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.