NO WARRANTY

Abstract : Planning for the development of products early in the lifetime of a software product line is critical to the success of that product line. Requirements for that development both affect and are affected by the product requirements. This technical report describes the addition of development requirements to product line analysis. It further describes the refinement of product and development responsibilities, and the relationships among them, by use of examples specifically targeted at the practitioner of product line analysis.


Introduction
Product line analysis was introduced in the technical report titled Product Line Analysis: A Practical Introduction and described in terms of the requirements model built by the analysis team [Chastek 01].That report described the work products constituting the product line requirements model and the relationships among them.The emphasis was on presenting a set of four essential work products (i.e., the use case model, the feature model, the object model, and the dictionary) and describing how the systematic elicitation, refinement, and analysis of product line requirements is made possible by those work products.
This report is aimed at the practitioner who will conduct the product line analysis.This practitioner is referred to as the product line analyst in this report, but the term characterizes a role rather than a job description.The role may be filled, for example, by a requirements engineer experienced in analyzing functional and "nonfunctional" requirements [Chung 00], by a software architect experienced in "global analysis" [Hofmeister 00,Ch. 3], or by a technical manager planning for product line development [Clements 02,Clements 03].
This report has two purposes.The first is to clarify the refinement portion of product line analysis [Chastek 01,Sect. 4.1].We do this in Section 2 using examples aimed at the practitioner.The second purpose is to describe briefly a new aspect of product line analysis that has been added since Product Line Analysis: A Practical Introduction was published: product line development.Requirements for product line development are now integrated explicitly into product line analysis.This aspect is factored into the examples presented in Section 2 and discussed in more detail later in this section.However, before we discuss that aspect, we need to describe briefly the key premises of product line analysis that figure prominently in this report.

