Recent Posts

Pages: [1] 2 3 ... 10
Business Analyst Concepts Discussion / Re: SDLC Methodology
« Last post by 171036906 on November 11, 2017, 09:42:30 am »
Software development life cycle (SDLC) is important for the software project success, the good software engineer should have the enough experience and knowledge to prefer an choose one model than another based on the project context.

Therefore, it may be required to choose the right SDLC model according to the specific concerns and requirements of the project. I wrote another article on how to choose the right SDLC, you can follow this link for more information.

In this article, we will explore the different types of SDLC models and the advantages and disadvantages of each one and when to use them.

Types of Software developing life cycles (SDLC)
Waterfall Model
V-Shaped Model
Evolutionary Prototyping Model
Spiral Method (SDM)
Iterative and Incremental Method
Agile development
Business Analyst Concepts Discussion / Re: what are the thumb rules of BA
« Last post by 171036906 on November 11, 2017, 09:40:55 am »
Anywhere, here are my rules of thumb to start the discussion:
Learn the language
It is your responsibility to understand the business domain.
It is not unreasonable that you don’t understand the domain but it needs to be recognised and planned for at the outset of the project, potentially with the assistance of the subject matter experts.
You need to ensure you get up to speed as quickly as possible and using the minimum of stakeholders’ time
Active listening
Listen to the client and replay what you have heard, constantly.
Repeat it in different ways to the client and other stakeholders.
Ask questions around the subject to ensure you understand all the variations and the nuances.
‘Reframing’ is an effective technique to confirm understanding and drive out detail, issues, assumptions and increase understanding.
Challenge all assumptions
Be determined and risk being unpopular (in the short term) for the project good.
If you don’t understand why an assumption has been made or why it is justified, challenge it!
If you don’t understand it, there is a good chance someone else doesn’t either.
Understand everything
Ensure you understand everything. If you don’t understand it then there is a risk it is wrong or unnecessary, all of which will contribute to problems or further cost later in the project.
You don’t need to understand the technical solution but you do need to understand all the requirements and be clear on their rationale and the benefit they provide.
If you can’t say this with all honesty, you need to be asking questions.
Be a guardian
You need to protect all of the following:
Objectives, requirements and sponsor’s budget
All stakeholders’ interests
Other people’s time
You must ensure the objectives are documented, agreed and understood and requirements contribute to those objectives. This ties in with protecting the sponsor’s budget to ensure project time is invested in what has been agreed and is not hijacked by local stakeholder interests.
However, you do need to ensure stakeholders are heard and their interests are protected.
Business Analyst Concepts Discussion / Re: What is RACI matrix
« Last post by 171036906 on November 11, 2017, 09:39:19 am »
Delegation is an essential part of a project manager's role, so identifying roles and responsibilities early in a project is important. Applying the RACI model can help. As the project manager, it is important that you set the expectations of people involved in your project from the outset.

Projects require many people's involvement, but how do you avoid a situation where people are struggling against one another to do a task. Equally difficult is dealing with a situation where nobody will take ownership and make a decision. How do people know their level of responsibility; when they should involve you their project manager, or when they should exercise their personal judgment?

The RACI model is a straightforward tool used for identifying roles and responsibilities and avoiding confusion over those roles and responsibilities during a project. The acronym RACI stands for:

Responsible: The person who does the work to achieve the task. They have responsibility for getting the work done or decision made. As a rule this is one person; examples might be a business analyst, application developer or technical architect.
Accountable: The person who is accountable for the correct and thorough completion of the task. This must be one person and is often the project executive or project sponsor. This is the role that responsible is accountable to and approves their work.
Consulted: The people who provide information for the project and with whom there is two-way communication. This is usually several people, often subject matter experts.
Informed: The people kept informed of progress and with whom there is one-way communication. These are people that are affected by the outcome of the tasks, so need to be kept up-to-date.
Without clearly defined roles and responsibilities, it is easy for projects to run into trouble. When people know what management expect of them, it is easier for them to complete their work on time, within budget and to the right level of quality.

A RACI matrix supports the model and is used to discuss, agree and communicate roles and responsibilities.

Creating a RACI Matrix (step-by-step)
Identify all the tasks involved in delivering the project and list them on the left-hand side of the chart in completion order.
Identify all the project roles and list them along the top of the chart.
Complete the cells of the chart identifying who has the responsibility, the accountability and who will be consulted and informed for each task.
Ensure every task has a role responsible and a role accountable for it.
No tasks should have more than one role accountable. Resolve any conflicts where there is more than one for a particular task.
Share, discuss and agree on the RACI Matrix with your stakeholders before your project starts.

