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?

Decision requirements models allow business analyst, architects and decision designers to describe the decision-making they need. When these models are combined with business-friendly decision tables, non-technical domain experts can represent critical “know-how” accurately and precisely resulting in faster time to value and fewer errors...

While a Business Analyst Manager has primary responsibilities of developing a team of Business Analysts and potentially best practices within the organization, the Lead Business Analyst’s key responsibilities also include ensuring the success of the execution of the Information Technology project, specifically the Business Analysis portion.

Today, it is very common for organizations to use The Decision Model for managing DQ logic. The results are impressive and also deliver unique advantages over other approaches. In some cases, organizations represent DQ logic in The Decision Model as part of requirements deliverables. In other cases, organizations create DQ logic in TDM-compliant software which validates the logic against TDM principles, generates and executes test cases, and sometimes deploys to target technology.

It's a new year, and time to go back to work. January is when we reset the statistics, brace for a new year, and try to prove ourselves once again.

Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are. Discussed, dissected, blogged about—why don’t they just go away?! 

The first core responsibility of the BA Manager is managing the team. BA Managers tend to be practice oriented. They strive to help grow and challenge their BA’s to be the best BA’s that they can. The BA Manager must know and understand the skills every BA needs and have the ability to help each BA perfect them. Understanding each BA’s strengths and weaknesses will help them create a development plan for their BA’s.

A few words to set up the story - my daughter is going to have a cyst removed from her left wrist. It's not a complicated procedure but she will be going in outpatient surgery on Dec 20 of this year. Now here's the business analysis part of the story.

This year’s top 10 business analysis trends show that in many ways, the more things change, the more they stay the same. In 2014, the focus will continue to be on delivering business value to the organization by leveraging the power of requirements at all levels through Agile and business architecture. Business analysts (BAs) will also continue their quest to take on new skills to meet a broader job scope and the needs of more multidisciplinary roles.

Have you heard it said that ‘business rules define the operational boundaries of an organization’? Do they?... Something is being bounded by business rules, but what? Does scope need to be understood in some deeper, richer sense? And how do these issues relate to smart business processes?

The path to choosing a third party business process management (BPM) system is riddled with potential pitfalls. The decision can make or break a business, so it’s worth the time and effort to get it right.

The lines between business analysts’ and project managers’ responsibilities seem to be becoming increasingly blurred, particularly in these tight economic times where candidates are sometimes expected to fulfill both roles. But it is crucial that companies understand the difference between these roles if they want their projects to be executed in the most efficient manner.

At the core of a good requirements management system is a good business process, not a fancy tool. Such process needs to clearly define how changes will be submitted and approved, and how team members will be notified when a change affects downstream or upstream work.