Data models and class diagrams are generally created to serve design purposes. If they include verbs at all, they are not vetted against business rules or other forms of operational business communication. Verbalization depends on well-constructed sentences, which in turn puts a premium on verbs. Fact models provide the basis for consistent and unambiguous verbalization, as well as for the design of IT artifacts. It is time to recognize full-fledged human communication as the starting point for anything written about business operations, including but not limited to, business rules and IT requirements.

In virtually every industry in which business analysts find themselves, employers are trying to do more with less. Normally, this means budget and personnel cuts, which are forcing many analysts to also do the work of project managers, prototype designers, and other roles—and often with a smaller budget for software and other analysis tools. In this environment, it may seem challenging for analysts to find ways to cut back even more, but proactively doing so will benefit not only your employer but your projects and your career. Here are a few ideas to research and pitch to your manager for cutting costs as you go about your daily work.

Context diagrams are instrumental in unearthing unknown requirements during the discovery phase, both by forcing an analyst to think through the context (thus the moniker context diagram) of a project methodically and by enabling stakeholders to do so as well.

There is a great deal of confusion about the role of the Business Rule Management System (BRMS). Given the prominent role of the words “business” and “management”, one would be forgiven for believing that a tool thus named would manage the business aspects of the rules of the business. But to the contrary, across the entire class of these tools there is little business management of business rules possible. For the most part, and almost without exception, these tools are provided by the vendor to ensure the most efficient execution of “business rules”, rather than the efficient management by the business of them.

If you can dream up ways to save your company money by developing new systems and better ways of working then the job of business analyst might be for you.  It's a job that currently has a skills shortage in the IT world, and that - says recruitment consultant Tom Derbyshire - means strong job candidates can call the shots.
 

The product backlog is a beautifully simple artifact – a prioritized list of the outstanding work necessary to bring the product to life. To work with the product backlog effectively, it needs regular attention and care; it needs to be carefully managed, or groomed. Business analysts can play an important role to ensure that this is done well.

There are many qualities that contribute to great business analysis. You have to be a good communicator and be able to analyze problems. It generally helps to have some solid background in the common techniques of business analysis. For some jobs you need domain knowledge, for others technical expertise. All of these are debated and discussed often in BA circles across the web. One of the attributes I don’t hear people talk about quite as much is being results-oriented.
 

Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

As stakeholders play decisive role towards solution delivery, it would be helpful for business analysts and project managers to have a stakeholder strategy. Stakeholder strategy can help facilitate communication between stakeholders and IT teams. Stakeholder strategy allows project members to consider stakeholder availability and associated risks early in the project lifecycle.

 Today it seems like every project is urgent due to time-to-market compression and fierce competition in the global marketplace.  In this article we recommend management techniques that can help you and your team manage the complexities that are most likely present in urgent projects, while establishing and maintaining an environment of adaptability, innovation, and creativity.

Excellent requirements prioritization is essential to any well-run project. It ensures that the project focuses on the most important elements first, and that everyone understands and agrees regarding what the project’s most important elements are. Good prioritization of requirements will also ensure that engineers, programmers and database analysts develop a project’s most critical elements in sync with the business needs.

The voluminous amounts of information that an analyst collects during the discovery and elicitation phases warrant a good deal of planning and organization in order to make business or user requirements into a usable, cohesive whole. As with any other organization process, the key element to requirements’ organization success is thorough preparation and planning.

 You remember the game of telephone, right? The test of communication skills where one person whispers a message to his neighbor, and that message is translated multiple times from person to person until eventually, the last contestant repeats her interpreted message aloud. The goal is for the final person in the chain to correctly hear the original message, but invariably, there is laughter all around as the message is misconstrued.

This article promotes a new approach to requirements management that reduces project complexity and improves communication between business and IT. This new approach can be used on its own, or as a supplement or precursor to existing approaches. Critical features of the approach are: detachment of business requirements from individual projects; and the production of testable requirements that can be shown to be complete, consistent, and correct prior to use within the SDLC.
 

We present a requirements framework and methodology that may be different from what you are doing. Its three prominent characteristics are a framework, a new model, and visualization. The framework ensures completeness of all requirements. The new model is the Decision Model, transforming important business thinking into a tangible and manageable business requirement. The visualization simulates user scenarios, alleviating the need for abstract specifications or models.