UNIVERSITY OF CALGARY. Requirements Engineering for Software Product Lines. By Chethana Kuloor

Transcription

1 UNIVERSITY OF CALGARY Requirements Engineering for Software Product Lines By Chethana Kuloor A PROJECT REPORT SUBMITTED TO THE FACULTY OF GRADUATE STUDIES IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF ENGINEERING IN SOFTWARE ENGINEERING DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING CALGARY, ALBERTA MAY 2002 Chethana Kuloor 2002 i

2 THE UNIVERSITY OF CALGARY FACULTY OF GRADUATE STUDIES The undersigned certify that they have read, and recommend to the Faculty of Graduate Studies for acceptance, a thesis entitled Requirements Engineering for Software Product Lines submitted by Chethana Kuloor in partial fulfillment of the requirements for the degree of Masters of Engineering in Software Engineering. Supervisor, Dr. Armin Eberlein, Dept. of Electrical and Computer Engineering Dr. Behrouz Homayoun Far, Dept. of Electrical and Computer Engineering Dr. Rob Kremer, Dept. of Computer Science Date ii

3 ABSTRACT The cost of fixing a requirements defect later in the development stage is much higher than the cost of identifying and fixing it in the early stages of development. In order to do this the system requirements must be properly identified, analyzed and reviewed early in the development process. Requirements Engineering (RE) is such a process that focuses on discovering, analyzing, documenting and managing the system requirements. Several processes and techniques have been developed to assist RE activities. A product line is a set or group of products that have a majority of features in common and vary only in certain specific features. Developing a group of products that have a majority of features in common supports a great deal of reuse in all the phases of system development. Due to the complex nature of product line development, requirements engineering is even more important for a product line. Hence a well-established requirements engineering process is vital. In this document, an attempt is made to address the area of RE for product line development. Several existing RE processes and techniques for single product development are briefly described. Also several existing product line practices are described and the RE activities in each of them are analyzed. The applicability of existing RE processes and techniques to product line development are assessed. Finally, a RE approach for product line development using aspect-oriented programming concepts and extensible Markup Language (XML) is proposed. iii

4 ACKNOWLEDGEMENT I would like to thank Dr.Eberlein, for his support and guidance throughout this project. I also thank my husband Soorya and son Shreyas for their patience, support and encouragement throughout this project. iv

5 TABLE OF CONTENTS ABSTRACT...III ACKNOWLEDGEMENT... IV LIST OF FIGURES... VIII LIST OF TABLES... IX 1 CHAPTER ONE: INTRODUCTION REQUIREMENT REQUIREMENTS ENGINEERING SOFTWARE REUSE SOFTWARE PRODUCT LINES DOMAIN ANALYSIS AND ENGINEERING ASPECT-ORIENTED PROGRAMMING EXTENSIBLE MARKUP LANGUAGE (XML) PROJECT GOALS DOCUMENT STRUCTURE DESCRIPTION CHAPTER TWO: REQUIEMENTS ENGINEERING PROCESSES AND TECHNIQUES INTRODUCTION REQUIREMENTS ENGINEERING Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Requirements Management...39 v

6 3 CHAPTER THREE: SOFTWARE PRODUCT LINE ENGINEERING INTRODUCTION PRODUCT LINE APPROACHES Synthesis Family-oriented Abstraction, Specification and Translation (FAST) PuLSE Deployment Phases Technical Components PuLSE Support Components FODA Odyssey-DE Sherlock The Definition Hierarchy Approach CHAPTER FOUR: ASSESSMENT OF REQUIREMENTS ENGINEERING PROCESSES AND TECHNIQUES INTRODUCTION REQUIREMENTS ENGINEERING FOR PRODUCT LINES Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Requirements Management Techniques CHAPTER FIVE: ASPECT-ORIENTED REQUIREMENTS ENGINEERING FOR PRODUCT LINES...74 vi

7 5.1 INTRODUCTION OVERVIEW OF THE APPROACH Requirements Capturing Requirements Analysis Commonality analysis by separating concerns Product Line Scoping and Characterization using Product Maps Product Line Modeling using OOA techniques Requirements Specification Requirements Review Requirements Management CHAPTER SIX: CONCLUSION SUMMARY OF RE PROCESSES AND TECHNIQUES SURVEY SUMMARY OF PRODUCT LINE PRACTICES CONCLUSION OF THE ASSESSMENT OF THE SUITABILITY OF RE PROCESSES AND TECHNIQUES TO PRODUCT LINE DEVELOPMENT SUMMARY AND CONCLUSION OF THE PROPOSED RE APPROACH FUTURE WORKSAND RECOMMENDATION ABBREVIATIONS, ACRONYMS, DEFINTIONS AND SYNONYMS REFERENCES vii

