PART II STANDARD
PART II STANDARD
Section 4 Requirements Analysis The requirements analysis phase lays the groundwork for software reuse. Attention to reuse at this point can have a major impact on the extent to which later project products are reusable. This section presents guidance for activities that can be performed in the requirements analysis phase to support the development of reusable software. Development of requirements is often done in whole or in part by the program customer (NATO or a host-nation program management office).These guidelines apply to custome activities as well as to contractor activities. The following subsections address establishing requirements that encourage reuse of existing software.requiring the development of reusable software,the role of domain analysis in the requirements phase,and the handling of the requirements specification as an RSC. 4.1 Requirements that Encourage Reuse The requirements specification must recognize and encourage software reuse. Reuse begins at the requirements stage.The software requirements lay the groundwork for reuse by providing a statement of the required functionality and performance.Requirements must identify any required or expected reuse,and must not inhibit other reuse. 4.1.1 Specify only what is really needed;overspecified requirements inhibit reuse. In many cases opportunities for software reuse are lost because the system requirements unnecessarily preclude them.The best opportunities for reuse arise when the system specification requires only the necessary functionality and performance.and allows the system designer to select operational specifics.This gives the designer the freedom to identify reusable components that can help provide the needed capability.An extremely explicit specification- for example,one that describes precise screen layouts or report formats- is unlikely to correspond to any existing software,and to thus require new development. G4.1.1.1 Examine each requirement for necessity.Be sure it is a requirement and not a part of the design solution. Particularly when the requirements specification is developed y som ne other tha the software designer.there is a tendency to include aspects of the solution that are not in fact requirements.Such requirements constrain the developer's options to offer a more cost-effective solution based on reuse.A point-by-point examination of each requirement which asks"Is this really something we need,or can we ask the developer 4-1
4-1 Section 4 Requirements Analysis The requirements analysis phase lays the groundwork for software reuse. Attention to reuse at this point can have a major impact on the extent to which later project products are reusable. This section presents guidance for activities that can be performed in the requirements analysis phase to support the development of reusable software. Development of requirements is often done in whole or in part by the program customer (NATO or a host-nation program management office). These guidelines apply to customer activities as well as to contractor activities. The following subsections address establishing requirements that encourage reuse of existing software, requiring the development of reusable software, the role of domain analysis in the requirements phase, and the handling of the requirements specification as an RSC. 4.1 Requirements that Encourage Reuse The requirements specification must recognize and encourage software reuse. Reuse begins at the requirements stage. The software requirements lay the groundwork for reuse by providing a statement of the required functionality and performance. Requirements must identify any required or expected reuse, and must not inhibit other reuse. 4.1.1 Specify only what is really needed; overspecified requirements inhibit reuse. In many cases opportunities for software reuse are lost because the system requirements unnecessarily preclude them. The best opportunities for reuse arise when the system specification requires only the necessary functionality and performance, and allows the system designer to select operational specifics. This gives the designer the freedom to identify reusable components that can help provide the needed capability. An extremely explicit specification— for example, one that describes precise screen layouts or report formats—is unlikely to correspond to any existing software, and to thus require new development. G4.1.1.1 Examine each requirement for necessity. Be sure it is a requirement and not a part of the design solution. Particularly when the requirements specification is developed by someone other than the software designer, there is a tendency to include aspects of the solution that are not in fact requirements. Such requirements constrain the developer’s options to offer a more cost-effective solution based on reuse. A point-by-point examination of each requirement which asks “Is this really something we need, or can we ask the developer
to se his own solution?"will help eliminate overspecified requirements.An nt party may be able to perform this review more effectively G4.1.1.2 Offer contractor(s)an opportunity to review the system specification to identify potential changes that could increase opportunities for reuse. When the requirements specification is prepared before going out for bids on a program. it is often first issued as a firm requirement.Instead,consider providing a draft specification to potential offerors with a request that they identify areas in which requirements could be modified to permit reuse of available software.When the specification is prepared jointly by the customer and the contractor as part of the contract it is important that software development per sonnel are involved to provide a similar insight. 4.1.2 Specify any required or expected reuse. Sometimes the organization developing the requirements specification will be aware ofexisting software that can or should be reused in developing the new system.If reuse is a requirement, it must be specified as such.For any such requirement,it must be possible to determine whether it is met G4.1.2.1 Provide a reuse goal. In most cases.there will probably not be a particular software component that must be reused.However,it may be desirable to encourage the developer to p ractice reuse.(This pticularly likely to be true onea signficnt lirary of has been deve al r ified This would indicat the of the overall system code re sultin reuse than om nev pmer ires some thought to dete mine ow ret Is me (e.g.,lines of of functions ret r of requirements sreused),how compliance will be assessed,how reuse with modification is counted,etc. G4.1.2.2 Provide an incentive for reuse. If it is not desired to require reuse,it might be appropriate to encourage it through some sort of contractual incentive,whenever possible. 4.2 Requiring Reusability velopm ble software,any specifically needed If the software to be developed for a system is to have reuse potential in future systems,this should be stated as a requirement.There are two possibilities(a)the software should generally be developed so as to facilitate reuse,and(b)specific parts of the software must be reusable in a given set of circumstances.In either case,the requirements must be established appropriately and explicitly 42
4-2 to propose his own solution?” will help eliminate overspecified requirements. An independent party may be able to perform this review more effectively. G4.1.1.2 Offer contractor(s) an opportunity to review the system specification to identify potential changes that could increase opportunities for reuse. When the requirements specification is prepared before going out for bids on a program, it is often first issued as a firm requirement. Instead, consider providing a draft specification to potential offerors with a request that they identify areas in which requirements could be modified to permit reuse of available software. When the specification is prepared jointly by the customer and the contractor as part of the contract effort, it is important that software development personnel are involved to provide a similar insight. 4.1.2 Specify any required or expected reuse. Sometimes the organization developing the requirements specification will be aware of existing software that can or should be reused in developing the new system. If reuse is a requirement, it must be specified as such. For any such requirement, it must be possible to determine whether it is met. G4.1.2.1 Provide a reuse goal. In most cases, there will probably not be a particular software component that must be reused. However, it may be desirable to encourage the developer to practice reuse. (This is particularly likely to be true once a significant library of RSCs has been developed.) In this case, a goal percentage of reuse might be specified. This would indicate the percentage of the overall system code resulting from reuse rather than from new development. Such a metric requires some thought to determine how reuse is measured (e.g., lines of code, number of functions reused, number of requirements reused), how compliance will be assessed, how reuse with modification is counted, etc. G4.1.2.2 Provide an incentive for reuse. If it is not desired to require reuse, it might be appropriate to encourage it through some sort of contractual incentive, whenever possible. 4.2 Requiring Reusability To ensure the development of reusable software, any specifically needed reusability must be explicitly required. If the software to be developed for a system is to have reuse potential in future systems, this should be stated as a requirement. There are two possibilities—(a) the software should generally be developed so as to facilitate reuse, and (b) specific parts of the software must be reusable in a given set of circumstances. In either case, the requirements must be established appropriately and explicitly
4.2.1 Establish explicit and verifiable reusability requirements in the contract. Little is to be gained by simply asking developers to make their software reusable.or by providing them with a reusability guidelines document like this one.Reusability must be specified as a project requirement.Requirements are only meaningful when they are explicitly stated and objectively measurable.A requirement for reuse must explain what reuse means,that is.how to know it if you've got it.There must be a way of assessing whether the requirement was met. G4.2.1.1 Specify anticipated scope of reusability. A reusability requirement can be made more explicit when the desired scope ofreuse is known.For example,it may be known that a software component will need to be reused on another platform,or that it must be adapted to a different communications interface. In such cases this can be made an explicit requirement Desired flexibility or parameterization can also be specified.For example,the system under development might require a window-oriented user interface.If it is anticipated that the interface will be the r systems the r can be tasked o pr vide a w application tha screens needed the origina system.In effect,known desired RSCs become program requirements in their own right G4.2.1.2 Specify conformance to a reuse standard. If a reuse standard such as this one is available,conformance can become a contractual requirement.In this case the developer should be expected to describe how conformance will be ensured.Alternatively,the developer might be asked to provide his own organization-specific or project-specific standard,again describing how it will be used. G4.2.1.3 Specify needed documentation Reusable software components,to be most usable,require documentation beyond progra n doc iSection 8 of this ma al addresses this requiremen Any such tation need should be contractually required G4.2.1.4 Identify/require tests for reusability. Like any other requirement,reusability requirements should be testable unde ng of how conformance to such requirements wil established during requirements specification.When an explicit requirement,such as the ability to operate on another platform or the ability to be parameterized differently, is known,this can be tested directly.When the requirement is conformance to a standard,the test will probably consist of quality assurance(QA)inspections,perhaps aided by some automated coding standards checker. G4.2.1.5 Provide for subsequent maintenance of RSCs ser responsible for an fixes.An alternative is that the library organization will want continued mai tena nce by 43
4-3 4.2.1 Establish explicit and verifiable reusability requirements in the contract. Little is to be gained by simply asking developers to make their software reusable, or by providing them with a reusability guidelines document like this one. Reusability must be specified as a project requirement. Requirements are only meaningful when they are explicitly stated and objectively measurable. A requirement for reuse must explain what reuse means, that is, how to know it if you’ve got it. There must be a way of assessing whether the requirement was met. G4.2.1.1 Specify anticipated scope of reusability. A reusability requirement can be made more explicit when the desired scope of reuse is known. For example, it may be known that a software component will need to be reused on another platform, or that it must be adapted to a different communications interface. In such cases, this can be made an explicit requirement. Desired flexibility or parameterization can also be specified. For example, the system under development might require a window-oriented user interface. If it is anticipated that the interface will be reusable in other systems, the contractor can be tasked to provide a window package that is tailorable to other applications, rather than one that provides only the specific screens needed for the original system. In effect, known desired RSCs become program requirements in their own right. G4.2.1.2 Specify conformance to a reuse standard. If a reuse standard such as this one is available, conformance can become a contractual requirement. In this case the developer should be expected to describe how conformance will be ensured. Alternatively, the developer might be asked to provide his own organization-specific or project-specific standard, again describing how it will be used. G4.2.1.3 Specify needed documentation. Reusable software components, to be most usable, require documentation beyond normal program documentation. Section 8 of this manual addresses this requirement. Any such documentation need should be contractually required. G4.2.1.4 Identify/require tests for reusability. Like any other requirement, reusability requirements should be testable. An understanding of how conformance to such requirements will be measured should be established during requirements specification. When an explicit requirement, such as the ability to operate on another platform or the ability to be parameterized differently, is known, this can be tested directly. When the requirement is conformance to a standard, the test will probably consist of quality assurance (QA) inspections, perhaps aided by some automated coding standards checker. G4.2.1.5 Provide for subsequent maintenance of RSCs. Maintenance of reusable software should be addressed. One approach is that RSCs are simply placed in the library and then reused as is, with the reuser responsible for any fixes. An alternative is that the library organization will want continued maintenance by
intenance activity 4.3 The Role of Domain Analysis Domain analysis identifies functional commonality across a range of systems or subsystems,and can influence the choice of requirements. Domain analysis is an activity above and bevond the effort normally carried out during a requirements analysis phase for a particular program.It is the analysis of a class of systems in a particular application domain,as well as of anticipated future requirements and evolving technology.Its objective is the identification of a common architecture and common functions and interfaces that apply across the domain.Once these are identified,software that is constructed according to this common architecture has greatly enhanced potential for reusability in future systems. Alternatively,a domain analysis may already have been done for the application area.Any such products should be examined for potential utility in developing the new system. 4.3.1 Consider future reuse opportunities when analyzing system requirements. A complete or partial domain analysis can increase the reuse potential of the software by making it a better fit to future requirements.The benefits of a domain analysis activity should be analyzed,and an effort undertaken if appropriate.A partial analysis of reusable subsystems and interfaces can also be worthwhile. G4.3.1.1 Evaluate the appropriateness of a domain analysis. Either a customer or a development contractor may make the decision that a domain analysis is desirable,either independently or in conjunction with a particular development effort.Some of the criteria in making such a decision are: Will the organization be building more systems in the same domain,and consequently be able to profit from the availability of a standard architecture and parts that fit that architecture? Is the technology of building systems in this area sufficiently well understood that a satisfactory standard architecture is a realistic expectation? Has the developer built similar systems,and thus gained the experience to ensure that the products of the domain analysis are usable? Is there a mechanism for requiring/ensuring that the products of a domain analysis are in fact used?For example,if a contractor is tasked to develop a standard architecture,is there a way to see that other contractors use it? Is there a way to amortize the cost of the domain analysis across the organizational elements that will profit from it? 4-4
4-4 the original developer. If this is the case, the program requirements should allow for such a maintenance activity. 4.3 The Role of Domain Analysis Domain analysis identifies functional commonality across a range of systems or subsystems, and can influence the choice of requirements. Domain analysis is an activity above and beyond the effort normally carried out during a requirements analysis phase for a particular program. It is the analysis of a class of systems in a particular application domain, as well as of anticipated future requirements and evolving technology. Its objective is the identification of a common architecture and common functions and interfaces that apply across the domain. Once these are identified, software that is constructed according to this common architecture has greatly enhanced potential for reusability in future systems. Alternatively, a domain analysis may already have been done for the application area. Any such products should be examined for potential utility in developing the new system. 4.3.1 Consider future reuse opportunities when analyzing system requirements. A complete or partial domain analysis can increase the reuse potential of the software by making it a better fit to future requirements. The benefits of a domain analysis activity should be analyzed, and an effort undertaken if appropriate. A partial analysis of reusable subsystems and interfaces can also be worthwhile. G4.3.1.1 Evaluate the appropriateness of a domain analysis. Either a customer or a development contractor may make the decision that a domain analysis is desirable, either independently or in conjunction with a particular development effort. Some of the criteria in making such a decision are: • Will the organization be building more systems in the same domain, and consequently be able to profit from the availability of a standard architecture and parts that fit that architecture? • Is the technology of building systems in this area sufficiently well understood that a satisfactory standard architecture is a realistic expectation? • Has the developer built similar systems, and thus gained the experience to ensure that the products of the domain analysis are usable? • Is there a mechanism for requiring/ensuring that the products of a domain analysis are in fact used? For example, if a contractor is tasked to develop a standard architecture, is there a way to see that other contractors use it? • Is there a way to amortize the cost of the domain analysis across the organizational elements that will profit from it?