An article in the current version of Requirements Engineering magazine (offered for free online by the IREB) caught my eye earlier today and I thought it was definitely worth recommending here so that others could give it a look. The article is called “TORE – A Framework for Systematic Requirements Development in Information Systems” and is written by several people who work at the Fraunhofer Institute for Experimental Software Engineering.
I had not come across TORE before, but it’s interesting in that it presents a list of decision points that have to be made in a Requirements Engineering effort at several different levels. It’s nice because it does not specify any particular techniques or methodologies, but rather is something you can drop into your existing process to help ensure you have made all the necessary decisions before moving on.
It’s a relatively quick and simple read and I highly recommend it.
Perhaps the single most important thing a business analyst can do when they start working on an initiative (whether it be a project, process, or problem analysis) is to learn the language of the stakeholder(s) they will be working with.
Learning the language of your stakeholder(s) should be among the very first tasks you undertake as a business analyst. Indeed, in my opinion, it is the very foundation of EVERY other activity a business analyst undertakes with that stakeholder.
- It is difficult to understand the business problem(s) you are trying to solve if you do not understand the subtleties of the language the stakeholder is speaking. Even common terms used within the larger organization can have subtly different meanings to your stakeholder that are important for you to know.
- When working with multiple stakeholders, you cannot communicate optimally with them if you do not do so in language that they understand at the most complete level.
- When working with multiple stakeholders, you cannot identify potential differences in stakeholder needs if you do not understand the exact language each stakeholder is speaking,
- You cannot most effectively plan to elicit information if you do not know the meanings and relationships of the concepts the stakeholders use.
- And you cannot fully understand the information you elicit from stakeholders if you do not understand the full meaning of what they communicate.