A variation of RACI used by the Project Management Institute (PMI) is RSI, responsible, sponsor and informed.

Other variations are:

RASCI: with the 'S' standing for 'Support'
RACIO: with the 'O' standing for 'Out of the Loop' or 'Omitted'
RACI-VS: with the 'V' standing for 'Verify' and the 'S' for 'Signatory'
What is a requirement?

A requirement in the context of Business Analysis is simply a statement provided by a stakeholder about what they believe they need in order to solve a particular business problem or respond to a specific business need.  Once this requirement has been raised by the stakeholder it is the business analyst’s role to further define, analyze, validate and prioritize the requirement statement as it is now included within the business analysis context of requirements management. In real life, the stakeholder will typically state their business problem or need and then provide a whole range of individual requirements throughout the requirements management process managed by the business analyst.

Business Requirements

Business Requirement Example: “Build a family home to replace the home that was burnt down including the addition of a garage. “

The Business Requirement is a high level statement describing what is required from the business’s perspective. In some contexts or projects there may be overlap between the Business Requirements statements and that of individual scope statements. For larger initiatives these will be different levels of expressing what is required.

Stakeholder Requirements

Stakeholder Requirement Example 1: “We need a family house with four bedrooms so that each child has their own bedroom”
Stakeholder Requirement Example 2: “We need the house to have two separate bathrooms to ensure the parents have their own bathroom separate from the children”
Stakeholder Requirement Example 3: “We need the house to be protected against future bush fires so that we don’t have to fear loosing our house again”
These examples are requirements, which are describing “what” the family need the new house to have. It is important to understand here that this type of requirement, the stakeholder requirement is not stating how they want these requirements to be implemented, they are simply stating what is required.  As a Business Analyst you must guard against requirement statements at this early stage of the project, which describes “how” to deliver the requirement. In the context of this example an example of a requirement, which describes “how” rather than “what” is needed would be this: “The family’s little girl states that she wants her bedroom to be painted pink with butterflies on the wall.” There are many stakeholders that will do exactly what the little girl has done and tell you as the business analyst how they want the solution to work before they have stated what exactly they are in need of.  The little girl is assuming that you know that she needs a bedroom and all she is concerned with is how the bedroom will look. Keep this in mind when you speak to your stakeholders in future about stakeholder requirements.

Solution Requirements

Solution Requirement Example 1: “I want my bedroom to be painted pink so that everyone will know it is my room” – Stakeholder who raised this requirement is the little girl.
Solution Requirement Example 2: “I want my bedroom floor space to be at least 30 square meters so that I can practice my skateboard tricks in the bedroom” – Stakeholder who raised this requirement is the teenage boy in the family.
Solution Requirement Example 3: “Every bedroom must have an air-conditioning unit implemented so that the family can stay cool during the summer” – Stakeholder who raised this requirement is the father in consultation with the architect.
Solution Requirement Example 4: “ The house must have fire resistant insulation in all the walls of the house to prevent significant fire damage.” – Stakeholder who raised this requirement is the builder who is adhering to a regulatory requirement.
The solution requirements describe how the stakeholder wants to implement their stakeholder requirements. In this example, the stakeholder requirement relating to having four bedrooms has been expanded upon with more specific solution requirements describing how that stakeholder requirement must be implemented (Solution requirements 1, 2 and 3 are expanding on that stakeholder requirement). Take note here that as you progress with your Requirements Analysis you are delving into more specific and detailed requirements.

Also keep in mind that although Solution Requirement example 2 has been stated and documented, it may be deemed invalid during a requirement validation session with all stakeholders in the room. It is important to capture all requirements but it is also important to validate and ensure that all stakeholders are in agreement about which requirements are in fact valid. In this example, the validation criteria may include budget constraints, which may be the reason why the teenage boy cannot have such a large room after all.

There are two sub-types of Solution Requirements:

