The purpose of this article is to assist the business analyst engaged in the elicitation of stakeholder requirements. The key to any successful elicitation is asking the right questions whether it be in interviews or a facilitation session. Although the right questions are dependent on the solution scope, there are generic questions that the business analyst can use to start the elicitation regardless of the solution scope. The author begins the article using a mind map to capture keywords of generic questions and then provides a list of generic questions drawn from that map of which specific solution scope questions can be added by the business analyst.

The CBAP® (Certified Business Analysis Professional) certification was begun in late 2006 to screen, test, and certify qualified and knowledgeable BAs. We now number over 600 CBAPs around the world, with more being added every week. For people dedicated to the field of business analysis, the CBAP is becoming the "gold standard"of our profession, much like the PMP® is for project management.

There has been much talk about the expansion of BA responsibilities, with business analysts being expected, in many organizations, not only to elicit and manage requirements, but also to perform project management, risk assessment, budgeting and other activities involved in delivering software solutions. As organizations become more environmentally conscious, yet another dimension is added to the BA work...

As a business analyst, you are a problem solver. You are skilled at tailoring an approach to a business situation with different kinds of models.  However, until now, you are missing one. Worthy of its own model, there is an important dimension left behind.  It lies buried, capable of wreaking havoc.

So far in this column on SOA for Analysts, I have talked about the use and re-use of services as building blocks to put together new or better business applications. Now you are getting familiar with this concept, I need to peel away a layer of the SOA onion and expose you to a few tears by revealing this as a half-truth.

With evolving economic and technological needs, career moves are practically universal in today's job market. Some of these career moves are actually leaps, such as an accountant transitioning to become a nurse, but others are much closer jumps, such a technical writer or documentation specialist moving into the often similar business analyst's role.

I've never been comfortable with the concept of "Man Hours," not that it's a gender issue, but rather it implies ignorance of how time is used in the work place and fumbles away some simple management concepts needed to run any business, namely accountability and commitment. Actually, I thought the "Man Hour" concept disappeared with the passing of the 20th century, but it appears to be making a comeback.

Given the economic downturn, "cheaper, better, faster" seems to be a universal mantra in business. To stay competitive, organizations must continually strive to be more agile and develop higher-quality solutions more quickly-despite obstacles such as geographically distributed teams, limited budgets and resources, quick delivery times, language barriers and government regulations. These challenges require teams to consider new ways of doing business so they can be more responsive to frequent business changes.

While Business Analysts are in demand, only the best will do. We investigate quintessential business analysis professional competencies, with a discussion of how academics and application can work together for your success. Key planning and preparation insights for CBAP certification are also uncovered.

I began my career at Cap Gemini Ernst & Young where doing business analysis and implementing large scale systems was my job. At that time, I just thought everyone intrinsically knew you had to understand the business and all the requirements before you begin designing a system (whether custom built or off the shelf).

We are witnessing a marked increase in both the importance of and focus on the work of the business analyst that is directly proportional to the depth with which cloud computing services are utilized. What's more, we are experiencing a shift in the tools and skills that our analysts and those of our customers are required to utilize.

As the process of capturing and documenting business requirements matures, there is often a watershed moment when an organization must decide whether to perform traceability of requirements as part of that process. Most companies involved with a formal methodology for software development utilize some degree of traceability; but those not familiar with it could be put off by the overhead of requirements management (RM), of which traceability is a component. Therefore, it helps to understand some of the value aspects of instituting traceability.

Anyone perusing the computing rags (or their online equivalents) will no doubt have noticed that this year's big thing for applications development is a combination of Cloud Computing and Software as a Service (SaaS). I'll talk about Clouds in a future blog, as I want to concentrate on the SaaS phenomenon today.

Businesses cope with manual, repetitive tasks to get the job done. Email, conference calls, and "walking the cubes" are too frequently the process for requesting information, getting approvals, and checking project status. Time and resources are wasted, errors abound, and everyone is less productive.

Automating these everyday business processes is the way to improve productivity and gain efficiency. Traditional Business Process Management (BPM) systems can provide a solution, but the cost and complexity to implement simple processes is often too expensive for many business units.
 

For almost every analyst, the day comes when you write a set of requirements that causes engineers to bemoan a recent development project that they just coded. "If only we'd known that you wanted to build this, we would have made the last project more flexible. Now we've hardcoded in changes that will take days to rebuild."