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.

In the book  Risk Savvy: How to Make Good Decisions, Gerd Gigerenzer describes the two sets of mental tools required for making decisions. When risks are known, good decisions require logic and statistical thinking. But when we are dealing with unknowable risks, good decisions also require intuition and smart rules of thumb.

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.

This article discusses Stephen King’s creative writing method and provides an example of using it in developing a use case narrative: the main scenario with alternate and exception paths. Yes, that is correct – Stephen King, the prolific writer of contemporary horror, science fiction and fantasy novels.

The UML Class Diagram, sometimes known as the Static Structure Diagram, shows the dependencies and persistent associations between object classes.

A UML Sequence Diagram is used most commonly to show the realization of a use case in terms of interactions between business entities or software objects. This diagram therefore helps with the transition from non-object oriented activity diagrams and use case diagrams to the object-oriented paradigm of modern software development.

Strategic Enterprise Analysis is the study, modeling, and maintenance of the strategic direction of a company. This article is about conducting SEA. Moreover, it is about how a senior business analyst facilitates this executive board effort.

One of my favorite tools in business analysis is the premortem. Instead of waiting until the end of a project to find out what went wrong, and learn for the future, we can use this technique to go on an “imaginary time travel” to avert real failures.

This is the tenth in a series that explains the thinking behind the Volere [1] requirements techniques—previous and future articles explore aspects of applying these techniques in your environment. This article illustrates how the requirements travel all the way through an organisation – and beyond - and how everyone is interested in/affected by them but all for different reasons.

Are you a Senior BA who is looking for a new challenge? The Management Consulting BA role may be for you. This role is particularly interesting for BA’s who have adapted best practices to their strengths and are looking for a greater degree of independence and responsibility.

In this article we address the question of How TEM? by providing a deeper look into TEM main constructs and how to do a high level design in TEM. For those who missed the first article we hope that you will still find this article useful and self-contained in such a way that it will be easy to follow and understand.

The “good old workshop”. As a business analyst practitioner and trainer I often get asked the question “should we use a workshop?” quickly followed by “how do we run it?”. This article addresses the first question (subsequent articles will look at the second).

An alternative to eliciting use cases and user stories is to identify the external events to which the system must respond. An event is some change or activity that takes place in the user’s environment that stimulates a response from the software system. An event-response table (also called an event table or an event list) itemizes all such events and the behavior the system is expected to exhibit in reaction to each event.