Functional Requirements: This type of solution requirement describes how the solution must behave. In the example of the house, it describes how the house must look (colors, size of bedroom) and perform (have an air-conditioning unit in each bedroom). In a system related scenario example, the different functions that you want a system to perform is typically described as functional requirements (in an Agile Project context, it is referred to as a ‘user story’). An easy way to remember this type of solution requirement is to think about what do you want to the system to be able to do. Another example in the context of the house would be that a functional requirement exists to have internal doors, which can be opened and closed but not locked. This is something that you want the house to be able to do, a function you want the house to be able to perform.
Non-functional Requirements: The non-functional requirement type of solution requirement describes the characteristics that you want the system to have. In the context of the house example, solution requirement 4 is describing a characteristic that is required of the house walls. It is not a function of the house but rather a characteristic of the walls. In the scenario of a system an example that compares to this house analogy would be a non-functional requirement describing the need to have a backup-system installed to be used in the event of a disaster to prevent unnecessary data loss. The non-functional type of solution requirement therefore describes the attributes a system or process should possess and not a function that the system must perform.
Transition Requirements

Transition Requirement Example: “The floors in the house must be covered with sheets to protect the carpets when the moving company moves the furniture into the house.”

A transition requirement describes a requirement that must be in place for a certain phase or period of time. In this example, the requirement to have the floor protect during the moving of furniture into the house is an example of a transition requirement. In the context of a system, a transition requirement could be that additional support staff must be available during the first month after the system have been implemented to assist with additional support queries that may be received.

In Conclusion

Once the Business Analyst has a clear picture about the different types of requirements and consequently the levels of detail of requirements it becomes second nature when identifying and categorizing requirements for a project. Requirements Analysis is all about understanding these types of requirements and managing them effectively through the Requirements Management Processes of a project.
Business Analyst Concepts Discussion / Re: SME
« Last post by 171036906 on November 11, 2017, 09:30:33 am »
A subject matter expert in business (also known as SME) is an individual with a deep understanding of a particular process, function, technology, machine, material or type of equipment. Individuals designated as subject matter experts are typically sought out by others interested in learning more about or leveraging their unique expertise to solve specific problems or help meet particular technical challenges.

Subject matter experts in some fields often serve as expert witnesses in lawsuits and other legal actions.

Typically, subject matter experts have developed their expertise in their particular discipline over a long period of time and after a great deal of immersion in the topic. Many subject matter experts have pursued advanced degrees in their area of specialization. Additionally, the experts maintain a rigorous program of continuous study in their field. Many are active as authors, publishing books or articles on their topic. Others serve as educators in college and universities. This additional work and study helps ensure the SME individual maintains a current and complete knowledge of their specific area of expertise.

It is common to draw upon a subject matter expert when attempting to navigate a particularly difficult challenge or problem. While many professionals are cross trained in their particular functions, some situations call for highly specialized knowledge. 

Information technology professionals will call upon various subject matter experts for insights into integrating new software applications or, fixing bugs or anomalies discovered during testing. 

Architects and engineers will call upon experts when considering new building technologies or design approaches.
Project teams engage subject matter experts when their more generalized knowledge of a topic is insufficient for the problem in front of them.
In the legal industry, expert witnesses are typically highly specialized subject matter experts called upon to testify in court cases, especially liability lawsuits.
Innovators striving to apply new technologies or advancements will often draw upon the originators or external specialists to help them solve specific technical or business challenges.
Business Analyst Concepts Discussion / Re: Tools used by a Business Analyst
« Last post by 171036906 on November 11, 2017, 09:28:19 am »
What activity does a business analyst spend a significant amount of time on? Communication. Microsoft Visio is a software application that aids communication and can be used for capturing and presenting ideas to stakeholders. You can use Visio for:

·       Preparing UML diagrams such as use case, activity and sequence diagrams.

·       Preparing process flow charts.

·       Creating data models.

·       Creating architecture diagrams, among other functions.
isio is easy to use and provides features for creating templates, applying themes and embedding models in other documents.

Visio is only one example, however. There are loads of diagramming software in direct competition with Visio, like Lucidchart.

Word Processing: Microsoft Word

Microsoft Word is another important and popular software application in the business analyst’s toolkit. For organizations not ready to acquire Requirements management tools, Microsoft Word can be used as a substitute for preparing requirements specification documents. You can create new templates using Microsoft Word or use existing templates for the documentation of software requirements. Microsoft Word allows you to set preferred fonts; apply your company’s theme; embed external objects such as Visio diagrams or Excel worksheets; create visuals and track changes where collaboration has taken place.

Analysis & Data Crunching: Microsoft Excel

When you require any kind of data analysis on the job, spreadsheet applications like excel can come in handy. If you want to create pivot tables; examine trends in data; sort and filter data; create charts or graphs, Microsoft Excel can fulfil that purpose and more. Excel provides many built-in mathematical and financial functions that can aid analysis.

Wireframing: Balsamiq

