Defect Removal Effectiveness (or efficiency as used by some writers) is calculated: DRE =Defects removed during a development phase

------------------------------------------------------------ x 100 % Defects latent in the product at that phase

Since the latent defects in a software product is unknown at any point in time, it is approximated by adding the number of defects removed during the phase to the number of defects found later (but that existed during that phase). For example, assume that the following table reflects the defects detected during the specified phases and the phase where those defects were introduced.

Defect Removal Effectiveness can also be calculated for the entire development cycle to examine defect detection efforts before the product is released to the field. According to Capers Jones, world class organizations have Development DRE greater than 95%. Development DRE = (Pre-release Defect) / (Total Defects) x 100% = (10+3+2+18+4+5+26+8) / (10+3+2+1+18+4+5+2+26+8+7) x 100 = 88% The longer a defect exists in a product before it is detected, the more expensive it is to fix. Knowing the DRE for each phase can help an organization target its process improvement efforts to improve defect detection methods where they can be most effective. Future DRE measures can then be used to monitor the impact of those improvement efforts.

Defect density is a measure of the total known defects divided by the size of the software entity being measured.

Number of Known Defects / Size The Number of Known Defects is the count of total defects identified against a particular software entity, during a particular time period. Examples include: ydefect to date since the creation of module ydefects found in a program during an inspection ydefects to date since the shipment of a release to the customer Size is a normalizer that allows comparisons between different software entities (i.e., modules, releases, products). Size is typically counted either in Lines of Code or Function Points. Uses: Defect Density is used to compare the relative number of defects in various software components. This helps identify candidates for additional inspection or testing or for possible reengineering or replacement. Identifying defect prone components allows the concentration of limited resources into areas with the highest potential return on the investment. Figure 1 illustrates a typical reporting format for Defect Density when it is being utilized in this manner.

The FURPS+ System for Classifying Requirements One such classification system was devised by Robert Grady at Hewlett-Packard. 2 It goes by the acronym FURPS+ which represents:
y y y y y

Functionality Usability Reliability Performance Supportability

The "+" in FURPS+ also helps us to remember concerns such as:

y y y y

Design requirements Implementation requirements Interface requirements Physical requirements

Let's look at each category in detail.

Functional Requirements These requirements generally represent the main product features. In a warehouse application, we might have requirements pertaining to order processing or stock control, for example. However, functional requirements are not always domain-specific. Providing printing capability is a functional requirement of particular significance to architecture, for example. Table 1 lists additional functional requirements that might be considered.

Table 1: Architecturally Significant Functional Requirements Function Description Auditing Provide audit trails of system execution. Provide services for tracking, acquiring, installing, and monitoring license Licensing usage. Localization Provide facilities for supporting multiple human languages. Mail Provide services that allow applications to send and receive mail. Online help Provide online help capability. Printing Provide facilities for printing. Reporting Provide reporting facilities. Security Provide services to protect access to certain resources or information. System Provide services that facilitate management of applications in a distributed management environment. Provide support for moving documents and other work items, including Workflow review and approval cycles. Usability, Reliability, Performance, and Supportability Requirements The remaining "URPS" categories describe non-functional requirements that are generally architecturally significant.
y y

y y

Usability is concerned with characteristics such as aesthetics and consistency in the user interface. Reliability is concerned with characteristics such as availability (the amount of system "up time"), accuracy of system calculations, and the system's ability to recover from failure. Performance is concerned with characteristics such as throughput, response time, recovery time, start-up time, and shutdown time. Supportability is concerned with characteristics such as testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability.

Design, Implementation, Interface, and Physical Requirements The "+" in the FURPS+ acronym is used to identify additional categories that generally represent constraints.

y y

A design requirement, often called a design constraint, specifies or constrains the options for designing a system. For example, if you specify that a relational database is required, that's a design constraint. An implementation requirement specifies or constrains the coding or construction of a system. Examples might include required standards, implementation languages, and resource limits. An interface requirement specifies an external item with which a system must interact, or constraints on formats or other factors used within such an interaction. A physical requirement specifies a physical constraint imposed on the hardware used to house the system shape, size, or weight, for example.

Realizing Requirements From the descriptions above, we can easily see that some functional requirements, and most requirements in the other FURPS+ categories, are architecturally significant. Now let's look at how we might classify the seemingly unrelated architectural requirements we listed earlier. Using the FURPS+ classification we can see that:
y y y y y y

"The product will be localized (support multiple human languages)" is a supportability requirement. "The persistence will be handled by a relational database" is a design requirement. "The database will be Oracle 8i" is an implementation requirement. "The system will run seven days a week, twenty-four hours per day" is a reliability requirement. "An online help system is required" is a functional requirement. "All presentation logic will be written in Visual Basic" is an implementation requirement.

Knowing how such requirements are realized will help us ask the right questions of our stakeholders. There is also value in understanding the relationships between categories of requirement that, at first glance, appear very disparate. Considering architectural mechanisms can assist us on both counts.