8 LIST OF FIGURES FIGURE 1. ASPECT ORIENTED PROGRAMMING STAGES [LADDAD 2002] FIGURE 2. ACTIVITIES IN THE REQUIREMENTS ENGINEERING PROCESS...21 FIGURE 3. THE SYNTHESIS DOMAIN ENGINEERING PROCESS [SYNTHESIS 1996]...42 FIGURE 4. PULSE OVERVIEW [BAYER 1999] FIGURE 5. FEATURE DIAGRAM EXAMPLE FIGURE 6. RE APPROACH FOR PRODUCT LINE DEVELOPMENT...75 FIGURE 7. PRODUCT MAP TECHNIQUE FOR PRODUCT LINE SCOPING FIGURE 8. USE CASE DIAGRAM FOR REPORT GENERATION ASPECT FIGURE 9. HIGH-LEVEL CLASS DIAGRAM FOR THE REPORT GENERATION ASPECT...90 viii

9 LIST OF TABLES TABLE 1. ASPECTS IDENTIFIED IN THE SPREADSHEET DOMAIN...79 TABLE 2. ASPECTS AND VARIATION POINTS...80 TABLE 3. SYMBOLS AND FUNCTIONS USED IN PRODUCT MAP...84 TABLE 4. USE CASE DESCRIPTION FOR REPORT GENERATION ASPECT...88 TABLE 5. OBJECTS IDENTIFIED FOR THE REPORT GENERATION USE CASE TABLE 6. ABBREVIATIONS AND ACRONYMS TABLE 7. DEFINITIONS ix

10 1 CHAPTER ONE: INTRODUCTION Requirement The capabilities or conditions that a customer or an end user expects from a system are called requirements. A requirement is something which a customer needs or something which needs to be designed [Macaulay 1996]. Requirements can be functional requirements such as the ability to check spelling in a word processor or they can be non-functional requirements such as high reliability or ease of use. From a designer or developer perspective, a requirement is a condition or capability that must be designed or implemented. Some requirements need to be satisfied from the organizational perspective. For example, products to be delivered in some geographical location may have to meet certain standards or satisfy certain government rules and regulations. Requirements play a key role in the design and implementation of a system. Therefore proper elicitation, analysis, specification and management of requirements are vital for the product development process. 1.2 Requirements Engineering Most of the system development processes used in the past do not have a systematic process-oriented approach to capture, analyze and manage the requirements. Macaulay presents examples of several product failures and abandoned projects due to a lack of understanding of system requirements [Macaulay 1996]. Errors that occur early in the software development life cycle, but

11 are not discovered until late in the life cycle are the costliest to fix [Thomas 1999]. 11 These reasons motivated software engineers to focus more on the requirements. Therefore, various processes have been developed to identify, analyze and manage requirements. The intention of such a process is to discover requirement defects and conflicts in the early stages of the development and to suggest corrections and resolutions. Requirements Engineering (RE) is a relatively new discipline in software engineering intended for capturing, analyzing, specifying and managing system requirements. Pohl [Pohl 1993] defines RE as: Requirements Engineering can be defined as the systematic process of developing requirements through an iterative, co-operative process of analyzing the problem, documenting the resulting observations in a variety of representation formats, and checking the accuracy of the understanding gained. From the above definition it is clear that RE is an iterative process. It may need several iterations to get a clear understanding of the problem situation and to produce a final requirements document. Results from all the activities involved in the RE process must be properly documented for future reference. Although RE is the initial stage in the development process, it influences all the phases of the development. It is likely that requirement changes may happen later in the development process. A good RE process must facilitate any need for such requirement changes in any phase of the development.

12 1.3 Software Reuse 12 Competition between companies has become very intense. Companies have to develop their products before their rival does to win the game. To attract new customers and to retain the existing installed base, the products developed must be better in quality, more reliable and cheaper. Software reuse is one approach to achieve the above goals. Systematic software reuse is the purposeful creation, management, support, and reuse of assets [JGJ 1997]. An asset could be any software artifact such as requirements specification, design document and implementation code. If an existing component can be reused several times there will be a significant decrease in both the production time and the testing time. There are several software reuse approaches such as object-orientation, component-based development and software product line development. 1.4 Software Product Lines Software product lines are families of products in which the family members share a majority of the functionalities and yet have functionalities unique to them. Software product lines have two types of requirements: requirements that are common to all the family members and requirements unique to individual family members. The key to a product line approach is to identify the commonalities and variabilities of the product members.

