A common problem I tend to notice is that many Business Analysts take a passive requirements gathering approach, that is to simply write things down like a scribe or court stenographer. This can happen when the business whom you are to represent, fail to give the BA access to quality SME's. Experienced BA's should see through this and escalate problems to the program director or project managers immediately, realising they could botch the requirements up if they don't have access to the people in the know.

This has happened to me recently. I couldn't get a hold of key people. I simply outlined the points or areas I needed to cover, stated that only "such and such" resources can help me and without them, "we will not have a sound platform" to move the project forward. Never be afraid to get what you want as a BA. You are critical to the whole project. Requirements gathering is such an important phase well worth investing time and money into.

Requirements are generally considered good enough if:

• The business can understand them and can validate them
• They solve the business problem
• Your business reps and stakeholders are happy
• Requirements are not wedded to design

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.

What vs How

http://www.snjtechconsulting.com.au One of the biggest dilemma's BA's face is how much detail to include and to satisfy the users representatives, the business and the development team. It is best to avoid detailed design like the right hand side of the above diagram, use cases should never be 'fully loaded'.

Most of the time you will find that the essential software requirements are often stable enough, however the design associated with the requirements is often very volatile and shouldn't be described too much early on.

Business analysts must keep their thoughts in the problem domain for as long as possible and resist becoming fixed on designs, screens or layouts until they have understood and conveyed the business domain comprehensively. There is nothing worse than spending days and even weeks on design for a functional requirement and then be told that 'piece' of functionality isn't required anymore.

What level of detail must a business analyst describe? And how much is too much?

The more you document, the more you will have to change. Scott Ambler says that “barely enough is good enough”. Business analysts and application development departments can unintentionally abuse use cases much more than they need to be. Most would agree that you do not want to build the system on paper first and try to think and incorporate every single viewpoint and must have design requirement (buttons, backgrounds, URL’s etc)

Most of the time as history has proved, too much documentation is simply a waste of time and money. Why? Well because during this ‘discovery phase’ it is human nature to think, discuss, validate and reject many ideas, but by documenting most of these even in a simple format I have seen some BA’s basically document the requirements specification at the command of the programmer, detailing every single error message, the exceptions and technical components called. At this point it is obvious the BA has lost his/her role in the project and has become a “gofer”. The requirements specification normally describes the business and user functional requirements. Real software design doesn’t usually start at this stage of the project and maybe the BA has been roped into design considerations from a simple harmless discussion.


Use cases or documentation development?

Have you seen too many alternate flows or exceptions in use cases? I have seen up to 20 different alternate flows for some use cases. Of course many error messages listed in use cases are alternate flows from the perspective of the programmer, certainly not the user. Use cases should always be written from the perspective of the user.

Many alternate flows are not within the problem domain of the user trying to achieve a goal. They should really belong in an implementation document and need not be shown to user or business representatives for the purpose of signing off the functional requirements.

What issues have you found when working with requirements documentation? Please share your stories.

Welcome

http://www.snjtechconsulting.com.au

Welcome to my blog

So you have just got that job as an IT Business Analyst. Congratulations! Did you come via a business role where you helped work on some projects, and management thought to themselves “lets make this person a BA”. Or have you just completed a Business Information Systems degree or similar and have decided that a client facing, anti programming, fact gathering role suited you better?

Well you have made a great career choice either way. Predictions from many corners of the world are saying the business analyst in IT is one of the fastest growing roles. Everyday people like you and me need to use more and more software in our daily lives. Mobile phone applications, internet and government applications are on the rise.

A business analyst can work from one industry to the next without much trouble. Since the job is about understanding what business and users want for a particular objective, you simply help take the orders, make a few suggestions and document/model the requirements according to the company policies or methodologies.

Hot jobs in 2010

http://www.computerworld.com/action/article.do?command=viewArticleTOC&articleId=112360

For instance, someone at this site would have had to model and gather the users requirements for the operation and fundamentals of this blogging service. Authoring, loading, auditing, checking, user management and registration…the list goes on.

A business analyst would have had to define, interview and double check all the functionality with business representatives and users alike. What would be popular with users? What hasn’t worked elsewhere in the blog community? The IT business analyst is the right smack bang in the middle of all projects and they are one of the most valuable members of any project. Who else does all the liaising between departments, validates, confirms and workshops ideas.

Degrees of change - CIO.com.au

You also have a global ticket to work in this world, especially Europe and Asia and before too long, China will be needing many BA’s. At least the corporates can’t offshore BA’s at present and many seem to think that it will never happen. A standard set of tools and practices is slowly starting to form for the business analyst. UML, RUP, Use cases, data modelling. Many books from world class authors such as Richter, Larman and Simison are ever popular. So what soft and hard skills do BA’s use? Diagramming, modelling, interviewing, writing documents…

So what are the two most important UML models for the business analyst?
The Use Case diagram and the Class diagram.

The Use Case diagram express the business and system functionality while the Class diagram describes the relationships between objects.

Difficult situations

A few years back I had a business representative complain that my requirements document wasn't up to scratch. I was told that there was no relationship between the use cases and that it was lacking in precise detail. It went further, he stated that it beared little resemblence to the feasibility document and that the requirements document needed to be useful for the life of the software, not just the vendor selection.

I answered the following way. Firstly, there is no need to have linked relationships between use cases, each one needs to stand on it's own to help the user acheive a goal. Secondly, I informed him that use cases weren't designed for extreme details like fields and screens. It would be like using an Excel spreadsheet to write a letter. I asked for another 6-8 weeks to satisfy the request for extreme details that early in the project, but he sheepishly declined. Software development was the focus, not documentation development.

I also mentioned the requirements document can be a great foundation for a user manual since it describes the relationship between the user and system. A user manual is better placed than a requirements document to teach new users how to use a system.

Serve End Users - Not your Egos

Here are some web sites that explain use cases...

Agile Modelling - Use Cases

Visual Case

Agile Modelling - System Use Cases

IBM Rational Works

Use case modelling tips