Recent Posts

Pages: [1] 2 3 ... 10
Business Analyst Concepts Discussion / Challenges faced by BA
« Last post by PavanB on January 23, 2018, 03:36:52 pm »
What are the challenges faced by business analyst in real time?
Business Analyst Concepts Discussion / Re: What is RACI matrix
« Last post by 1173025809 on January 23, 2018, 02:39:32 pm »
RACI stands for responsible, accountable, consulted and informed, where -
Responsible: person who performs an activity or does the work.
Accountable: person who is ultimately accountable and has Yes/No/Veto.
Consulted: person that needs to feedback and contribute to the activity.
Informed: person that needs to know of the decision or action.

A RACI chart is a matrix of all the activities or decision making authorities undertaken in an organisation set against all the people or roles. A RACI analysis is useful for:-
- Workload Analysis: when used against individuals or departments overloads can be quickly identified.
- Re-organisation: to ensure that key functions and processes are not overlooked. Employee Turnover: newcomers can quickly identify their roles and responsibilities.
- Work Assignment: allows duties to be redistributed effectively between groups and individuals.
- Project Management: allows for flexibility in matrix management situations allowing for the right balance between line and project accountabilities.
- Conflict Resolution: provides a forum for discussion and resolving inter-departmental conflict.
- Documents the Status Quo: the output from RACI is a simple yet effective method of documenting the roles and responsibilities in an organisation.
Business Analyst Concepts Discussion / Re: What are the Non Functional Requirements
« Last post by 1173025809 on January 23, 2018, 02:25:18 pm »
In addition to the obvious features and functions that we will provide in our system, there are other requirements that don't actually do anything, but are important characteristics nevertheless, are called "Non-functional requirements" or sometimes "Quality Attributes."

For example, attributes such as performance, security, usability, compatibility are not a "feature" of the system, but are a required characteristic. We can't write a specific line of code to implement them, rather they are "emergent" properties that arise from the entire solution. The specification needs to describe any such attributes the customer requires. We must decide the kind of requirements that apply to our project and include those that are appropriate.

Here are some examples of non-functional requirements:

1. Performance requirements -
Requirements about resources required, response time, transaction rates, throughput, benchmark specifications or anything else having to do with performance.

2. Operating constraints -
List any run-time constraints. This could include system resources, people, needed software, ...

3. Platform constraints -
Discuss the target platform. Be as specific or general as the user requires. If the user doesn't care, there are still platform constraints.

4. Accuracy and Precision -
Requirements about the accuracy and precision of the data. (Do you know the difference?) Beware of 100% requirements; they often cost too much.

5. Modifiability -
Requirements about the effort required to make changes in the software. Often, the measurement is personnel effort (person- months).

6. Portability -
The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing.

7. Reliability -
Requirements about how often the software fails. The measurement is often expressed in MTBF (mean time between failures). The definition of a failure must be clear. Also, don't confuse reliability with availability which is quite a different kind of requirement.  Be sure to specify the consequences of software failure, how to protect from failure, a strategy for error detection, and a strategy for correction.

8. Security -
One or more requirements about protection of your system and its data. The measurement can be expressed in a variety of ways (effort, skill level, time, ...) to break into the system.  Do not discuss solutions (e.g. passwords) in a requirements document.

9. Usability -
Requirements about how difficult it will be to learn and operate the system. The requirements are often expressed in learning time or similar metrics.

10. Legal -
There may be legal issues involving privacy of information, intellectual property rights, export of restricted technologies, etc.
Business Analyst Concepts Discussion / Re: Basics of Gap Analysis
« Last post by 1173025809 on January 22, 2018, 11:09:05 pm »
Any exercise that involves comparing the present state of the business with a conceptual and desired future state, with the objective of “closing the gap” can be called Gap Analysis.
As far as business definition is concerned, gap analysis can be defined in a number of ways, which more or less point towards the same meaning:
1. It is the process through which a company compares its current or actual performance to its expected performance to determine whether it is meeting its objectives and using its resources effectively.
2. It is a technique that businesses use to determine what steps need to be taken in order to move from their current states to their desired future states.

Gap Analysis can be done in three stages -

1. Accurately defining the required changes/future goals: If you are not clear about the organization’s goals, all your efforts will be in vain. The first and foremost thing to be done is to identify what exactly the goals of the business are and the changes needed to achieve these goals. If the goal is not clear, the improvement exercise will keep on deviating from its desired path.

2. Identifying the current scenario and associated issues: In order to reach ‘where you want to be’, you have to first assess ‘where you stand.’ For example, a failure to see the real reason behind the poor performance of the relevant units of your business may affect profit and growth on the long run. At this stage, the analyst may organize brainstorming sessions, employee interviews, document review sessions to gain insight into present challenges. Only after a comprehensive definition of present challenges can one get a clear picture of the situation.