13 13 Instead of continually reinventing the wheel, or incorporating parts of old systems in an ad hoc manner, organizations following a product line approach can consolidate their key software assets within a high-quality, reusable software core, and concentrate their resources on adopting this core to meet the changing needs of the customer [Atkinson 1999]. With a systematic iterative process including proper domain analysis, feasibility study, market analysis, design and implementation, the software product line approach could result in high quality products. Any artifacts including requirements, design documents and implementation codes that are common across the family members can be reused. Only product-specific functionalities have to be developed separately. 1.5 Domain Analysis and Engineering Domain Analysis and Engineering (DA&E) is a sub-process of the software product line development practice. The DA&E process is concerned with the elicitation, analysis and modeling of reusable domain artifacts whereas the product line development practice is concerned with the entire process of identifying, developing and using the domain artifacts for developing a family of products. In Domain Analysis and Engineering (DA&E), the Analysis phase mainly focuses on identifying the commonalities and variabilities of the application domain. This phase is equivalent to the requirements engineering phase in the product development process. It also deals with feasibility study and cost-benefit analysis of the domain.

14 14 The Domain Engineering phase deals with defining a reference architecture for the domain. 1.6 Aspect-Oriented Programming Aspect-oriented programming is a programming approach based on the concept of Separation of concerns [Laddad 2002]. A concern is a concept, goal or area of interest. A system can be considered as a combination of several core-level concerns and system-level concerns. Core-level concerns include the business logic and system-level concerns include other system-level features such as logging, authentication and persistency. Many such system-level concerns tend to influence multiple implementation modules. They are called crosscutting concerns. Since these crosscutting concerns affect many implementation modules even with programming approaches such as object-orientation, they make the resulting system harder to understand, design and implement [Laddad 2002]. The solution for the above problem is to separate such crosscutting concerns and recompose them as a collection of loosely coupled aspects. This process is called Aspect-Oriented Programming. The following figure shows the various stages involved in aspectoriented programming development.

15 15 Figure 1. Aspect-Oriented Programming Stages [Laddad 2002]. Initially, the system requirements are decomposed into core-level and system-level concerns. In the next stage, each concern is implemented separately. Individual concerns can be implemented using object-oriented programming. In the next stage, an aspect integrator specifies the integration rules by developing aspects. Finally, the weaving process composes those aspects into the final system. This approach goes one step further in the reuse than the object-oriented approach. When different concerns or aspects are implemented separately, there is less coupling between implementation modules. This would not only make the system easier to understand but also increase the level of reuse. For product lines, in addition to the above benefits, it is possible to identify variations among the members by analyzing these system concerns. It is possible that there are products in the family that vary in crosscutting concerns. In such cases separation of concerns can help to identify and characterize product lines. In this project, separation of concerns is used in the requirements engineering process for

16 product lines. It is used in the initial stage of requirements engineering to identify 16 common and variable features. Later in the analysis and design each aspect can be considered separately in order to make the analysis and design process simpler. 1.7 Extensible Markup Language (XML) Extensible Markup Language (XML) is a generic markup language that enables data representation in a structured format [W3C 2000]. Unlike any programming language, XML only represents the data and the interpretation of that data is left to the user. In XML documents data are represented using a pair of tags ( < and > ) called elements and optional attributes (name= value pair). These elements can be either simple or nested. Following is a simple XML document representing data about students. Element Attribute <students> <student id= 4898 > <lastname>kuloor</lastname> <firstname>chethana</firstname> <address>university of Calgary</address> <program>m.eng </program> </student>.. </students> XML is extensible because, the elements and attributes used need not be predefined. Users can define their own elements and interpret them as desired. The

17 data in an XML document can be treated as objects and represented in a 17 hierarchical tree like structure. This object tree can be traversed using different techniques and the required data can be queried and used. XML is becoming a more and more popular data exchange format. In this project, XML is used to specify product-line requirements, to develop individual application specifications from the domain specifications and to maintain the dependency between various domain and individual product artifacts. 1.8 Project Goals The software product family approach enables a great deal of reuse in all the phases of the development. All the assets such as requirements, design, test cases and implementation that are common to all the members can be reused in the development of each family member. Since the product line development approach involves different types of customers, several member products and requirements common to all the family members, it is important to have a good requirements engineering process. A significant amount of work has been done in the area of domain analysis and engineering. However, most of it describes the design and implementation of the family architecture and application architecture. The area of requirements engineering is not completely addressed. In this project, an attempt is made to assess various existing requirements engineering processes and techniques for their suitability for product line practices. Also a new requirements engineering methodology for product lines is proposed. Summary of the Project Goals:

