It is certainly true that use cases are a powerful technique for discovering the functional requirements for a system being developed. However, this statement suggests that use cases are the only tool needed for representing a software system’s functionality. In most cases, they aren't.

Based on our projected trends, 2015 looks to be a year of significant change, and business analysts are on the front line of change. Several major industries, and the many organizations within them, are in the process of transition so it should be no surprise that the importance of the business analyst only increases as markets shift and organizations are forced to deal with the accelerating pace and volatility of business.

The structure that use cases provide is far superior to the nearly worthless technique of asking users “What do you want?” or “What are your requirements?” In this article I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren't a sufficient solution to the requirements problem.

In the world of underlying competencies that contribute to strong business analysis, the soft skill of analytical thinking and problem solving may seem pretty self-explanatory. Clearly, it involves sorting through business problems and information in an informed, methodical way. In order to do this, an analyst must research the problem and then propose intelligent solutions.

Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn't work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline. This article defines the requirements baseline and describes when to create one.

A typical business function might contain several unique events each of which we want to end up as a component of a larger software application. So how do we go from a table containing textual information to a specification which a developer can use?

This article is the last in a trilogy of articles that map the evolution of a proven, practical, and robust methodology that applies decisioning techniques to fundamentally remake commercial software architecture and development.

This column examines the three basic kinds of knowledge workers involved in business processes, and discusses how the distinctions among them are important for engineering smarter business solutions.