3. Devising the action plan: Now that you know the present and future expectations, you can think of the how factor, which is in form of a plan. How will you implement the action plan to close the identified gaps? The solutions may include a number of steps like hiring more employees, procuring extra machines and equipment, offering perks and incentives to get the best out of employees and so on.
Business Analyst Concepts Discussion / Re: Tools used by Business Analyst
« Last post by 1173025809 on January 22, 2018, 06:05:46 pm »
From my little usage and understanding on the functionality of Tools pointing out some of widely used in Business Analyst are -
1. Documentation: MS Word.
2. Presentation: MS Powerpoint. Similar rules as above.
3. Data Analysis: MS Excel.
4. Modeling, Flowcharts: MS Visio.
5. Wire-framing, Mockups: Balsamiq, MS Visio.
6. Communication, Collaboration: A good understanding of how to “effectively” use email, chat, phone, audio and video conferencing, web meeting, shared network/cloud storage systems, SVN.
An elicitation technique is any of a number of data collection techniques used in anthropology, cognitive science, counseling, education, knowledge engineering, linguistics, management, philosophy, psychology, or other fields to gather knowledge or information from people.

Typically the BA is dealing with a variety of input points (that is, IT, sales, and finance) where each has a different documentation and reporting structure, often along with a unique culture and language. Strong organizational and communication skills are required during this phase, as it is generally up to the BA to shape the information into models, diagrams, and other tools to communicate the findings to decision makers and to team members.

Enterprise opportunities, restrictions, assumptions, and current reality are all reflected by stakeholders during requirements elicitation. The BA must be able to resolve conflicts between requirements, eliminate the potential for conflicts (if possible), and achieve consensus among team members and stakeholders as requirements are defined and prioritised.
When considering elicitation activities, the BA must develop strategies for two primary functions: Preparing for Elicitation and Conducting Elicitation.

Requirements Elicitation Techniques -
-Document Analysis
-Focus Groups
-Interface Analysis
-Requirements Workshops
Business Analyst Concepts Discussion / Re: What is Importance of flow chart
« Last post by 1173025809 on January 22, 2018, 05:45:05 pm »
A flowchart is a type of diagram that represents an algorithm, workflow or process.
The Business Analysis Body of Knowledge defines a flowchart as a "Visual representation of the sequential flow and control logic of a set of related activities or actions." They are often employed by Business Analysts as a non-UML process modelling tool.
The major importance of Flowchart are -
1. Process Documentation.
2. Workflow Management and continuous improvement.
3. Programming.
4. Troubleshooting Guides.
5. Regulatory and Quality Management Requirements.
Business Analyst Concepts Discussion / Re: Basics of Gap Analysis
« Last post by 1171921109 on January 21, 2018, 09:57:44 pm »
Gap Analysis is the process of comparing two things in order to determine the difference or “gap” that exists between them.   Once the gap is understood, the steps required to bridge the gap can be determined.

Most often gap analysis is used to compare two different states of something; the current state and the future state. 

Gap analysis can be conducted on:

1) a system – features that exist in the system now versus the features that need to exist in the future
2) a system interface – data that a system provides to an interface now versus data that will need to be provided in the future
3) a business process – activities and steps of a current business process versus the activities and steps that will be supported by the business process in the future
4) business goals and metrics – how well a business meets certain goals and metrics now versus the targeted goals and metrics at some point in the future.
Business Analyst Concepts Discussion / Re: SME
« Last post by 1171921109 on January 21, 2018, 09:55:11 pm »
My view is that while business domain knowledge does matter, analysis skills and experience are far more important. It is certainly important to have a basic understanding of the industry in which you are working, as this helps you to know which questions to ask when starting a project.  However,  this knowledge is something that can be expanded upon over time as you gain exposure to more and more projects.  In fact, in my experience, new BAs from outside industries are often able to add a huge amount of value by “questioning” standard industry norms and conventions and adding a new focus on true objectivity.

To draw an analogy, I view core Business Analysis work as a bit like driving a car.  You learn a core set of techniques up-front and learn even more when you apply them in all sorts of terrains and adverse conditions.  You learn to be creative and use different tools and techniques when need to get a particular result.

Changing industries as a BA is a little like driving in an unfamiliar country.  You need to know the basic rules of the road and you need a map.  But once you have these things, you can drive as effectively and efficiently as you could back home (using all or most of the same techniques).

Driving is driving. The analysis is analysis. In both cases, you need a map of the landscape, and you need to read the map before you set out. However, you don’t need to understand the mechanics of the engine at the outset – and if you do eventually need to know this there will hopefully be a mechanic (SME) to help you!

However, I do believe that there are a number of core skills above and beyond the benchmark BA competencies that are of particular relevance when changing industries or projects
Business Analyst Concepts Discussion / Re: Business Analyst delivered documents.
« Last post by 1171921109 on January 21, 2018, 09:49:28 pm »
Business Analyst delivered documents.

Each of these documents has a specific template and it’s a part of the overall project documentation. The documents are:

1) Project vision Document
2) Requirement Management Plan
3) User stories
4) Use cases
5) Business Requirement Document
6) Requirement traceability matrix (RTM)
7) Functional requirement specification (FRS)/ Functional Specification Document (FSD)
8) System requirement specification (SRS)/ System Requirement Document (SRD)
9) Test case
Pages: [1] 2 3 ... 10