18 18 To describe various requirements engineering processes and techniques in use. To identify and analyze requirements engineering processes and techniques used in various software product line and domain engineering approaches. To assess the applicability of various requirements engineering techniques to the software product line development process. To propose a new requirements engineering methodology for product line development using the aspect-oriented programming concept and XML. 1.9 Document Structure Description This document is structured into six chapters. The following section briefly describes each chapter: Chapter One: Introduction A brief introduction to several major concepts used in this project is provided. Topics include description of requirements, requirements engineering, software reuse, software product line development, aspect-oriented programming, extensible markup language (XML) and others. Chapter Two: Requirements Engineering Processes and Techniques The requirements engineering process is described. Various stages in the requirements engineering process are briefly explained. Several techniques that assist the requirements engineering process are also briefly described.

19 Chapter Three: Software Product Line Engineering The product line 19 engineering concepts are explained in detail. Several software product lines and domain engineering practices are introduced and the RE processes and techniques used in each one of them are reviewed. Chapter Four: Assessment of Requirements Engineering Processes and Techniques The applicability of several requirements engineering processes and techniques that are known from single product development are assessed for their suitability for use in software product line development. Chapter Five: Aspect-Oriented Requirements Engineering for Product Lines A requirements engineering approach for the product line development process is proposed. It uses separation of concerns techniques to identify the common and variable requirements. XML is used as a language to specify and navigate the dependency between requirements. Chapter Six: Conclusion The project is summarized. Project limitations are described. Directions for future work are given.

20 2 CHAPTER TWO: REQUIEMENTS ENGINEERING PROCESSES 20 AND TECHNIQUES 2.1 Introduction Requirements engineering is a sub-discipline of software engineering that focuses on discovering, analyzing, specifying and managing the system requirements. In this chapter, the requirements engineering process and various requirements engineering techniques that exist in the literature are discussed. The first section describes the requirements engineering process and its various phases. The following sections explain various processes and techniques that can be used in different stages of the RE process. 2.2 Requirements Engineering Requirements engineering is a systematic and iterative process. The activities involved in the process may not be sequential or mutually exclusive. According to Sommerville and Kotonya, a requirements engineering process is a structured set of activities, which are followed to derive, validate and maintain a system s requirements document [Sommerville 1998]. The purpose of the requirements engineering process is to ensure that the system requirements are complete, precise, consistent and pertinent. Depending on the context, levels of expertise and amount of available resources, each organization can define its own requirements engineering process. The

21 21 requirements engineering process consists of several activities. Figure 1 illustrates activities involved in a typical RE process. Figure 2. Activities in the Requirements Engineering Process A typical Requirements Engineering process has five phases [Sommerville 1998]. They are: Requirements Elicitation, Requirements Analysis, Requirements

22 Specification, Requirements Validation and Requirements Management. Each 22 phase is described in more detail below Requirements Elicitation Requirements Elicitation is a process during which product requirements are elicited from a variety of sources. Possible sources of information for this task are the customer, end user, any other stakeholder, books, existing applications, domain knowledge, organizational standards or constraints and any other rules or regulations. Various techniques can be used for eliciting requirements [Macaulay 1996]. Brief descriptions of several such techniques are provided below. Interviews Interviewing is a technique where requirements engineers and different stakeholders communicate directly with each other. Interviews are usually conducted in a question-answer format with the intention of eliciting the required information for system development. There are two types of interviews: structured and unstructured [Macaulay 1996]. They are also called closed and open interviews [Sommerville 1998]. In the structured interview, the requirements engineer prepares a list of specific questions and collects responses for them from the customer. An unstructured interview is a discussion between the requirements engineer and stakeholders about the problem concepts and concerns of users. Here the requirements engineer makes note of certain topics to be discussed [Macaulay 1996, Sommerville 1998].

23 Interviews are good techniques to learn more about specific concepts. However, 23 interviewing requires lots of experience. Both the interviewer and interviewee must have proper background knowledge and excellent communication skills. The interviewer must be well prepared for the interview. The list of specific questions to be asked must be prepared well in advance. Even if they are successfully conducted, Interviews alone are not sufficient for requirements capturing. They can assist other techniques to elicit system requirements. Customer survey, questionnaires, Data Mining Surveys and questionnaires are requirements elicitation techniques in which a list of questions regarding the problem domain or concerns is prepared and distributed to the customers. Responses are collected and analyzed to study the customer needs. In order to get valuable responses, it is important to properly design the questionnaire and distribute it to the appropriate sample population [Macaulay 1996]. Data Mining is a technique used to analyze and extract useful patterns from the data collected. Mining the data about customers such as the responses to a product survey or customers reaction to a new technology, can draw important conclusion about their needs. These techniques are useful if the proposed product is targeted towards a large number of customers. In such cases, information gathered from a few customers will not be sufficient. Surveys and Questionnaires can be used to obtain information from a large number of customers. Data mining techniques can be used to analyze the data obtained from those surveys to identify different classes of customers and

