With 24-hours a day, unceasing news being forced in our ears and down our throats, with computers that blog, phones that text and everything that twitters, we have information rushing back and forth at us at speeds that can only be measured in nanoseconds. It is information on steroids and it can and often does get us in trouble. Analyzing, corroborating, vetting and authenticating this rush of information, misinformation and hyperinformation are at times almost impossible.
As Business Analysts, we are usually dubbed as “Change Agents”. The challenge, though, is that most of us find this role very bewildering and, even, distressing.
Maybe it’s time to get back to the basics behind requirements and why we need them. In this 3-piece article series, we are getting back to the basics of requirements. Our first installment addresses how to ask the right questions.
A combination of process modeling (BPMN) and decision modeling (DMN) simplifies business processes by eliminating and replacing entire sections of the model with a decision model—the decision logic of the process model is precisely captured by decision modeling a separate yet linked model.
More successful business analysts seek out feedback, face tense situations head-on, and actively pursue new challenges. While they don’t necessarily like to fail, they trust in their ability to bounce back so they choose the difficult over the simple. It’s not uncommon for a successful business analyst to need to navigate any of the following situations, with grace.
The question of efficiency in business analysis and, what is more, of potential obstacles that prevent an analyst from being efficient, has always been considered very important. It goes without saying that there are some more or less objective reasons that prevent analysis from being done properly... There are however some types of problems that are caused by not so obvious reasons.
The purpose of this article is to show the expansion of an existing Business Process Model and Notation (BPMN) model due to an increased interest in a partner’s processes. In a previous article, I developed a BPMN model on a home medical process associated with peritoneal dialysis. In that article, I modeled a process, Ship Dialysis Equipment, as a black box pool;
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.
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us