In a discussion in the IIBA LinkedIn group, someone asked ‚Are any of you using UML, and how is working out for you?‘ The answer is like always: ‚it depends‘. It depends on the situation and what others expect.
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.