Design rationale: concepts, techniques, and use
Design rationale: concepts, techniques, and use
Design Rationale Systems: Understanding the Issues
IEEE Expert: Intelligent Systems and Their Applications
Easing the Transition to Software Mass Customization
PFE '01 Revised Papers from the 4th International Workshop on Software Product-Family Engineering
Designing Software Product Lines with UML
SEW '05 Proceedings of the 29th Annual IEEE/NASA Software Engineering Workshop - Tutorial Notes
FeaturePlugin: feature modeling plug-in for Eclipse
eclipse '04 Proceedings of the 2004 OOPSLA workshop on eclipse technology eXchange
Configuring Common Personal Software: a Requirements-Driven Approach
RE '05 Proceedings of the 13th IEEE International Conference on Requirements Engineering
Rationale Management in Software Engineering
Rationale Management in Software Engineering
Software Engineering Using RATionale
Journal of Systems and Software
Multi-tiered design rationale for change set based product line architectures
Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge
Rationale-Based Software Engineering
Rationale-Based Software Engineering
A process-oriented approach to design rationale
Human-Computer Interaction
Making argumentation serve design
Human-Computer Interaction
| Hi-index | 0.00 |
The process of designing and building a software system requires making many decisions. These decisions, the alternatives considered, and the reasons behind the choices comprise the rationale for the completed system. The driving force behind many, if not most, of these decisions is the need to meet the stakeholder requirements for the system being developed. Software product line approaches allow developers to design and develop families of products that share a common platform of behaviors and infrastructure. These approaches are based on assembling a configuration of a set of common features (commonalities) along with a set of product specific features (variabilities) to form a new product with a low amount of effort. In this context, these variabilities represent a wide variety of potential "design" alternatives. The goal of our research is to bring the end-user into the process of configuring a software product through the use of system level rationale that maps product line features to system requirements. Specifically, in our approach we specify rationale at the level of a feature diagram. Accordingly, we are taking advantage of the natural correlation between alternative features in a feature diagram and the alternative structure used in design rationale. This allows the end-user to indicate which requirements apply to their product and to have that selection generate a set of product features that satisfy those requirements.