ReqTGUI
A Prototype for Solving and Visualizing Decision Problems
in Requirements Engineering with Constraint Programming
Authors
Joel Johansson & Oskar Präntare
June 20, 2013
M
ASTER’
S THESIS WORK CARRIED OUT AT THED
EPARTMENT OFC
OMPUTERS
CIENCE, L
UNDU
NIVERSITY.
Examiner
Krzysztof Kuchcinski
Supervisor
Björn Regnell
Abstract
In requirements engineering there are prioritization and release planning problems. These problems have earlier been solved with the help of algorithms adapted for a specific interpretation.
The thesis investigates the possibility to solve the prioritization and release planning problems with constraint programming using a prototype to visualize the solutions and the flexibility that constraint programming provides. The prototype and its functionality was validated by comparisons with the ReleasePlanner tool.
By describing prioritization and release planning problems as constraint pro-gramming satisfaction problems users have the opportunity to customize their problems and solutions, solve a wider range of problems and allowing the users to explore how changes affect the solution. The thesis is a proof of concept with limitations in the research concerning optimization and usability of the prototype. The new research presented in the thesis is the possibility to merge prioritiza-tion methods by formulating them as constraints and a hierarchical requirements engineering model. The thesis resulted in a prototype that visualizes the constraint based solutions of requirements engineering decision problems and applies the flexibility of constraint programming to release planning problems.
Testing shows that the prototype is applicable for smaller release planning problems. Future work includes performance optimization, formulating more pri-oritization methods as constraints and improving usability.
Keywords: Constraint programming, prioritization, release planning, reqT, Re-leasePlanner and requirements engineering.
Acknowledgements
The following thesis is, as most research, a continuation and extension of the past work of others. The following thesis would not be possible without everyone that have earlier indirectly or directly contributed to the fields of research connected to the thesis.
We would like to give our sincere thanks to those that have helped us through-out the thesis: Our test subjects Richard Berntsson Svensson and Christian Söder-berg, our examinator and constraints expert Krzysztof Kuchcinski, the students who helped us with our surveys, Siri Dovner for her suggestions and our families for their dearest and continuous support.
Special thanks to Guenther Ruhe, Mark Przepiora and the ReleasePlanner tool for their extensive help by providing data, research and enabling the comparisons to be made. Finally gratitude goes to our supervisor Björn Regnell who has given his continous support and working into the middle of the night to be able to finish the extra functionality in reqT that we needed.
Contents
1 Introduction 6 1.1 Problem formulation . . . 6 1.2 Motivation . . . 7 1.3 Scope . . . 7 1.4 Terminology . . . 72 Background and Related work 9 2.1 Requirements engineering . . . 9 2.1.1 Requirements Specification . . . 9 2.1.2 Requirements Prioritization . . . 9 2.1.3 Release Planning . . . 9 2.2 Constraint Programming . . . 10 2.3 Agile Development . . . 10 2.4 ReqT . . . 12 2.5 Previous Work . . . 13 2.5.1 ReleasePlanner . . . 13 3 Methodology 15 3.1 Overview . . . 16 3.2 Elicitation . . . 17 3.2.1 Literature study . . . 18
3.2.2 First survey questionnaire . . . 18
3.2.3 Second survey questionnaire . . . 18
3.2.4 Brainstorm . . . 19 3.2.5 Interview . . . 19 3.3 Specification . . . 19 3.3.1 Data model . . . 19 3.3.2 Virtual windows . . . 20 3.4 Implementation . . . 21 3.4.1 Release planning . . . 21 3.5 Validation . . . 24 3.6 Threats to validity . . . 24 3.7 Tools . . . 25 4 Theory 26 4.1 Requirements engineering . . . 26 4.1.1 Prioritization . . . 26 4.1.2 Release planning . . . 29 4.2 Constraint programming . . . 31 5 Implementation 32 5.1 Back end . . . 32 5.1.1 Mutable reqT . . . 32 5.1.2 Prioritization . . . 33
5.1.3 Release planning . . . 36 5.2 Front end . . . 38 5.2.1 View . . . 38 5.2.2 Add / Edit . . . 40 5.2.3 Prioritization . . . 42 5.2.4 Release plan . . . 43
5.2.5 Requirements engineering visualization . . . 46
5.3 Architecture . . . 46
5.3.1 Extending ReqTGUI . . . 48
6 Results 50 6.1 Validation . . . 50
6.1.1 ReqTGUI validation . . . 50
6.1.2 Release plan validation . . . 51
6.1.3 Release planning flexibility . . . 53
6.2 Examples . . . 56
6.2.1 Software scenario . . . 56
6.2.2 Use case of the software scenario . . . 57
6.2.3 Enviromental logistics scenario . . . 60
6.3 Discussion and conclusions . . . 62
6.4 Result limitations . . . 62 6.5 Future work . . . 63 7 References 64 7.1 Written references . . . 64 7.2 Online references . . . 65 A ReqT models 66
B Release planning problem 71
C Requirements engineering models 74
D First Survey 77
E Second Survey 83
1
Introduction
The Introduction chapter gives a basic understanding of the purpose of the thesis and the outline.
The thesis is divided into chapters and begins by attempting to introduce the reader to the current research that the thesis is built upon. It continues by explaining the specific solutions proposed by the authors and ends with the results.
ReqTGUI – A Prototype for Solving and Visualizing Decision Problems in Re-quirements Engineering with Constraint Programming, was initially inspired by Björn Regnell’s and Krzysztof Kuchcinski’s article ofExploring Software Product Manage-ment Decision Problems with Constraint Solving - Opportunities for Prioritization and Release Planning[14]. In the article the authors gave a proof of concept of using constraint satisfaction problem modeling to solve requirements prioritization and re-lease planning problems, the advantages of modeling prioritization and rere-lease plan-ning problems as constraint satisfaction problems and a number of considerations for further research. Regnell et al. also stated that at the time when the article was writ-ten earlier suggested solutions used specific algorithms for the given problems. The article suggested that algorithms and constraints can be combined through constraint programming to reach solutions to release planning problems [14].
With the suggested future research in mind the focus of the thesis is aimed at solv-ing requirements prioritization and release plannsolv-ing problems with constraint program-ming, where a solution can make use of multiple prioritization algorithms, and to visu-alize the problems and their solutions with the help of a prototype. The thesis resulted in the prototype calledReqTGUI, a concept of a hierarchical requirements engineering model and a concept of merging prioritization methods and solving release planning problems with constraints. To be able to validate the results, the prototype is compared to the tool ReleasePlanner that is based on one of the largest release planning models, see subsection Previous work.
1.1
Problem formulation
The problem the thesis is investigating is that requirements prioritization and release planning problems have not used multiple methods nor algorithms and not been able to use the benefits of constraint programming described by Regnell et al [14]. Pre-vious work has suggested that using multiple algorithms or methods with constraint programming is possible[14]. Release planning modeled as a constraint programming satisfaction problem has to our knowledge not been implemented in a tool nor have we found any earlier attempts to visualize the results when recieving multiple solutions to requirements engineering problems through constraint programming.
Therefore our problem formulation is: How can a constraint programming-based approach to describe and solve software requirements prioritization and release plan-ning problems be implemented and visualized?
1.2
Motivation
Solutions using constraint programming instead of specific algorithms have the benefit of being flexible, granting the user the ability to explore multiple possible solutions or to customize the problems that are to be solved [14]. Thereby a constraint programming solution complement to the already existing tools is motivated.
As seen in Appendix D the students who participated in the survey about the re-quirements engineering tool reqT states that they preferred a solution that is able to visualize requirements engineering. To provide deeper access to constraint program-ming solutions a visualization is implemented.
With a solver of prioritization and release planning problems a claim can be made that a problem resembling a selection of requirements to a given amount of resource constrained releases can be solved, see page 9. Even though the focus of the thesis is software requirements engineering, the same ideas could be argued to also be appli-cable when e.g. minimizing environmental damages or emissions of a manufactured product, see the Examples subsection.
1.3
Scope
As described in the start of the Introduction chapter the thesis focuses on the implemen-tation of release planning functionality through a constraint programming perspective and attempts to visualize the new perspective with a prototype. The thesis focuses on providing and describing these features rather than making any attempts of refinement. The aim of the thesis is not to attempt to optimize the prototype, to research the abil-ity of scalabilabil-ity in the design nor research the usabilabil-ity of the prototype. No formal attempts of usability evaluation or improvements are performed in the thesis. The re-search is focused to see if constraint programming can solve the same problems as the current release planning solvers and see if constraint programming is able to extend the functionality of current tools. As described in the Methodology chapter we are also limited by any limitations that may be imposed by reqT [29] or the Scala programming language [31].
1.4
Terminology
The Terminology subsection explains how we have used some words, acronyms and abbreviations in the thesis. The intent of the Terminology subsection is to facilitate the understanding of the thesis.
Back end The software that provides the algorithms and solutions to the problems the
front endprovides from the users.
Done A description of when an implementation and validation of a task is completed. DSL Domain specific language.
Elicitation Requirements engineering process described in the Background and Re-lated work chapter. The process to find requirements.
Front end A visualization providing an interface for users to interact with theback end.
GUI Graphical user interface. ID Identification
JVM Java virtual machine
LTH Faculty of Engineering at Lund Unversity.
Objective function A function representing the benefit of a prioritization or release plan solution according to a specified objective.
Optimal solution The solution of a release planning problem that has the highest pos-sibleutility functionvalue.
Release A bundle of requirements planned to bedoneat a specific time. ReqTGUI The name of the prototype.
UML Unified modeling language.
Utility function Theobjective functionrepresenting the sum ofWASvalues in a re-lease plan.
2
Background and Related work
The reader needs to have an understanding of the fields that are used in the research of the thesis. The Background and Related work chapter is aimed at giving the reader an introduction. The chapter begins with a description of the fields that are related to the thesis, a simple introduction to how they are applied and finally the chapter discusses their influences to the various parts of the thesis.
2.1
Requirements engineering
A requirement represents information about a system, with a focus on what the system should do rather than how it should be done [10]. Requirements engineering is the process of finding the requirements, goals, responsibilities and constraints surrounding a system’s operation and development. These attributes for requirements engineering are derived from processes that together produces, validates and maintains a system’s requirements document [21].
2.1.1 Requirements Specification
When a system is to be developed it is useful to collect requirements to get knowledge of the desired functionality of the system. Elicitation is the process of finding and describing requirements. Requirements specification is the continued improvement of the requirements by specifying a more thorough description of the desired functions of a system [10].
2.1.2 Requirements Prioritization
Most software projects have time and cost constraints making it impossible to realize all candidate requirements. Requirements prioritization involves identifying the most valuable requirements according to the different stakeholders’ opinions [14]. Often the quality of a software product is determined by how well the product satisfies the needs of the customers and the product users. When prioritizing requirements different aspects can be taken into consideration, some common aspects are for instance impor-tance, cost and risk. A prioritization process is easy if the prioritization is based on only one aspect but if you add more, the priorities are likely to change since trade-offs have to be made [6].
An example of a prioritization following the ordinal ranking prioritization method-ology [22] of the requirements A, B, C, D and E can be seen in Specification 1, where the requirements have been given a value denoting their relative importance.
2.1.3 Release Planning
Release planning is the process of selecting the requirements that are to be introduced to a product in a set of releases. The selection is based on a number of given constraints and can concern one or many releases [19]. In comparison with the more specific soft-ware release planning problems the same ideas still apply. Softsoft-ware release planning
Specification 1Example of ranking prioritization of requirements A, B, C, D and E. Priority of A = 5 Priority of B = 4 Priority of C = 3 Priority of D = 2 Priority of E = 1
has been used to describe the pursuit of deciding what each release, of a sequence of releases that together creates a software product, should contain [14].
Often projects with the goal of creating new software systems are more likely to be successful if the product is released as a sequence of releases, since the time-to-market aspect can be crucial depending on the nature of the project it is often better if the product can be released at an earlier stage. If there is more than one release the suggested management strategy, according to Lauesen [10], is to manage each release as an individual project.
2.2
Constraint Programming
A constraint is a rule that by specific conditions can be satisfied. Constraint based problems that have solutions only when all constraints have been satisfied are consid-ered constraint satisfaction problems. Constraint programming solves constraint satis-faction problems by formulating constraints and finding the solutions that satisfy the constraints [11].
K. R. Apt has formulated a principle saying that constraint programming is about solving a fomulated constraint satisfaction problem of a general problem with general methods or through a given domain [1].
A constraint satisfaction problem is written as a combination of sets of variables, finite domains and constraints [14]. A variable is for instance in JaCoP considered to be a value that is within a finite domain [25].
Examples of constraint solvers are JaCoP [25] and MiniZinc [28]. Simple con-straint programming examples are given by Regnell et al. [14], one of the examples is described in the Theory chapter in Specification 6. More complex examples, theory and tools can be found at the JaCoP homepage [25].
2.3
Agile Development
Agile development is a software development process that follows a methodology inspired by the agile manifesto [19]. Agile development of software is an iterative process[5]. In iterative development, progress is measured in completed features, each iteration should always have working software, functionality in iterative development isdonewhen the feature is fully integrated, requirements are reconsidered at each iter-ation, all planning is a collaboration between the team and the customer and the design should be open and flexible [19].
In the agile methodology called Extreme Programming change requests to a sys-tem is described with the help of stories. Prioritization and relese planning is decided in an event called the Planning Game, where the cost and priority of each story is determined[2]. In a Planning Game stories are given a sorted location compared to other stories as to visualize the priority of each story, the result is the release plan [16]. James Shore [16] prefers a methodology of representing the stories as cards, see Figure 1 for a story example at LTH, and spreading the cards out over a table, see Figure 2 for an example of ordering cards at LTH, thereby allowing the people involved to move and access the stories directly. Agile development is used in the thesis’ methodology and have influenced the visualization of requirements engineering in the prototype.
Figure 2: Example of ordering of stories at LTH in 2013.
2.4
ReqT
ReqT is a free open source software requirements modeling tool developed in Scala, with which it is possible to create and manage scalable requirements models. ReqT demonstrates how requirements can be represented as a graph and is based on the premise of translating requirements engineering as a programming language, giving the user a higher extent of access and functionality [29]. Some of the potential ad-vantages of reqT over a regular document handler is the ease of accessing specific requirements, partitioning a requirements model and the ability to expand the usage of requirements through its command interface giving the user the full collection abilities of the languages Java and Scala [29].
In reqT all requirements are contained in a representation of a model and all inter-actions are made through the model representation [29]. A model may be merged, split or by other means interacted with by other models. For instance, allowing users to split a model into smaller parts that each user may work on and when the users are finished with their modifications, each user can merge their model with the other users’ models [30].
One property of reqT models is that they areimmutable. When a model is edited a copy of the original model containing the modifications is created [30].
In reqT the basic abstract unit by which models are built with is called anentity. Entities are divided into two groups,contextandrequirement. Requirements define the product while context represents the surrounding environment e.g. stakeholders and releases. An entity always contains an ID and may also contain a set of attributes or relations. A relation is a connection between two entities describing a rule of how the entities affect each other while attributes are descriptive information of an entity[30].
language, all development that integrates reqT needs to be developed in Scala[30].
2.5
Previous Work
The Previous work subsection describes the work that have influenced the research of the thesis and the design of the release planning model. There are several previously developed release planning models. Svahnberg et al. [17] presented 24 models mainly belonging to three groups, where EVOLVE with the ReleasePlanner tool is the largest group of models [17].
Earlier software projects concerning requirement management with visualization of software projects and release planning are for instance Agilefant [19] and Release-Planner [17]. ReleaseRelease-Planner solves prioritization and release planning problems [17] while Agilefant focuses on the visualization of the requirement management [19]. Par-allel to the projects there have also been research in mathematical solutions to software release planning [7].
Constraint programming has earlier been proposed to solve specific parts of the release planning process [14], for instance staffing [3], though the usage of constraint programming to allow a combination of the different parts to solve a release plan has at the time of the thesis been a novel idea [14]. Regnell’s and Kuchcinski’s article of
Exploring Software Product Management Decision Problems with Constraint Solving - Opportunities for Prioritization and Release Planningstated that they were first to introduce a combination of previous approaches with constraint programming to solve release planning problems[14]. The article brought forward the potential advantages of using constraint programming in release planning as flexible specification, interactive exploration, scalability, alternative release plans and optimization support.
Ruhe et al.[12] suggested a hybrid approach to release planning, combining con-straint programming and existing release planning algorithms, and empirically tested constraint programming in a release planning context. The conclusion was that exist-ing release plannexist-ing algorithms are more efficient than constraint programmexist-ing, but that constraint programming is preferred when advanced release planning objectives exist or as a complement to existing algorithms [12].
Constraint programming applied to release planning was described by Regnell and Kuchcinski [14] as a novelty. To our knowledge no further work, except the mentioned work by Ruhe et al, has been presented by the time of the formulation of the thesis in 2013. Earlier solutions do not use constraint programming to generate alternative release plans, visualize the constraint programming in a release plan nor show the ability to express the constraint programming defined release plans for different kinds of engineering processes.
2.5.1 ReleasePlanner
ReleasePlanner is a decision tool implementing the EVOLVE release planning model [17]. It is used to determine the best possible road-mapping, prioritization and release planning strategies. ReleasePlanner attempts to find strategies that maximize a stake-holder’s priority satisfaction while keeping the solution within boundaries by resource consumptions and capacities [24].
The EVOLVE release planning model is an evolutionary genetic and iterative algo-rithm that is able to take into account the prioritization of the stakeholders, incremental release planning, considerations of coupling or precedence constraints and generates suggestions of optimal release planning [8].
ReleasePlanner is based on more than forty man-years of research and development [24] and is used by more than one hundred companies within the software industry. As a part of the EVOLVE family the ReleasePlanner is considered by far the largest of the existing release planning models. Of these reasons ReleasePlanner has been deemed interesting in earlier academic research and used as example for further studies [17]. This influenced us to use ReleasePlanner for validation purposes in the thesis.
3
Methodology
The Methodology chapter describes the workflow used in the thesis, that has followed a requirements engineering inspired methodology. Each requirements engineering pro-cess is described as how it was adapted and used during the development of the thesis and the prototype.
The various stages have been elicitation, specification, prioritization, implementa-tion and validaimplementa-tion. The process has been iterative, inspired by Agile development, where the stages have been repeated for each iteration. The various techniques that are used in the thesis are influenced by the techniques described by Lauesen [10].
Elicitation has been the process of discovering what may be accomplished in the thesis. In the elicitation process techniques such as brainstorming, interviews, ques-tionnaries and literature studies have been used. In the beginning the structure of the thesis was elicited whereas closer to the end the elicitation was used to find more within areas that in earlier stages were found to be incomplete.
The specification process is used to describe how everything should be accom-plished in the thesis. Data model, virtual windows and a prototype have been used as specification techniques. For each elicited idea of what should be accomplished in the thesis the authors have specified how the idea should be included. At the start the spec-ification process was mostly details of the thesis processes and later the specspec-ification developed to create more depth and focus of understanding what had been discovered. Prioritization has been the process of discovering the importance of what content should be included in the thesis. The prioritization has mostly been carried out through discussions and brainstorming discovering ordinal prioritization models. As the au-thors during the writing of the thesis both developed the final prototype and expanded existing software in cooperation with the supervisor the prioritization process included more than one stakeholder.
Once details are established concerning what should be included and how, the next stage in turn is implementation. The implentation stage consists of implementation of requirements into the final protoype, though it also includes implementation of the deliverables, described in Figure 3, of each of the different stages.
Validation is the last stage and makes sure that each of the earlier stages has been correct and either starts a new iteration to redo earlier work or a new iteration to include more in the thesis.
In a more general statement each of the iterations has been a part of a larger iteration spanning the whole project, see Figure 3. The authors started by eliciting the thesis and the problems, specified how the thesis should be implemented, implemented the thesis based on the prioritization and finally validated the thesis as a whole.
Figure 3: Methodology of the thesis
3.1
Overview
At the start of the thesis a project plan of the work process was defined and is illus-trated in Figure 4. The described steps are elicitation, specification, prioritization, validation, implementation, report, presentation and review. Each step was iterated as explained in the Methology chapter. In the validation phase a requirements document would be released in five versions. The requirements document would be a document explaining the requirements engineering processes in the thesis and give information of the prototype requirements. The implementation process created the source code and the automated tests that were required to consider a requirement to bedone. The im-plementation started with incorporating the reqT DSL in the prototype, designing the architecture, implementing the release planning model and functionality. The drafts of the thesis report was released continuously for reviews to the supervisor.
An example of a requirement that has been implemented and specified in the require-ments document is the feature VPr1 fomulated in Specification 2 and an example of a requirement that has been dropped is described in Specification 3. The requirements
Figure 4: Original project plan
document for the prototype resulted in 270 elicited requirements, 185 specified require-ments, 130 prioritized, 82 dropped requirerequire-ments, 67 requirements connected to a goal, 64 requirements implemented in the prototype and 48 requirements with automated tests. The combined requirements in the reqT model are described with 2600 lines of reqT code.
Specification 2Done requirement.
Feature("VPr1") has (
Gist("Edit stakeholder prioritization"),
Spec("A stakeholder should be able to assign prioritization to all requirements in the graphical user interface."),
Comment("Elicited from literature studies of Mark Przepiora et al, 2012, A hybrid release planning method and its empirical justification. Specified by Virtual window."),
Status(TESTED) ),
Feature("VPr1") requires Feature("MEShPr1")
Specification 3Dropped requirement.
Feature("CGePr2") has (
Gist("Consider dependencies during prioritizations."),
Spec("When generating a prioritization, requirement dependencies shall be taken into account when deciding which
priority a requirement has."),
Comment("Elicited from questionnaire: 2nd Survey"), Status(DROPPED) ), Feature("CGePr2") helps ( Goal("CGPr1"), Goal("MGRuhe1") )
3.2
Elicitation
The thesis work started with an elicitation of the requirements and what would be re-quired to be finished at the end of the thesis. The elicitation started with a literature study and was followed by questionnaries to the students with experience with reqT
who have earlier been a part of a requirements engineering course and to the students of the LTH course EDA270, Coaching of programming teams [23]. The students of the course EDA270 were selected as they were responsible of coaching and administrating other students in an agile project [23]. As a follow up to the questionnaires the au-thors had an interview with the students of EDA270 to find present problems and work processes in their agile environment. After these elicitations the authors ended the early eliciation with brainstorming processes together with the supervisor to discover their expectations, requirements and prioritizations of the thesis. The early elicitation process documentation can be found in the appendix.
3.2.1 Literature study
The literature study was a study, review and validation of literature that we considered to be relevant to the thesis and some literature adviced by our supervisor. The goal was to discover what may be accomplished and the general structure of the thesis. Requirements connected to the thesis and the prototype were also elicited. A summary of the literature and their research is presented in the Background and Related work and the Theory chapters. The literature study decided the focus of the thesis in line with Regnell et al. [13], inspired the authors to have a more agile consideration in the prototype, made the authors decide to use ReleasePlanner [24] and the related research [15] [12] as what to compare and benchmark the prototype against.
3.2.2 First survey questionnaire
The first survey was sent to the students who have used reqT in the requirements en-gineering course at LTH during 2012 and was written in collaboration with our su-pervisor who is also the coordinator of the course and creator of reqT. The intent of the first survey was to elicit requirements of reqT by the former users and to get a better understanding of the goals and motivations. As there are few answers and less specific design questions the goal with the first survey was to receive guidelines and understanding. The questions, intent and the answers can be found in the appendix D. The first survey gave a higher focus and motivation to implement the prototype with a graphical user interface.
3.2.3 Second survey questionnaire
The second survey was sent to the students in the course EDA270 at LTH [23]. The students are coaching and managing students working with an agile project. As the authors had been informed that the students practiced iterative requirement prioriti-zation, release planning, requirement visualization and requirement engineering the intent with the Second survey was to reach a better understanding of requirements and how to visualize requirements engineering.
The objective of the second survey was to gather the students’ experiences. As the answers are affected by agile ideas the questionnaire is used more as general guide-lines of requirement engineering and visualization. The questions and their intent can
be found in the appendix E. The second survey elicited and specified visualization re-quirements.
3.2.4 Brainstorm
Brainstorming is an activity of elicitation but is also used for prioritization [10]. Brain-storming was used in the thesis as the activity of discovering all possible ideas, regard-less of quality, while also receiving an early prioritization.
The first brainstorming was with Björn Regnell and occured at the 8th of February 2013. The elicitation was of goals and domain requirements of the prototype. The process started with Björn Regnell stating ideas and Oskar Präntare and Joel Johansson recording his answer. The authors only interactions with Björn Regnell during the brainstorm were to explain the brainstorm process structure and ask questions if they did not understand an idea. Afterward Björn Regnell prioritized the requirements. The brainstorm elicited, specified and prioritized requirements of the prototype.
The second brainstorming was with Oskar Präntare and Joel Johansson the 14th of February 2013. Each of the authors elicited and specified their requirements of the prototype and the thesis. Afterwards the authors prioritized the elicited requirements.
Both of the brainstorming sessions created and specified requirements. The prior-itization helped to understand the priority of each requirement, how the requirements should be scheduled and a better understanding of the goal of the thesis.
3.2.5 Interview
An interview with the coaching students at LTH mentioned in the second survey ques-tionnaire subsection were conducted. The intent of the interview was to examine present problems and processes. The interview should not be used for high level re-quirements except during stakeholder analysis. The questions should be broad ques-tions about every day issues and quesques-tions specific to the elicitation [10].
The questions were prepared ahead of time. The interviewed wrote their answers to each question. Agile words were chosen for the requirements engineering processes to give the students a better understanding of the questions. The questions, intent and an-swers can be found in the EDA270 interviews appendix. The results from the interview were the elicitation of concepts and visualization requirements.
3.3
Specification
Specification was described in the Background and Related work chapter as the provement of requirements. The specification process is in our methodology the im-provement of the thesis and the prototype.
3.3.1 Data model
The intent of the data model is to elicit and specify data requirements and for purposes of verification [10]. In the thesis requirements engineering model there are several
important words derived from the data model specification process: Requirement, con-text, attribute, relation, constraint, release, release plan, resource and prioritization. A requirement can have many attributes and relations, the same holds for a context. A prioritization is a set of priorities of requirements assigned by a context. A resource can both be the cost of implementing a requirement or the resources available for a release. A release plan consists of constraint defined rules of how a group of releases are related. The releases are given a requirement prioritization and a set of available resources. A better explanation of these words are given by reqT [29] or in the reqT subsection. An example of a data model is given in Figure 5. The data model elicited and specified requirements while also giving the authors an idea of how prioritization and release planning may be modeled in the prototype.
Figure 5: Data model of requirements.
3.3.2 Virtual windows
Virtual windows is a visual representation of requirements representing all informa-tion that a system requires but without any funcinforma-tionality. A virtual window is used to understand what a graphical interface contains and see if more data requirements are needed [10]. The virtual windows are used for elicitation, specification, verifica-tion and validaverifica-tion. The virtual windows have been constructed from the data model and the information gathered in the literature study, the surveys and the interviews. The virtual windows gave an early representation of the requirements engineering and visualization requirements. A virtual window is shown in Figure 6.
Figure 6: Virtual window of prioritization.
3.4
Implementation
The implementation of the prototype followed an agile development process, where the authors at the start of each iteration estimated the cost of the features included in the deliverable and concluded what features that would belong to the current release through discussions based on information from the relations, prioritization and the cost estimates of each feature. The features were put on story cards and progressed through the phases todo, doing, review and done, that were represented by the Status attribute in reqT asP LAN N ED, P LAN N ED, IM P LEM EN T ED, T EST ED in re-spective order, taken from the reqT status promotion ladder [29]. This process was repeated for a total of five iterations with continous feedback from our supervisor re-garding changes and new requirements.
3.4.1 Release planning
The order of the implementation of the deliverables was decided by ordering the re-quirements by prioritization. A deliverable with the same prioritization value as an-other requirement but with a higher cost was given a lower prioritization order. The cost of a requirement was given by the authors as a number between zero and ten that would be a relative value of the cost of a requirement based on the authors’ earlier experiences. The order of the deliverables was also affected by constraints, that a re-quirement had to be in a specific deliverable or that one rere-quirement required another requirement. Sometimes the order was changed as the authors believed that a different order could be positive for the thesis.
Description Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
Cost 21 39 32 27 30
Effort 11 17 10 9 9
Cost/Effort ∼2 ∼2.3 ∼3.2 3 ∼3.3
Table 1: Iteration cost and effort in total days spent for each iteration.
The implementation of the prototype started with a preparatory iteration zero1 and then commenced through five more iterations. Each iteration started with a selection of requirements given the prioritization and constraints. All the requirements were put on story cards and given a cost. Given a priority and a cost the story card started in the todo phase and continued over the board. When a story was doneit had auto-mated tests, all functionality was documented, the story had been reviewed and the functionality described in the story could be accessed by a user. For specific reasons some requirements did not recieve automated tests and thereby were given the status
IM P LEM EN T EDrather thanT EST ED. The requirements completed in the first iteration are described in Specification 4. In table 1 the cost of all requirements re-leased in an iteration is given together with the effort translated as the total amount of workdays spent on each iteration. As seen in the table the authors were able to com-plete more cost per effort after a few iterations had passed, one cost corresponds to almost one third of a workday.
Specification 4The first iteration as a reqT model.
Model(
Feature("VTp1") has (
Gist("See tooltip of graphical components by hoovering."),
Spec("Important graphical components should provide data on a tooltip if the user hover with the mouse over said components."),
Status(TESTED), Prio(7),
Cost(3),
Comment("Elicited from literature studies of Jenifer Tidwell, 2005, Designing interfaces, First edition, O’Reilly Media Inc., Sebastopol, p. 176."),
),
Feature("VIm1") has ( Gist("Open models."),
Spec("Existing models saved in files can be imported/opened in the GUI."), Status(TESTED),
Prio(9), Cost(2),
Comment("Elicited from brainstorm with Oskar Präntare 15th February 2013"), ),
Feature("VVw1") has (
Gist("Select views from a main view."),
Spec("The different views shall be accessible from a main view in the GUI."), Status(TESTED),
Prio(8), Cost(3),
Comment("Elicited from brainstorm with Oskar Präntare 15/2 2013"), ),
Feature("MWarn1") has (
Gist("Warning if duplicate ID"),
Spec("The system shall warn if one tries to create an entity with a name that already exists for an entity of the same type."),
Status(TESTED), Prio(6),
Cost(4),
Comment("Elicited from brainstorm with Oskar Präntare 15/2 2013"), ),
Feature("VM2") has ( Gist("Multiple models."),
Spec("It should be possible to view and select a multiple of models"), Status(TESTED), Prio(7), Cost(3), Comment("Elicited by Björn Regnell 28/2-2013"), ), Feature("VEM1") has ( Gist("Extraction view."),
Spec("A view that allows extraction of new models from a selected model"), Status(TESTED), Prio(7), Cost(6), Comment("Elicited by Björn Regnell 28/2-2013"), ) )
3.5
Validation
The validation started by first having the supervisor verify the content of the product and the thesis. At the final stage of the validation a number of verifications occured. A verification of using constraint programming to solve release planning and prioritiza-tion problems. That the prototype can perform the release planning problem by Ruhe et al. inThe art and science of software release planning[15]. The prototype allows a combination of multiple prioritization methods in the release planning. The proto-type visualizes multiple prioritization solutions. The protoproto-type has the functionality described by Ruhe et al. inA hybrid release planning method and its empirical justifi-cation[12]. Finally verification that the automated tests for the features included in the prototype are successful. The automated tests were written with the use of TestCase in reqT, an example can be seen in Specification 5.
Specification 5Example of an automated test. TestCase("TME4") has (
Gist("Tests creating and naming resources."), Code(""" import gui._;
var m = Model(F(1), F(2), F(3))
var container = new ModelContainer(m)
var addFirstOk = container.addResource("Godis") var addExisting = container.addResource("Godis") container.entity = F(1)
container.addCost("Godis", 15)
var costOk = ((container.model / Resource("Godis") !! Submodel) / F(1) !! Cost) == 15
addFirstOk && !addExisting && costOk """),
Expectation("true") ),
TestCase("TME4") verifies Feature("ME4")
3.6
Threats to validity
Each of the processes described in the Methodology chapter have issues that may cause errors. As the selection of the literature was subjective and of limited scope, relevant information may have been excluded or the literature that was used may have given the wrong idea of the research fields in question. The interviews and questionnaires were only directed to a small academic group of students that may give an errenous description to the authors. The brainstorming was performed with three people who were all deeply involved with the thesis making it possible that the requirements or goals are not adapted to the intended audience. The data model and the virtual windows were developed at an early stage of the thesis making them to some extent differ from the final prototype as they are describing data and requirements that were later dropped.
The release planning during the implementation was directly connected to the prior-itization and the cost estimates discovered during the specification and elicitation pro-cesses. The prototype was directly connected to reqT and thereby also JaCoP making the prototype maybe lack desired functionality and take other steps in the development than it otherwise would have. As the research in the literature study claims that the ReleasePlanner is an interesting tool in a release planning environment, as explained in the ReleasePlanner subsection, the thesis has focused on the research and functional-ity connected to the ReleasePlanner. If the research that promotes the ReleasePlanner is errenous large parts of the thesis maybe haven’t adapted to the needs of a release planning tool.
As the validation is made during a limited time and by a limited test group the validation is likely to miss issues and have problems caused by human errors. Since the prototype is not validated in an industry setting the prototype may not be adapted for how release planning is actually performed outside an academic setting.
3.7
Tools
To help the development of the prototype of the thesis reqT has been used as a tool. The reasons why reqT has been selected as the basis for the prototype is first that reqT is built for expressing requirements engineering models as code, giving the thesis all the pieces needed for a requirements engineering model. Secondly reqT is a requirements engineering tool that, during the development of the prototype, has integrated constraint programming functionality with JaCoP and promotes development of requirement en-gineering procedures with the help of constraint programming [30]. Third reason is that reqT is developed at LTH and therefore the authors have had a possibility to adapt the development of reqT to the needs of the thesis [29].
With the choice to use reqT in our development the prototype needs to, according to the ReqT subsection, be written in the Scala programming language [29][31].
The constraint programming framework used in reqT is JaCoP [25], which we thereby also take advantage of both directly and through reqT. The constraint program-ming examples written in the thesis are written in MiniZinc2[28].
2MiniZinc is a constraint modeling language, further information can be found at:
4
Theory
The Theory chapter begins with explaining the existing theory of requirements engi-neering together with the assumptions made in the thesis of how to adapt requirements engineering to an implementable model. In the Constraint programming subsection we argue how we think constraint programming should be viewed and utilized in a requirements engineering scenario. Some specifications in the Theory chapter origins from Regnell et al. [14]. The specifications are used to exemplify how requirements engeering problems can be represented as constraints. The WAS example is directly used in the prototype.
4.1
Requirements engineering
Requirements engineering was earlier mentioned in the Background and Related work chapter and is of high importance to the problem formulation of the thesis. The tool reqT tries to accomplish requirements engineering by translating the requirements and processes into programming methods within what reqT has named models [29] [13]. The reqT models follow the theory principle, also stated by other research [4], that requirements engineering can be divided as various entities where each entity has rela-tions and attributes [29]. These relarela-tions and attributes have been argued to be possible to describe with the help of constraints [4] [14].
4.1.1 Prioritization
As prioritization is a process to find the most valuable requirements, according to the stakeholders, a relationship between the stakeholders and the value of a requirement can be stated. The relationship has usually been defined by a specific method, often described as an algorithm, which enacted by the stakeholder creates a numerical out-put that is supposed to define the prioritized value of a requirement [14]. The thesis assumes that a requirement can have any prioritized value and that there is no definite maximum value of any requirement’s priority, thereby stating that a prioritization value should start from zero and be of any value from zero to infinity, where the largest value is the most prioritized value. The authors also argue that a list of prioritized require-ments can be ordered by their priority value and that the best prioritized order is zero, representing the first position in the ordered list. Thereby the authors claim a difference between prioritized value and a prioritized order, where the prioritized value should be maximized and prioritized order should be minimized if to reach the most optimal list of requirements in regard to their prioritization. Similarly to maximize a prioritized value Ruhe et al. uses an objective function to reach an optimal release plan by max-imizing the sum of the weighted satisfaction of the stakeholders and their prioritized value of each requirement [15].
Regnell et al. proposed that it is possible to express prioritization methods with constraint programming [14]. As to define requirements prioritization as a constraint satisfaction problem they defined prioritization methods as the problem of connecting a set of requirements entitiesn,{ri|1≤i≤n}to a set of numerical values{pi|1 ≤
a criteria and may be any integer between[1...m], where m is the maximum value the stakeholder may give a requirement. The prioritization methods Regnell et al. [14] gave as examples were translated into constraint programming using the MiniZinc language [28], and are shown in Specification 6 and 7.
Specification 6A priority ranking example given by Regnell et al. [14].
int: n = 5; array[1..n] of var 1..n: P; constraint alldifferent(P); constraint P[1] > P[2]; constraint P[2] > P[3]; constraint P[3] < P[4]; constraint forall ( i in 1..n) ( P[5] >= P[i] ); solve satisfy; output [show(P)];
Specification 7A priority grouping example given by Regnell et al. [14].
int: n = 7; array[1..n] of var 1..5: P; constraint forall ( i in {1,2,3}) ( P[i] = 5 ); constraint P[4] > 3 /\ P[5] < P[4]; constraint P[6] = P[4] + 1; constraint P[7] >= P[5] + 3; solve satisfy; output [show(P)];
If the constraints in a prioritization problem are consistent a set of solutions is possible to find. To allow the prioritization generated through constraint programming to be more flexible Regnell et al. [14] proposed that if a prioritization method has a too large set of solutions, more constraints can be added to the prioritization method to reduce the number of possible solutions. If those added constraints are consistent with the constraints that already exists, a solution set is still possible to find. If a prioritization method consists of constraints and if further constraints can be added, provided that the consistency is retained, then an assumption can be made that two such constraint based prioritization methods, prioritized by the same criteria, by the same stakeholder and with the same set of features, can be merged. The assumption is:Any set of constraint based prioritization methods may be merged if they originate from a consistent prioritization of the same stakeholder, criteria, set of features and type of priority. For examples see Specification 8 – 10.
In summary the theories of requirements prioritization affecting our implemention are the following: Given a list of requirements that each has a prioritized value a pre-ferred solution is a solution that maximizes the sum of the prioritized values included.
Specification 8Simple priority constraints.
constraint P[1] > P[2];
constraint P[2] > P[3];
constraint P[3] < P[4];
Specification 9Another priority constraints example.
constraint P[1] > P[4];
constraint P[1] > P[3];
A stakeholder can prioritize a set of requirements with the help of prioritization meth-ods. A stakeholder can prioritize a requirement more than once with a mix of chosen prioritization methods. A prioritization method’s result can be translated to a set of constraints. The constraints from different prioritization methods can be merged if the constraints are consistent with each other. The merged constraints, from the prioritiza-tions made by a stakeholder, allow generating each requirement’s prioritized order or value.
Specification 10Simple priority constraints in Specification 8 merged with constraints in Specification 9. constraint P[1] > P[2]; constraint P[2] > P[3]; constraint P[3] < P[4]; constraint P[1] > P[4]; constraint P[1] > P[3];
4.1.2 Release planning
Release planning is how to assign requirements to a sequence of releases given a num-ber of constraints [15] [12] [14]. The goal is to make the optimal feasible release plan by maximizing business value and satisfying the stakeholders while not violating the constraints set upon the release plan [15]. Ruhe et al. gives two approaches to accom-plishing the optimization [15]. TheArt of release planningis the release planning based on human intuition, communication and negotiation to reach the optimal solu-tion. TheScience of release planningdefines the problem and through algorithms reaches the optimal solution. Both approaches attempt to describe the problem that given a number of requirements entitiesn, {ri|1 ≤ i ≤ n} and release entitiesK,
{rei|1 ≤ i ≤ K} the goal is to assign eachrei to a releaseK. The assignment is
affected by a number of constraints and prioritizations. Examples of constraints are dependencies or resource availability for a release compared to the resources needed to realize the requirement. Each prioritization is made by a stakeholder. If the set of stakeholders isS,{si|1 ≤i≤S}each stakeholder inShas an importanceIm. The
importance of a stakeholder affects the importance of the stakeholder’s prioritization [15].
Regnell et al. [14] made a model of the release planning example given by Ruhe et al. [15]. Explanations of each of the variables can be found in the article and in Specification 12.
Specification 11The example by Ruhe et al. [15] with only initial values for the input array variablesr,valueandurgencygiven by Björn Regnell et al. [14].
N = 15; K = 2; R = 4; S = 2; lambda = [ 4, 6 ]; ksi = [ 7, 3 ];
% ksi is multiplied by 10 to have integer values
C = [|7, 8, |9, 12, |13, 14, |]; P = [|2, 1, |5, 6, |3, 11, |8, 9, |13, 15, |]; Cap = [| 1300, 1450, 158, 2200, | 1046, 1300, 65, 1750, |]; r = [| 150, 120, 20, 1000, | 75, 10, 8, 200, % ... etcetera value = [| 6, 7, 9, 5, % ... etcetera urgency = array3d(1..S, 1..N, 1..3, [ % stakeholder 1 5, 4, 0, 5, 0, 4, 9, 0, 0, % ... etcetera
Regnell et al. [14] showed that Specification 11 could be solved with constraint programming where dependency and other rules are specified as constraints. Solv-ing release plannSolv-ing problems with constraint programmSolv-ing was shown to also give the benefit that if there are more than one solution each solution can be found with a constraint satisfaction problem solver.
Specification 12The release planning example modeled as a constraint satisfaction problem by Regnell et al. [14].
int: N; % number of features
int: K; % number of releases
int: R; % number of resources
int: S; % number of stakeholders
array[1..N] of string: feature_id;
array[1..N, 1..R] of int: r;
array[1..S, 1..N] of int: value;
array[1..S, 1..N, 1..3] of int: urgency;
array[1..3, 1..2] of int: C; % coupling array[1..5, 1..2] of int: P; % precedence
array[1..S] of int: lambda; % stakeholder importance array[1..K] of int: ksi; % release importance
% ksi is multiplied by 10 to have integers array[1..K, 1..R] of int: Cap; %capacity array[1..N, 1..K] of var int:
WAS = array2d(1..N, 1..K, [ ksi[k] * sum (j in 1..S)
(lambda[j] * value[j,i] * urgency[j,i,k]) | i in 1..N, k in 1..K]);
% Variables ==========
array[1..N] of var 1..K+1: x; % feature release number var int: F; % objective function
% Constraints =========
constraint % dependency constraints forall ( i in index_set_1of2(C) )
( x[C[i,1]] = x[C[i,2]] ) /\
forall ( i in index_set_1of2(P)) ( x[P[i,1]] <= x[P[i,2]] );
constraint % resource constraints forall ( k in 1..K, j in 1..R)
( sum (i in 1..N)
( r[i,j] * bool2int( x[i] = k) ) <= Cap[k, j] );
constraint % objective function
F = sum (k in 1..K, i in 1..N ) ( WAS[i, k] * bool2int(x[i] = k ) );
solve maximize F;
In summary the theories of requirements release planning that affect our imple-mentation mostly derived from these theories. Release planning is the assignment of requirements to a specific release. Assignment of a requirement to a release is affected by constraints on the requirements. The assignment of a requirement to a release is affected by the prioritization made by the stakeholders. Each stakeholder’s prioritiza-tion’s importance is based on the stakeholder’s importance. Release planning can be translated to a set of constraints. All possible solutions of a release planning problem can be found.
4.2
Constraint programming
As stated in the previous subsections the authors argues that prioritization methods can be translated to constraints, that release planning can be translated to a set of constraints and that a preferred release plan is a release plan that maximizes the sum of the priori-tized values of the set of released requirements. The release planning constraints have already been given as an example in Specification 12.
As to be able to translate a requirements model with relations to constraints we have made the following assumptions: a requirement requiring another requirement,B re-quiresA, is equal to the statement thatAmust be completed before B can be com-pleted, which is equal to stating thatBmust be in a later or the same release asA. Inspired by the ranking prioritization example Specification 1 and the constraint for-mulation by Regnell et al. of a ranking prioritization in Specification 6 we can formu-late the ranking prioritization example Specification 1 as constraints. The example has the requirementsA,B,C,DandEwhereP is the list of prioritized values for each requirement ordered asP[A, B, C, D, E]stating that the priority value ofAis equal toP[1]andB is equal toP[2]. In this example if a requirementAhas a higher pri-oritized value than another requirementBthe relation is explained with the constraint
P[1]>P[2].
Specification 13Example of ranking constraints translation of Specification 1.
P[1]>P[2] P[2]>P[3] P[3]>P[4] P[4]>P[5]
5
Implementation
The Implementation chapter describes the implementation of the prototype and gives a description of the background to the choices made during the implementation together with a how and why the authors developed the features of the prototype.
As the prototype would use reqT, described in the Tools subsection, the prototype was required to be implemented in Scala. To be able to take full advantage of our ex-perience with front end development in Java [26] we implemented the graphical user interface in Scala using Java Swing [26].
The goals for the prototype are to be able to create and edit requirements models in reqT, express prioritizations with constraints, solve a release planning problem with constraint programming, solve the release planning problem expressed by Ruhe et al. inThe art and science of software release planning[15], provide the flexibility of con-straint programming, allow the users to explore the solutions and to be able to access everything through a graphical user interface.
A more general requirement that has affected the design of the graphical user inter-face is that each viewable piece in the front end should be accessible independently by the user from the command prompt, for instance to start a prioritization view of a model from the command prompt without allowing access to the other parts of the graphical user interface. Another requirement is that the prototype provides the means to edit an immutable reqT model in a mutable fashion through the graphical user interface. The requirements engineering processes missing in reqT at the time of the thesis are prioritization and release planning. These processes have been implemented as con-straints and are applied by the user in the graphical user interface.
5.1
Back end
The back end subsection describes the development of the software that is used by the graphical user interface to visualize results. Examples of what is considered a part of the back end software is reqT, a mutable model container and the constraint based prioritization and release planning processes.
5.1.1 Mutable reqT
In reqT everything is immutable. All modifications creates a copy of the original model with the given modifications instead of modifying the original model [30]. A require-ment is that the given reqT immutable objects should be able to be represented to the user in the graphical user interface and be mutable.
To make the model simulate a mutable behaviour all users need to have access to the most recently modified copy of the model. In the prototype this functionality is provided with the help of a mutable gatekeeper named ModelContainer. The modified copy of the model is kept in the ModelContainer and thereby providing access at all time to the most recent copy of the model.
5.1.2 Prioritization
The implementation of the prioritization processes followed the ideas presented in the Theory and the Background and Related work chapters.
The prioritization process requires that all prioritization methods should be able to generate the constraints needed to represent the given reqT model. If a user had taken the example given in Specification 1 and used it to create the reqT model example given in the Specification 14, then the prototype’s method OrdinalConstraints would with Specification 14 as input generate the constraints given in Specification 13. Specification 14Example of a reqT model of Specification 1.
Model(
Feature("A") has Prio(5), Feature("B") has Prio(4), Feature("C") has Prio(3), Feature("D") has Prio(2), Feature("E") has Prio(1) )
Figure 7: Abstract constraints to generate a prioritization constraints satisfaction prob-lem.
All prioritization methods’ constraints for each stakeholder are thereafter merged, similarily as shown in Specification 10, and together become a constraint satisfaction
problem for each stakeholder’s prioritization of the requirements. Inspired by the WAS function in Specification 12 a requirement’s prioritization value is thereafter given by the sum of each stakeholder’s prioritization value of the requirement multiplied by the importance of the stakeholder. The constraints that are generated during a prioritization are shown in Figure 7.
To exemplify a prioritization there can for instance be a model with two stakehold-ers, S1 with an importance of one and S2 with an importance of two. An example of generated constraints from the features given in Specification 14 of the prioritization of stakeholder S1 is in Specification 15. The example of constraints generated by stakeholder S2’s prioritization is in Specification 16.
Specification 15Example of constraints of stakeholder S1
P[1]>P[2] P[2]>P[3] P[3]>P[4] P[4]>P[5]
Specification 16Example of constraints of stakeholder S2
P[4]>P[3] P[3]>P[5] P[5]>P[2] P[2]>P[1]
A requirement’s priority value is described, in the Theory chapter, by the sum of the priority value of the requirement of each stakeholder multiplied with the importance of the stakeholder. An example of a prioritization with the stakeholders S1 and S2 is in Specification 17 and a solution to the example is in Specification 18.
Specification 17Example of constraints the prioritization given Specification 15 and Specification 16.
int: N = 5; % Numbers of features. int: S = 2; % Number of stakeholders.
array[1..N] of int: FP = ;% Priority values of a feature.
array[1..S] of int: stakeImportance = [|1, 2|] %Importance of each stakeholder array[1..N, 1..S] of int: SP;% Priority values of a feature per stakeholder. % Priority values of a feature per stakeholder method.
array[1..S, 1..N] of int: P = array2d(1..S, 1..N, [|5, 4, 3, 2, 1 | 1, 2, 4, 5, 3|]); % S1 constraints SP[1,1]>SP[2,1] SP[2,1]>SP[3,1] SP[3,1]>SP[4,1] SP[4,1]>SP[5,1] % S2 constraints SP[4,2]>SP[3,2] SP[3,2]>SP[5,2] SP[5,2]>SP[3,2] SP[2,2]>SP[1,1]
% Summarize the stakeholder’s prioritization multiplied % with the stakeholder’s importance.
forall (f in 1..N)( FP[f]= sum(stakeImportance * SP[f]) )
Specification 18Example of a reqT prioritization solution to Specification 17.
Feature("A") has Prio(7), Feature("B") has Prio(8), Feature("C") has Prio(11), Feature("D") has Prio(12), Feature("E") has Prio(7)
Multiple prioritization solutions are managed in the back end implementation by having the user specify an upper limit for the amount of solutionsK and in return recieves the set of the first found solutions ranging from0to K. A low level description of what information a prioritization contains is given in the model in the appendix in Figure 30.
5.1.3 Release planning
The release planning implementation in the prototype offers the user two alternatives on what basis to enact the release plan. The first is created with the constraints speci-fied in the example given in Specification 12, where the goal is to maximize the WAS function to solve the release planning problem expressed by Ruhe et al. inThe art and science of software release planning[15]. The second alternative is to maximize the prioritization value created with the processes explained on page 33 by minimizing the sum of the priority values of not released requirements. In both alternatives the sum of the cost of the requirements in a release is constrained to not exceed the capacity limit of the release.
Figure 8 shows how the requirement and release attributes are used to generate the constraints needed for a release plan for the second release plan alternative described above.
Figure 8: Abstract constraints to generate a release planning constraints satisfaction problem.
An example of a release plan solved with the second alternative can be found in Specificiation 22 in the appendix. Stakeholder Kalle has ranked the requirements with the ordinal prioritization method and generated the release plan that maximizes the priority value of the solution. The capacities of the releases are not enough to be able to release all requirements. Even if requirementA has a higher priority value than requirementI the cost ofAis higher. To allow adding requirementAto any release a higher priority sum of requirement priority values need to be removed, making any solution that releases requirementAnot optimal. Thereby the requirementsAandB
are not released. In Figure 9 a high level description of the release planning model is given. A more detailed description of all input required to generate a release plan is given in the model in the appendix in Figure 31 and a complete release planning solution is shown in Figure 32.
Figure 9: Abstract release plan model
5.2
Front end
The Front end subsection describes the development of the graphical user interface and the access it provides for reqT, prioritization, release planning and visualization. The front end of the prototype consists of a window named GUI that contains the basic functionality such as the menu, accessing models and the list of entities.
To implement the requirement, that each viewable piece in the graphical user in-terface should be accessible independently by the user from the command prompt, the GUI uses the view it recieves at initialization as the default view to use when opening new ModelContainers.
All content in reqT is represented in models containing attributes or relations con-nected to entities[30]. The prototype visualizes the importance of the models by rep-resenting the ModelContainer as the container of all visual representation. At the top of the prototype’s visualized hiearchy are model tabs that each visualize a separate ModelContainer. If a user selects one of these tabs the user gets access to the model it contains. The most important views in the prototype are described below.
5.2.1 View
There are two views aimed at giving the user the ability to explore models, Map (Fig-ure 10) and ReqT (Fig(Fig-ure 11). Map is a map inspired view where the user can get an overview of all the entities in a model. In the map the user can zoom, pan and view eventual submodels. The Map also provides access to the Edit view of an entity. The ReqT view on the other hand allows the user to explore the complete textual
represen-Figure 10: Overview of a model in Map view
Figure 11: Model in reqT code in the ReqT view
5.2.2 Add / Edit
The Add / Edit tab enables the user to add new and edit already existing entities. The Edit view displays all of the details of a selected entity and allows the user to add or remove attributes and relations (Figure 12). To select an entity to edit the user can use the list visible to the right in the prototype. The list provides functionality for searching by entity name and to filter by entity type.
Figure 13: The view where a stakeholder can prioritize according to the method de-scribed by Ruhe et al.[15]
5.2.3 Prioritization
Prioritization contains views where the stakeholders can prioritize according to dif-ferent prioritization methods. Figure 13 shows the supported prioritization methods: $100, ordinal and the method described by Ruhe et al. [15]. When the stakeholders have prioritized the user can solve the prioritization and explore the solutions in the Overview view, Figure 14.
Figure 14: A solution to a prioritization
5.2.4 Release plan
Connected to release planning there are two views. The Create view where the user can create a release plan, Figure 15, and the Release board view where the user can view the release plan solution, Figure 16. To create a release plan the user defines the resources, selects a number of releases to include in the release plan, specifies the capacities of the releases and the resource consumption of the entities. With the collected information a release plan can be generated and the user is presented with the found solution.
5.2.5 Requirements engineering visualization
As seen in Figure 10 the entities are visualized as cards on a board similarly as de-scribed in the Agile subsection to involve the users better with the entities. By selecting an entity it can be modified or further specified.
The prioritization visualization in the prototype gives a list of prioritization meth-ods views that can be used by the stakeholders to prioritize requirements. Each method view allows a stakeholder to prioritize the requirements according to the selected method. When the stakeholders have prioritized the requirements a prioritization solution can be generated. The resulting solutions are presented as a list to the left in the prototype. A solution is visualized inspired by the use of cards as explained in the Agile subsection, where each card is placed on a map depending on the requirements priority. If there are multiple solutions to a prioritization, all possible locations for a card are shown. When the user selects a solution the position for each card in that particular solution is highlighted. In summary the prioritization visualization allows a user to view all the alternative solutions to the prioritization problem and visualize the prioritization as an extreme programming board to involve the users with the prioritization, see Figure 17.
Figure 17: Multiple prioritization solutions visualized in the prototype. In Figure 16 a generated release plan is visualized as a board. Each release is a column and the requirements located in the release is a row.
5.3
Architecture
The code of the prototype is divided into five groups based on functionality. The refer-ences between the groups are shown in Figure 19.
gui The gui group has all functionality connected to the