Many a time, you will be working with stakeholders who need more than requirements specification documents or use cases. You need to learn how to use wireframing applications to create mockups of how your proposed system will look or work. Wireframes focus on content, user interaction and but not on internal processing. Balsamiq is a useful tool for creating wireframes quickly in brainstorming sessions and for getting immediate feedback from stakeholders. Business analysts and designers use this category of tools for creating mockups which once signed off, can be converted into actual system designs.

Requirements Management: Rational Requisite Pro

One of the most popular Requirements management tools is Rational Requisite Pro. If you are part of a team of business analysts working on a large project, you are likely to require a more robust solution like this for managing your requirements. Requirements management tools provide the functionality of word processing along with the capability to sort and query data using a dynamic database. This makes it easy to trace requirements along with their changes and prioritize them for implementation. Requirements management tools also have features for conducting impact analysis and managing an audit trail of changes.

Collaboration: Google Docs

More often than not, Business Analysts will need to share documents with team members and stakeholders. Google Docs is a very useful tool for sharing non-confidential work online; chatting and collaborating with other stakeholders on the project.

Presentation: Microsoft Powerpoint

The last but definitely not the least, is a software tool for preparing and delivering formal presentations. As a business analyst, you will be faced with situations where you need to communicate ideas, justify your position or deliver updates to project stakeholders. Delivering a presentation can be made easier with a presentation software like Powerpoint or Keynote.

This article has listed some of the most popular software tools used by Business Analysts. A decision on which specific tools to go for would naturally depend on key factors like your unique requirements and budget.
Business Analyst Concepts Discussion / Re: What is Importance of flow chart
« Last post by 171036906 on November 11, 2017, 09:26:18 am »
Few importance of flow charts for organisation:

Workflow Management and Continuous Improvement

Workflows don't manage themselves. To ensure that you are meeting your customers' needs, you need to take control of your business processes. The first step to workflow management is to define the current state of your processes by creating an "As-Is Flowchart". That allows you to analyze your processes for waste and inefficiency. After you have identified areas for process improvement, you can then craft new flowcharts to document the leaner processes.


Information technology played a big influence on the use and spread of flowcharts in the 20th century. While Dr. W. Edwards Deming was advocating their use in quality management, professionals in the data processing world were using them to flesh out their programming logic. Flowcharts were a mainstay of procedural programming, however, and with the advent of object oriented programming and various modeling tools, the use of flowcharts for programming is no longer as commonplace as it once was.

That said, even with in the scope of object oriented programming, complex program logic can be modeled effectively using a flowchart. Moreover, diagramming the user's experience as they navigate through a program is a valuable prerequisite prior to designing the user interface. So flowcharts still have their place in the world of programming.

Troubleshooting Guides

Most of us have come across a troubleshooting flowchart at one time or another. These are usually in the form of Decision Trees that progressively narrow the range of possible solutions based on a series of criteria. The effectiveness of these types of flowcharts depends on how neatly the range of problems and solutions can fit into a simple True/False diagnosis model. A well done troubleshooting flowcharts can cut the problem solving time greatly.

Regulatory and Quality Management Requirements

Your business processes may be subject to regulatory requirements such as Sarbanes-Oxley (SOX), which requires that your accounting procedures be clearly defined and documented. An easy way to do this is to create accounting flowcharts for all your accounting processes.
Business Analyst Concepts Discussion / Re: What are the Non Functional Requirements
« Last post by 171036906 on November 11, 2017, 09:02:29 am »
I wanted to give a little more detail about each of the items on that list, and there's a good excerpt that I think will help.

Availability: A system's availability, or "uptime," is the amount of time that it is operational and available for use. This is specified because some systems are designed with expected downtime for activities like database upgrades and backups.
Efficiency: Specifies how well the software utilizes scarce resources: CPU cycles, disk space, memory, bandwidth, etc.
Flexibility: If the organization intends to increase or extend the functionality of the software after it is deployed, that should be planned from the beginning; it influences choices made during the design, development, testing, and deployment of the system.
Portability: Portability specifies the ease with which the software can be installed on all necessary platforms, and the platforms on which it is expected to run.
Integrity: Integrity requirements define the security attributes of the system, restricting access to features or data to certain users and protecting the privacy of data entered into the software.
Performance: The performance constraints specify the timing characteristics of the software. Certain tasks or features are more time-sensitive than others; the nonfunctional requirements should identify those software functions that have constraints on their performance.
Reliability: Reliability specifies the capability of the software to maintain its performance over time. Unreliable software fails frequently, and certain tasks are more sensitive to failure (for example, because they cannot be restarted, or because they must be run at a certain time).
Reusability: Many systems are developed with the ability to leverage common components across multiple products. Reusability indicates the extent to which software components should be designed in such a way that they can be used in applications other than the ones for which they were initially developed.
Robustness: A robust system is able to handle error conditions gracefully, without failure. This includes a tolerance of invalid data, software defects, and unexpected operating conditions.
Scalability: Software that is scalable has the ability to handle a wide variety of system configuration sizes. The nonfunctional requirements should specify the ways in which the system may be expected to scale up (by increasing hardware capacity, adding machines, etc.).
Usability: Ease-of-use requirements address the factors that constitute the capacity of the software to be understood, learned, and used by its intended users.
Here are the 9 elicitation techniques defined by the BABOK for business analysts:

