Are you into supermodels?

http://www.snjtechconsulting.com.au/

Model more than Claudia Schiffer and Naomi Campbell combined….

Business analysts should model scenarios, functions and discussion points from day one of the project. Modelling helps break down communication barriers and encourages team members to discuss options and solve problems.

Use UML models at the first opportunity, even if your department doesn’t practice them officially. They will be enlightened to see simple, clear descriptions of your requirements, compared to the structured techniques from the past. Concentrate on the use case diagram and a conceptual class diagram at first. If you have a Business Analyst who does this exceptionally well in your organisation, pay them really well and try to retain them. They are very hard to find.

Many business representatives instantly warm to the use case diagram, because they can see themselves within the diagram, playing out a role or using the new system. The use case diagram is a great way of building rapport with your business representatives. Encourage them to help you model this diagram, include their business vocabulary in the use case names wherever possible.

Try to avoid users corporate job titles as the names of your actors in the use case model. Use actor hierarchies to show them where they may fit in exactly.

Once I had a client insist that she needed to be on the use case model as a Client Manager because, 1) she was important and 2) she was the boss. That’s fine! It showed that she was keen to help out and define the requirements. I did not want to offend her and make my job harder but when I asked her about the exact functionality she would require, it turned out she only wanted to enquire on existing deals.

So I explained to her that the system didn’t need to know her precise corporate job title, it just needed to know what future functionality attracted her interest. I then showed her that she could achieve the goal of enquiring on orders by using the general user “view only” access to the system.

There was also an Approver user, a Submitter user and an Administrator user on the use case model. They had more defined and direct needs. It turned out that she wouldn’t require such advanced functionality.