|
 |
| Articles and White Papers
|
|
|
|
|
|
|
|
Entries for the 'Requirements Analysis (BABOK KA)' Category
» FEATURED: Adapting Your Requirements Practices - Part 1 of 2
 (341 Views)
( 0 Comments)
| 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... |
» FEATURED: Debating Use Cases and Requirements
(382 Views)
( 0 Comments)
| 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 ... |
» Collaborate for Quality: Using Workshops to Determine Your Project's Requirements
(525 Views)
( 0 Comments)
| 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... |
» FEATURED: Why Aren’t YOU Doing Requirements Right?
(531 Views)
( 0 Comments)
| 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 |
» Introduction to Requirements: The Critical Details That Make or Break a Project
(579 Views)
( 0 Comments)
| 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... |
» Requirements When the Field Isn’t Green
(431 Views)
( 0 Comments)
| 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... |
» When Telepathy Won’t Do: Requirements Engineering Key Practices
(361 Views)
( 0 Comments)
| 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... |
» FEATURED: How to Document Information System Requirements
 (461 Views)
( 0 Comments)
| 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... |
» Validated requirements from business use cases and the Rational Unified Process
(423 Views)
( 0 Comments)
| 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... |
» Prioritization Puzzles: Practices for Prioritizing Your Product Requirements
(370 Views)
( 0 Comments)
| 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... |
|
 |
|
|