24 24 certain patterns or relationships in their needs. However, it is always difficult to get a good and representative number of responses to surveys. In addition to this, the list of questions prepared should be relevant and should be distributed to the right sample population. Market Analysis The process of analyzing the product market for its current and future trends is called market analysis. Market analysis is a good technique to elicit requirements for a system. Gathering information about the competitor products would help to identify the features that are not present in current products [Macaulay 1996]. Market analysis is a good technique to analyze similar products in the market. It can reveal how technologies may change in the near future. It can also predict changes in customer s demands. Using these details, organizations can make decisions about selecting certain features or technologies for their products. However, in order to obtain good results from the analysis, the market expert must be well experienced and should have the skill to collect the required information. Focus Groups Focus groups are group session approaches, where requirements engineers observe and study users needs. Groups of users are allowed to discuss in a free environment certain problem concepts under the supervision of the requirements engineer. The requirements engineer acts as the facilitator and his role is passive. When the users discuss with each other, the requirements engineer can learn about

25 what they think about the product and what they actually want from the product 25 [Macaulay 1996]. Focus groups are group session approaches for requirements capturing. Since the users are allowed to discuss in a free environment, problems that occur due to a lack of communication can be reduced. It is easier to participate in a free discussion than in a structured interview. In addition to this, when different customers discuss certain topic, it is easy to identify requirements conflicts and to resolve them. However, the requirements engineer must have good listening and problem solving skills. Also when several different customers discuss together, it is important to maintain proper coordination between them. Future Workshops Future workshops are group session approaches similar to focus groups. In a future workshop session, the current problem situation is discussed, future visions of the systems are generated and possible solutions to realize those visions are discussed [Macaulay 1996]. Like Focus Groups, Future Workshops are a very good group session approach for requirements capturing. In addition to that, in Future Workshops future visions of the system are generated. During the process, any changes in the technologies or product features that may occur in the future can be foreseen. Using these details, the organization can not only make better selections for its current product, but also develop plans for its future products. Soft Systems Methodology (SSM)

26 26 SSM is a system development framework that allows for system analysis from both the organizational and technical perspective. Unlike traditional system development processes, which focus only on solving the technical requirements, SSM tries to analyze the problem situation and proposes necessary organizational changes to improve the organizational structure and processes. SSM has several distinctive stages. They are the Problem Situation Unstructured, the Problem Situation Expressed, building Root Definitions of relevant systems, conceptual modeling, comparison with the real world and implementing the feasible and desirable changes [Macaulay 1996]. SSM is a system development practice. SSM analyzes the environment in which the current product is residing and proposes the changes required for both the process and product improvements. It not only considers technical aspects but also the organizational aspects of product development. It also supports communication between the management and technical personnel. In addition to this, systems are analyzed from different viewpoints by defining several root definitions. This would identify conflicts in customer requirements or in different viewpoints. Cooperative Requirements Capture (CRC) Cooperative requirements capture is another group session approach for requirements engineering. The idea is to include not only the users and designers but also those who have a stake in the product. In this approach all the stakeholders together explore the user environment and develop a shared vision of the future system. During the group session, participants discuss the current user activities and

27 envision any possible changes that might occur in future. Such a shared 27 understanding of the system would help to solve any requirements conflicts and to develop a system that satisfies the needs of all the stakeholders [Macaulay 1996]. The advantage of using the CRC approach for requirements engineering is that it involves all the stakeholders in the decision making process. Due to this, the needs of different stakeholders can be easily understood. Since all the stakeholders explore and develop a shared understanding of the current and future visions of the product, it is possible to identify requirement changes and conflicts early in the development process. In addition to this, it supports communication between the participants. Scenario Based Requirements Elicitation In this technique, user requirements are collected using a set of interaction scenarios. A scenario is a particular instance of the system s use describing the interactions between the system and users of the systems. Having understood the problem concept, different scenarios can be identified by consulting the system users. Scenarios can be documented using a format that is suitable for the organization. However, Sommerville suggests that regardless of the format, each scenario must include information about the pre-condition, post-condition, normal and any exceptions in the flow of event and any other parallel activities [Sommerville 1998]. Scenario based elicitation is a good technique to capture system requirements. It is easier for the customer to describe how he or she performs certain sequences of

