Requirements Analysis (BABOK KA)

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...

We know that we must involve all the stakeholders if we want to discover a project’s requirements. But we need some guidelines on how to involve the right people and, given how busy everyone is, how to minimize the time and maximize the result. In this article, requirements expert Ellen Gottesdiener (www.ebgconsulting.com) shares her consider...

A multitude of sins can be hidden behind the phrase “living document.” You can submit documents that are incomplete or inconsistent as long as you promise to fix it later. In this month’s issue of Strategic Software Engineering, I want to talk about the strategic importance of being realistic about the state of knowledge, plans an...

In part 1 of this article EBG Consulting's Ellen Gottesdiener discussed the need to adapt your requirements practices to your product and project. In part 2, she explores additional issues for tailoring requirements development and management. Author: Ellen Gottesdiener

Should your requirements practices embrace the change-driven approach of agile methods--lightweight models, minimal documentation, and little process? Or should you take a risk-driven approach--robust models, careful validation, and rich documentation? In this two-part weekly column, EBG Consulting's Ellen Gottesdiener explains that you should tail...

Read about the lively Use Case Panel: Discussion Among the Gurus - a panel held at the 2002 Rational Users Conference. "Doug Rosenberg wouldn't have a 20-page use case. Ian Spence would. But, as Ellen Gottesdiener reminded the panel, it's not all about size. Welcome to the Use Case Panel: Discussion Among Use Case Gurus. And what a panel it ...

Just how important is it to fully develop your project’s requirements? After all, nailing down your requirements usually takes only 8% to 15% of your overall project effort. Truth be told, it’s not really something you’ll want to spend your resources and energy on—unless, that is, you care at all about the quality of your pr...

This article explores the top nine reasons the author, requirements expert Ellen Gottesdiener, has heard for NOT doing requirements right -- and how to address these reasons in response.  Author: Ellen Gottesdiener

Every project has requirements. It doesn't matter if it's building hardware solutions, developing software solutions, installing networks, protecting data, or training users. For the project to be a success, knowing what the requirements are is an absolute must. Requirements exist for virtually any components of a project or task. For example, a p...