SWOT is an acronym for Strengths, Weaknesses, Opportunities and Threats. By using these four areas to identify an organization’s characteristics and climate, a SWOT Analysis offers a high-level evaluation of your company’spros and cons.The goal of a SWOT Analysis is to help an organization to identify strategies for success.

There’s little argument that investigating and identifying business needs (i.e. requirements) is a critical task of business analysis. However it’s of little use correctly identifying business needs if we can’t then effectively document them - to the clients who will be paying for the solution and to the developers who will be building it. In today’s time poor world we need to address both audiences in a single document.

I never really understood the hubbub associated with system design. People tend to look upon it as a complicated process. Actually it's not, yet the corporate landscape is littered with disastrous system projects costing millions of dollars, all because developers overlooked some rather simple principles for design and focused on technology instead.

Use case diagrams are used to show the decomposition of a business problem or software solution into a set of discrete functions (the use cases) which can be enacted by or on behalf of users (the actors). In a nutshell, this diagram shows who (the actors) can do what (the use cases) when interacting with the software solution.

With the vast array of data that organizations have access to, Customer Analytics is becoming a top priority so you can predict how customers will behave when they receive a catalog, enter a store, research and buy online, or interact with your organization in any other way. The more you know about customer and prospect preferences, the more successful you will be at creating relevant offers that resonate with them positively.

...Why, even with the word Analyst in our title, is the role of BA more associated with requirements rather than analytics? My hypothesis is pretty simple:  If Business Analysts are not required to produce specific analysis related artifacts, then both analytical competencies and requirements efficacy will be diminished.

The Decision Model (TDM) is a methodology and framework for modelling the business logic behind business decisions. Its popularity, adoption, and number of ground-breaking success stories are increasing significantly. TDM, as a powerful but simple graphical notation, is easy for both business people to understand and IT professionals to implement. As such, it puts business people in control of their business rules and logic and it accelerates IT’s ability to automate them quickly and without errors.

This article describes an integrated system of actions, tasks, and methods for managing project stakeholders. It highlights the strategic business actions, the tactical project tasks, and operational methods conducted by project sponsors, project managers and business analysts respectively.

 Analytics drive key strategic decisions in major corporations every day. However most legacy tools and solutions that help companies make these critical strategic decisions, simply aren’t built to deal with the reality of today’s modern business environment. Below are some essential questions to ask as you assess the potential benefits and limitations of new strategic analytic platforms for your organization.
 

Unified Modeling Language (UML) Activity Diagrams are rather like traditional flowcharts that may be used to describe the steps required to enact high level business processes or low level algorithms. From the software analyst’s perspective these diagrams are most useful for representing business processes, so this will be our focus here. Whereas activity diagrams are often relegated to the final chapters of the UML text books, I prefer to present them up-front as the logical starting point for any UML analysis and design endeavor.

Sure, you put a lot of time into creating a prototype, a mockup, screenshot, or wireframe (are there any other names for the user interface drawing I’ve missed?). You may have drawn it on a whiteboard, in VISIO, or even used a requirements tool to create it. At the end of the day, no matter how much time you spend on it, it’s nothing more than a picture. And those of you who have worked in IT know developers cannot code and create a solution solely from a picture. 

As Business Analysts, we are involved in requirements development and management day in and day out with most of the time spent on eliciting, analyzing and specifying business and software requirements for multiple projects. We follow or adopt multiple frameworks, approaches and tools that help us to successfully gather and analyze requirements. Having done all these things to ensure the success of the projects, we still end up in a few projects wherein we have “missed” few requirements.

An operational business decision has structure that you can’t capture using business process models, use cases, or similar techniques. If you fail to delineate that structure, you completely miss a core part of what makes business processes smart. The structure of a decision can be diagrammed in top-down, business-friendly fashion using a Question Chart (Q-Chart™ for short).

But what about user experience or interaction designers? Does every software project truly need a UX/UI specialist (or team of specialists)? Or could this aspect of the solution be taken care by the collaboration between the BA and the development team?

Unlike decision rules, behavioral rules do not pertain directly to determining the best or most appropriate answer (outcome) among alternatives... Three simple but typical examples in article illustrate. Avoid force-fitting a decision-oriented approach to every business rule problem. It simply doesn’t work!