28 28 activities than answering a list of questions or simply stating the needs. In addition to this, individual scenarios are easier to understand and design rather than a whole system. Multiple Viewpoint Requirements Capture This is an approach, which helps to collect system requirements from different viewpoints. Different stakeholders will have different requirements that the system needs to fulfill. Each stakeholder has his/her own viewpoint on the services that the system should provide and the way in which it should be provided. In this approach, different viewpoints of the system are identified and the requirements for each viewpoint are collected separately [Sommerville 1997]. This technique enables to study the system from different viewpoints. Requirements gathered from each viewpoint can be analyzed to identify requirements conflicts. Through proper negotiations, most appropriate requirements can be selected. On the other hand, it is a very good technique to develop a generic product that satisfies the needs of different customers. Observation and Social Analysis Occasionally, it is difficult to elicit requirements just by talking to the users or asking questions. Users are often experts in performing jobs rather than describing how they do them. In such cases, observing and recording the users working in their real environment for a considerable amount of time can provide a lot of information about their requirements. Such techniques used to observe the user s behavior are called Observations and Social Analysis Techniques. These techniques include

29 ethnographic studies, where an ethnographer observes and records a group of 29 users working in their real work place [Macaulay 1996, Sommerville 1998]. When there is a lack of domain knowledge in the organization, Observations and Social Analysis are good techniques to elicit system requirements. For example, if the system being developed is completely new, developers may not have adequate domain knowledge required for product development. Sometimes users are not capable of explaining how they perform certain tasks and what they want from the product. In such cases, this is a very good technique for requirements capturing. Designer as Apprentice This is a technique where the designers learn from the user about their work. Here user is the master and designer is the apprentice who learns by watching and listening to the user. The idea behind this technique is to provide the designer with some practical knowledge about the end user s working environment and his/her requirements on the proposed system [Macaulay 1996]. Getting some practical knowledge about the user s work practice helps designers to better understand their needs. It also promotes communication between the user and designer. However, to get good results, the designers should have excellent learning skills Requirements Analysis This phase focuses on analyzing and refining the requirements gathered in the elicitation phase. A feasibility study and cost-benefit analysis of the product

30 30 development process may be conducted and the scope of the system is determined. Customer requirements are analyzed and requirements conflicts if any are resolved. Requirements analysis ensures that the system is going to provide the services that the customers require. It also helps the designer to understand the customer requirements. The following are some of the techniques used for requirements analysis. Structured Systems Analysis (SSA) Structured systems analysis is a function-oriented approach for requirements analysis. In this approach a hierarchy of activities that are required to develop the proposed system are generated. Initially, the most abstract functions are identified. For each abstract function the specific sub-functions required are identified. Some of the commonly used modeling techniques in this approach are data-flow diagrams, data dictionaries and entity-relationship models. Data-flow diagrams represent the flow of data in a system. Various processes required to carry out the user s tasks are identified. The flow of data between various processes is marked using specific notations. Entity-relationship diagrams are used to model the logical data structure of the system. Entities are physical or conceptual objects of the system [Macaulay 1996, Davis 1993]. SSA techniques are useful to understand system requirements from the technical perspective. SSA techniques are function-oriented approaches for system design. The techniques in SSA model system data and functions separately. They do not support component-based development. Hence, systems developed using these

31 31 techniques are difficult to manage and reuse. However, if organizations have lots of experience in function-oriented development, SSA techniques can be used to model and design the system. Object-Oriented Analysis (OOA) Object-oriented analysis has its origin in the object-oriented programming approach. In this approach, system requirements are analyzed using object-oriented techniques. An object is the encapsulation of an entity with its properties and behavior. Since objects represent real world entities, they are easy to understand and model. Object-oriented analysis involves several activities including the identification of different objects in the domain and their relationships, flow of messages between the objects and the evaluation of changes in their states due to events or any other stimuli [Macaulay 1996, Davis 1993]. This is a semi-formal modeling approach that has predefined diagrams and notations for modeling. The Unified Modeling Language (UML) is a widely used object-oriented modeling language. Since OOA techniques support component-based design and implementation, they are very good for reuse. The encapsulation of attributes and behavior as objects represent real world entities. Hence the system represented as a collection of objects is easier to understand and manage. In addition to this, component-based development enables designing the system as a collection of loosely coupled components. Since these components are loosely coupled, they can be reused independently.

32 32 Participatory Design This is a requirements analysis approach that emphasizes strong user involvement in system design. Both the designers and users work together in the analysis and design of the proposed system. The advantage of such a practice is that designers and users can learn from each other about the work practices and technical possibilities through mutual experiences. Users can learn new technologies through the training provided by designers and designers can get experience about user s work practice by actually doing their job. Several techniques including Future Workshops, Cooperative Prototyping, Design mock-ups and Future Games are used in Participatory Design [Macaulay 1996]. Since this approach involves users in the system design, problems that may occur due to a lack of communication can be avoided. All the users can participate in the decision making process. Designers can learn more about users needs by actually doing their work. Users can work with the designer to learn about the design and to verify that the design is going to meet all their needs. Joint Application Design (JAD) JAD is a group session requirements analysis and design approach developed by IBM. JAD defines six different roles of participants who should participate in a session: a session leader or facilitator, a system analyst, a specialist, a user representative, an information system representative and the executive sponsor. JAD can be used at different levels of abstraction including high-level problem

