Jennifer deJong from SDTimes wrote an article on the business analyst role.

"Of all the roles associated with developing software, perhaps none needs a makeover as badly as the business analyst. Intended as a pivotal position that translates business needs to software requirements, the role varies widely across organizations."

This presentation was originally made at the Silicon Valley IIBA Chapter meeting in June 2008 by Kathleen (Kitty) Hass from Management Concepts (www.managementconcepts.com).

Kitty is also a new board member at-large for the IIBA.

| View | Upload your own

Ten Tips for Driving Better Project Outcomes
This is the recording of the June 12, 2008 Catalyze Webcast recording with Carey Schwaber from Forrester.

"It’s no secret that in the battle to bring effective business software to market on time and on budget, business analysts are on the front lines.   What can business analysts do to improve requirements definition practices and make a difference in project outcomes?  Join us as Forrester Senior Analyst, Carey Schwaber, shares a set of 10 practical tips that you can immediately put into action in your organization.  The Webcast was sponsored by iRise."

The slides are available here.

The modern Business Analyst – a definition

Here is a blog post that "suggests a minimal way to gather requirements, one that produces a (minimum) requirements document in an iterative and agile manner.

Nick Malik blogs for the Inside Architecture blog on MSDN.

From Scott Ambler -

"Many organizations have an IT role called analyst, and will often differentiate between various types:

• Requirements analysts who are responsible for requirements elicitation
• Systems analysts who are responsible for analyzing the requirements to determine the system needs to fulfill those requirements
• Business analysts who are responsible for understanding the business and making recommendations for improvement
• Business system analysts whose responsibilities are a combination of those of a requirements analyst, business analyst, and a system analyst.

The focus of this discussion is on business system analysts (BSAs) even though many of the issues (or flavors thereof) are pertinent to the other analyst types.  BSAs typically have experience in a wide range of techniques, including interviewing, structured meeting approaches such as Joint Application Development (JAD), modeling sessions, and model reviews.  Good BSAs have a good understanding of the business domain and are typically “people persons”.  This article covers:

1. Why Have BSAs?
2. The Traditional Activities of an Analyst
3. Business Analysts Gone Awry
4. Towards Agile Analysts
5. BSA as Product Owner?"

From the IIBA website:

"The public review draft of version 2 of the BABOK is now available for download. This document represents a complete draft of version 2 of the knowledge areas contained in the Guide to the Business Analysis Body of Knowledge®. The IIBA would like to thank the many volunteers who have contributed their time and energy to the development of this material since the release of Version 1.6 in 2006.

This draft is being made available to the business analysis community to gather feedback on the content and quality of this material in order that the IIBA™ may assess the current state of the draft and make decisions about which changes should be included in the final release of version 2. The public review will be conducted between March 31, 2008 and May 15, 2008.

We ask that members of the business analysis community or those with an interest in business analysis, whether or not they are members of the IIBA, provide the IIBA with feedback regarding the quality and content through an online survey. The survey will request that you provide us with a rating of the quality of each task, technique, and competency, and provide you with an opportunity to suggest additional tasks and techniques that might be missing from this draft. You may also provide feedback directly to bok@theiiba.org, although we regret that we will be unable to respond directly to such feedback.

Following the completion of the public review, the IIBA will conduct additional surveys to assess the importance of each task and technique to the business analysis community in order to make a final determination of the content that will be included in the final draft. In conjunction with the public review, we are conducting practitioner and expert reviews which will provide us with additional qualitative feedback on the content and quality of this release. When all of the reviews are complete, we will begin revising the text of the BABOK to include the changes suggested by the community, with the final release of version 2 targeted for the third quarter of 2008. The CBAP™ exam will continue to be based on version 1.6 until the final release of version 2. Once version 2 is generally available, the IIBA will announce a date for conversion of the exam.

Thank you for helping us ensure that the BABOK serves the needs of the business analysis community."

From SoftwareMag.com - a Journal for IT Professionals.

"Successfully addressing requirements management from a more iterative approach requires aligning business with IT; open communication is key"

This is an article by Lana Gates on the importance of requirements to business.

This month's content includes:

• IIBA Blog SPotlight
• CBAP Exam schedule for 2008
• International Spotlight

Working virtually has become so common these days; one probably doesn’t even realize how often he comes into contact with virtual colleagues. Globalization and technology have definitely changed the landscape of today’s work environment. Outsourcing, offshoring, nearshoring and homeshoring are becoming a common part of our occupational landscape.

As a Business Analyst in today’s working environment, it’s important to understand the dynamics, challenges and best practices of the classic office and how they compare with those of the virtual office.

In moving from requirements analysis to design, use cases are often recommended as the starting point for the derivation of classes. However, exactly how classes are to be found within the use case is not entirely obvious. Typical approaches suggest a simple noun/verb search or brainstorming. Recent work is moving towards an interrogation of the use case diagram as a means of validation and of the description (and scenario) to elicit objects in the problem domain. This paper presents a set of Elicitation Questions that enables the interrogation of descriptions from the perspectives of specification, software architecture and design. This qualitative 'interrogation' teases out design issues. The Elicitation Questions were trialled through application to a real industrial project at a financial services company. Feedback from practitioners shows that the Elicitation Questions are important in raising design and testing issues from the use case descriptions but the organisational culture in how software is developed would impact its uptake.

These are the slides used in the webcast delivered by Barbara Carkenord from B2T Training on February 14, 2008.

Barb showed us how to think through communication needs before gathering requirements – and how these communication planning techniques can be used on any project.

You can either view the slides below or download as a PDF.  The recording of the webcast can be found here.

| View | Upload your own

This is a recording of the webcast delivered by Barbara Carkenord from B2T Training on February 14, 2008.

Barb showed us how to think through communication needs before gathering requirements – and how these communication planning techniques can be used on any project.

This is a copy of the January 2008 newsletter from the IIBA.  Included in this month's edition are:

• The annoyance of bad terminology - by Kevin Brennan
• Business analysis trends
• The Software Requirements Memory Jogger - reviewed by Carol Deutschlander
• Endorsed education provider update

The US News and World Report came out with their list of best careers for 2008 on December 19th and Systems Analysts was one of the highlighted professions.

"The Ace Widget Co. has an ancient computer system. It'd like to upgrade to an Oracle-based operation with wireless capabilities, so employees can access the system with their BlackBerrys. The systems analyst orchestrates the effort. He starts by interviewing users, teasing out what they need as opposed to what they want—the nice-to-have things usually cost more than necessary."

Read the rest of the article for more information.