Author Bio
I’ve been a big fan of technical peer reviews and inspections for nearly twenty-five years now. I’ve seen the benefits, and I’ve learned something from every review in which I’ve participated. Weaving peer reviews into the cultural fabric of an organization takes time, though. A new review process is fragile, being easily disrupted by unpleasant […]
Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn’t work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline. Baseline Defined The […]
Software products are rarely delivered in final form with the first release. More commonly, they evolve through a series of releases or iterations that correct defects, add progressively more features, and enrich or update previously implemented features. This means that during requirements development you’ll be accumulating requirements that could be targeted for various releases. You […]
The major consequence of requirements problems is rework—doing over something that you thought was already done. Rework can consume 30 to 50 percent of your total development cost, and requirements errors account for 70 to 85 percent of the rework cost. The data from Hewlett-Packard in Figure 1 shows that it costs far more to […]
The CEO of a major corporation who was present when I described requirements traceability at a seminar asked, “Why wouldn’t you create a requirements traceability matrix for your strategic business systems?” That’s an excellent question. He clearly saw the value of having that kind of data available to the organization for each of its applications. […]
The first part in this series of articles presented an overview of requirements traceability, identified the potential kinds of traceability links you could define among a project’s artifacts, and stated several motivations for tracing requirements. This article, adapted from my book Software Requirements, 2nd Edition, describes the requirements traceability matrix. The Requirements Traceability Matrix The […]
Rather than expecting use cases to contain one hundred percent of the system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to […]
I once read a book about use cases that stated, “To sum up, all functional requirements can be captured as use cases, and many of the nonfunctional requirements can be associated with use cases.” I agree with the second part of this sentence, but not with the first part. It is certainly true that use […]
Use cases are recognized as a powerful technique for exploring user requirements. The great benefit they provide is to bring a user-centric and usage-centric perspective to requirements elicitation discussions. The business analyst employs use cases to understand what the user is trying to accomplish and how he envisions his interactions with the product leading to […]
Software products are created for users, be they human beings, hardware devices, or other software systems. A user is a stakeholder who will interact with a completed system either directly (that is, hands on) or indirectly (for example, using reports from the system but not generating those reports personally). Users can be grouped into user […]