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 importance of elicitation cannot be overstated, for it is the linchpin to any requirements project.

[Read the rest of this article...]

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.

When this happens in business however, it’s no laughing matter... There is a tendency to interpret information in very individualized ways, but as business analysts (BAs), we don’t want to allow for that. Rather, BAs strive for clear, concise and coherent articulation of requirements because it influences the outcome of solutions.

[Read the rest of this article...]

Before you can chart how you are going to implement a solution, everyone involved in the development effort must agree on why you need it to start with and that it is the very best solution available. Business requirements are fundamental to any development effort because they define where you are going by articulating the business problem and its solution—why it is needed and how to measure its success.

[Read the rest of this article...]

Very few people doubt it nowadays: The gathering of requirements and its appropriate documentation is a fundamental step in the success of any project. Yet, many people still disregard it.

[Read the rest of this article...]

Requirements gathering activities should be scheduled by your project plan like any other project related activities. If these activities don't track to the schedule, whether because the schedule isn't feasible or some other reason, it will cause all the dependant activities to slip. Once you've chosen your requirements gathering approach and the stakeholders you'll meet with to gather the requirements, you can schedule the meetings, or interviews, or other methods for soliciting the requirements.

[Read the rest of this article...]

There are various ways and means by which requirements for software development projects can be gathered and documented.  Before you start documenting the requirements you might want to be sure if you have captured all the required information.
 

[Read the rest of this article...]

The requirements you capture must be stated in business terms, must be clearly stated, must be concise, and must be feasible. To ensure that requirements are clearly stated, you should have them proof read by someone external to the project (or at least someone not familiar with the requirements you've captured).

[Read the rest of this article...]

A User Requirements Capture is a research exercise that is undertaken early in a project lifecycle to establish and qualify the scope of the project. The aim of the research is to understand the product from a user’s perspective, and to establish users’ common needs and expectations. The user requirements capture is useful for projects that have a lack of focus or to validate the existing project scope. The research provides an independent user perspective when a project has been created purely to fulfil a business need. The requirements capture findings are then used to balance the business goals with the user needs to ensure the project is a success.

[Read the rest of this article...]

Quality requirements contribute to the success of agile and traditional project management projects. The requirements definition process followed in a traditional project management framework and the features-based storyboarding that is typical of agile approaches are different, but they also have many similarities. The actual process used to define and gather requirements may be different, but the criteria for quality requirements remain constant. What are these similarities and differences in the process of gathering requirements? What happens to the role of the business analyst in an agile environment?

[Read the rest of this article...]

There are many requirements elicitation methods, but we seldom see elicitation performed specifically for security requirements. One reason for this is that few elicitation methods are specifically directed at security requirements. Another factor is that organizations seldom address security requirements elicitation specifically and instead lump them in with other traditional requirements elicitation methods.

This article describes an approach for doing trade-off analysis among requirements elicitation methods. Several case studies were conducted in security requirements elicitation; the detailed results of one case study and brief results of two other case studies are presented here.

[Read the rest of this article...]