How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.

I’ve come to the conclusion that most projects produce better results when they have specialized people playing the various roles, rather than trying to be resourceful and wear multiple hats.

Visual models don’t have to be complicated. Unless your organization uses formal UML or BPMN standards, focus on learning to create simple visual models. In this article, we’ll explore 3 simple visual models that a new business analyst should be skilled in creating because they add a lot of value to projects and generally improve your requirements documentation. 

Driving Lessons. We all did it. We all know how that very first one went. It was described to us that the clutch should be engaged, place the car in first gear, release the handbrake, release the clutch and press down on the accelerator… Only for the car lurch forward then stutter and lurch forward again. This process continues several times before the car stalls and comes to a stop.

No matter how thorough a job you do on requirements elicitation, there is no way to be certain that you have found them all. No little green light comes on to announce “You’re done!” You should always plan on new requirements trickling in throughout the project. However, an excessive rate of change of requirements suggests that important requirements were overlooked during elicitation.

As a Business Analysts we work with goals and objectives of our clients or companies in order to deliver business value, but how often do we sit and work on professional goals and objectives? How often do we use the skills that we possess on ourselves and our own professional activities? This year I plan to do exactly that, I have put together four BA resolutions that I believe will make me a better BA.

So, what’s new now? A shift is occurring. Not only are decision models sanctioned as a new kind of deliverable, but thousands of them already operate in production systems serving major corporations. What’s new now is the emergence of an important question: what kinds of decisions belong in decision models and why?

The emergence of decision analysis techniques[1] is hugely important for both business rules in particular and business analysis in general. The same is true for decision tables, although current innovations[2] are more of a re-invigoration than fresh invention. [3]Every business analyst should be familiar with these decision analysis and decision table techniques.

Before we get carried away with decisions, however, we need to take a deep breath and do a reality check. This article discusses three major (and quite harmful) myths of the business decision space.

The close of one year tends to encourage us to reflect on what has occurred in business analysis and project management during the past year and think about future trends. As we reflect on the past, we thought it might be interesting to review some of the trends we’ve seen over the last five years and when we spotted them as trends

The purpose of this brief article is to provide a simple example on how to link and verify four models: use case, data flow diagrams, entity relationship diagrams, and state diagrams. Note the word verify, not validate. Verify in this context means that the technique is consistent and complete, not that it reflects correct requirements.

What if you want to use your business analysis skills, but don’t want to be in BA management or a team leader role? What if you want a different kind of role, but one that still uses your business analysis skills? Are there other roles out there for a skilled Business Analyst?

The answer is yes!

"What we have here, is failure to communicate". This is the catch phrase of a once very popular movie. And while the theme of this movie has nothing to do with the corporate business world, its meaning most certainly does.

How often do we hear “We don’t have time for analysis—let’s just get the project done!” Or “Modeling?! That’s so 1990s.” Or “Modeling is the developer’s job. Yours is to get the requirements.” Or “We’re doing Agile. Requirements evolve, so let’s not waste time with use cases or process models.” We have often heard every argument under the sun why spending time modeling requirements wastes time. However, we believe that modeling actually saves time.

Prior to the creation of something as potentially complex and ubiquitous of a website, an analyst must create a thorough, precise set of requirements in consultation with the right subject matter experts and business stakeholders. But unless one is armed with the proper planning procedures and techniques, the prospect of creating requirements for something as vast as an online business presence or functioning e-commerce system (or both) can be intimidating.

Do “Agile”projects need written requirements? Let us answer this question in this short article. As you may know, more and more software development teams have been adopting “Agile”processes over the past decade or so. As you may also know, Agile development processes such as Scrum and XP emphasize “working software” over requirements documentation.  Does this mean detailed, written requirements should be avoided in Agile projects?