33 33 concept analysis, requirements analysis and specification of the design. Structured system analysis techniques such as data-flow diagrams, entity-relationship diagrams and data dictionaries are the most commonly used techniques in JAD [Macaulay 1996, U of Texas 1998]. JAD is a very good technique to involve system users in the design process. However, it uses SSA techniques for requirements analysis. SSA techniques are not highly supportive of reuse. Reuse of any component such as requirements, design and code components can reduce the amount of resources needed for development. Instead of SSA techniques, if OOA techniques are used, JAD can become a very good group session approach for requirements engineering. Quality Function Deployment (QFD) QFD is an approach developed in Japan to produce quality products in the automotive industry in It focuses on translating customer requirements into technical requirements throughout the product development process. Later in 1993 it was adapted to software development by Bett [Macaulay 1996]. The entire QFD process focuses on a house of quality, which maps customer requirements to the proposed product features. Each development phase can use its own house of quality. QFD for the planning phase is used for requirements analysis. The house of quality is centered on a matrix that shows the relationship between the customerstated requirements and the proposed product features. Participants are asked to rate each requirement according to their relevance to a particular feature. In addition to this, correlation between various technical features, customer s importance of

34 each requirement and market evaluation of the competitive features are also 34 considered. Based on the subjective analysis of the above factors, the final product features are selected. Thus the QFD approach helps to develop quality features that are important to customers [Macaulay 1996]. QFD is a good approach to select product features and to make high-level design decisions. It encourages the organization to consider factors such as customer s priority and competition for requirements analysis. In order for QFD to be efficient, it needs tool support. Without tool support it will be time consuming and less efficient. Also, when used for large systems with hundreds of requirements, QFD will be very difficult to manage Requirements Specification In this phase, requirements gathered in the elicitation phase and refined in the analysis phase are properly documented for future reference. Any software work product including requirements and design can be specified using special terms and notations. Requirements specifications provide a solid artifact for the developer about what to develop during the product development. The specification can also serve as part of the contract between the users and developers. It also serves as a means against which the product features can be validated. Requirements can be either documented using a structured document format such as a Software Requirements Specification (SRS) or they can be specified using organization specific specification languages [McPhee 2001].

35 Software Requirements Specification (SRS) 35 A software requirements specification is a structured document used to record requirements in human readable format. A requirements specification document is a specification of what a computer system is required to do [Macaulay 1996]. SRS are the simple and easiest format to document system requirements. They can be used as reference documents for requirements review and testing. Since SRS documents are written in human readable language, they are easy to understand. However, it is difficult to specify ambiguous and inconsistent requirements using SRS. Formal Methods Formal Methods is a mathematical approach to specify system requirements. Special notations and languages with a defined mathematical meaning are used to specify system requirements [FME 2002]. However Formal Methods have a very steep learning curve and hence are expensive to adopt. They are mainly used in mission critical systems, where precision and relevance of the requirements are absolutely necessary [Macaulay 1996]. Formal Methods are very difficult to learn and expensive to adopt. However, once understood, the system requirements can be precisely specified. The use of formal languages makes the developer think more carefully about the system requirements. Also in order to specify requirements using Formal Methods, the developer needs to have a clear understanding of the requirements.

36 2.2.4 Requirements Validation 36 Once the requirements are analyzed and specified, they must be validated with all the stakeholders for their relevance, completeness and precision. Requirements Validation is concerned with checking the requirements for omissions, conflicts and ambiguities and for ensuring that the requirements follow quality standards [Sommerville 1997]. Requirements validation gives the customers an opportunity to verify that their requirements are considered. For developers, requirements validation is a means to understand that they are developing the right product that the customer wants. Interviews, formal reviews, group reviews, prototyping and requirements testing are some of the techniques that can be used for validation. If any changes, defects or flaws are identified during validation, necessary actions are identified and required activities are repeated until satisfactory results are obtained [McPhee 2001]. Requirements Reviews Requirements reviews are techniques where stakeholders review the requirements specification document for its completeness, precision and relevance. Requirements Reviews can be either informal or formal. In an informal review, stakeholders review the requirements document and give feedback to the requirements engineer. The requirements engineer takes necessary actions based on feedback [McPhee 2001]. In case of a formal review, a formal meeting is arranged between the requirements engineer and a group of stakeholders. The requirements engineer presents all the requirements in the specification document one by one to the group members. The