Document Analysis
Focus Groups
Interface Analysis
Requirements Workshops

Many new BAs feel they should be using all of the techniques and are worried they aren’t getting elicitation right. Or, they think about their experience in this area and it seems that most of the time they get information about stakeholder needs through casual conversations and reviews, so their experience with elicitation seems a bit informal.

This is an area of business analysis that it’s very common for professionals to have relevant experience in. It’s also an area where even the most senior BAs never stop improving.
Business Analyst Concepts Discussion / Re: Product Owner Role
« Last post by 171036906 on November 11, 2017, 08:44:52 am »
Here are the top ten activities  a Product Owner must perform well in order to keep project teams effective:

1.Creates and MAINTAINS the Product Backlog. I emphasize MAINTAINS as this is an on-going job and more than likely a full-time activity. Nothing is constant in the world of software and it’s important that the Product Owner keeps his/her eye on the ball. Note: the Product Backlog must be groomed prior to the Sprint Planning Meeting in order for the team to remain productive.

2. Prioritizes and sequences the Backlog according to business value or ROI (there are lots of tools to help Product Owners do this and lots of books on the subject) The Product Owner is required to have the Backlog sequenced prior to the Sprint Planning Meeting. This means that each user story must be ordered by relative importance. It’s no good to have 5 high priority or 5 medium priorities. It’s important to know which User story is #1, which is #2 etc.

3. Assists with the elaboration of Epics, Themes and Features into user stories that are granular enough to be achieved in a single sprint. User Stories are elaborated at the last responsible moment and it is the Product Owners responsibility to be there during the Sprint Planning meeting to help the teams to understand exactly what is required.

4. Conveys the Vision and Goals at the beginning of every Release and Sprint. The Product Owner must continuously remind the Team of the Sprint and Release goals. This helps to keep the team on track and serves as an over-arching yardstick for the team to measure their activity and progress against.

5. Represents the customer, interfaces and engages the customer. The Product Owner must continuously engage the customer and stakeholders to ensure the Team is building the right product and therefore delivering the ROI expected of it. The Product Owner has the opportunity to steer the team in a different direction at the end of every Sprint, so he/she must be ready to do just that if necessary.

6. Participates in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives. There’s always a lot going on and always an excuse to miss the meetings. But each of these Scrum ceremonies is another chance for the Product Owner to inspect and adapt. And as a result being present at these ceremonies is tantamount to success.

7. Inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done. Work that is either not complete or un-done needs to be re-prioritized or sequenced. An Agile PM is one who is quick to recognize and understand change and to ensure the Product Team adapts to the change in landscape, be it competition, target market or other.

8. Can change the course of the project at the end of every Sprint (30 days if you’re following traditional Scrum methodology by the book). The Product Owner is in complete control and can steer the team in a completely different direction at Sprint boundaries. And good Agile teams will welcome this change as long as the Product Owner is confident and knowledgeable.

9. Communicates status externally. The product owner is the voice of the Team to the outside world and should ensure that all channels of communications are open and that projects have the right amount of support required to succeed.

10. Terminates a Sprint if it is determined that a drastic change in direction is required e.g. a competitor releases a new version which demands a counter response. This is a pretty serious event for Scrum teams. And what this means “technically” is that all work done up until that point is lost. I have not seen this done to many times in my career especially since, there’s really not that much time between Sprints in any event.

The responsibilities of the Product Owner are onerous and there is no one else on the team to cover for him/her or pick up the slack. So if you’re choosing a Product Owner, choose wisely, the difference can be success or failure for the entire project or, in the worst of circumstances, the success or failure of the company.
Pages: [1] 2 3 ... 10