More on Requirements versus Design

   

So far, we have treated software requirements, design decisions, and design constraints as if they were distinct entities that can be clearly differentiated in both time and type. That is, we have stated or implied the following.

  • Requirements (mostly) precede design.

  • Users and customers, because they are closest to the need, make requirements decisions.

  • Technologists make design decisions because they are best suited to pick, among the many design options, which option will best meet the need.

graphics/requirements_icon.gif

This is a good model, and it is the right starting point for a requirements management philosophy. We've presented the story in this fashion for a reason. It is best to understand requirements before design, and most design constraints ("use XYZ class library for database access") are important design decisions recorded in the requirements assets so that we can ensure that we achieve them for a contractual or legitimate technical reason.

If we couldn't make these classifications at all, the picture would be very muddled, and we couldn't differentiate requirements from design. Further, we would no longer know who is responsible for what in the development process. Even worse , our customers would dictate design, and our designers would dictate requirements.

But a subtle yet serious complication underlies this discussion and belies the simple paradigm we've presented. Returning to our case study, for example, if the team makes a design decision, such as selection of a PC technology to run in the HOLIS CCU subsystem, it's likely to have some external impact on the user. For example, a system prompt or log-on screen will show up somewhere in the user's world. Better yet, we will probably want to take advantage of some user input capabilities of the OS, and those functions will certainly exhibit external behaviors to the user. (Note to the techies among you: Yes, we could hide it, but that's beside the point.)

Given the definitions we've provided in this chapter, the question becomes: Once the impact of a design decision causes external behavior seen by the user, does that same decision, which now clearly affects "input or output from the system," now become a requirement? You could argue that the correct answer is "yes," or "no," or even "it doesn't really matter," based on your individual interpretation of the definitions and analysis we've provided so far. But that makes light of a very important matter, as an understanding of this issue is critical to an understanding of requirements design and indeed the nature of the iterative process itself. Let's take a closer look.

Iterating Requirements and Design

In reality, the requirements versus design activities must be iterative. Requirements discovery, definition, and design decisions are circular. The process is a continual give and take, in that

graphics/20infig01.gif

Occasionally, inclusion of a new technology may cause us to throw out a host of assumptions about what the requirements were supposed to be. We may have discovered an entirely new approach that obviates the old strategy. ("Let's throw out the entire client/data access/GUI module and substitute a browser-based interface.") This is a prime and legitimate source of requirements change.

This process is as it should be; to attempt to do otherwise would be folly. On the other hand, there is grave danger in all of this, for if we do not truly understand the customer's needs and the customer is not engaged actively in the requirements process ”and yes, in some cases, even understanding our design- related decision ” the wrong decision might be made. When properly managed, this "continual reconsideration of requirements and design" is a truly fantastic process, as technology drives our continually improving ability to meet our customer's real needs. That's the essence of what effective and iterative requirements management is all about . But when improperly managed, we continually "chase our technology tail," and disaster results. We never said it would be easy.

   


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
EAN: N/A
Year: 2003
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net