TwinPeaks '12: "Enhancing the Software Architecture ..."
Enhancing the Software Architecture Analysis and Design Process with Inferred Macro-Architectural Requirements
Plamen Petrov, Ugo Buy, and Robert L. Nord
(University of Illinois at Chicago, USA; SEI/CMU, USA)
Traditionally the flow of authoritative information and control in requirements and software engineering is from requirements to architecture, design, development, implementation and testing. Iterative, spiral and agile methods, among others, have introduced increments and iterations in eliciting and discovering requirements within the project life cycle. Yet the authoritative flow of information across organizational boundaries within the enterprise continues to be from requirements to architecture to design. We argue that two additional implicit sources of information should be included in the requirements engineering process, contextual environment concerns and architectural patterns and heuristics. To account for these two sources of implicit requirements information we introduce the concept of forward and backward inferred macro-architectural requirements. Forward inferred macro-architectural requirements are elicited from contextual environment concerns. Backward inferred macro-architectural requirements are extracted through a reverse requirements elicitation process from architectural heuristics and patterns. We have observed significant improvements in the efficiency of the development processes and the quality of the final software products as a result of making inferred macro-architectural requirements explicit.
@InProceedings{TwinPeaks12p20,
author = {Plamen Petrov and Ugo Buy and Robert L. Nord},
title = {Enhancing the Software Architecture Analysis and Design Process with Inferred Macro-Architectural Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {20--26},
doi = {},
year = {2012},
}
TwinPeaks '12: "What do Software Architects ..."
What do Software Architects Expect from Requirements Specifications? Results of Initial Explorative Studies
Anne Gross and Joerg Doerr
(Fraunhofer IESE, Germany)
Software requirements specifications (SRS) serve as an important source of information for software architects with regard to deriving suitable architectural design decisions. However, from a software architect’s viewpoint, using these documents efficiently and effectively is often difficult. One could attribute these observations to the fact that SRS also have to address and satisfy the information needs of other document consumers involved in downstream activities like interaction design, user interface design or testing – which is, indeed, very challenging for requirements engineers. In this position paper, we present goals and initial results of explorative studies aimed at investigating information needs that should be fulfilled in SRS from the viewpoint of software architects. In these studies, we gained first insights into the relevance of certain artifact types (like descriptions of interactions or system functionalities) and their suitable representation in terms of notations. Furthermore, the analysis of these initial results revealed variances within the group of software architects regarding information needs. This has motivated the planning and conduction of further studies in the near future that will investigate factors such as expertise or individual motivation, which might influence the information needs from software architects’ viewpoints.
@InProceedings{TwinPeaks12p41,
author = {Anne Gross and Joerg Doerr},
title = {What do Software Architects Expect from Requirements Specifications? Results of Initial Explorative Studies},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {41--45},
doi = {},
year = {2012},
}
TwinPeaks '12: "What do Software Architects ..."
What do Software Architects Expect from Requirements Specifications? Results of Initial Explorative Studies
Anne Gross and Joerg Doerr
(Fraunhofer IESE, Germany)
Software requirements specifications (SRS) serve as an important source of information for software architects with regard to deriving suitable architectural design decisions. However, from a software architect’s viewpoint, using these documents efficiently and effectively is often difficult. One could attribute these observations to the fact that SRS also have to address and satisfy the information needs of other document consumers involved in downstream activities like interaction design, user interface design or testing – which is, indeed, very challenging for requirements engineers. In this position paper, we present goals and initial results of explorative studies aimed at investigating information needs that should be fulfilled in SRS from the viewpoint of software architects. In these studies, we gained first insights into the relevance of certain artifact types (like descriptions of interactions or system functionalities) and their suitable representation in terms of notations. Furthermore, the analysis of these initial results revealed variances within the group of software architects regarding information needs. This has motivated the planning and conduction of further studies in the near future that will investigate factors such as expertise or individual motivation, which might influence the information needs from software architects’ viewpoints.
@InProceedings{TwinPeaks12p41,
author = {Anne Gross and Joerg Doerr},
title = {What do Software Architects Expect from Requirements Specifications? Results of Initial Explorative Studies},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {41--45},
doi = {},
year = {2012},
}
TwinPeaks '12: "Your What is My How: Why Requirements ..."
Your What is My How: Why Requirements and Architectural Design Should Be Iterative
Michael W. Whalen, Anitha Murugesan, and Mats P. E. Heimdahl
(University of Minnesota, USA)
Systems are naturally constructed in hierarchies in which design choices made at higher levels of abstraction levy requirements on system components at lower levels of abstraction. Thus, whether an aspect of the system is a design choice or a requirement depends largely on one's location within the hierarchy of system components. In addition, it is often the case that systems are not constructed top-down, but rather middle-out; compatibility with existing systems and architectures, or availability of specific physical components may influence high-level requirements. Despite these facts, several of the reference models commonly used for requirements, including the four-variable model and world machine model, do not account for hierarchical decomposition. In this position paper, we argue that requirements and architectural design should be more closely aligned: that requirements reference models should account for hierarchical system construction, and that architectural design notations should better support specification of requirements for system components. We briefly describe work to this end that was performed on the META II project and describe the gaps in this work that need to be addressed to meet practitioner needs.
@InProceedings{TwinPeaks12p36,
author = {Michael W. Whalen and Anitha Murugesan and Mats P. E. Heimdahl},
title = {Your What is My How: Why Requirements and Architectural Design Should Be Iterative},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {36--40},
doi = {},
year = {2012},
}
TwinPeaks '12: "Interplay Between Requirements, ..."
Interplay Between Requirements, Software Architecture, and Hardware Constraints in the Development of a Home Control User Interface
Michael Sørensen Loft, Søren Snehøj Nielsen, Kim Nørskov, and Jens Bæk Jørgensen
(Mjølner Informatics, Denmark)
We have developed a new graphical user interface for a home control device for a large industrial customer. In this industrial case study, we first present our approaches to requirements engineering and to software architecture; we also describe the given hardware platform. Then we make two contributions. Our first contribution is to provide a specific example of a real-world project in which a Twin Peaks-compliant approach to software development has been used, and to describe and discuss three examples of interplay between requirements and software architecture decisions. Our second contribution is to propose the hardware platform as a third Twin Peaks element that must be given attention in projects such as the one described in this paper. Specifically, we discuss how the presence of severe hardware constraints exacerbates making trade-offs between requirements and architecture.
@InProceedings{TwinPeaks12p1,
author = {Michael Sørensen Loft and Søren Snehøj Nielsen and Kim Nørskov and Jens Bæk Jørgensen},
title = {Interplay Between Requirements, Software Architecture, and Hardware Constraints in the Development of a Home Control User Interface},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {1--6},
doi = {},
year = {2012},
}
TwinPeaks '12: "Architecture-Driven Quality ..."
Architecture-Driven Quality Requirements Prioritization
Anne Koziolek
(University of Zurich, Switzerland)
Quality requirements are main drivers for architectural decisions of software systems. However, in practice they are often dismissed during development, because of initially unknown dependencies and consequences that complicate implementation. To decide for meaningful, feasible quality requirements and trade them off with functional requirements, tighter integration of software architecture evaluation and requirements prioritization is necessary.
In this position paper, we propose a tool-supported method for architecture-driven feedback into requirements prioritization. Our method uses automated design space exploration based on quantitative quality evaluation of software architecture models. It helps requirements analysts and software architects to study the quality trade-offs of a software architecture, and use this information for requirements prioritization.
@InProceedings{TwinPeaks12p15,
author = {Anne Koziolek},
title = {Architecture-Driven Quality Requirements Prioritization},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {15--19},
doi = {},
year = {2012},
}
TwinPeaks '12: "Interplay Between Requirements, ..."
Interplay Between Requirements, Software Architecture, and Hardware Constraints in the Development of a Home Control User Interface
Michael Sørensen Loft, Søren Snehøj Nielsen, Kim Nørskov, and Jens Bæk Jørgensen
(Mjølner Informatics, Denmark)
We have developed a new graphical user interface for a home control device for a large industrial customer. In this industrial case study, we first present our approaches to requirements engineering and to software architecture; we also describe the given hardware platform. Then we make two contributions. Our first contribution is to provide a specific example of a real-world project in which a Twin Peaks-compliant approach to software development has been used, and to describe and discuss three examples of interplay between requirements and software architecture decisions. Our second contribution is to propose the hardware platform as a third Twin Peaks element that must be given attention in projects such as the one described in this paper. Specifically, we discuss how the presence of severe hardware constraints exacerbates making trade-offs between requirements and architecture.
@InProceedings{TwinPeaks12p1,
author = {Michael Sørensen Loft and Søren Snehøj Nielsen and Kim Nørskov and Jens Bæk Jørgensen},
title = {Interplay Between Requirements, Software Architecture, and Hardware Constraints in the Development of a Home Control User Interface},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {1--6},
doi = {},
year = {2012},
}
TwinPeaks '12: "Binding Requirements and Component ..."
Binding Requirements and Component Architecture by Using Model-Based Test-Driven Development
Dongyue Mou and Daniel Ratiu
(Fortiss, Germany)
Model-based testing is a well known technique to generate automatically highly qualitative tests for a given system based on a simplified testing model. Test-driven development is an established development practice in the agile development projects, which implies firstly the partial specification of a system by using tests, and after this, the development of the system. In test driven development the system implementation is continuously checked against the tests in order to assess its correctness with respect to the specification. In this paper we investigate how can these two methods be combined such that the advantages of these two approaches can be leveraged: highly qualitative test-cases used as specification of requirements and support of a continuous checking of architecture. We propose to formalize sub-sets of requirements into models that are amenable to generate tests by using automatic techniques well-known from model based testing. These tests can then be used to check the system architecture specification against the requirements in a continuous manner.
@InProceedings{TwinPeaks12p27,
author = {Dongyue Mou and Daniel Ratiu},
title = {Binding Requirements and Component Architecture by Using Model-Based Test-Driven Development},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {27--30},
doi = {},
year = {2012},
}
TwinPeaks '12: "Your What is My How: Why Requirements ..."
Your What is My How: Why Requirements and Architectural Design Should Be Iterative
Michael W. Whalen, Anitha Murugesan, and Mats P. E. Heimdahl
(University of Minnesota, USA)
Systems are naturally constructed in hierarchies in which design choices made at higher levels of abstraction levy requirements on system components at lower levels of abstraction. Thus, whether an aspect of the system is a design choice or a requirement depends largely on one's location within the hierarchy of system components. In addition, it is often the case that systems are not constructed top-down, but rather middle-out; compatibility with existing systems and architectures, or availability of specific physical components may influence high-level requirements. Despite these facts, several of the reference models commonly used for requirements, including the four-variable model and world machine model, do not account for hierarchical decomposition. In this position paper, we argue that requirements and architectural design should be more closely aligned: that requirements reference models should account for hierarchical system construction, and that architectural design notations should better support specification of requirements for system components. We briefly describe work to this end that was performed on the META II project and describe the gaps in this work that need to be addressed to meet practitioner needs.
@InProceedings{TwinPeaks12p36,
author = {Michael W. Whalen and Anitha Murugesan and Mats P. E. Heimdahl},
title = {Your What is My How: Why Requirements and Architectural Design Should Be Iterative},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {36--40},
doi = {},
year = {2012},
}
TwinPeaks '12: "Interplay Between Requirements, ..."
Interplay Between Requirements, Software Architecture, and Hardware Constraints in the Development of a Home Control User Interface
Michael Sørensen Loft, Søren Snehøj Nielsen, Kim Nørskov, and Jens Bæk Jørgensen
(Mjølner Informatics, Denmark)
We have developed a new graphical user interface for a home control device for a large industrial customer. In this industrial case study, we first present our approaches to requirements engineering and to software architecture; we also describe the given hardware platform. Then we make two contributions. Our first contribution is to provide a specific example of a real-world project in which a Twin Peaks-compliant approach to software development has been used, and to describe and discuss three examples of interplay between requirements and software architecture decisions. Our second contribution is to propose the hardware platform as a third Twin Peaks element that must be given attention in projects such as the one described in this paper. Specifically, we discuss how the presence of severe hardware constraints exacerbates making trade-offs between requirements and architecture.
@InProceedings{TwinPeaks12p1,
author = {Michael Sørensen Loft and Søren Snehøj Nielsen and Kim Nørskov and Jens Bæk Jørgensen},
title = {Interplay Between Requirements, Software Architecture, and Hardware Constraints in the Development of a Home Control User Interface},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {1--6},
doi = {},
year = {2012},
}
TwinPeaks '12: "Interplay Between Requirements, ..."
Interplay Between Requirements, Software Architecture, and Hardware Constraints in the Development of a Home Control User Interface
Michael Sørensen Loft, Søren Snehøj Nielsen, Kim Nørskov, and Jens Bæk Jørgensen
(Mjølner Informatics, Denmark)
We have developed a new graphical user interface for a home control device for a large industrial customer. In this industrial case study, we first present our approaches to requirements engineering and to software architecture; we also describe the given hardware platform. Then we make two contributions. Our first contribution is to provide a specific example of a real-world project in which a Twin Peaks-compliant approach to software development has been used, and to describe and discuss three examples of interplay between requirements and software architecture decisions. Our second contribution is to propose the hardware platform as a third Twin Peaks element that must be given attention in projects such as the one described in this paper. Specifically, we discuss how the presence of severe hardware constraints exacerbates making trade-offs between requirements and architecture.
@InProceedings{TwinPeaks12p1,
author = {Michael Sørensen Loft and Søren Snehøj Nielsen and Kim Nørskov and Jens Bæk Jørgensen},
title = {Interplay Between Requirements, Software Architecture, and Hardware Constraints in the Development of a Home Control User Interface},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {1--6},
doi = {},
year = {2012},
}
TwinPeaks '12: "Enhancing the Software Architecture ..."
Enhancing the Software Architecture Analysis and Design Process with Inferred Macro-Architectural Requirements
Plamen Petrov, Ugo Buy, and Robert L. Nord
(University of Illinois at Chicago, USA; SEI/CMU, USA)
Traditionally the flow of authoritative information and control in requirements and software engineering is from requirements to architecture, design, development, implementation and testing. Iterative, spiral and agile methods, among others, have introduced increments and iterations in eliciting and discovering requirements within the project life cycle. Yet the authoritative flow of information across organizational boundaries within the enterprise continues to be from requirements to architecture to design. We argue that two additional implicit sources of information should be included in the requirements engineering process, contextual environment concerns and architectural patterns and heuristics. To account for these two sources of implicit requirements information we introduce the concept of forward and backward inferred macro-architectural requirements. Forward inferred macro-architectural requirements are elicited from contextual environment concerns. Backward inferred macro-architectural requirements are extracted through a reverse requirements elicitation process from architectural heuristics and patterns. We have observed significant improvements in the efficiency of the development processes and the quality of the final software products as a result of making inferred macro-architectural requirements explicit.
@InProceedings{TwinPeaks12p20,
author = {Plamen Petrov and Ugo Buy and Robert L. Nord},
title = {Enhancing the Software Architecture Analysis and Design Process with Inferred Macro-Architectural Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {20--26},
doi = {},
year = {2012},
}
TwinPeaks '12: "Towards Understanding Requirement ..."
Towards Understanding Requirement Evolution in a Software Product Line: An Industrial Case Study
Yijian Wu, Didar Zowghi, Xin Peng, and Wenyun Zhao
(Fudan University, China; University of Technology Sydney, Australia)
In most software development practices, software requirements and architecture are addressed simultaneously. The architecture may grow based on a core specification of requirements, and the requirements may also be elicited incrementally as the architecture gets more and more concrete. In this paper, we present a case study on the development history of Wingsoft Examination System Product Line (WES-PL), an active, industrial software product line with a history of more than eight years. We focus on 10 member products, 51 major versions that have been delivered to customer or archived in the repository between December 2003 and May 2012, by tracing both requirement and architectural changes. We identify a requirement change classification from the viewpoint of architectural impact. We claim that software requirements are negotiated and may be guided by existing software architecture design, especially in the process of software product line development. Product strategy requirements play an important role in marketing requirement negotiation. We also find typical evidences showing that a product leader or architect has to make difficult decisions to keep a balance between marketing requirements from customer-side and software architectural design from his own side.
@InProceedings{TwinPeaks12p7,
author = {Yijian Wu and Didar Zowghi and Xin Peng and Wenyun Zhao},
title = {Towards Understanding Requirement Evolution in a Software Product Line: An Industrial Case Study},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {7--14},
doi = {},
year = {2012},
}
TwinPeaks '12: "Enhancing the Software Architecture ..."
Enhancing the Software Architecture Analysis and Design Process with Inferred Macro-Architectural Requirements
Plamen Petrov, Ugo Buy, and Robert L. Nord
(University of Illinois at Chicago, USA; SEI/CMU, USA)
Traditionally the flow of authoritative information and control in requirements and software engineering is from requirements to architecture, design, development, implementation and testing. Iterative, spiral and agile methods, among others, have introduced increments and iterations in eliciting and discovering requirements within the project life cycle. Yet the authoritative flow of information across organizational boundaries within the enterprise continues to be from requirements to architecture to design. We argue that two additional implicit sources of information should be included in the requirements engineering process, contextual environment concerns and architectural patterns and heuristics. To account for these two sources of implicit requirements information we introduce the concept of forward and backward inferred macro-architectural requirements. Forward inferred macro-architectural requirements are elicited from contextual environment concerns. Backward inferred macro-architectural requirements are extracted through a reverse requirements elicitation process from architectural heuristics and patterns. We have observed significant improvements in the efficiency of the development processes and the quality of the final software products as a result of making inferred macro-architectural requirements explicit.
@InProceedings{TwinPeaks12p20,
author = {Plamen Petrov and Ugo Buy and Robert L. Nord},
title = {Enhancing the Software Architecture Analysis and Design Process with Inferred Macro-Architectural Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {20--26},
doi = {},
year = {2012},
}
TwinPeaks '12: "Binding Requirements and Component ..."
Binding Requirements and Component Architecture by Using Model-Based Test-Driven Development
Dongyue Mou and Daniel Ratiu
(Fortiss, Germany)
Model-based testing is a well known technique to generate automatically highly qualitative tests for a given system based on a simplified testing model. Test-driven development is an established development practice in the agile development projects, which implies firstly the partial specification of a system by using tests, and after this, the development of the system. In test driven development the system implementation is continuously checked against the tests in order to assess its correctness with respect to the specification. In this paper we investigate how can these two methods be combined such that the advantages of these two approaches can be leveraged: highly qualitative test-cases used as specification of requirements and support of a continuous checking of architecture. We propose to formalize sub-sets of requirements into models that are amenable to generate tests by using automatic techniques well-known from model based testing. These tests can then be used to check the system architecture specification against the requirements in a continuous manner.
@InProceedings{TwinPeaks12p27,
author = {Dongyue Mou and Daniel Ratiu},
title = {Binding Requirements and Component Architecture by Using Model-Based Test-Driven Development},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {27--30},
doi = {},
year = {2012},
}
TwinPeaks '12: "How to Avoid Taking Three ..."
How to Avoid Taking Three Lefts When You Can Go Right: Making the Architectural Perspective Count
Deepti Savio and Girish Suryanarayana
(Siemens, India)
Although current trends in software development methodologies allow for changes to requirements at various phases of development, modifying the existing system design to reflect these changes is often architecturally challenging. In many real world instances, seemingly simple updates to user or functional requirements often have a significant impact on several dimensions of the overall system architecture. The effects of this impact make the realization of the change architecturally infeasible within the constraints imposed by other requirements, the existing architecture, the technical environment, and the available resources. Here, we describe two instances of this issue that were encountered in an industry project to highlight why it is critical to have a visible, distinct, and continuously updated mapping between requirements and constraints. We share some insights from our experiences, and outline possible approaches that would help establish a dialogue between the product manager and the system architect in a project, before modifications to requirements are accepted.
@InProceedings{TwinPeaks12p31,
author = {Deepti Savio and Girish Suryanarayana},
title = {How to Avoid Taking Three Lefts When You Can Go Right: Making the Architectural Perspective Count},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {31--35},
doi = {},
year = {2012},
}
TwinPeaks '12: "How to Avoid Taking Three ..."
How to Avoid Taking Three Lefts When You Can Go Right: Making the Architectural Perspective Count
Deepti Savio and Girish Suryanarayana
(Siemens, India)
Although current trends in software development methodologies allow for changes to requirements at various phases of development, modifying the existing system design to reflect these changes is often architecturally challenging. In many real world instances, seemingly simple updates to user or functional requirements often have a significant impact on several dimensions of the overall system architecture. The effects of this impact make the realization of the change architecturally infeasible within the constraints imposed by other requirements, the existing architecture, the technical environment, and the available resources. Here, we describe two instances of this issue that were encountered in an industry project to highlight why it is critical to have a visible, distinct, and continuously updated mapping between requirements and constraints. We share some insights from our experiences, and outline possible approaches that would help establish a dialogue between the product manager and the system architect in a project, before modifications to requirements are accepted.
@InProceedings{TwinPeaks12p31,
author = {Deepti Savio and Girish Suryanarayana},
title = {How to Avoid Taking Three Lefts When You Can Go Right: Making the Architectural Perspective Count},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {31--35},
doi = {},
year = {2012},
}
TwinPeaks '12: "Your What is My How: Why Requirements ..."
Your What is My How: Why Requirements and Architectural Design Should Be Iterative
Michael W. Whalen, Anitha Murugesan, and Mats P. E. Heimdahl
(University of Minnesota, USA)
Systems are naturally constructed in hierarchies in which design choices made at higher levels of abstraction levy requirements on system components at lower levels of abstraction. Thus, whether an aspect of the system is a design choice or a requirement depends largely on one's location within the hierarchy of system components. In addition, it is often the case that systems are not constructed top-down, but rather middle-out; compatibility with existing systems and architectures, or availability of specific physical components may influence high-level requirements. Despite these facts, several of the reference models commonly used for requirements, including the four-variable model and world machine model, do not account for hierarchical decomposition. In this position paper, we argue that requirements and architectural design should be more closely aligned: that requirements reference models should account for hierarchical system construction, and that architectural design notations should better support specification of requirements for system components. We briefly describe work to this end that was performed on the META II project and describe the gaps in this work that need to be addressed to meet practitioner needs.
@InProceedings{TwinPeaks12p36,
author = {Michael W. Whalen and Anitha Murugesan and Mats P. E. Heimdahl},
title = {Your What is My How: Why Requirements and Architectural Design Should Be Iterative},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {36--40},
doi = {},
year = {2012},
}
TwinPeaks '12: "Towards Understanding Requirement ..."
Towards Understanding Requirement Evolution in a Software Product Line: An Industrial Case Study
Yijian Wu, Didar Zowghi, Xin Peng, and Wenyun Zhao
(Fudan University, China; University of Technology Sydney, Australia)
In most software development practices, software requirements and architecture are addressed simultaneously. The architecture may grow based on a core specification of requirements, and the requirements may also be elicited incrementally as the architecture gets more and more concrete. In this paper, we present a case study on the development history of Wingsoft Examination System Product Line (WES-PL), an active, industrial software product line with a history of more than eight years. We focus on 10 member products, 51 major versions that have been delivered to customer or archived in the repository between December 2003 and May 2012, by tracing both requirement and architectural changes. We identify a requirement change classification from the viewpoint of architectural impact. We claim that software requirements are negotiated and may be guided by existing software architecture design, especially in the process of software product line development. Product strategy requirements play an important role in marketing requirement negotiation. We also find typical evidences showing that a product leader or architect has to make difficult decisions to keep a balance between marketing requirements from customer-side and software architectural design from his own side.
@InProceedings{TwinPeaks12p7,
author = {Yijian Wu and Didar Zowghi and Xin Peng and Wenyun Zhao},
title = {Towards Understanding Requirement Evolution in a Software Product Line: An Industrial Case Study},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {7--14},
doi = {},
year = {2012},
}
TwinPeaks '12: "Towards Understanding Requirement ..."
Towards Understanding Requirement Evolution in a Software Product Line: An Industrial Case Study
Yijian Wu, Didar Zowghi, Xin Peng, and Wenyun Zhao
(Fudan University, China; University of Technology Sydney, Australia)
In most software development practices, software requirements and architecture are addressed simultaneously. The architecture may grow based on a core specification of requirements, and the requirements may also be elicited incrementally as the architecture gets more and more concrete. In this paper, we present a case study on the development history of Wingsoft Examination System Product Line (WES-PL), an active, industrial software product line with a history of more than eight years. We focus on 10 member products, 51 major versions that have been delivered to customer or archived in the repository between December 2003 and May 2012, by tracing both requirement and architectural changes. We identify a requirement change classification from the viewpoint of architectural impact. We claim that software requirements are negotiated and may be guided by existing software architecture design, especially in the process of software product line development. Product strategy requirements play an important role in marketing requirement negotiation. We also find typical evidences showing that a product leader or architect has to make difficult decisions to keep a balance between marketing requirements from customer-side and software architectural design from his own side.
@InProceedings{TwinPeaks12p7,
author = {Yijian Wu and Didar Zowghi and Xin Peng and Wenyun Zhao},
title = {Towards Understanding Requirement Evolution in a Software Product Line: An Industrial Case Study},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {7--14},
doi = {},
year = {2012},
}
TwinPeaks '12: "Towards Understanding Requirement ..."
Towards Understanding Requirement Evolution in a Software Product Line: An Industrial Case Study
Yijian Wu, Didar Zowghi, Xin Peng, and Wenyun Zhao
(Fudan University, China; University of Technology Sydney, Australia)
In most software development practices, software requirements and architecture are addressed simultaneously. The architecture may grow based on a core specification of requirements, and the requirements may also be elicited incrementally as the architecture gets more and more concrete. In this paper, we present a case study on the development history of Wingsoft Examination System Product Line (WES-PL), an active, industrial software product line with a history of more than eight years. We focus on 10 member products, 51 major versions that have been delivered to customer or archived in the repository between December 2003 and May 2012, by tracing both requirement and architectural changes. We identify a requirement change classification from the viewpoint of architectural impact. We claim that software requirements are negotiated and may be guided by existing software architecture design, especially in the process of software product line development. Product strategy requirements play an important role in marketing requirement negotiation. We also find typical evidences showing that a product leader or architect has to make difficult decisions to keep a balance between marketing requirements from customer-side and software architectural design from his own side.
@InProceedings{TwinPeaks12p7,
author = {Yijian Wu and Didar Zowghi and Xin Peng and Wenyun Zhao},
title = {Towards Understanding Requirement Evolution in a Software Product Line: An Industrial Case Study},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {7--14},
doi = {},
year = {2012},
}