At some stage in their working life, every business analyst will have some involvement with data modelling. They may need to model how data is (or will be) used or - if they only deal with requirements investigation - then someone else in the team will need to verify that the data to support new functions will be available.

There are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article, expect to spend more time than average developing detailed requirements specifications.

Lean techniques use a process-oriented approach. In non-industrial organizations however, the process is invisible. In order to apply Lean techniques successfully in this environment, the visibility of processes has to be significantly increased. Employees have to learn to look at their organization from a process viewpoint. Furthermore, it is important that the method is applied to all layers of the organization.

Instead of taking for granted that either you find a flavor of agile that will fit the needs of your organization, or you must completely dismiss the use of agile methods, a much more valuable approach is to determine, for each individual project, which agile concepts should be embraced or not.

To remain competitive, it is more important than ever for an organization’s leadership team to use business analysis (BA) practices to execute strategies through innovative solutions. Over the years, business analysis has been rapidly developing as a profession and as a core business practice in many organizations; however, all too often business analysis is still in its foundational stages.

Several conditions make it appropriate to leave the requirements descriptions at a higher level of abstraction. Recognize that these are broad guidelines. The BA should perform a risk-benefit analysis to balance the potential downside of omitting important information against the effort required to include it.

For several decades, software reuse has been a recognized solution to improving efficiency of software development. However, implementing reuse in practice remains challenging and the IT community has little visibility into the state of the practice specifically as it pertains to reusing software requirements. This paper presents the results of a survey conducted in the global IT industry in 2010 and discusses the state of the practice for software requirements reuse.

We have always been fascinated by the exceptional business analysts who can create order out of total chaos. The ones who can ask those great questions, who can figure out what’s important and what’s less so, who can synthesize lots of information, put it all into their magic hat and come out with requirements that make sense to all the stakeholders.

Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?”

Your new system just went live and the project, that replaced a critical legacy system, is coming to a close. Business analysts gathered requirements and worked closely with users and developers, but did you capture all of the requirements?

Many IT managers have chosen to execute long-term projects in an iterative approach rather than a single linear fashion. This approach is not necessarily agile as the methodology is still “waterfall”-based but rather a series of waterfall executions (or terraced). This approach introduces new challenges for business analysts.

By taking a closer look at how your company is developing software, and what is working for projects with different profiles, it’s possible to leverage winning strategies and hybrid approaches to make your software initiatives equally or more successful in the future.

Before harvesting business rules, you should be aware of some basic principles and absorb them into your practices. First, all business rules are subject to change, including (and perhaps especially) business rules derived directly from business policies. The ability to change and redeploy business rules is essential to business agility.

This article proposes a V-Model for agile development testing and invites feedback from the reader. The agile method used in this article is Scrum; the author assumes the reader is familiar with this solution development life cycle.

RuleGuide is a tool that accelerates and improves the quality of business decision and rule capture, analysis and management. By providing an enterprise repository for business decisions, rules, and associated metadata, RuleGuide fosters ongoing collaboration and alignment ofthe business and IT teams.