In the discipline of business analysis, the "hard skill" is writing (or modeling) and documenting the system or software requirements so that they are recorded, communicated and approved. Often, however, this important skill is also the one that is understood the least. Various formats or deliverables are used to document system and software requ...

This paper is intended to provide a high-level overview and introduction to the Business Process Modeling Notation (BPMN). The context and general uses for BPMN will be provided as a supplement to the technical details defined the BPMN 1.0 Specification, which has been recently completed and released to the public. The basics of the BPMN notation w...

Effective communication among application development project stakeholders is often challenging, especially when the team is geographically distributed or time constrained. IBM® Rational® software helps organizations automate, integrate, and govern the core business process of software and systems delivery via the IBM Rational Software Delivery Pla...

People come to the job of Business Analyst in many different ways. Some people graduate from college and immediately start to work as a junior Analyst for a major corporation. Often a Business Analyst has some years of work experience in some related field before starting to work as an analyst.

You may choose to work for a company in the role of Business Analyst, or you may be a consultant and some of what you do is work as a Business Analyst.

Once you are working as a Business Analyst, what can you expect in terms of career growth?

Author: Geri Schneider Winters

Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement—or whether you should delve into them at all—you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on r...

The Cornerstone of Business Transformation. The fiercely competitive twenty-first century business environment poses challenges at every turn. Both public and for-profit organizations must be flexible and adaptable to remain competitive. It is through successful projects that organizations manage change, deliver new business solutions, and ultimat...

Each year, organizations across the globe face astronomical project failure rates, often wasting millions of dollars per failed project. This paper examines the roots of project failure and centers in on the elusive, often undefined role of the business analyst. In response to research showing that many organizations have not set concrete requireme...

In this article from ESI Horizons newsletter, Chip Schwartz discusses his experiences with sitting for the first Certified Business Analyst Professional (CBAP) exam in November 2006. Author: Chip Schwartz

RUP describes a process for developing software systems. It seems there are so many variations of RUP, how do you know which is best for you and your organization, if any? What do all those acronyms mean? Where are these things coming from?

Author: Geri Schneider Winters

This article describes a common pitfall of thinking of analysis and design together as a single process, and highlights the need to treat analysis and design as two separate processes. The author, points out that much of the UML standard, as it is explained today, is described in terms of design artifacts rather than analysis artifacts. Author: Co...

Describes the difference between a data dictionary and an implicit data dictionary and why an implicit data dictionary (or no data dictionary at all) may spell trouble for your project. Can data dictionaries be used with UML Use Cases or an XP methodology? Author: Conrad Weisert

In the last few years, the agile software development movement has created a paradigm shift in how we work to understand system requirements. Agile teams shape software systems using a collaborative process, with executable software at its heart and documents marginalised to a peripheral role. This creates a fundamental shift away from tools for ma...

A use case represents a case of use of a system, ideally one that captures a functional requirement in terms of an identifiable and testable goal. So, what is the best way to document a use case? Approaches to content range from diagrammatic to textual, formal to free form, expansive and detailed to brief and abstract. The approaches to tool usage ...

A few years ago I took a photograph an old wooden tombstone. The tombstone read, “Walter Crumbly, Hanged by Mistake – Sorry Walter.” It seems like the software industry wants to collectively hang the waterfall software development method and structured methods. In the not too distant future the software development industry will wake up and realize...

Some of you may be working on systems with many complex relationships between the parts. These complex systems may be described as a system of systems, or may be described as a product line, or perhaps both at once.

In these cases, you will often find that the requirements of a large, overall system are shared among a number of related projects, each of which implements some well-defined part of the overall system.

Author: Geri Schneider Winters