Understanding what people need and require from a product is important. So requirements are important. But what is a requirements and what are “good” or “bad” ones? I set forth to find the ultimate answer and found 42. So lets add a bit more structure and talk about the problem, solution and the conversation side and conclude with a question: where should the development team invest their energy: into creating the specification or into discussing the best possible solution given the constraints?
Tag Archives: requirement
Agile conversation or requirements engineering?!
Requirements engineering (RE) has a long and successful tradition. Different approaches always existed. Still it is optimized for an artifact driven setup: Individuals pass on documents. Agile practices are however geared for an interaction driven setup where individuals form one “super-brain”. The discussion about requirements is part of the agile conversation. And now, the proven approaches from RE suddenly create friction and bad smells. So, should we forget about requirements?
Continue readingKeep knowledge alive – living documentation
Keeping knowledge about a product alive is no easy task. Software teams struggle with manually mainting vast documentation in UML tools, text documents, wiki sites and more. We all know about the amount of effort and dedication needed to do this well given the amount of redundancy. There is a promising vision of a living documentation, i.e. a documentaiton automagically created from those things the teams create anyway, like automated and manual tests, backlog items, meeting protocols and more.
Killing or curing – experience the future
Have you seen the keynote of Stephan Frickas at the RE ’12 in Chicago? His team created a simulated environment and let real users experience prototypes to figure out, if the requirements (and the design) fit. It’s killing or curing the user centred way!
Continue reading