%0 Conference Paper %1 schwaber02 %A Schwaber, Ken %B Proceedings of the International Workshop on Time Constrained Requirements Engineering %D 2002 %K agile requirements %P 12--16 %T The Impact of Agile Processes on Requirements Engineering %X This paper discusses how agile processes resolve a paradox of requirements engineering – the need to formulate a clear vision of a system in a world of constantly changing requirements. This paper provides an alternative to current theory based on experiences by agile process practitioners. The paper describes (1) current requirements engineering practices in agile processes, (2) a summary of experiences of practitioners of agile processes regarding requirements engineering, (3) the variance between agile practices and requirements engineering disciplines described in the literature, press, and academia, and, (4) an area of research.

@inproceedings{schwaber02, abstract = {This paper discusses how agile processes resolve a paradox of requirements engineering – the need to formulate a clear vision of a system in a world of constantly changing requirements. This paper provides an alternative to current theory based on experiences by agile process practitioners. The paper describes (1) current requirements engineering practices in agile processes, (2) a summary of experiences of practitioners of agile processes regarding requirements engineering, (3) the variance between agile practices and requirements engineering disciplines described in the literature, press, and academia, and, (4) an area of research.}, added-at = {2006-03-24T16:34:33.000+0100}, author = {Schwaber, Ken}, biburl = {https://www.bibsonomy.org/bibtex/26e6eedeaf1694325b039c5e083709d05/neilernst}, booktitle = {Proceedings of the International Workshop on Time Constrained Requirements Engineering}, citeulike-article-id = {268294}, comment = {- assumes the conclusion is true... "frequent inspection and immediate adaptation to results are the primary mechanisms for dealing with complexity" - huh? says who? - I agree the notion that a system must be fully specified prior to starting seems unnecessary - emergence is valid enough. Where is the bnd? - investigate DSDM's 80/20 claim - any idea whether this applies in complex systems? - position paper, badly written (or quickly)}, description = {sdasda}, interhash = {721482a98dd4cd9f36763d9fcf9d5744}, intrahash = {6e6eedeaf1694325b039c5e083709d05}, keywords = {agile requirements}, month = {September}, pages = {12--16}, priority = {0}, timestamp = {2006-03-24T16:34:33.000+0100}, title = {The Impact of Agile Processes on Requirements Engineering}, year = 2002 }