Kashif’s Blog

This summer i want to write mainly about stakeholders of a project.

“Any person who has some interest in a project or influenced by that project is a stakeholder of that project.”

In this blog i want to discuss about Stakeholders prospectives which is always a very tricky exercise for a Business Analyst.

A perspective is an overview and understanding of a stekholder about an organization or a specific situation. For example, in a bank, a cashier can think it important to give best services to customers. But a marketing director can think about giving best marketing services and sales of the bank. Here a cashier has a different perspective and a marketing director of the same organization(bank) has a different perspective.

A useful framework to manage stakeholders perspectives is CATWOE.

C - Customer

A - Actor

T- Transformation

W - World View

O - Owner

E - Environment

Stakeholders perspectives can be modelled using Business Activity Modelling(BAM) technique which i will discuss in my next blog.

A list of Business Analysis books to read:

Click here

I have recently read ISEB Busienss Analyst book by Debra Paul. This book is available to buy from British Computer Society and from Amazon as well.

Good luck with your reading.

A competency is something a business analyst needs in order to perform his or her job effectively.

The set of business analysis competencies can be divided into three broad groups.

• Behavioural skills and personal qualitie
• Business knowledge
• Techniques

Behavioural skills are arguably more important than technical or business skills, as they are prerequisite for working with other people.
It is often said that it is easier to give a person with good behavioural skills the techniques needed for a job than to graft behavioural skills on to a good technician.

The following are the typical problems which causes a poor requirements analysis:

• lack of relevance to the objectives of the project;
• lack of clarity in the wording;
• ambiguity;
• duplication between requirements;
• conflicts between requirements;
• requirements expressed in such a way that it is difficult to assess whether they have been achieved;
• requirements that assume a solution rather than state what is to be deleivered by the system;
• uncertainity among business users about what they need from the new system;
• business users omitting to identify requirements;
• inconsistent levels of detail;
• users and analysts taking certain knowledge for granted and failing to ensure that there is a common understanding;

The first point often results from a lack of terms of reference for the project. The eighth difficulty, that the users are uncertain of their needs, is by no means uncommon in a world of new business practices and enw technology. The business analyst is the person who must help the users to visualize precisely what they need the new system to perform and then to articulate it.

Another source of diffculties for the business analyst is recognising the different viewpoints behind each user.

A Business Analyst therefore must be very careful about requirements analysis as a large proportion of errors are introduced at the requirements analysis stage. 

The above detailed points are taken from ISEB Business Analysis book by Debra Paul. While studying the Requirements Engineering chapter, i found it worthwhile to share these points with you:)