Your new system just went live and the project, that replaced a critical legacy system, is coming to a close. Business analysts gathered requirements and worked closely with users and developers, but did you capture all of the requirements?

Many IT managers have chosen to execute long-term projects in an iterative approach rather than a single linear fashion. This approach is not necessarily agile as the methodology is still “waterfall”-based but rather a series of waterfall executions (or terraced). This approach introduces new challenges for business analysts.

By taking a closer look at how your company is developing software, and what is working for projects with different profiles, it’s possible to leverage winning strategies and hybrid approaches to make your software initiatives equally or more successful in the future.

Before harvesting business rules, you should be aware of some basic principles and absorb them into your practices. First, all business rules are subject to change, including (and perhaps especially) business rules derived directly from business policies. The ability to change and redeploy business rules is essential to business agility.

This article proposes a V-Model for agile development testing and invites feedback from the reader. The agile method used in this article is Scrum; the author assumes the reader is familiar with this solution development life cycle.

RuleGuide is a tool that accelerates and improves the quality of business decision and rule capture, analysis and management. By providing an enterprise repository for business decisions, rules, and associated metadata, RuleGuide fosters ongoing collaboration and alignment ofthe business and IT teams.

In this article we focus, not so much on the similarities among decision models, but on their differences. More than that, we explore the idea of classifying decision model structures based on differences in their logic. The decision model diagram is the first place to look for visible differences among decision models.
 

I was very intrigued with this concept when I read it in the Business Analysis Body of Knowledge (BABOK). This concept is so powerful and if used more in organizations can produce remarkable events; however, I have found that Systems Thinking can only be utilized to its fullest potential if the culture of the organization allows for that. However, as business analysts this is a concept that we should have in our arsenal of tools...

 The Data Flow Diagram (DFD) provides a graphical representation of the flow of data through a system. It shows logically what information is exchanged by our system processes and external interfaces or data stores, but it does not explicitly show when or in what sequence the information is exchanged.

Continuous change is a central fact of life for business these days. The techniques you use for business analysis must be based on the assumption that business rules will change, often quite rapidly. The best business solution is one that caters to such change, always doing so in the manner friendliest to business people and Business Analysts.

My understanding is that, in practice, successful agilists tend to bring together a number of activities, tasks, and deliverables that are from beyond the boundaries of what may be called “pure agile.” This mixing and matching of software process elements from agile and non-agile (more formal) approaches is a much more practical way of using these methods.

This article is all about putting your systems analysis into context; literally and metaphorically. It’s all about drawing and interpreting the not-quite-UML Context Diagram that is sometimes referred to as the System Context Diagram.

Why does it take an 'act of congress' for some organizations to realize that what they are doing is not working? I have been in many industries(media, manufacturing, financial and the judicial system) and no matter what industry I've been in I’ve seen some of the same themes.

Facilitation is one of the most critical soft skills of the business analyst, as well as one of the most difficult to master. Working with various stakeholders requires tremendous preparation, insight and finesse in addition to an understanding of key principles of the facilitation process.

Like most business analysts, Charles captured business rules as part of requirements gathering. Also like most business analysts, he followed traditional business rules approaches. These included writing individual business rule expressions, storing them outside the confines of process models and use cases, and providing pointers to them. However, he changed his approach after experimenting with The Decision Model.