We tackled a complex analysis problem yesterday and I was reminded how great it is to have a developer available to help with brainstorming during requirements elicitation.
A manager at one of our clients has a very complex algorithm for optimizing revenue in a boutique division of their organization. This division has been so successful that the senior managers want to share the success with the rest of the organization. They asked us to automate the algorithm so that it could be used by other managers and other divisions. The reason that the algorithm is so successful is that it was developed by a brilliant human brain and has been refined over several years of practical use.
Our initial interviews had indicated that the algorithm is a set of intuitively applied business rules with a lot of exceptions. Before our session yesterday we weren't really sure that this thinking process could be automated. But we brought together the key business stakeholders, a developer and the BA team to see what we could do. As we painfully extracted intuition, assumptions, experiential knowledge and gut feel business rules from the SME, our developer was jotting notes and adding his own questions. As we began to understand the basic steps in the process we tried to write them/document them in a format that would lead to some kind of repeatable process. As BAs we could "see" the pattern but we couldn't imagine how to make a machine understand it or repeat it. But our developer could. He saw an approach that would allow all of the rules to be applied appropriately.
This was a great reminder that business rules used by business people are often very complex and are difficult to document. Our SME would tell you that it was difficult for him to explain this complex thinking process, even though he "invented" it. Everyone in the room learned a tremendous amount about the process and the business. We just have the start of our design but at least we have a start. Without our developer there, we may have left the room deciding that software support was not possible for this complex process.
June 26th, 2007 at 11:20 am
That is a point well stated, Barbara!
On a parallel thought, our develeoper friends do add a flavour of realism to the whole requirement gathering initiative. I have often felt that we BAs, by virtue of our open-mindedness and mindest to capture clients’ requirements while offering problem alleviation strategies do tend to jump a fine line. We may feel sometimes that a particular solution is valid in a particular situation. In reality the solution may not be technically feasible in the clients’ setup and this is usually brought into the forefront by an IT Project Manager or the members of the development team who may provide technical reasoning to refute the proposed solution.
July 16th, 2007 at 4:27 pm
I'd have to disagree on this point. As Business Analysts, our job is to elicit and communicate business requirements, to facilitate the "what" discussions, not the "how" discussions. Having developers in requirements meetings often tends to slant the discussions toward the implementation side leaving many requirements on the table, either dismissed for "implementation" reasons, or often forgotten as discussions get sidetracked. Even though a client's current technology may not support a business requirement, it should still be documented and left to the stakeholders/sponsors to make the final determination to implement whatever the cost. There may be a legal, regulatory, or business case for the requirement of which the developers may be aware. A better approach is to develop the use case(s) and then have a discussion with development, if warranted to flesh out any concerns. Again, this is one BA's opinion.