This Article 
   
 Share 
   
 Bibliographic References 
   
 Add to: 
 
Digg
Furl
Spurl
Blink
Simpy
Google
Del.icio.us
Y!MyWeb
 
 Search 
   
Learning from Failure, Part 1: Scoping and Requirements Woes
November/December 2009 (vol. 26 no. 6)
pp. 68-69
Frank Buschmann, Siemens Corporate Technology
Time and again, software projects fail. Some of the reasons for failure relate to software architecture. In this edition of the column I'll discuss two mistakes that aren't the prime responsibility of architects, but architects are directly affected if they occur: missing, wrong, or creeping system scope; and vague, unnecessary, or extreme nonfunctional requirements. Not addressing these mistakes can lead software projects to trouble before concrete architecture elaboration even begins.

1. Chaos Report 2007, Standish Group, 2007.
2. E. Woods, "Top Ten Architecture Mistakes," Proc. Java and Object-Oriented Conf. (JAOO 08), 2008; http://www.eoinwoods.info/docJAOO2008-Top10Mistakes.pdf .
3. F. Buschmann, "The Role of Failure in Successful Software Design," tutorial presented at Proc. Object Oriented Programming Conf. (OOP 09), 2009, SIGS Datacom, 2009.
4. A. Kossiakoff and W.N. Sweet, Systems Engineering: Principles and Practices, Wiley-Interscience, 2002.
5. P. Clements, R. Kazman, and M. Klein, Evaluating Software Architectures—Methods and Case Studies, Addison-Wesley, 2002.
6. A. Cockburn, Writing Effective Use Cases, Addison-Wesley, 2000.
7. K. Beck, eXtreme Programming Explained: Embrace Change, 2nd ed., Addison-Wesley, 2004.

Index Terms:
software architect, software architecture, software engineering, nonfunctional requirements, requirements engineering, system scope, functionality
Citation:
Frank Buschmann, "Learning from Failure, Part 1: Scoping and Requirements Woes," IEEE Software, vol. 26, no. 6, pp. 68-69, Nov.-Dec. 2009, doi:10.1109/MS.2009.179
Usage of this product signifies your acceptance of the Terms of Use.