As far as the individual change is concerned, what we need to know and do –as business analysts- is “How to design the proper tactics and interventions that institutionalize the change (e.g. new ERP system, redesigned business processes, new organizational structure, new policies, etc.”) at an individual level”.

Based on requirements, ASE decomposes a system into its sub-systems (business processes), the procedural work flow for each, and determine what programs are necessary to implement the computer procedures (software specs). To do this, we determined there were three basic types of sub-systems...

People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation.  This makes it sound as though there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize “what” and design should emphasize “how.” 

I’ve had the great pleasure of working through audits with the business I support over the last 2 years. It’s been a journey for sure and as regulators, internal audit teams and testing teams work to ensure that are processes are solid. First, let’s start with what does this word compliance mean? Compliance means conforming to a rule, such as a specification, policy, standard or law.

 

In this article, we discuss three of the basic elicitation techniques used in business analysis in order to obtain the requirements for the system being designed: Interviewing, Job Shadowing and Facilitation.

Adoption of The Decision Model (TDM) is growing and includes major corporations, such as those in the financial industry. As a result, decision models based on TDM are operating in production worldwide on behalf of critical business transactions and some with huge transaction volumes.  This means there are organizations and people with several years of TDM experience. However, there are also people and organizations interested in TDM and contemplating how to get started. This article provides insights by which business analysts can plant the seed for TDM.

The PBD starts with examining the end-product data elements and associated business rules. The BA team then uses this information to redesign a process that produces the end-product. Special note about the team. The lead BA should remind the team members that this is a redesign effort. This is a real challenge especially for the team members who are knowledgeable with the existing process. It may be best to recruit team members with a “fresh pair of eyes.” Note that there is no doubt that the BA team will consider automation in the redesign. In this effort, the BA team should keep in mind a quote attributed to Bill Gates [3] on BPM.

“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. [7]

In my experience, all benefits come from redesigning or improving existing processes, not by applying automation through software. Software only facilitates the process improvement.

2015 has kicked off and most of us are already fully entangled in the daily grind. Unlike people, projects show no sign of a ‘getting back into the swing of things’ period. The pressure keeps building as organisations are pushed to keep up with industry in order to stay competitive and profitable. So what does 2015 have in store for us? My view is that the following 4 trends can be expected to be prevalent for Business Analysts during the year.

Rather than expecting use cases to contain all of a system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a software requirements specification, although you could add them to the use case description if you prefer.

...the fact remains, you cannot build anything of substance, be it a system or otherwise, without a methodology. The question then becomes, how to construct a methodology suitable for your company or a given project. To this end, I offer this tutorial on designing methodologies.

There seem to be thousands of guides that will (or at least say they will) prepare you for the job interview and make you flawlessly land the job of your dreams. That’s pretty cool, but actually before you nail the job interview, first, you have to get to this stage and this proves unreachable for thousands of candidates every day. So this time, for a change, let’s focus on the 8 traps that await you on your way to the interview for your dream job.

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[1]. Analyzing, corroborating, vetting and authenticating this rush of information, misinformation and hyperinformation are at times almost impossible.

In the corporate world, when we join a company, we are normally presented with several documents from the Human Resources department which we are asked to sign. As a newcomer, you would be wise not to rush through this process and review each document carefully. If you have questions, ask. You do not want to be surprised if a problem arises during your employment or afterwards as an ex-employee

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.