Requirements Analysis (BABOK KA)

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

 Most books and articles on software requirements are written as though you’re gathering requirements for a brand-new product—what’s sometimes called a green-field project. In reality, few people have that opportunity on every project. Many developers work on maintenance projects. In such a project you’re usually adding...

The software industry is exhibiting an increasing interest in requirements engineering — that is, understanding what you intend to build before you’re done building it. Despite the hype of "Internet time," companies across many business domains realize that time spent understanding the business problem is an excellent investme...

In the discipline of business analysis, the "hard skill" is writing (or modeling) and documenting the system or software requirements so that they are recorded, communicated and approved. Often, however, this important skill is also the one that is understood the least. Various formats or deliverables are used to document system and software requ...

Effective communication among application development project stakeholders is often challenging, especially when the team is geographically distributed or time constrained. IBM® Rational® software helps organizations automate, integrate, and govern the core business process of software and systems delivery via the IBM Rational Software Delivery Pla...

Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement—or whether you should delve into them at all—you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on r...

In the last few years, the agile software development movement has created a paradigm shift in how we work to understand system requirements. Agile teams shape software systems using a collaborative process, with executable software at its heart and documents marginalised to a peripheral role. This creates a fundamental shift away from tools for ma...

Some of you may be working on systems with many complex relationships between the parts. These complex systems may be described as a system of systems, or may be described as a product line, or perhaps both at once.

In these cases, you will often find that the requirements of a large, overall system are shared among a number of related projects, each of which implements some well-defined part of the overall system.

Author: Geri Schneider Winters