Posts tagged BABOK

Business Analysis for Business Intelligence

Over the past few years, I’ve spoken to user groups to share my experiences working with use cases, scenarios, and user acceptance tests in support of data warehousing and Business Intelligence (BI) BI analysis. Afterwards, many people ask me to summarize my recommendations. In response, I wrote a short article – Requirements Tips for Data Centric Projects. You can access it here (note: you may have to register).

In my article, I focus on analyzing the context of usage. In addition, remember this: to elicit, analyze, and specify requirements in this space, almost all of the time-tested data-centric techniques are still necessary.

People often asked me for additional tips and advice. What additional considerations for business analysis for BI?

Continue reading

Best Books for Software Developers

This winter, SD Times editor Jennifer deJong Lent asked me to contribute an SD Times article on recommended books for developers. Jennifer and I agreed my list would exclude books about languages, databases or IDEs. I was pleased to contribute.

Jennifer begins her article with the following: “With the proliferation of online articles and ebooks, old-fashioned paper books seem not to have a place in today’s world. Many experts, however, still find useful things in paperbacks and hardcovers. From technology to people and team management, these books still help developers out today. Here are what the experts recommend.”

Continue reading

Tips on Software Security Requirements

Security requirements are a difficult quality attribute to elicit and specify. (Quality attributes are one the three types of nonfunctional requirements—along with interfaces, and design & implementation constraints*). Distinguishing can help. So too, it helps to

Sue Burk distinguishes between security requirements and security controls, shares four categories of security requirements, provides suggestions for eliciting security requirements, and explains why making them testable is important in her expert response.

Continue reading

Requirements Tips for Data Centric Projects

Are you working on data-centric software products? For example, ones that involves building a data warehouse, using extract-transform-load (ETL) and getting the gold—delivering business intelligence and analytic reports and queries for business decision makers?

Sue Burk shares the value of scenarios to define acceptance tests, and other practical techniques to improve your success with these data-centric projects in her expert response.

Continue reading

This Week’s Business Analysis and Requirements Workshop: 2 Days of Learning in Las Vegas

I was recently interviewed by SearchSoftwareQuality editor Yvette Francino about this week’s Business Analysis and Requirements Workshop at the Better Conference/Development Conference this week in Las Vegas, Nevada (6-7 June, 2011).

Yvette asked me to explain the logistics, if we would be emulating gathering requirements for a particular project and if the workshop be relevant regardless of domain area. Here are my answers: As conference chair,

Continue reading

What Inquiring Minds Want to Know: 120 Brains, 30 Minutes, 13 Themes

What Tough Agile Analysis Questions Do Business Analysts Need Answered? This is the question I posed to the participants in a facilitated workshop at the Building Business Capability Conference (BBC) 2010 this past fall. The BBC conference, held in the Washington, D.C. area, was the first official IIBA ® conference. It offered tracks for business…

Continue reading

Lessons on Distributed Volunteer Collaboration: Retrospective on Delivering the IIBA BABOK, Part 2

In my earlier post, I talked about a project I am working on: an all-volunteer effort to write an Agile-BABOK® extension (now we are officially calling it an “extension”, vs. an addendum).

I had suggested we learn from a similar effort—the development of the BABOK itself.

I figured the agile extension effort would be an ideal opportunity to document and leverage the lessons learned in conducting a project staffed by our geographically dispersed volunteers.

What works? What doesn’t? How can we adjust our practices based on our experience?

To learn about the BABOK development effort, I interviewed Mary Gorman, the person I consider the most knowledgeable about the BABOK (except for Kevin Brennan, IIBA’s VP, Body of Knowledge). (By the way, Mary’s BABOK Navigation tools are being freely provided to the business analysis community on our EBG Consulting web site.)

Continue reading

Lessons on Collaboration: Retrospective on Delivering the IIBA BABOK, Part 1

What are good practices for delivering a complex product for a broad global customer with a group of volunteers scattered all over the world?

This is a real-world question for me right now: I’ve volunteered to participate on the Agile-BABOK® (Business Analysis Body of Knowledge) addendum effort. Like the BABOK itself, this addendum can impact the practices of a broad worldwide community of professionals.

Learn From Those Who Have Been There Before

Two groups have tackled the problem of using volunteers to deliver an industry standard, so I figured we should “learn before we burn”. One group is the PMI Agile Community of Practice group, and the other is the BABOK Body of Knowledge Committee.

Ideally, learning what worked for these groups, along with their suggestions for what they would do differently were they to do this again, could help the Agile-BABOK addendum effort to start smart: leverage what they’ve found works, avoid or mitigate what didn’t work, and adjust their practices based on their experience.

Continue reading

How Agile is Influencing the Traditional Business Analyst Role: Part 1

How is Agile influencing the traditional role of the Business Analyst? What will the future hold for people with business analysis skills? A Modern Analyst writer for an upcoming article posed these and other questions to me.

Because the final article will be an amalgamation of responses and not contain my full set of responses, I’m sharing them here with you, in two parts.

Let me know what your reactions are!

Since the term “Agile” is used in so many contexts, what does “Agile” mean to you?

I assume in this article you are focusing on agile practices for product development (and not “agile” as a marketing term—e.g., “we’re an agile business”). Recognizing that a product can be software, hardware, a complex hardware and software system, or business process change, I would turn to the Agile Manifesto and its underlying principles.

It is striking how humanistic and pragmatic the manifesto and its principles are: “individuals and interactions” and “customer collaboration” are valued along with “working software”; the twelve principles include responding the “changing requirements” and frequent delivery along with simplicity, technical excellence, self-organization, and reflection.

When you study the history of software engineering and software methods, you discover that many of the practices that fall under the “agile” umbrella are not new. We stand on the shoulders of those who have written, researched, and experimented with good practices. We should not forget our history.

Studying those practices and history is informative. The agile “movement” will fade, and the most useful agile practices will become mainstream. I think Alistair Cockburn was spot-on at the Agile 2009 conference, when he said his keynote was about “burying agile, not praising it”; that is, people aren’t arguing very much about agile. Most of the theoretical issues are settled. Now we’re focused on how to implement agile practices.

Remember when structured development methods, and then information engineering, and then object orientation were the hot topics and next silver bullet? Take object orientation: object technology is a common lingua franca for developers. It’s been assimilated.

The same thing will happen with agile. Iterative development, timeboxing, or kanban-like flow models for development (continuous integration, test-driven development, user-acceptance-driven development, or BDD, behavior-driven development)—all this will become common practice.

Even “classic” agile is changing. Some people are adapting lean practices, others are figuring out how to address agile/adaptive architecture, and the software craftsmanship movement is pushing for attention.

So, to sum up with the keywords that inform my work—the ones that pop into my head when I think about agile—I would name these: customer collaborative, business value, adaptive, self-reflection, incremental, and iterative.

Continue reading

EBG Product Agility Newsletter

Get tips, stories and news on product discovery & delivery

Join our community and receive periodic tips, stories, and news on agile product management, product ownership, backlog and value management, collaboration, teamwork, and more.

Sign up Here