Requirements continue to be a major problem area for most organizations. According to industry reports, the leading causes of quality, cost, and schedule problems are lack of understanding of the customer’s needs, incomplete requirement specifications, and managing changing requirements. In fact, requirements are so important that one of the definitions of quality is, “conformance to requirements”. If requirements are not good, the costs of poor quality will be high and the resulting products and services will not be good either. So what can an organization focus on now to measurably improve their requirements? This article will describe some practical strategies that organizations can use to measurably improve their requirements.

The role of business analysts and systems analysts appears to be very closely related, and there is no agreement on the definitions of the roles or the required skill set to become one of the said analysts. Though the number of these positions is increasing, the understanding of what the business and systems analysts are remains unclear and differs between organisations. A review of literature shows that there are common roles and skills between the two positions, as well as very distinct roles and skills that are clear. This research has demonstrated that although there is some harmony between the articles and interviews on the distinctions between the business analyst and the systems analyst, there are still discrepancies that can only be understood through further research.

I get this question and variations of it all the time! What is a senior business analyst? What skills do I need to develop to become one? What are the most valued business analyst competencies?

This is a tough question. And although finding the answer can be difficult, it’s also a tough question because it has multiple answers. Business analysis, like many, if not most, professions, exists within an organizational context. Different organizations value different competencies and so senior can mean something different depending on the organization in which you work and the strengths you bring to the table.
 

A thorough discovery of business requirements is almost never readily available at an analyst’s fingertips—rarely can requirements be quickly looked up as one would gather information for a term paper or study for a test. Much of business or technical requirements is not documented anywhere—it resides in the minds of stakeholders, in feedback that has yet to be obtained from end users, and from a study of flowcharts and surveys that have yet to be created. And so requirements must be elicited, or drawn out, and the methodology in doing so must be logical and meticulous... The purpose of requirements elicitation, therefore, is to thoroughly identify the business needs, risks, and assumptions associated with any given project.

Decision tables have long been a successful technique for representing structured logic. Being visual, they circumvent the need for unnatural formal language or grammar. We use them not only to communicate that logic, but also to automate it. They are especially useful for validating the logic’s completeness and consistency.  Yet, this article advocates that this is not enough.
 

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.