The Role of the Supplementary Specification


In Chapter 20 we took a more rigorous look at specificity in software requirements and noted that there are a significant number of requirements that are not a natural fit for the use-case "container." For example, a statement such as "The application must run on Windows XP" is fairly clear, so it seems silly to try to include such a requirement in a use-case format just because we like use cases.

In this chapter we introduce the concept of the supplementary specification. It's called "supplementary" because we assume the use-case format will contain most of the functional requirements for the system, and we'll supplement the use-case model with these additional requirements. This may be the 80/20 rule for software requirements, in that most of the expressed requirements for many systems may be best expressed in use-case form. However, effective requirements management requires that we focus as seriously on the 20 percent of the requirements not expressed as use cases as we do on the other 80 percent. Otherwise, our application may fail because it doesn't run on the platforms of choice for the user , doesn't meet some crucial quality or regulatory standard, or in some other way fails to meet the needs of our customers or the extended stakeholder community.

Sometimes, when requirements are being defined for systems that, although complex, do not exhibit a high degree of externally visible functional behavior, the supplementary specification may carry the bulk of the requirements while the use cases carry only those behaviors more directly visible to a user or external device.


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: