This is the last article in this current  “Deep Dive Models in Agile” series and covers Decision Models, which include both Decision Trees and Decision Tables. Decision Models include two RML System models (Decision Trees and Decision Tables) that detail the system logic that either controls user functions or decides what actions a system will take in various circumstances.

The point is, no amount of elegant programming can solve a system problem without someone who understands the overall system architecture, someone who understands how the business works. Attacking systems development without such orchestration, such as one program at a time, will not produce the desired results. That would be like trying to build a bridge without a set of blueprints; it would probably be disjointed and one end would likely not connect with the other in the middle. 

What is Leading with Influence?... It is about the ability to affect the actions, decisions, and thinking of others to accomplish key goals or tasks that you consider to be important. Simply put, leading with influence is about getting people to willingly follow the direction that you provide when you lack organizational authority. It is about leading when you are not in charge. As a Business Analyst, I want delivery partners on a project to follow the guidance I provide without having to demand their compliance.

While BABOK and other sources include Behavioral Characteristics as an essential underlying competency for business analysts, many analysts may have only a vague idea of how it applies to their personal work environment, or even exactly what behavioral characteristics are, so let’s define those first.... The term behavioral characteristics simply refers to an analyst’s workplace ethics and character. 

The purpose of this brief article is to explain the connection between documenting requirements and contract type. Recently I consulted with a firm eliciting requirements for a new product. In this case, an internal business analyst team was documenting the product requirements by consulting with appropriate stakeholders. The follow-on project intent was to outsource the work to develop the product in the form of a contract.

I take the approach that as Business Analysts, the line between requirements and design is an imaginary line. We need to be pragmatic (abandon purist thinking) and not be afraid to wear the design cloak, to adopt design thinking. 

 

So how do we incorporate design thinking in Business Analysis in a value-add way? Take the following thoughts into consideration when working on your next project that involves building or significantly updating a customer-centric application.

---

Author: Michael Roy, Business Analysis Professional / Requirements Leader

Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.

 

Don't underestimate how pervasively across your organization business rule is misunderstood. What is a true business rule?

A true business rule is simply a criterion used in daily business operations to shape behavior or make decisions. The things that IT implements under today’s software platforms are not true business rules; rather, they are mostly encoded representations of business rules.

I bet everyone has, at least once in their career, heard the expression:

iRise gives Business Analysts the tools they need to communicate clearly with both the business and its stakeholders.  They use working previews that can be virtually indistinguishable from the final product.  When business analysts uses iRise to elicit and document requirements: the business analyst becomes a powerful weapon to get to the right answer, ...

State Models include two RML Data models (State Tables and State Diagrams) that show the transition of an object through various states or statuses, including which transitions are valid and what triggers an object to transition state. A state is a short-form description of a stage in a data object’s life that influences the behavior of the system.

The end products of requirements development for a business analytics project will be similar to those for any other project—a set of business, user, functional, and nonfunctional requirements. Process flows, use cases, and user stories can reveal that someone needs to generate analytics results, and performance requirements describe how quickly they need results, but none of these uncovers the complex knowledge required to implement the system... An effective elicitation strategy for business analysts (BAs) is to drive requirements specification based on the decisions that stakeholders need to make to achieve their business objectives.

A good business definition is not only good because it is clear and concise, but because it holds a clear, exclusive position within its full set of peers – i.e., the glossary for your business vocabulary. This discussion outlines five basic guidelines for ensuring the quality of a glossary holistically, focusing on avoiding naming anomalies, subtle redundancies, and avoiding circularities. Find out how you can become world-class at communicating the meaning of your business concepts. Part of the secret is a clear focus on seed concepts.

We hit a challenge however when we attempt to promote the value of Business Analysis to IT Management or the Business...  The reality is that simply promoting “better requirements” does not sell our value-add in terms that management from an IT or Business perspective understands... So how do we do this? Let me share five lessons learned based on my experience as a senior requirements management consultant. 

The paradigm shift towards agile and lean product development has brought collaboration between large cross-functional team in the spotlight. The existing literature is already mature explaining clearly how benefits can be reaped fast by executing a clean transition to agile delivery by enhancing the performance of the new cross-functional teams. However, in parallel, the time spent in endless meetings by product owners, business analysts, engineers, product managers and many others involved in the product creation, has grown exponentially. This leaves key product people with little or no time to do the critical activities they are employed for.

You see, I am a business analyst (BA), and more precisely the lesser-spotted, lazy beta alpha, the evolutionary pinnacle of my profession, at the tip of the BA spear. While the work of throwing or stabbing with the spear requires an effort by the arm that wields it, I prefer the sharp bit to do the work for me. In other words, doing as little as possible apart from…well, being sharp. While the sharp bit does all the work I am able to still the get the glory and recognition of a job well done. While the spear tossers return with painful shoulders, weary and, hopefully sometimes with a degree of success.