I often get asked ‚what is the best tool for requirements engineering and requirements management?‘ The answer is not so simple because what starts out as a question about a tool only for one group of people quickly turns into a question about the underlying process and organization. If you want the whole truth and nothing but the truth about introducing these tools suites into an organization you should read this post.
By now, most organizations should have understood that they have to become more agile in order to stay in business. Like any new trend, people need practice to use it correctly. Some organizations have taken shortcuts and bent the rules of Agile and Scrum, and „forgot“ to think before they started to implement. A software development will seldom be successful without some form of thinking, specification, and documentation. The question is „how much thinking is actually useful?“
„In which part of the organization should a business analyst or requirements engineer be located?“ is actually an age-old question. It always comes along with other questions like the „what is the difference between a business analyst and a requirements engineer?“, as well as the WHAT and HOW. These questions have a symbiotic relationship.
Am Swiss Requirements Day 2015 wird Roger Köppel die zweite Keynote halten. Als Chef-Redakteur der Weltwoche wird er Verbindungen und Ähnlichkeiten zwischen den Berufen des Journalisten und des Requirements Engineers aufzeigen. Die ablehnende Haltung von potenziellen Teilnehmern ihm gegenüber zeigt aber, wie schwierig es ist, ein guter Requirements Engineer zu sein.