37 37 group members are expected to review each requirement and provide the necessary feedback. All the comments on the requirements are recorded for later discussion. The review group is also responsible for making decisions regarding any actions to be taken to solve the problems identified [Sommerville 1997]. Requirements Review is a good technique to verify requirements. Since each requirement is reviewed separately, any problems can be detected. However, selection of the review team is important for its success. If the review team includes members from the RE process only, then it is possible that they may overlook some of the problems. On the other hand, if the review team includes external members, they must have proper domain knowledge to understand the requirements. Prototyping Prototyping is a technique for constructing a partial implementation of a system so that the customers, users or developers can learn more about a problem or a solution to that problem [Davis 1993]. System prototypes can de developed to demonstrate the system behavior before the final product is being developed. Users have an opportunity to really see how the final system is going to behave and they can provide any feedback regarding possible misunderstandings or any other changes in the requirements. There are several types of prototyping techniques in use. The following are the most commonly used prototyping techniques. Throwaway prototyping: In this type of prototyping, the system prototype is developed in order to understand more about a particular problem or its

38 solution and after its purpose is served, the prototype is simply discarded. 38 This type of prototype requires less effort than the evolutionary prototypes. Evolutionary prototyping: In this technique, system prototypes are developed to analyze a particular problem or its solution. The prototype it is then adapted to satisfy the needs that were better understood from it. This process is repeated until the final system is developed, hence the name evolutionary prototype. For requirements validation either a throwaway prototype or an evolutionary prototype can be developed. A quick and dirty prototype can be developed just to show the customer that some features are mandatory or to uncover any missing features. While building an evolutionary prototype, the initial prototype must be modified and enriched to incorporate the feedback obtained from the customer until the final real system is evolved [Davis 1993]. However, both throwaway and evolutionary prototypes necessitate additional development time and other resources. Requirements Testing Requirements testing is a process in which the final system is tested against each requirement in the specification document. For this, a test plan that contains the test cases to test each requirement in the final system is developed during requirements analysis. At least one test case must be defined for each requirement and some requirements may be tested using more than one test case to verify system functionalities during different state changes of the system. Testing the system

39 39 against each requirement ensures that the requirements are properly implemented [Rosenberg 1998]. While defining test cases for each requirement in the requirements analysis phase, it may be possible to identify some of the requirement defects or any other problems. In order to define a test case, it is necessary to precisely understand each requirement for the system Requirements Management Requirements management is required throughout the requirements engineering process. Major responsibilities for this phase are to ensure facilitation of various requirements engineering activities, management of requirement changes, proper documentation of various activities and requirements tracing. Requirements can be very efficiently managed with proper tool support. With the tool support, it is possible to manage various documents, models and other work products without much effort. In addition to this, with the help of proper tools, work products can be easily modified and traced. Also changes to requirements can be easily managed through proper version control techniques.

40 40 3 CHAPTER THREE: SOFTWARE PRODUCT LINE ENGINEERING 3.1 Introduction A product line or family is a collection of products that have a majority of features in common and vary in some unique features. The process of developing a family of products using reusable domain artifacts through a set of activities is called Software Product Line Engineering. Software Product Line Engineering has two major phases: Development of a domain framework and development of individual products. The process of developing the domain framework is called Domain Analysis and Engineering (DA & E) or Domain Engineering. The main objective of DA&E is to identify commonalities and variabilities among the family members and to develop a reusable domain framework. Requirements engineering activities are carried out in the early stages of DA&E to identify and characterize product line requirements and potential member products. They also involve activities such as product line requirements modeling, specification, validation and management. Individual products are then developed according to business and market strategies. This process is called Application Engineering. However, the actual number of steps and activities in each step are different for the various product line development processes. 3.2 Product Line Approaches There are several product line approaches in the literature. The major goal of all the approaches is to develop a reference architecture for the product family.

41 41 Some of the approaches such as Synthesis and PuLSE provide only a framework for product line development whereas others including KobrA, FODA and Sherlock present a specific product line practice. Although many product line practices have several requirements engineering activities, they do not completely address the area of requirements engineering. Several product line practices are described below. The requirements engineering activities in each of them are reviewed Synthesis Synthesis is a process that provides a framework for product line development [Synthesis 1996]. It can be tailored to different organizational contexts. The criterion for adopting a suitable Synthesis process is based on the reuse level of an organization. The Synthesis process has two sub-processes: Domain Engineering and Application Engineering. Domain Engineering is a set of iterative processes intended to produce an application development environment for a particular product family. Figure 3 shows various activities and products involved in the domain engineering sub-process of Synthesis.