So you’ve developed a set of requirements for some portion of your next systems development project. Now what? Experienced project managers and software developers understand the value of translating requirements into rational project plans and robust designs. These steps are necessary whether the next release represents 1 percent or 100 percent of the final product. As shown in Figure 1, requirements serve as the foundation for project plans, designs, code, and tests. In addition to these connections, there is a link between the requirements for the software to be built and other project and transition requirements. Those include data migrations, training design and delivery, business process and organizational changes, infrastructure modifications, and others.

I’ve been a Business Analyst for about 15 years now starting as a graduate back in the day. And while I do not consider that to be close to a career’s worth of experience I have certainly seen significant changes in the way business analysis is performed and the tools that are used thanks to the evolution of technology.

This article covers a trend in the industry that has been yielding great results for companies looking to deliver more successful projects. By cutting down on huge initiatives with outrageous requirements documents that just can't be managed and focusing on implementing features and functionality a piece at a time, companies can be sure to deliver more value to customers more often. 

Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles...

Bias is seen in action through bad decisions, miscommunication, perceptual blindness, and alienation of groups with diverse thought. Here’s what the dictionary says about bias: “A preference or an inclination, especially one that inhibits impartial judgment.”

It is common for projects to be initiated based on blueprints. However, a blueprint is just a guide to the future state. Its intended purpose is to guide the subsequent analysis and design activities. It does not answer all the questions. The details of what, how, and why are left to requirements analysis.

It appears to me people still have trouble defining information requirements and, as such, they are at a loss as to how to build total systems. Thereby, they are content building either a single business process or a program. Therefore, here is the conceptual foundation for all system design. Information Driven Design begins with a simple concept...

Essentially, the IIBA® does not view “testing” as being part of the BA role. Obviously I disagree. When it comes to hours associated with test planning/strategies, the IIBA® should accept them as work experience in qualifying to sit for the CBAP® exam.

Being required to produce documents that create massive information bloat and don’t add value is frustrating as it slow projects down and creates additional project cost that isn’t needed. It’s a headache for Project Manager, Business Analyst and everyone on the team. What we need is the smallest set of information that can be verified and validated quickly that directly ensures the highest quality outcome of the project. 

Gathering and documenting requirements to develop software is often seen by business analysts as their core task. Actually, they are there to deliver value to the business—everything else is secondary.

Do we “on board” new project team members? In today’s busy organizations individuals are shuffled around all the time being assigned and unassigned almost daily to projects. We employ the “sink or swim” mentality. New person it’s your job to figure it out and get it done.

Many skilled individuals do ask themselves: “How can I be sure, that I am doing well?” Especially in the business analysis sphere, the criteria of a quality job may be vague or only partly relevant.

In reality, what many people do is try to measure the quality of business analysis work through analyzing some aspects of BA artifacts they produce.

This article attempts to explore a theoretical interpretation of “User Experience”. It will explore the meaning of ‘User Experience’ itself by focusing on the user, the technology and the resulting experience from the two interacting with each other. It will define some user experience roles relating to associated professions, and also attempt to describe the single important dynamic of user experience.

You finally did it. You figured out the real business problem your project is meant to solve, and identified a solution that is far superior than the originally proposed. Now you just need to get buy-in from the project sponsor so the delivery team can alter their plans and set out to build the higher-value solution you devised. But there is one problem: the project sponsor was deeply involved in identifying the original solution and nurturing it. It’s his baby… and if you say it needs to be overhauled, you are basically saying his baby is ugly. Now what? How do you make sure your news aren’t received as an insult, and dismissed with defensiveness by the decision-maker?

Discovery of real needs is the responsibility of the business analyst. Choosing the optimal solution is usually the responsibility of the stakeholders. Working together, both parties can ensure that they are providing the maximum business value.