Requirements Analysis (BABOK KA)

Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increas...

IAG Consulting’s new Business Analysis Benchmark makes one thing clear: almost 70 percent of companies surveyed set themselves up for both failure and significantly higher cost in their use of poor requirements practices. That failure came at a significant cost: the average $3 million project cost companies using poor requirements practices an aver...

THE ANALYST (aka, Systems Analyst, Systems Engineer, Systems Architect, Business Analyst) - requires specifications about the end-User's information requirements in order to design a system solution.  This is normally based on a definition of the user's business actions and/or decisions to be supported.  Following the system design, the Analyst produces the specifications required by the Programmer and DBA to fulfill their part of the puzzle.  From this perspective, the Analyst is the translator between the end-User and the Programmers and DBAs.

Each party has his own unique perspective of the puzzle and, as such, requires different "specifications."  To compound the problem though, the role of the Analyst sharply diminished over the years, leaving it to the Programmers to try and determine what the end-User needs, a skill they are typically not trained or suited for. 

The main benefit of today’s Agile development methodologies such as Scrum or XP is the promise of delivering more in a shorter period of time and the value derived from having the flexibility to adjust your course mid-way through a development effort. But does this type of approach allow for requirements management? Is RM necessary given the shorte...

Many studies have shown that requirements errors are very costly. By one estimate (in an article by Donald Firesmith for the Software Engineering Institute), requirements errors cost US businesses more than $30 billion per year and often result in failed or abandoned projects and damaged careers. The common wisdom is to find and fix requirements er...

Requirements Risk management could be a useful approach to requirements analysis, and lead to better requirements management.

High level the idea goes like this:

Risk management is an important part of project management
Requirements management is also a critical part of the puzzle
Should we be running a requirements risk management process on our projects?
The purpose of this article is to introduce the topic of Requirements risk into the Requirements Management discussion. Feedback and commentary is welcome and can be provided at ModernAnalyst.com

Requirements Simulation is a technique used to visually define and model business, user and technical requirements. The value proposition of most tools in the marketplace today is to bridge the communication gap between business and IT by empowering the Business Analyst to completely, and clearly define application requirements. Since specialized ...

A use case study is designed to describe a situation in which the program is being utilized by the end user. It will tell a story of sorts describing how the program works and the input of the user. It does not tell how the program was developed. The details of the programming are not included in the use case study. You are trying to express the concept behind the creation.

Author: Tony de Bree

Sometimes the business analyst can be so caught up in a project he or she forgets tried and true methods do not always work. The analysis team is trying to get done what the customer has scoped out and sets up a plan of action. The plan of action requires certain fundamentals. There are times when these rudimentary ideas just do not work for the client. The client can not understand why these steps may be so important. This is when the business analyst needs to step back and ask the same questions as the client. It is all in communication.

Author: Tony de Bree

One of the unfortunate aspects of industry-level paradigm shifts, such as what we're seeing with the move to agile software development, is that the followers of the incumbent paradigm often get to set the tone of the conversation. A perfect example of this is that traditionalists will often claim that agile approaches are riskier than traditional ...

Several software projects are over budgeted or have to face failures during operations. One big reason of this is Software Company develops wrong software due to wrong interpretation of requirements. Requirements engineering is one of the well known discipline within Software engineering which deals with this problem. RE is the process of eliciti...

Extreme programming (XP) introduced the practice of expressing requirements in the form of user stories, short descriptions of functionality–told from the perspective of a user–that are valuable to either a user of the software or the customer of the software. The following are typical user stories for a job posting and search site: ...

As long as practitioners recognize that use case diagrams are optional and iconic (as opposed to schematic), they shouldn't have problems. The diagrams are useful, for example, on whiteboards as a way of sketching and framing an agenda while people are writing up and reviewing use case detail on index cards. The trouble starts, however, when pr...

There are many problems associated with requirements engineering, including problems in defining the system scope, problems in fostering understanding among the different communities affected by the development of a given system, and problems in dealing with the volatile nature of requirements. These problems may lead to poor requirements and the c...

The requirements engineering phase of software development projects is characterised by the intensity and importance of communication activities. During this phase, the various stakeholders must be able to communicate their requirements to the analysts, and the analysts need to be able to communicate the specifications they generate back to the sta...