Product Line Analysis
Product line analysis • identifies the stakeholders and other sources of requirements information • initializes the product line analysis work products that make up the product line requirements model and adds the elicited information to those work products • refines those work products  Product line analysis identifies opportunities for large-grained reuse across a product line; hence, it is not concerned with all the requirements.It identifies the system responsibilities that provide the functional features and quality attributes of the products in the product line, and permits early reasoning about commonality and variability.The key premises of product line analysis are • Product qualities are features.
• System responsibilities are the basis for commonality and variability analysis within the requirements.
• Initial requirements modeling: Product line analysis analyzes and refines the high-level, rather than the detailed, requirements for a product line.The more detailed requirements engineering that is part of any software engineering effort is a necessary complement to product line analysis but will not be pursued here; abundant documentation on it is available elsewhere (e.g., Sommerville and Sawyer's book [Sommerville 97]).
By product qualities, we mean attributes such as performance, scalability, and security.A feature is a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems [Kang 90].Product qualities are modeled as features in product line analysis.The feature model categorizes features into functional features and quality features.Quality features are modeled separately within the feature model because they are characteristics that are not restricted to particular functional features-they can cut across functional boundaries.This separation of concerns highlights the importance of quality features while ensuring that they are subject to the same analysis and refinement as functional features.
The second key premise of product line analysis is that determining the commonality of system responsibilities is vital.As Chastek and associates point out in Product Line Analysis: A Practical Introduction, features do not provide sufficient insight into the internal responsibilities of a product line [Chastek 01, Sect.3.3]: they capture commonality and variability as perceived by customers and end users.System responsibilities capture commonality and variability as perceived by the developer, and it is that commonality and variability that can be leveraged in the core assets.
The brevity of product line analysis benefits both the architect and the technical managers.
The modeling terminates according to several criteria listed in Product Line Analysis: A Practical Introduction; for example, the judgment by the product line architect that the requirements model is sufficiently detailed to allow design to begin (i.e., a practical understanding of the product line issues has been achieved).This is one of the large-scale decisions that an architect has to make early in the design process.
A similar argument for brevity arises from the decision a technical manager must make when deciding on the split between core asset development and product development.That decision concerns the allocation of resources and its effects on core assets and products; it does not require minutely detailed requirements as input.

Product Line Development
Product line development can be viewed as a system that produces products.The sources of the requirements for that system, at least initially, are available in the business case, the market analysis, and so forth (see Appendix C).For example, the business case might specify that the current technical staff must be used for the product line.The market analysis might specify that the best opportunity for this organization lies in producing customizable products.Such business and marketing information provides constraints-that is, requirements-on the product line development system.
The users of that system are the core asset developers, the product developers, and the technical managers.In particular, the "Technical Planning" practice area raises specific questions concerning core asset development and production planning.There is an implied assumption that the technical manager makes the decision about the split (i.e., the allocation of resources) between core asset and product development.
• the functionality and qualities of the development in addition to those of the products in the product line.Figure 2  • documented processes (e.g., for testing, for using core assets to build products) • a production strategy and production plan These artifacts give rise to requirements for product line development.For example, a government contract may mandate the use of a particular development process, or an organization may decide to maximize the use of commercial off-the-shelf (COTS) products as part of its production strategy.A technical manager must make informed decisions (before and during development) based on these requirements.
An example of a product line development quality is the time to market for a product (i.e., the time from product order to product delivery).This quality is a production constraint that can have a profound effect on everything from the architecture of the product line to the hiring and training plans of an organization.
For a software product line, development includes both core asset and product development.
Tradeoffs must be made concerning the allocation of resources for each development effort: • How should resources be split between core asset and product development?
• How many resources (money, personnel, and time) should be dedicated to core asset development?
• How much of the functionality and qualities can be implemented in the core assets?How much has to be done by the product developers?
• Which split best supports the organization's business and market goals for the product line?
These tradeoffs require decisions.Product line analysis captures and refines information about development that serves as input for making those decisions.
As a final note, the whole point of making the distinction between products and their development is to permit early reasoning about the effects of one on the other.This reasoning is particularly important for the production strategy because a major concern of that strategy is ensuring that the core assets to be used in a product will actually work together.Example 5 on page 16 discusses some of the effects that product line development qualities have on products.

About This Report
The primary audience for this report is product line analysis practitioners who want concrete information on how to refine the requirements model once the work products have been ini-tialized.A secondary audience consists of technical managers responsible for allocating resources to core asset and product development.
Section 2 is the heart of the report; it describes how practitioners refine the elicited information, using examples drawn from the home integration system (HIS) environment.The examples clarify the refinement portion of product line analysis and incorporate the newer material on development functionality and qualities.Section 3 presents a summary of the report.
The authors' underlying assumption is that readers are familiar with Product Line Analysis: A Practical Introduction [Chastek 01].For readers' convenience, this report provides appendices that recap some material from that report: • Appendix A describes the basis of the examples in this report-the HIS that was introduced in Product Line Analysis: A Practical Introduction.
• Appendix B lists possible product line stakeholders and the types of information that can be provided by or elicited from them.
• Appendix C describes product line analysis and adds new material that places it in the context of A Framework for Software Product Line Practice [Clements 03].

Refinement
This

Description
The kinds of end-user-visible features provided by an HIS include the following: • monitoring and control of devices and appliances (e.g., furnace and refrigerator) • security (e.g., intrusion detection and response) • safety (e.g., fire detection and response) • comfort (e.g., heating and cooling) • entertainment (e.g., music and video programming) • reporting (e.g., system-usage statistics) This list represents an initial refinement of a product in the HIS product line.Each feature could be refined further, as indicated by the parenthetical examples, but the ultimate goal of the refinement is to identify the sets of system responsibilities (i.e., the requirements objects) associated with each feature.
The initial object model is simply a set of requirements objects corresponding to the features.For example, a Safety object corresponds to the safety feature, a Report object corresponds to the reporting feature, and so on.The initial responsibilities of the Safety object might be to obtain information from the detecting device, alert the occupants of the house, possibly take some action to suppress the fire, and inform the fire department.

Discussion
This example describes a typical decomposition of a proposed product line into functional features and their mapping to an initial set of associated system responsibilities.
The initial identification of product functionality and the resultant requirements objects is only a part of the HIS's refinement.A first-level refinement should also identify desired product qualities (e.g., performance) and features of the development (e.g., cost, tool support).Referring to Figure 3, the initialization of the product line requirements model deals with all four of the shaded nodes.
Features should be categorized as product or development features initially according to whichever classification makes the most sense.The initial categorization is not critical (e.g., is cost a product feature or a development feature?) because the subsequent refinement takes care of the issue (e.g., by clarifying exactly what is meant by cost).
The features and their associated requirements objects are not a partitioning of the product line, but they should cover the product line and its development.Expect overlap between the qualities of the products and their development (i.e., core assets and product development).
For example, the safety-critical nature of the software for a nuclear power plant is realized in both the products (e.g., via built-in redundancy) and by their development (e.g., via a formal, strictly enforced development process).

Description
In addition to detecting and responding to events (e.g., fire, intrusion) and errors (e.g., the HIS's inability to command a device), the HIS maintains a log of all such occurrences.The main responsibility of the HIS Report object is to process the logged data and present it to an interested reader in a usable format.For example, an average homeowner doesn't necessarily want to wade through a large volume of error logs but might like to know if particular HIS services are underutilized, or if a particular device requires several retries before it responds to a command from the HIS.
Refining reporting means answering some basic questions such as • What gets reported?The logs maintained by the HIS may include items such as HIS start-up and shutdown times, device errors, devices added/removed, which users logged in to the HIS over the time period covered by the log, and so forth.What information, either taken directly from the log data or derived from it, ends up in the report?
• For whom are the reports intended?For all users or just some of them?Can the contents be customized for particular users?
• What purpose do the reports serve?Are they simply statistics (e.g., number of device errors, maximum number of simultaneously active devices)?Or does the reporting capability analyze the data for trends (e.g., resource-consumption data indicate a need to upgrade the HIS, or device-usage data indicate that controlled devices are not being used in an energy-efficient way)?
• What constitutes a report?a static table of numbers? a graphical representation such as a histogram?or an interactive applet that guides users through the information?
• When are reports issued?daily, weekly, monthly, or on demand?Can a report be issued to remind a user that periodic maintenance of the furnace is now due?Can reports be archived?Do particular events-a device failure, for example-trigger particular reports? CMU/SEI-2003-TR-008 The answers to these questions drive the refinement of the Report object.For example, the refinement might focus on the type of reports to be produced by the HIS.Such a refinement would yield requirements objects such as • Report Device Errors • Report User Logins (who logged in and when, whether the login was local or remote, etc.) • Report Access Violations (when a user tries to access information without authorization) • Report Usage Statistics • Report Incidents (e.g., fire, attempted break-in) Object refinement also includes the identification of responsibilities associated with requirements objects.To report a device error, for example, requires knowledge about which device has the error, which kind of error it is, and when to report it and to whom.Reporting usage statistics implies a responsibility for data reduction and possibly data analysis, in addition to delivery of the report to the right recipient in the correct format.
Refinement also includes identifying the information exchanges that occur between requirements objects.As mentioned above, the Report Device Error object needs information about which device has the error and which kind of error it is.Getting that information will likely involve an exchange of information between a Device object and a Report object.Similarly, the Report Incident object needs information about an incident that might include device information.Information will also flow to and from the HIS user interface.All information flows among requirements objects need to be identified and documented in the object model.

Discussion
The initial point of this example is to illustrate basic refinement by posing "who, what, when, where, and why" kinds of questions (although the "where" question doesn't seem applicable here).In terms of Figure 3, this example illustrates the refinement of product functionality (node 1).
The example illustrated decomposition by report type (the "what" question), but other decompositions are possible.A decomposition by "when" would yield periodic, on-demand, and event-driven reporting, while a decomposition by "why" would yield resourceconsumption reports or energy-efficiency reports.If the decomposition is problematic, a use case can help focus the discussion and elicit responsibilities.
A second point raised by this example is generalization.When examining the requirements objects proposed as answers to the refinement questions listed above, it becomes apparent that the responsibilities associated with reporting can be generalized.Regardless of whether the report concerns device errors, user logins, or incidents, there are some common system responsibilities such as • Access logged data.
• Process this data into a report.
• Customize the reported information for different consumers.
• Allow for multiple representations of the output.
• Exchange information with the user interface.
This sort of generalization during refinement can be extended beyond the scope of the individual requirements object or objects that triggered it.For example, one of the basic functions of an HIS is monitoring and controlling: Monitor the operation of all devices, detect and report abnormal operating conditions (e.g., a faulty device), and perform control actions (e.g., activate, deactivate devices, take a faulty device offline).But what does "monitor" actually mean?The original product line analysis report refined and generalized one aspect of monitoring-monitoring incidents such as fires and attempted burglaries-into an Incident Monitor object and associated Incident Logger and Incident Responder objects.Collectively, those objects are responsible for recognizing incidents that require a response, identifying such incidents so that a response can be made, logging them for future reference, and initiating an appropriate response.Apart from the real-time detection-response sequence, are the responsibilities of the monitoring portion of monitoring and control all that different from reporting?Conversely, if reports can be triggered by events such as a device failure, how is that different from the event notification associated with the typical monitoring and control functions the HIS performs?And are any monitoring or reporting responsibilities common to the diagnostics capability of the HIS? Recording, accessing, processing, customizing, and presenting information within the HIS constitutes a set of recurring requirements whose commonality and variability warrant investigation.
Finally, note that a generalized requirement to customize information for users, or to restrict its availability to certain kinds of users, implies that something in the HIS has to be responsible for keeping track of user preferences and user privileges.So, the decomposition and generalization of requirements objects and responsibilities in one functional area can trigger the identification of entirely new functionality.

Description
This example is similar to Example 1 in that it illustrates basic refinement.However, the refinement is applied to a quality rather than a function.The point of the example is to show that qualities are subject to the same kind of refinement as functionality.
Because HISs are intended for use by people who do not necessarily possess (or desire to possess) knowledge of software systems, a pervasive HIS quality is usability.The initial concept may be expressed vaguely in a market analysis as the need to make HIS products "user friendly," or in a product feature catalog as "easy to learn" without requiring extensive training or documentation.There is no universally accepted definition of the usability of a software system; which characteristics of usability are important depend on the context of use.A report by Bass and colleagues examines characterizations of usability and their connection to software architecture [Bass 01].The characterizations considered include • checking for correctness • providing good help to users • recovering from failure • providing modifiable user interfaces (to reflect new functions and/or presentation desires) • supporting the canceling and undoing of commands For the purpose of this example, we assume that the initial concept of usability is for the HIS to be tolerant of users' mistakes.This means, for example, that it will allow users to cancel and undo operations, and that simple data-entry mistakes will not require a user to reenter all the data.Thus, an initial decomposition of usability leads to requirements objects such as These objects constitute a more operational definition of usability than "user friendly."Applied to the reporting function described in the previous example, it means that a user can correct errors in the setting up of what to report and when to report it.It also means that scheduled reports can be cancelled, and that a mistake in setting desired reporting preferences can be corrected without having to reenter all the other preferences.

Discussion
The requirements objects identified above-Undo Operation, Cancel Operation, and Reuse Data-are more than just a refinement of the usability quality, however.To undo an operation or to reuse data introduces the responsibility of maintaining session data.Thus, the refinement of the product quality has led to the discovery of new HIS product functionality.Referring to Figure 3, this example illustrates an explicit connection between product functionality (node 1) and product quality (node 2).
The example focused on the relationship between usability and the reporting functionality.
Beyond the reporting function, however, it is clear that undoing and canceling operations, and correcting user mistakes have applicability across many of the HIS functions (e.g., arming the security system, operating the heating and cooling, adjusting the lighting, programming the entertainment system, configuring devices, upgrading the HIS software, and so on).Thus, refining usability, even within the narrowly defined interpretation of the initial decomposition, needs to consider the context of usage (which functions are affected and when, why the quality is important for them, etc.).
System qualities, in addition to being subject to the same kind of decomposition and generalization as functionality, cannot be refined in isolation.They almost always cut across multiple system functions.Refining qualities proceeds in parallel with refining functionality.In terms of the conceptual table presented in Product Line Analysis: A Practical Introduction, refining means going down the usability column (and its refinements) and asking questions about the intersection of that quality with the functionality defined by the rows.Both qualities and functions may be refined further according to the recursive process described in Product Line Analysis: As a variant of this example, consider another case in which refining a quality attribute leads to the discovery of a need for new functionality.One of the business goals for the HIS product line (see Appendix A) is to provide an "expandable" system to which a homeowner can add new devices.Beyond adding more of the same devices (e.g., additional smoke detectors or lighting controllers), a homeowner could add a surveillance camera to complement the motion-detection feature, or a carbon-monoxide detector for added safety.The "userfriendly" HIS would therefore need to be able to accommodate these new devices.The usability aspect of concern here is the modifiability of the HIS user interface.Adding new devices or services means that the HIS must provide functionality to make their installation, configuration, and testing simple, and their output customizable for different consumers.Thus, as in the earlier example dealing with reporting, refinement has led to the discovery of new HIS functionality, but in this case, the trigger is the refinement of a quality rather than functionality. 2 The fact that qualities cut across multiple functions means that the commonality and variability of qualities across a product line should be explored in addition to that functionality.The refinement of the object model ensures that both functional and quality information, and their potential interactions, are captured in the object model.As a result, the product line architect and other core asset developers are presented with a comprehensive statement of the problems to be solved by the product line.

Example 4: Product Line Development Functionality 2.4.1 Description
Up to now, the examples have focused on the refinement of product functionality and qualities.This example examines the functionality associated with product development.
As an example of refinement, consider the case of tool support.If the development organization concludes that tool support is required to meet the development schedule, the following questions must be addressed: • Which parts of the product line development would benefit from tool support?
• At what point during the development will such support be needed?
• Do any commercially available tools meet our needs?
• Do any management decrees constrain our choices?For example − Use existing in-house tools.− Use only commercially available tools.
• Do we need to build our own in-house tools?
The developers and technical managers are asked these questions during the elicitation of requirements information from the sources depicted on the left-hand side of Figure 1.Their answers result in requirements that are added to the product line requirements model.The purpose here is to provide the basis for later management planning rather than to supplant such planning. 2 In fact, there may also be market-driven reasons for providing a customizable user interface: the high-end Lux-HIS product could offer full customization, while the low-end Econo-HIS product offers little or no customization.(The actual products in the product line could contain the same software load and a "key" for enabling or disabling the customization software.) An even less-open-ended requirement still needs to be scrutinized.For example, a contract that requires the use of the Unified Modeling Language (UML) has associated responsibilities such as • determining how UML will be used to support product line development • selecting an appropriate tool and evaluating it • identifying training needs (for both UML and other specific tools)

Discussion
The example shows how development-related refinement proceeds in exactly the same way as product-related refinement.In both, the functionality and qualities of product line development affect one another.Tool support, for example, may help improve the time to market of products in the long run, but the short-term need to provide training in the tool suite may disrupt the schedule for the first product release.
As in the product-specific case of Example 2, generalization within refinement is possible for development functionality.The responsibilities shown above are not specific to tool support for UML; they apply to any tool purchased in the commercial marketplace. 3  Another facet of tool support is the programming language to be used.The choice of a programming language affects the design; for example, the Ada programming language supports modularity (and eventually modifiability) better than the C programming language.The effect on product functionality is probably indirect through the "time to implement."If more needs to be done for implementation, less functionality may be achievable by a given date.In particular, in a product line of real-time systems, a mismatch between the problem (e.g., realtime control) and the implementation language (e.g., no support for concurrent processes) requires additional work to overcome the limitations of the language.Referring to Figure 3, this example illustrates connections among product functionality (node 1), a product quality (node 2), and development functionality (node 3).
A variant of the programming-language issue is the case where development functionality not only affects products but also introduces new development responsibilities.Consider the case of choosing to use the aspect-oriented programming (AOP) language AspectJ-an aspectoriented extension of the Java programming language [Kiczales 01].AOP deals with crosscutting aspects-such as the synchronization of concurrent objects or failure handling-by permitting them to be modeled and coded separately from the functional code.The aspect 3 For a more detailed discussion of tool-support issues, see the "Tool Support" practice area of A Framework for Software Product Line Practice [Clements 03].
CMU/SEI-2003-TR-008 code is then "woven" into the functional code at specific join points by an aspect weaver.AOP thus brings new responsibilities related to • identifying concerns that cut across multiple objects • coding the concerns as aspects • identifying the join points in the code where the separately coded aspects will be incorporated • weaving the aspects into the code In summary, this example provides an illustration of the fact that the requirements associated with product line development can affect each other and the actual products to be built.It is incumbent upon the product line analyst to elicit such requirements (if they are not already stated somewhere) and clarify them to the point where any connections to product requirements (i.e., product functionality or qualities) are exposed.Product line analysis handles the refinement of either kind of requirement-product or product line development-in the same way.

Description
The final example illustrates performance as a quality of product line development.In this context, "performance" is expressed in terms of cost and time.For example, how much does it cost to produce a product?How quickly can a product be produced?For the purpose of this example, we focus on a specific aspect of performance-namely time to market.We also assume that the organization producing the HIS for this example has a market analysis report specifying that the organization must • enter the HIS market as soon as possible, even if the initial product has limited functionality • be able to add new features quickly into its HIS products Both of these goals refer to time to market, the refinement of which leads to two basic alternatives: 1.For an organization adopting a product line approach, it can mean the expected delivery date of the first product.
2. For an up-and-running product line, it can mean the time from the receipt of a customer order for a product to the delivery of that product.
An organization might not use the term time to market and instead speak of ship date, delivery date, or release date.It is up to the product line analyst to ferret out such information and record any relevant terminology in the dictionary.Regardless of the terms used, the fundamental quality to be elicited is the fact that there is a target date by which development must come up with a product.

Discussion
This example is an illustration of the fact that the development of a product can have qualities associated with it.The refinement of the time-to-market quality feature clarifies its meaning for the downstream developers and enables them to assess the consequences of any constraints imposed by a time-to-market requirement on the development schedule.
The analyst also needs to determine what is meant by "the initial product has limited functionality."To do that means determining which product features or qualities can be sacrificed for that initial delivery, and then marking them as such in the requirements model.This is one way in which a product line development quality can affect product functionality and qualities.In terms of Figure 3, this example illustrates connections among product functionality (node 1), a product quality (node 2), and development functionality (node 3).
Time to market can be a constraint on 1. product development: How much time a company has from product order to product delivery limits the amount of time available for production.For example, if the market analysis says that a certain toy is needed by Christmas, one way to meet that deadline is to offer minimal functionality in that toy (i.e., node 1 of Figure 3 is affected).
2. core asset development: How much time a company has to develop the first product limits the amount of time available to develop the core assets.Constraints on the delivery order of products (as specified by market analysis) can also affect the order in which pieces of the core assets are implemented.
The fundamental message in either case is that the time to market here is a constraint; in fact, the goals and alternatives listed in the description section above are all production constraints that need to be factored into the production strategy, production plan, and core assets.Other constraints, such as those involving predictability and cost, will act in a similar fashion.
As a final example of a product line development quality, consider usability.An organization might employ relatively "inexperienced" people to be product developers, and hence require development to be straightforward (i.e., a highly usable product development system).This, in turn, implies greater responsibility for the core asset developers, more planning, possibly support tools, and documentation-all to make product development easier.Referring to

Summary
This report has presented an orchestrated set of examples that illustrate and provide guidance on the refinement portion of product line analysis.The examples also show how information elicited early is transformed into system responsibilities that are used by developers as the basis for analyzing commonality and variability across a product line.This report has introduced a new aspect of product line analysis-the integration of product line development requirements into the analysis-and woven it into the examples.In addition, this report has emphasized that product line analysis is not an exhaustive approach to product line requirements; the brevity of the approach permits an early start on the design of the architecture and the product line development system.
Product line analysis is requirements engineering for a product line.Requirements engineering needs an up-front integrated view of products and their development.A product line represents a substantial investment, and that investment is at risk if the product line development system is not in line with the strategic goals of the organization.An example of such a risk occurs when an executive's goals for the product line are not communicated to the developers.Cross effects between product line development and the products make including development responsibilities in requirements engineering imperative.Product line analysis effectively mitigates the risk of pursuing a product line approach.

The "What to Build" Pattern
A Framework for Software Product Line Practice provides guidance for the individual practice areas on the left side of Figure 4, but there is another source of guidance on how the practice areas actually work together.Clements and Northrop provide a "divide and conquer" approach to applying the 29 practice areas of the framework in their book on software product lines [Clements 02].The guidance takes the form of product line practice patterns that deal with subsets of practice areas acting in concert to achieve a specific goal.The pattern that has a direct bearing on product line analysis is the "What to Build" pattern-a subset of practices that an organization must master in order to choose which products should be in its product line.The practice areas of the pattern are exactly those listed on the left side of Figure 4. 4   Product line analysis is, in effect, a realization of the "What to Build" pattern that emphasizes the concerns of practitioners tasked with eliciting and analyzing the high-level requirements for a product line.The pattern also has an Analysis variant that has a broader context and adds practice areas dealing with requirements for the product line, the architecture, and the way core assets will be developed.The job of product line analysis is to ensure that the outputs of the practice areas are collectively transformed into a useful product line requirements model.
The product line analyst is the agent who combines and refines information from these sources and delivers it as the product line requirements of the architecture and production strategy.In addition, since the practice areas of the pattern can be conducted in parallel by separate groups, who do not necessarily communicate and coordinate effectively with each other, the analyst is responsible for maintaining a consistent "big picture" view of the product line.For example, product line analysis may uncover conflicts between the business and marketing views of the product line, gaps in the domain knowledge needed to build assets or products, or ambiguities in the articulation of desired quality attributes. 4 Because the pattern and the interactions between its practice areas are described in detail by Clements and Northrop, we don't describe that information here.

Obtaining Development Information
The practice areas of the "What to Build" pattern are sources of early strategic information about the qualities that affect product and core asset development.Table 2 shows several examples of that information.

Market Analysis
• the time to market (product order to product delivery) • flexibility (customizability) as a marketing strategy (e.g., targeting customers who want features not offered by competitors) Building a Business Case • the cost to develop the product (affects both product development and core asset development) • the charge for the product (cost to customer) • the cost of developing the core assets • the organizational structure (available personnel and expertise impose constraints on core asset and product development)

Scoping
• bounds on the variability among the products in the product line • test cases for verifying core assets Understanding Relevant

Domains
• the definition of commonality • the relationship between domain stability and the product production system Technology Forecasting • the evolution of the products and product line • domain and product development tools on the horizon (or, conversely, the lack of suitable tools in the marketplace imposing constraints or limits on the choices available for product production) • applicable standards Product line analysis nominally occurs "downstream" from the activities on the left side of Figure 4.If the practice areas in Table 2 have no documented outputs (e.g., a scoping report), the analyst must get the needed information from those responsible for those areas.In reality, of course, the process of eliciting, analyzing, and refining the information is highly iterative, with feedback from product line analysis to each activity (e.g., refinement of the product line's scope as the understanding of the requirements deepens).
In summary, the basic premise of product line analysis is that you need to analyze the following before you build the product line: • what the product line is supposed to do • how it is supposed to behave • how it will be built This is true whether the approach to building the product line is reactive (i.e., generalizing core assets from existing products) or proactive (i.e., creating core assets and then using them to build products).

Figure 1 :
Figure 1: Product Line Analysis The first bullet above refers to the left-hand side of the figure, the second bullet refers to the model in the middle of the figure, and the third bullet refers to the model and its targets on the right-hand side of the figure.The stakeholder list in Appendix B provides examples of requirements sources, and Section 2 provides examples of refining the product line model.

Figure 3 :
Figure 3: Product Line Functionalities and Qualities: A Key for the Examples

Figure 3 ,
Figure 3, this is an example of a connection between development functionality (node 3) and development quality (node 4).

illustrates this concept. Products Product Line Development Functionality Qualities Functionality Qualities Products Product Line Development Functionality Qualities Functionality Qualities Products Product Line Development Functionality Qualities Functionality Qualities
duction strategy are covered in the "Architecture Definition" practice area [Clements 03] and the technical report titled Guidelines for Developing a Product Line Production Plan [Chastek 02], respectively.Chung and colleagues provide useful information about quality attributes (or nonfunctional requirements, as those authors call them) in software engineering, and the extensive list of qualities in their book includes development qualities as well as product ones[Chung 00, p. 160].Bass and colleagues describe how quality attributes affect software architecture[Bass 01; Bass 03, Ch. 4].

Table 2 :
Practice Areas of the "What to Build" Pattern and Examples of the Information They Provide