ReqTGUI A Prototype for Solving and Visualizing Decision Problems in Requirements Engineering with Constraint Programming

Size: px
Start display at page:

Download "ReqTGUI A Prototype for Solving and Visualizing Decision Problems in Requirements Engineering with Constraint Programming"

Transcription

1 ReqTGUI A Prototype for Solving and Visualizing Decision Problems in Requirements Engineering with Constraint Programming Authors Joel Johansson & Oskar Präntare June 20, 2013 MASTER S THESIS WORK CARRIED OUT AT THE DEPARTMENT OF COMPUTER SCIENCE, LUND UNIVERSITY. Examiner Krzysztof Kuchcinski Supervisor Björn Regnell

2 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 programming 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 prioritization 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 prioritization methods as constraints and improving usability. Keywords: Constraint programming, prioritization, release planning, reqt, ReleasePlanner and requirements engineering. 2

3 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 throughout the thesis: Our test subjects Richard Berntsson Svensson and Christian Söderberg, 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.

4 Contents 1 Introduction Problem formulation Motivation Scope Terminology Background and Related work Requirements engineering Requirements Specification Requirements Prioritization Release Planning Constraint Programming Agile Development ReqT Previous Work ReleasePlanner Methodology Overview Elicitation Literature study First survey questionnaire Second survey questionnaire Brainstorm Interview Specification Data model Virtual windows Implementation Release planning Validation Threats to validity Tools Theory Requirements engineering Prioritization Release planning Constraint programming Implementation Back end Mutable reqt Prioritization

5 5.1.3 Release planning Front end View Add / Edit Prioritization Release plan Requirements engineering visualization Architecture Extending ReqTGUI Results Validation ReqTGUI validation Release plan validation Release planning flexibility Examples Software scenario Use case of the software scenario Enviromental logistics scenario Discussion and conclusions Result limitations Future work References Written references Online references A ReqT models 66 B Release planning problem 71 C Requirements engineering models 74 D First Survey 77 E Second Survey 83 F EDA270 interviews 88 5

6 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 Requirements Engineering with Constraint Programming, was initially inspired by Björn Regnell s and Krzysztof Kuchcinski s article of Exploring Software Product Management 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 release planning problems, the advantages of modeling prioritization and release planning 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 written 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 solving requirements prioritization and release planning problems with constraint programming, where a solution can make use of multiple prioritization algorithms, and to visualize the problems and their solutions with the help of a prototype. The thesis resulted in the prototype called ReqTGUI, 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]. Previous 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 planning problems be implemented and visualized? 6

7 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 requirements engineering tool reqt states that they preferred a solution that is able to visualize requirements engineering. To provide deeper access to constraint programming 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 applicable 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 implementation 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 ability of scalability in the design nor research the usability of the prototype. No formal attempts of usability evaluation or improvements are performed in the thesis. The research 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 end provides 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 Related work chapter. The process to find requirements. 7

8 Front end A visualization providing an interface for users to interact with the back 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 possible utility function value. Release A bundle of requirements planned to be done at a specific time. ReqTGUI The name of the prototype. UML Unified modeling language. Utility function The objective function representing the sum of WAS values in a release plan. WAS Weighted average satisfaction of stakeholder priorities. 8

9 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] 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] 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 importance, 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 methodology [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 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 software release planning problems the same ideas still apply. Software release planning 9

10 Specification 1 Example 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-tomarket 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 considered constraint satisfaction problems. Constraint programming solves constraint satisfaction 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 constraint 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 is done when the feature is fully integrated, requirements are reconsidered at each iteration, all planning is a collaboration between the team and the customer and the design should be open and flexible [19]. 10

11 In the agile methodology called Extreme Programming change requests to a system 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 1: A story located on a board at LTH in

12 Figure 2: Example of ordering of stories at LTH in 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 advantages 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 interactions 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 are immutable. 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 an entity. Entities are divided into two groups, context and requirement. 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]. An important note is that, since reqt is programmed in the Scala programming 12

13 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]. ReleasePlanner solves prioritization and release planning problems [17] while Agilefant focuses on the visualization of the requirement management [19]. Parallel 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 Planning stated 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 constraint programming and existing release planning algorithms, and empirically tested constraint programming in a release planning context. The conclusion was that existing release planning algorithms are more efficient than constraint programming, 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 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 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 stakeholder s priority satisfaction while keeping the solution within boundaries by resource consumptions and capacities [24]. 13

14 The EVOLVE release planning model is an evolutionary genetic and iterative algorithm 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. 14

15 3 Methodology The Methodology chapter describes the workflow used in the thesis, that has followed a requirements engineering inspired methodology. Each requirements engineering process 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, implementation and validation. 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, questionnaries 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 accomplished 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 specification process was mostly details of the thesis processes and later the specification 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 authors 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. 15

16 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 illustrated 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 be done. The implementation 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 requirements 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 16

17 Figure 4: Original project plan document for the prototype resulted in 270 elicited requirements, 185 specified requirements, 130 prioritized, 82 dropped requirements, 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 2 Done 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 3 Dropped 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 required 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 17

18 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 authors 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 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 First survey questionnaire The first survey was sent to the students who have used reqt in the requirements engineering course at LTH during 2012 and was written in collaboration with our supervisor 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 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 prioritization, 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 guidelines of requirement engineering and visualization. The questions and their intent can 18

19 be found in the appendix E. The second survey elicited and specified visualization requirements Brainstorm Brainstorming is an activity of elicitation but is also used for prioritization [10]. Brainstorming was used in the thesis as the activity of discovering all possible ideas, regardless of quality, while also receiving an early prioritization. The first brainstorming was with Björn Regnell and occured at the 8th of February 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 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 prioritization helped to understand the priority of each requirement, how the requirements should be scheduled and a better understanding of the goal of the thesis Interview An interview with the coaching students at LTH mentioned in the second survey questionnaire subsection were conducted. The intent of the interview was to examine present problems and processes. The interview should not be used for high level requirements except during stakeholder analysis. The questions should be broad questions about every day issues and questions 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 answers 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 improvement of requirements. The specification process is in our methodology the improvement of the thesis and the prototype 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 19

20 important words derived from the data model specification process: Requirement, context, 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 Virtual windows Virtual windows is a visual representation of requirements representing all information that a system requires but without any functionality. 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, verification and validation. 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. 20

21 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 as P LANNED, P LANNED, IMP LEMENT ED, T EST ED in respective 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 regarding changes and new requirements Release planning The order of the implementation of the deliverables was decided by ordering the requirements by prioritization. A deliverable with the same prioritization value as another 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 requirement had to be in a specific deliverable or that one requirement required another requirement. Sometimes the order was changed as the authors believed that a different order could be positive for the thesis. 21

22 Description Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Cost Effort Cost/Effort Table 1: Iteration cost and effort in total days spent for each iteration. The implementation of the prototype started with a preparatory iteration zero 1 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 done it had automated 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 IMP LEMENT ED rather than T EST ED. The requirements completed in the first iteration are described in Specification 4. In table 1 the cost of all requirements released 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 complete more cost per effort after a few iterations had passed, one cost corresponds to almost one third of a workday. 1 See Hedin et al. [9] for further details of what an iteration zero is. 22

23 Specification 4 The 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"), ) ) 23

24 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 prioritization problems. That the prototype can perform the release planning problem by Ruhe et al. in The art and science of software release planning [15]. The prototype allows a combination of multiple prioritization methods in the release planning. The prototype visualizes multiple prioritization solutions. The prototype has the functionality described by Ruhe et al. in A hybrid release planning method and its empirical justification [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 5 Example 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. 24

25 The release planning during the implementation was directly connected to the prioritization and the cost estimates discovered during the specification and elicitation processes. 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 functionality 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 engineering 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 programming examples written in the thesis are written in MiniZinc 2 [28]. 2 MiniZinc is a constraint modeling language, further information can be found at: [28] 25

26 4 Theory The Theory chapter begins with explaining the existing theory of requirements engineering 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 relations and attributes [29]. These relations and attributes have been argued to be possible to describe with the help of constraints [4] [14] 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 output 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 requirements 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 maximizing 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 entities n, {r i 1 i n} to a set of numerical values {p i 1 i n}. There p is the requirement s numerical value given by a stakeholder based on 26

27 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 6 A 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 7 A 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 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 preferred solution is a solution that maximizes the sum of the prioritized values included. 27

28 Specification 8 Simple priority constraints. constraint P[1] > P[2]; constraint P[2] > P[3]; constraint P[3] < P[4]; Specification 9 Another 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 methods. 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 prioritizations made by a stakeholder, allow generating each requirement s prioritized order or value. Specification 10 Simple 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]; 28

29 4.1.2 Release planning Release planning is how to assign requirements to a sequence of releases given a number 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 accomplishing the optimization [15]. The Art of release planning is the release planning based on human intuition, communication and negotiation to reach the optimal solution. The Science of release planning defines the problem and through algorithms reaches the optimal solution. Both approaches attempt to describe the problem that given a number of requirements entities n, {r i 1 i n} and release entities K, {re i 1 i K} the goal is to assign each re i to a release K. 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 is S, {s i 1 i S} each stakeholder in S has an importance Im. 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 11 The example by Ruhe et al. [15] with only initial values for the input array variables r, value and urgency given 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. Solving release planning problems with constraint programming 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. 29

30 Specification 12 The 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; output[ "x = "++show(x)++"\n"++"f = "++show(f)]; 30

31 In summary the theories of requirements release planning that affect our implementation 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 prioritization 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 prioritized 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 requires A, is equal to the statement that A must be completed before B can be completed, which is equal to stating that B must be in a later or the same release as A. Inspired by the ranking prioritization example Specification 1 and the constraint formulation by Regnell et al. of a ranking prioritization in Specification 6 we can formulate the ranking prioritization example Specification 1 as constraints. The example has the requirements A, B, C, D and E where P is the list of prioritized values for each requirement ordered as P [A, B, C, D, E] stating that the priority value of A is equal to P [1] and B is equal to P [2]. In this example if a requirement A has a higher prioritized value than another requirement B the relation is explained with the constraint P [1]>P [2]. Specification 13 Example of ranking constraints translation of Specification 1. P[1]>P[2] P[2]>P[3] P[3]>P[4] P[4]>P[5] 31

32 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 experience 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. in The art and science of software release planning [15], provide the flexibility of constraint 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 interface 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 constraints 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 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 requirement 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. 32

33 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 14 Example 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 problem. All prioritization methods constraints for each stakeholder are thereafter merged, similarily as shown in Specification 10, and together become a constraint satisfaction 33

34 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 stakeholders, 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 15 Example of constraints of stakeholder S1 P[1]>P[2] P[2]>P[3] P[3]>P[4] P[4]>P[5] Specification 16 Example 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

35 Specification 17 Example 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 18 Example 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) 35

36 Multiple prioritization solutions are managed in the back end implementation by having the user specify an upper limit for the amount of solutions K and in return recieves the set of the first found solutions ranging from 0 to K. A low level description of what information a prioritization contains is given in the model in the appendix in Figure 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 specified 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. in The 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. 36

37 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 requirement A has a higher priority value than requirement I the cost of A is higher. To allow adding requirement A to any release a higher priority sum of requirement priority values need to be removed, making any solution that releases requirement A not optimal. Thereby the requirements A and B 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

38 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 interface 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 connected to entities[30]. The prototype visualizes the importance of the models by representing 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 View There are two views aimed at giving the user the ability to explore models, Map (Figure 10) and ReqT (Figure 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- 38

39 Figure 10: Overview of a model in Map view tation of the model in reqt code. 39

40 Figure 11: Model in reqt code in the ReqT view 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. 40

41 Figure 12: Edit view showing an entity called Feature(1) 41

42 Figure 13: The view where a stakeholder can prioritize according to the method described by Ruhe et al.[15] Prioritization Prioritization contains views where the stakeholders can prioritize according to different 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

43 Figure 14: A solution to a prioritization 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. 43

44 Figure 15: The view where a stakeholder creates a release plan 44

45 Figure 16: A solution to a release plan 45

46 5.2.5 Requirements engineering visualization As seen in Figure 10 the entities are visualized as cards on a board similarly as described 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 methods 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 references between the groups are shown in Figure

47 gui The gui group has all functionality connected to the initialization of the prototype. constraints The constraints group is all constraint generation and automatic interaction with the reqt constraints. views All views. node Anything that visualizes requirements as cards. utility The ModelContainer and general utilities that are helpful in the prototype. The prototype is built with Scala standard libraries together with Java Swing, reqt and JaCoP. An illustration of how the layers of the prototype are ordered and depend on each other is visualized in Figure 18. In a simplified description the prototype is initalized either with the GUI for a specific desired view or the ReqTGUI to gain access to the complete ReqTGUI functionality. A view is a visual representation that contains a ModelContainer. Views are used for all user interactions and visualizations within the prototype. A view can either contain information, a PanelView, or other views, a TabbedView. Figure 20 shows an UML of how the most important views are connected. The prioritization constraints generation is connected to the prioritization view and used in the release planning constraints generation. The release planning constraints generation is connected to the release planning view. ReqTGUI, excluding the automated tests and the reqt model, contains 134 classes and about 6000 lines of code. The automated tests are written with about 900 lines of code. ReqTGUI has full functionality to complete a release planning. We think that the areas that requires further work are within prioritization, accessing entities that are located deep within the hierarchical reqt model, optimizing the constraints, easing manually adding of constraints and improving usability. We believe these improvements can be made with the current architecture and that further work should extend ReqTGUI rather than attempting to create a new graphical interface with the same functionality. Figure 18: The ReqTGUI layers 47

48 Figure 19: The relations between the groups Figure 20: UML of the most important views of the prototype Extending ReqTGUI When extending ReqTGUI we believe that it is preferrable if the developer has experience with Scala collections, reqt and Java Swing. To create a new view a developer should extend the view functionality and add all visualization in the updateview method, see Specification 19. All interaction with the model should occur through the ModelContainer. To add a prioritization method the 48

49 developer needs to first implement a prioritization view that gives a user access to add a prioritization to a stakeholder. After a view is created a developer needs to create a ConstraintCreator that has the name of the prioritization method returned with the tostring and all constraint generation in the createconstraints method, see Specification 20. To include the new method in ReqTGUI the method needs to be added to the map in CreateConstraints, which contains all available prioritization methods. Specification 19 Source code of view /** A View can be viewed by GUI **/ trait View extends Component { var container: ModelContainer = _ addcomponentlistener(new ComponentAdapter() { /** Update if the View is resized **/ override def componentresized(e: ComponentEvent) { if (isvisible()) { updateview() } } /** Update if the View becomes visible **/ override def componentshown(e: ComponentEvent) { try{ updateview() }catch{ case e : Exception => warn(e.getmessage()) } } }) /** updateview updates the graphical view of the View **/ def updateview() } /** Launch a specific view v is the View which is to be launched. **/ def launch(v: View) { container.launch(v) } 49

50 Specification 20 Source code of ConstraintCreator /** ConstraintCreator creates Constraints **/ class ConstraintCreator(){ /** createconstraints adds the prioritization * constraints to the modelcontainer. container is the ModelContainer that is to be edited. stakeholder is the Entity which prioritizes. model is the stakeholder s current prioritization. */ def createconstraints(container : ModelContainer, stakeholder : Entity, model : Model) {} /** tostring returns the name of the ConstraintCreator method. String of the method s name. */ override def tostring() : String = {return "Error unnamed value"} } 6 Results The Results chapter describes the results and conclusions reached in the thesis. The validation subsection describes the results of the final validation processes with successes and failures. The Examples subsection describes examples of scenarios when the prototype may be used. Discussion and Conclusions summarizes and discusses the results and the thesis potential value. 6.1 Validation The validation subsection describes the results of the validation process described in the Methodology chapter. First a validation of the prototype and its functionality. Secondly a release plan validation, to make sure that ReqTGUI is capable of solving the problem described by Ruhe et al. in The art and science of software release planning [15]. The validation subsection attempts to validate that the thesis has solved the problems described in the Problem formulation subsection ReqTGUI validation Ruhe et al. in A hybrid release planning method and its empirical justification [3] stated a usability test that would test the effiency of a release planning process. The test was described by having a group of people perform eight tasks. While the subjects complete the given tasks both the time the tasks needed to be completed and two counters would be used to measure the effiency of the release planning tool. Tasks The list of tasks which were to be completed. 1 Adding a feature to feature repository 2 Editing a feature already available 50

51 3 Defining a dependency between features 4 Defining available resources 5 Editing available resources 6 Inputting stakeholder votes 7 Editing stakeholder importance 8 Generating a solution Counters The description of the counting during all tasks 9 Number of errors or failed commands 10 Frequency of help or documentation use The prototype was validated by having each of the tasks performed by two test subjects. Neither of the subjects had seen the application earlier nor did they get any introduction to the application prior to the interaction. Since the thesis won t consider performance or usability, as explained in the Scope subsection, the time needed to complete the tasks was not tracked. The following results were received: Experimental subject 1 Number of errors or failed commands: 4 Frequency of help or documentation use: 4 Experimental subject 2 Number of errors or failed commands: 1 Frequency of help or documentation use: 2 As the subjects have been able to perform the tasks described in the list above the existance of the desired functionality is validated. The errors and help the subjects required were mostly explained by the subjects themselves by the lack of feedback or text in the application Release plan validation To validate the release planning capabilities of ReqTGUI the release planning problem expressed by Ruhe et al. in The art and science of software release planning [15] was translated to a reqt model and solved with the prototype. The generated optimal solution was compared with the described problem to confirm that the generated solution included the precedence and resource allocation constraints defined by the problem. The value of the solution, described in table 2, was compared to the qualified solutions given by Ruhe et al. in the article [15] by calculating the sum of the weighted average satisfaction of the stakeholder priorities of all features. The solution from ReqTGUI resulted in a higher satisfaction value than the two examples in the article. Note that the qualified solutions by Ruhe et al. [15] were never claimed to be optimal. 51

52 Feature Release WAS , , , , , , Objective function value F(x) 2022,2 Table 2: The prototype s solution to the release planning problem[15]. Regnell et al. [14] remarked on inconsistencies in the solutions proposed by Ruhe et al. [15] concerning resource usage where the capacity limit constraint of the problem s resource 3 was violated[14]. To investigate the violation ReleasePlanner was used to solve the problem described by Ruhe et al. [15], the optimal solution with ReleasePlanner is presented in Appendix B. The use of urgency in ReleasePlanner has changed since the article was written so we were unable to exactly replicate the model. ReleasePlanner s optimal solution violated the same capacity limits of resource 3 as described by Regnell et al. [22]. This violation explains why the optimal solution by the ReleasePlanner has a higher value than that found to be optimal by ReqTGUI, something that is further discussed in the Release planning flexibility subsection. In A hybrid release planning method and its empirical justification [12] Ruhe et al. gave examples of constraints currently not supported in the ReleasePlanner tool. The given constraints were customized by us to match the problem tested in table 2 and to have the constraints force a different optimal solution. The following is the authors revised version of the constraints that were described by Ruhe et al. [12]: A. At most one of features 1, 2 and 3 may be released B. At least two of features 9, 10 and 11 must be released C. Exactly two of features 12, 13 and 14 must be released D. If all of features 3, 5 and 6 are released, the utility function value is increased by 600 points Constraints A D were formulated in the prototype with the use of a constraint that counts the number of selected features that are not planned in a release. For instance 52

53 Feature Release WAS , , , , , , Constraint D value 600 Objective function value F(x) 1855,4 Table 3: Solution to release plan problem[15] with constraints A D constraint A can be translated to constrain the number of features to not be released should be greater than, or equal to, two. In addition to counting an IfThenElse constraint was used in the translation of D stating that if all features were released the utility function value would be increased with the specified amount, otherwise the utility function would not be increased at all. The results are shown in table 3. The table 3 validates that the constraints A C are all fulfilled and that the optimal solution takes advantage of the added value following constraint D. To further read up on the constraints Count or IfThenElse, see JaCoP s homepage [25] Release planning flexibility One of the goals with the prototype was to present the results from release planning to the user so that the user can compare how changes to the preconditions affect the optimal solution. In the prototype each new optimal release plan solution is presented in a new tab, letting the user compare the results as well as exploring the underlying model from where the solution was generated. This can be demonstrated using the problem described in the previous section where the optimal solutions generated from the prototype and ReleasePlanner diverged. Figure 21 shows how the solution described in Table 2 is presented in the prototype. The capacity of resource 3 in release 2 is changed from 65 to 75, since 75 is the amount of resources used in the optimal solution from ReleasePlanner presented in the Appendix B Table 5. The new solution in ReqTGUI is shown in Figure 22. Feature(15) has now been planned to be released in release 2, instead of being postponed, because of the extended resource capacity. The new solution is equal to the optimal solution 53

54 generated by the ReleasePlanner in Appendix B Table 5, resulting in the total WAS value of the release plan increasing from 2022,2 to 2076,2. The flexibility holds for other kinds of precondition changes as well. For example if stakeholder 2, from the Appendix B, changes its priority value of feature 5 from 2 to 9 in the original problem the results by the prototype will be as in Figure 23. The difference to the original problem solution in Figure 21 is that feature 4 and feature 5 have swapped releases with each other. Viewing the different release plans the user can explore how changes affect the generated solutions. Figure 21: Release plan solved with the prototype for the problem described in Appendix B. 54

55 Figure 22: Release plan solved with the prototype for the problem described in Appendix B with the capacity of resource 3 in release 2 increased to 75. Figure 23: Release plan solved with the prototype for the problem described in Appendix B with the value of feature 5 of stakeholder 2 increased to 9. 55

56 6.2 Examples In the Examples subsection a couple of examples of the prototype solving is represented. The Examples subsection is to both validate that the constraints programming solution to release planning gives flexibility and allows users to solve a wider range of problems. Furthermore the authors hope that the Examples subsection gives the reader a better understanding of the potential of the thesis and to inspire the readers to use the prototype Software scenario A represention and solution of a simple software scenario with the help of the prototype. The given software scenario is a web shop that is a combination of a front end web page with a back end that together provides customers the functionality to buy wares. The web shop is a simple scenario with only one stakeholder, represented by the product owner. The product owner directly gives the priority of the features. The problem to be solved is that the company has a varying amount of different kinds of developers available for each release, making the company feel that it is hard to decide the optimal order of releasing each feature. Testing, front end design and back end programming is demanded in different amounts by the different features. The high level features elicited for this example are Item database, Web shop, Service system and Billing system. The reqt model representing the software scenario problem is given in Specification 24 in Appendix A. In Figure 24 the prototype has in the generated release plan divided the Item database to the Summer release, both the Billing system and the Service system to the Winter release and the Web shop to the Final release. All features are managed to be released before the deadline of the final release. Of the required resources the Summer release is using 10/10 testing, 25/30 back end development and 0/10 front end development. The Winter release is using 30/30 testing resources, 32/50 back end development and 10/10 front end development. The Final release uses 30/50 testing, 2/5 back end development and 90/100 front end development. None of the capacity limit constraints are broken. Figure 24: Image of the prototype s generated release plan of a web shop 56

57 6.2.2 Use case of the software scenario The Use case of the software scenario describes the tasks required of a user to solve the web shop scenario described in the Software scenario subsection with ReqTGUI. Create all features, resources, releases and stakeholders mentioned in the scenario in the Add / Edit tab. Each of the entities are created with the same functionality, see Figure 25. Add a relation that Billing system requires Database in the Add / Edit tab by selecting Billing system and adding the requires relation, see Figure 26 In the Prioritization tab the user selects the Ordinal method and the stakeholder Product owner. Prioritize according to Specification 24, see Figure 27. Add the releases to the release plan in the Release plan View, see Figure 28. Edit the capacity in the Releases section of each release in the Release plan View, see Figure 28. Edit the cost of each requirement in the Requirements section in the Release plan View, see Figure 28. Edit the importance of the stakeholder Product owner in the Stakeholder section of the Release plan View, see Figure 28. Click on the Generate release plan button at the bottom of the Release plan View, see Figure 28. View the generated release plan solution of the software scenario presented in the Release board tab, see Figure

58 Figure 25: Create entities in Add / Edit Figure 26: Add relations between features in Add / Edit 58

59 Figure 27: Input a stakeholder s prioritization Figure 28: View of editing a release plan 59

60 6.2.3 Enviromental logistics scenario In the environmental logistics example a company is to transport goods from New York City to Miami and also have transportation between Rochester and Jacksonville. Each of these routes allows multiple possible scenarios, each with a specific priority, time cost, dollar cost and carbon dioxide cost. The goal is to choose the transportation that has the least carbon dioxide cost while still maintaining a given budget. The following scenarios are taken from the article by James Winebrakea et al. [20]. New York to Miami Scenario #1 Dollar cost 925 Time in hours 61 Carbon dioxide emissions in kg 390 Scenario #2 Dollar cost 668 Time in hours 49 Carbon dioxide emissions in kg 1295 Scenario #3 Dollar cost 1226 Time in hours 25 Carbon dioxide emissions in kg 1388 Rochester to Jacksonville Scenario #1 Dollar cost 866 Time in hours 54 Carbon dioxide emissions in kg 328 Scenario #2 Dollar cost 1007 Time in hours 17 Carbon dioxide emissions in kg 1158 The goal is to minimize the carbon dioxide while meeting the budget and time schedule. The constraints that are used to describe that only one scenario for each route can be selected can be to state that only one scenario of each route may have a release order that is released. An example of such constraints given by reqt if there is only one release is given in Specification 21. A visualization of the environmental logistics problem in a requirements engineering perspective is to view each scenario as an elicited feature and that the consequences to choose a specific scenario are costs. Each feature in the same group of scenarios 60

61 Specification 21 Example of the constraints stating that only one scenario for each route can be selected using reqt. Count(List((Feature("New York to Miami scenario 1")!Order), ( Feature("New York to Miami scenario 2")!Order), ( Feature("New York to Miami scenario 2")!Order)), Var("Count New York to Miami scenarios"), 0), Var("Count New York to Miami scenarios")#==1, Count(List((Feature(" Rochester to Jacksonville scenario 1")!Order), ( Feature(" Rochester to Jacksonville scenario 2")!Order)), Var("Count Rochester to Jacksonvillei scenarios"), 0), Var("Count Rochester to Jacksonvillei scenarios")#==1 excludes the implementation of the other features in the same group. The priority of a feature to be included is the carbon dioxide emissions the feature creates. As there is no requirement on the transportation order the release plan can be represented by one release, called Selected scenarios. An example of a budget of Selected scenarios is that the total time of the goods transportation can be a maximum of 90 hours and a dollar cost of Note that the budget is randomly selected to show the complexity of, if given a logistics problem, minimizing the amount of carbon dioxide emissions released. As the priority is specified as a number, the negative amount of the carbon dioxide emissions in kg, a priority value prioritization method is performed. The reqt model representing the Enviromental logistics problem is given in Specification 25. To minimize the carbon dioxide all carbon dioxides are given a priority with negative numbers. To allow negative numbers the reqt s jacop setting defaultinterval is set to between and The prototype produced the solution seen in Figure 29 selecting scenario #1 for the transportation from New York to Florida and scenario #2 of the transportation from Rochester to Jacksonville. The total cost is 1932 of a maximum of 2000 dollars, the total time is 78 of 90 hours and the total carbon dioxide emissions are 1548 kg. Thereby the carbon dioxide emissions have been minimized as much as possible while maintaining the given budget. Figure 29: Image of the prototype s generated release plan of a environmental logistics problem 61

62 6.3 Discussion and conclusions The thesis has validated that it is possible to solve prioritization and release planning problems with the help of constraint programming. The prototype, that visualizes the solutions, is able to perform the functionality described by Ruhe et al. [3] and the prototype is able to perform the functionality that Ruhe et al. states that ReleasePlanner lacks, see page 51. The prototype is able to merge the results from different prioritization methods and find a prioritization solution from the methods. The thesis has given examples of how to use ReqTGUI in software engineering projects and has validated that these and other problems can be solved. We can therefore state that the prototype is functional and able to solve prioritization and release planning problems. To connect the conclusions to the Problem Formulation subsection the prototype is able to use multiple prioritization methods as explained in the Theory chapter, the flexibility of constraint programming can be applied to the release planning problems as seen in the Release plan validation subsection and given multiple solutions to a prioritization the solutions are visualized. The prototype can now be described as an answer to the problem formulation of the thesis: How can a constraint programming-based approach to describe and solve software requirements prioritization and release planning problems be implemented and visualized? The prototype provides new methods regarding how constraints can be combined and generated from prioritization methods, how prioritizations and release plans can be represented in requirements models and how the interaction with the model can be enacted by a user through a graphical user interface. Contribution examples that are provided by the thesis: Prototype for visualizing requirements, prioritization and release planning. The prototype provides to the users a flexibility with constraints, visual exploration of possible solutions and is an empirical proof of allowing the creation of release plans with constraints. Concept of a requirements engineering model of prioritization, see Figure 30 and release planning, see Figure 32. The concept provides a hierarchal model of release planning and can be used as a basis for future release planning solvers or research. It should be noted that the prototype is one possible answer to the problem formulation and that a multitude of other possible, and probably more optimal, solutions exists. Suggestions for improving the solution are described in the Future work subsection. 6.4 Result limitations There are limitations to the results of the thesis. The visualization represented in the Front end subsection has not been through any thorough usability tests and may therefore require improvement. The authors considers the current including of manual constraints like those described in Release plan validation to be quite difficult and requires improvement. The prototype is adapted for smaller release planning problems and have 62

63 performance issues when the release planning problem becomes larger. The prototype only provides the possibility to compare different release planning solutions manually and it is currently not possible to view alternative solutions that have equal optimality. We have discovered that at the time of the thesis reqt is not able to load models larger than a few thousands requirements, which also limits the prototype to the same degree. The thesis prioritization model is only applicable if stakeholders are consistent with their prioritization and their use of priority value versus priority order during prioritization. The release planning functionality in ReqTGUI only optimizes given a single benefit, the priority value, which makes the release planning too simplified for some use cases. 6.5 Future work As described in the Scope subsection the prototype is not attempting to optimize performance and thereby it is a possibility that ReqTGUI does not adapt well for scalability. A suggested future improvement is to try to improve performance and to allow solutions for larger models. Given the possibility of flexibility and searching for alternative solutions that is given by constraint programming a future work could be to allow comparisons between release plans and to visualize what consequences a specific change in a constraint will cause. In regard to the release planning the release plan finds an optimal solution given a specific benefit to optimize. To further improve release planning and extend the functionality for more research fields the authors believe that using multiple benefits and specifying costs or capacity as dynamic variables would be interesting. As the thesis proposed a new take on prioritization by allowing merging of prioritization methods, a possible future work is to implement the more commonly used prioritization methods within requirements engineering with the help of constraints. In the usability field there is a problem that arises both during prioritization and in release planning. As far as the authors of the thesis have discovered, there is a lack of research concerning how to best visualize many solutions of ordered entities in parallell without confusing the user. In the prototype a solution was made to visualize a solution and its alternatives on a map, though the authors believe that there is an extensive amount of work to extend and research usability in the area. 63

64 7 References The References chapter divides the references in written and online sources. 7.1 Written references References [1] Krzysztof R. Apt, 2003, Principles of Constraint Programming, Press syndicate of the university of Cambridge, Cambridge, p, 6. [2] Ulf Asklund, Lars Bendix, Torbjörn Ekman, 2004, Software configuration management practices for extreme programming teams, Turku. [3] Ahilton Barreto, Márcio de O. Barros, Cláudia M.L. Werner, 2008, Staffing a software project: A constraint satisfaction and optimization-based approach Computers & Operations Research, Volume 35, Issue 10, [4] David Benavides, Sergio Segura, Antonio Ruiz-Cortés, 2010, Automated analysis of feature models 20 years later: A literature review, Seville, pp [5] Lars Bendix, Torbjörn Ekman, 2007, Software configuration management in agile development, p 136, Lund. [6] Patrik Berander, Anneliese Amschler Andrews, 2005, Engineering and Managing Software Requirements, Springer Verlag, Berlin, pp [7] Felipe Colares, Jerffeson Souza, Rafael Carmo, Clarindo Pádua, Geraldo R. Mateus, 2009, A New Approach to the Software Release Planning, Belo Horizonte, p [8] Des Greer, Guenther Ruhe, 2005, Software release planning: an evolutionary and iterative approach, Calgary. [9] Görel Hedin, Lars Bendix, Boris Magnusson, 2003, Teaching extreme programming to large groups of students, Lund. [10] Soren Lauesen, 2002, Software Requirements - Styles and Techniques, Pearson Education Limited, Edinburgh Gate, p. 12, 24, 41. pp [11] Krzysztof Kuchcinski, 2012, Lecture 1, EDAN01, Lund. [12] Mark Przepiora, Reza Karimpour, Guenther Ruhe, 2012, A hybrid release planning method and its empirical justification, ESEM 12, New York, pp [13] Björn Regnell, 2013, reqt.org Towards a Semi-Formal, Open and Scalable Requirements Modeling Tool, Lund, p. 118 [14] Björn Regnell, Krzysztof Kuchcinski, 2011, Exploring Software Product Management Decision Problems with Constraint Solving - Opportunities for Prioritization and Release Planning, Lund. 64

65 [15] Guenther Ruhe and Moshood Omolade Saliu, 2005, The art and science of software release planning, Software, IEEE, vol. 22, no. 6, pp [16] James Shore, The art of agile development, O Reilly Media, [17] Mikael Svahnberg, Tony Gorschek, Robert Feldt, Richard Torkar, Saad Bin Saleem, Muhammad Usman Shafique, 2010, A systematic review on strategic release planning models, Information and software technology, volume 52, issue 3, Ronneby. [18] Jenifer Tidwell, 2005, Designing interfaces, First edition, O Reilly Media Inc., Sebastopol, p. 103, 118, 119, 176. [19] Jarno Vähäniitty, 2012, Towards Agile Product and Portfolio Management, Aalto University, Helsinki, p. 7, 11, 12, 21, 22, 32, 35. [20] James Winebrakea, James Corbett, Aaron Falzaranoa, J. Scott Hawkerc, Karl Korfmacherd, Sai Kethae and Steve Zilora, 2008, Assessing Energy, Environmental, and Economic Tradeoffs in Intermodal Freight Transportation, pp [21] Krzysztof Wnuk, 2011, Visualizing, Analyzing and Managing the Scope of Software Releases in Large-Scale Requirements Engineering, E-huset, Lund, p Online references References [22] Björn Regnell, ETS170 Requirements engineering lecture four, May 2013, [23] EDA270, May 2013, [24] Expert decisions, May 2013, https://www.expertdecisions.com [25] JaCoP, May 2013, [26] Java, May 2013, [27] Martin Fowler, Jim Highsmith, 2001, The Agile Manifesto, feburary [28] MiniZinc, May 2013, [29] ReqT, February 2013, [30] ReqT on github, March 2013, https://github.com/reqt/reqt [31] Scala, March 2013, 65

66 A ReqT models In the reqt model examples appendix a list of reqt models which have been used in the thesis are presented. 66

67 Specification 22 Example of a simple release plan reqt model with prioritization from Specificiation 23. Model( Feature("A") has (Prio(5), Order(2), Submodel()), Feature("B") has (Prio(2), Order(2), Submodel()), Feature("C") has (Prio(3), Order(0), Submodel()), Release("Re1") has ( Order(0), Submodel( Feature("C") has (), Feature("J") has (), Feature("D") has (), Feature("K") has () ) ), Resource("Points") has Submodel( Release("Re1") has (Capacity(11), Submodel()), Feature("C") has (Cost(2), Submodel()), Feature("B") has (Cost(3), Submodel()), Feature("A") has (Cost(6), Submodel()), Feature("D") has (Cost(1), Submodel()), Feature("E") has (Cost(1), Submodel()), Feature("F") has (Cost(1), Submodel()), Feature("G") has (Cost(1), Submodel()), Feature("H") has (Cost(1), Submodel()), Feature("I") has (Cost(2), Submodel()), Feature("J") has (Cost(3), Submodel()), Feature("K") has (Cost(5), Submodel()), Release("Re2") has (Capacity(6), Submodel()) ), Feature("D") has (Prio(10), Order(0), Submodel()), Feature("E") has (Prio(4), Order(1), Submodel()), Feature("F") has (Prio(8), Order(1), Submodel()), Feature("G") has (Prio(7), Order(1), Submodel()), Feature("H") has (Prio(6), Order(1), Submodel()), Feature("I") has (Prio(1), Order(1), Submodel()), Feature("J") has (Prio(9), Order(0), Submodel()), Feature("K") has (Prio(11), Order(0), Submodel()), Release("Re2") has ( Order(1), Submodel( Feature("I") has (), Feature("E") has (), Feature("H") has (), Feature("G") has (), Feature("F") has () ) ), Subdomain("Prioritizations") has Submodel(), Subdomain("Release plan") has Submodel() ) 67

68 Specification 23 Example of a simple prioritization reqt model. Model( Feature("A") has (Prio(5), Order(2)), Feature("B") has (Prio(2), Order(2)), Feature("C") has (Prio(3), Order(0)), Feature("D") has (Prio(10), Order(0)), Feature("E") has (Prio(4), Order(1)), Feature("F") has (Prio(8), Order(1)), Feature("G") has (Prio(7), Order(1)), Feature("H") has (Prio(6), Order(1)), Feature("I") has (Prio(1), Order(1)), Feature("J") has (Prio(9), Order(0)), Feature("K") has (Prio(11), Order(0)), Stakeholder("Kalle") has ( Prio(1), Submodel( Subdomain("Prio") has Submodel( Subdomain("Ordinal") has Submodel( Feature("I") has (Prio(1)), Feature("B") has (Prio(2)), Feature("C") has (Prio(3)), Feature("E") has (Prio(4)), Feature("A") has (Prio(5)), Feature("H") has (Prio(6)), Feature("G") has (Prio(7)), Feature("F") has (Prio(8)), Feature("J") has (Prio(9)), Feature("D") has (Prio(10)), Feature("K") has (Prio(11)) ) ), Feature("I") has (Prio(1)), Feature("B") has (Prio(2)), Feature("C") has (Prio(3)), Feature("E") has (Prio(4)), Feature("A") has (Prio(5)), Feature("H") has (Prio(6)), Feature("G") has (Prio(7)), Feature("F") has (Prio(8)), Feature("J") has (Prio(9)), Feature("D") has (Prio(10)), Feature("K") has (Prio(11)) ) ) ) 68

69 Specification 24 Example of a simple web shop Model( Product("Online webshop") has Gist("A web shop where customers can shop online."), Feature("Item database") has Gist("Database and information providerof the wares which are to sale."), Feature("Web shop") has Gist("Online webpage where customers buy wares."), Feature("Service system") has Gist("Provides the customer with the wares the customer has bought."), Feature("Billing system") has (), Product("Online webshop") owns (Feature("Billing system"), Feature("Item database"), Feature("Service system"), Feature("Web shop")), Feature("Service system") requires (Feature("Billing system"), Feature("Item database")), Feature("Billing system") requires Feature("Item database"), Feature("Web shop") requires (Feature("Billing system"), Feature("Item database"), Feature("Service system")), Resource("Testing") has Submodel( Release("Final release") has Capacity(50), Release("Summer") has Capacity(10), Release("Winter") has Capacity(30), Feature("Web shop") has Cost(30), Feature("Item database") has Cost(10), Feature("Service system") has Cost(10), Feature("Billing system") has Cost(20) ), Resource("Back end development") has Submodel( Release("Summer") has Capacity(30), Release("Winter") has Capacity(50), Feature("Web shop") has Cost(2), Release("Final release") has Capacity(5), Feature("Item database") has Cost(25), Feature("Service system") has Cost(20), Feature("Billing system") has Cost(30) ), Resource("Front end development") has Submodel( Release("Final release") has Capacity(100), Release("Summer") has Capacity(10), Release("Winter") has Capacity(10), Feature("Web shop") has Cost(90), Feature("Billing system") has Cost(10) ), Stakeholder("Product owner") has ( Prio(1), Submodel( Subdomain("Prio") has Submodel( Subdomain("Ordinal") has Submodel( Feature("Web shop") has Prio(4), Feature("Billing system") has Prio(2), Feature("Item database") has Prio(2), Feature("Service system") has Prio(1) ) ) ) ), Release("Summer") has Order(0), Release("Winter") has Order(1), Release("Final release") has Order(2) ) 69

70 Specification 25 Example of logistics optimization Model( Feature("NyMi sc1") has (), Feature("NyMi sc2") has (), Feature("NyMi sc3") has (), Feature("RoJa sc1") has (), Feature("RoJa sc2") has (), Stakeholder("James Winebrakea et al.") has ( Prio(1), Subdomain("Prio") has Submodel( Subdomain("Ruhe") has Submodel( Feature("NyMi sc1") has (Prio(-390)), Feature("NyMi sc2") has (Prio(-1295)), Feature("NyMi sc3") has (Prio(-1388)), Feature("RoJa sc1") has (Prio(-328)), Feature("RoJa sc2") has (Prio(-1158)) ) ) ) ), Release("Combined releases") has ( Order(0), Constraints(Count(Seq((Feature("New York to Miami scenario 1")!Order), ( Feature("New York to Miami scenario 2")!Order), ( Feature("New York to Miami scenario 2")!Order)), Var("Count New York to Miami scenarios"), 0), Var("Count New York to Miami scenarios")#==1, Count(Seq((Feature(" Rochester to Jacksonville scenario 1")!Order), ( Feature(" Rochester to Jacksonville scenario 2")!Order)), Var("Count Rochester to Jacksonvillei scenarios"), 0), Var("Count Rochester to Jacksonvillei scenarios")#==1)), Resource("Time in hours") has Submodel( Feature("NyMi sc2") has (Cost(49)), Feature("RoJa sc2") has (Cost(17)), Feature("NyMi sc1") has (Cost(61)), Feature("NyMi sc3") has (Cost(25)), Feature("RoJa sc1") has (Cost(54)), Release("Selected scenarios") has (Capacity(90)) ), Resource("Cost in dollars") has Submodel( Feature("NyMi sc2") has (Cost(668)), Feature("RoJa sc2") has (Cost(1007)), Feature("NyMi sc1") has (Cost(925)), Feature("NyMi sc3") has (Cost(1226)), Feature("RoJa sc1") has (Cost(866)), Release("Combined releases") has (Capacity(2000)) ) ) 70

71 B Release planning problem Resources Stakeholder 1 Stakeholder 2 Urgency / release Urgency / release Feature R1 R2 R3 R4 Value Rel1 Rel2 Rel3 Value Rel1 Rel2 Rel Total resources 2,615 3, ,375 Capacity, Rel 1 1,300 1, ,200 Capacity, Rel 2 1,046 1, ,750 Table 4: The release plan problem described by Ruhe et al.[15] Coupling constraints: 1. Feature(7) should be in same release as Feature(8) 2. Feature(9) should be in same release as Feature(12) 3. Feature(13) should be in same release as Feature(14) Precedence constraints: 1. Feature(2) should be in earlier or same release as Feature(1) 2. Feature(5) should be in earlier or same release as Feature(6) 3. Feature(3) should be in earlier or same release as Feature(11) 4. Feature(8) should be in earlier or same release as Feature(9) 5. Feature(13) should be in earlier or same release as Feature(15) 71

72 Solution with ReleasePlanner Resource usage Release 1 Release 2 Feature Released in WAS R1 R2 R3 R4 R1 R2 R3 R , , , , , , Total value 2,076.2 Total resource consumption 1, , ,550 Total resource capacity 1,300 1, ,200 1,046 1, ,750 Table 5: The optimal solution to problem [15] generated in ReleasePlanner. Note that the solution uses more of resource 3 than which is available in release 2. 72

73 Solution with prototype Resource usage Release 1 Release 2 Feature Released in WAS R1 R2 R3 R4 R1 R2 R3 R , , , , , , Total value 2,022.2 Total resource consumption 1, , ,550 Total resource capacity 1,300 1, ,200 1,046 1, ,750 Table 6: The optimal solution to problem [15] generated in the prototype. Note that the total value is lower than the solution in table 5, the reason is that the prototype is bound by the resource constraints. 73

74 C Requirements engineering models The release planning model has been developed during the thesis. The representation is using reqt terminology to give a connection between the Specification examples and the model represented in the Release planning model appendix. The model coloured in red, context entities in blue, requirements as green and attributes as orange. Prioritization example An example model of a generated prioritization. Figure 30: Prioritization model concept 74

75 Release plan model input An example model of the inputs required to generate a release plan. Figure 31: Inputs required to generate release plan 75

76 Generated release plan model All data located in an example of a generated release plan. Figure 32: A generated release plan 76

reqt.org A Scala DSL for Constraint-based Requirement Engineering using JaCoP

reqt.org A Scala DSL for Constraint-based Requirement Engineering using JaCoP reqt.org A Scala DSL for Constraint-based Requirement Engineering using JaCoP Björn Regnell Lund University Sweden The 12th Workshop of the Network of Sweden-based researchers and practitioners of Constraint

More information

Requirements Engineering: Elicitation Techniques

Requirements Engineering: Elicitation Techniques 2008:PR003 Requirements Engineering: Elicitation Techniques Sai Ganesh. Gunda Source:http://www.marcocioffi.com/archives/2005/04/requirements-engineering/ MASTER S THESIS Software Engineering, 2008 Department

More information

What is a life cycle model?

What is a life cycle model? What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

11 Tips to make the requirements definition process more effective and results more usable

11 Tips to make the requirements definition process more effective and results more usable 1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to

More information

Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014

Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014 Scrum, User Stories, and More! CSCI 5828: Foundations of Software Engineering Lecture 22 11/06/2014 1 Goals Cover Material from our User Stories Book Chapter 15: Using Stories With Scrum Chapter 16: Additional

More information

Information Science 1

Information Science 1 Topics covered Information Science 1 Terms and concepts from Week 05 The software development process Program'Development /Algorithms'and'Problem'Solving/'' ' software software life cycle life-cycle models

More information

User Stories Applied

User Stories Applied User Stories Applied for Agile Software Development Mike Cohn Boston San Francisco New York Toronto Montreal London Munich Paris Madrid Capetown Sydney Tokyo Singapore Mexico City Chapter 2 Writing Stories

More information

TABLE OF CONTENTS ABSTRACT ACKNOWLEDGEMENT LIST OF FIGURES LIST OF TABLES

TABLE OF CONTENTS ABSTRACT ACKNOWLEDGEMENT LIST OF FIGURES LIST OF TABLES TABLE OF CONTENTS ABSTRACT ACKNOWLEDGEMENT LIST OF FIGURES LIST OF TABLES ii iii x xiv CHAPTER 1: INTRODUCTION 1 1.0 Background 1 1.1 Research Motivation 4 1.2 Research Objectives 5 1.3 Project Scope 6

More information

User experience prototype requirements PROJECT MANAGEMENT PLAN

User experience prototype requirements PROJECT MANAGEMENT PLAN Tallinn University Institute of Informatics User experience prototype requirements PROJECT MANAGEMENT PLAN Authors Roger Puks Erkki Saarnit Ekaterina Shafeeva Maria Angelica Medina Angarita Lecturer Peeter

More information

STRATEGIC RELEASE PLANNING AND EVALUATION OF OPERATIONAL FEASIBILITY

STRATEGIC RELEASE PLANNING AND EVALUATION OF OPERATIONAL FEASIBILITY STRATEGIC RELEASE PLANNING AND EVALUATION OF OPERATIONAL FEASIBILITY Guenther Ruhe 1) & Joseph Momoh 1)2) 1) Laboratory for Software Engineering Decision Support University of Calgary 2500 University Drive

More information

(Refer Slide Time: 01:52)

(Refer Slide Time: 01:52) Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This

More information

Product Release Planning in Consideration of Technical Debt

Product Release Planning in Consideration of Technical Debt Fifth International Workshop on Managing Technical Debt, Baltimore 2013 Product Release Planning in Consideration of Technical Debt Guenther Ruhe (joint work with Jason Ho) University of Calgary, Canada

More information

www.stephenbarkar.se Lean vs. Agile similarities and differences 2014-08-29 Created by Stephen Barkar - www.stephenbarkar.se

www.stephenbarkar.se Lean vs. Agile similarities and differences 2014-08-29 Created by Stephen Barkar - www.stephenbarkar.se 1 www.stephenbarkar.se Lean vs. Agile similarities and differences 2014-08-29 Purpose with the material 2 This material describes the basics of Agile and Lean and the similarities and differences between

More information

Develop Project Charter. Develop Project Management Plan

Develop Project Charter. Develop Project Management Plan Develop Charter Develop Charter is the process of developing documentation that formally authorizes a project or a phase. The documentation includes initial requirements that satisfy stakeholder needs

More information

Quantification and Traceability of Requirements

Quantification and Traceability of Requirements Quantification and Traceability of Requirements Gyrd Norvoll Master of Science in Computer Science Submission date: May 2007 Supervisor: Tor Stålhane, IDI Norwegian University of Science and Technology

More information

The Basics of Scrum An introduction to the framework

The Basics of Scrum An introduction to the framework The Basics of Scrum An introduction to the framework Introduction Scrum, the most widely practiced Agile process, has been successfully used in software development for the last 20 years. While Scrum has

More information

Software Engineering Reference Framework

Software Engineering Reference Framework Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

More information

The most suitable system methodology for the proposed system is drawn out.

The most suitable system methodology for the proposed system is drawn out. 3.0 Methodology 3.1 Introduction In this chapter, five software development life cycle models are compared and discussed briefly. The most suitable system methodology for the proposed system is drawn out.

More information

3C05: Unified Software Development Process

3C05: Unified Software Development Process 3C05: Unified Software Development Process 1 Unit 5: Unified Software Development Process Objectives: Introduce the main concepts of iterative and incremental development Discuss the main USDP phases 2

More information

CSE 435 Software Engineering. Sept 16, 2015

CSE 435 Software Engineering. Sept 16, 2015 CSE 435 Software Engineering Sept 16, 2015 2.1 The Meaning of Process A process: a series of steps involving activities, constraints, and resources that produce an intended output of some kind A process

More information

Oracle Real Time Decisions

Oracle Real Time Decisions A Product Review James Taylor CEO CONTENTS Introducing Decision Management Systems Oracle Real Time Decisions Product Architecture Key Features Availability Conclusion Oracle Real Time Decisions (RTD)

More information

Software Processes. Coherent sets of activities for specifying, designing, implementing and testing software systems

Software Processes. Coherent sets of activities for specifying, designing, implementing and testing software systems Questions What is the life cycle of a software product? Why do we need software process models? What are the goals of a software process and what makes it different from other industrial processes? Software

More information

Agile Software Development Methodologies and Its Quality Assurance

Agile Software Development Methodologies and Its Quality Assurance Agile Software Development Methodologies and Its Quality Assurance Aslin Jenila.P.S Assistant Professor, Hindustan University, Chennai Abstract: Agility, with regard to software development, can be expressed

More information

SE464/CS446/ECE452 Software Life-Cycle and Process Models. Instructor: Krzysztof Czarnecki

SE464/CS446/ECE452 Software Life-Cycle and Process Models. Instructor: Krzysztof Czarnecki SE464/CS446/ECE452 Software Life-Cycle and Process Models Instructor: Krzysztof Czarnecki 1 Some of these slides are based on: Lecture slides by Ian Summerville accompanying his classic textbook software

More information

Surveying and evaluating tools for managing processes for software intensive systems

Surveying and evaluating tools for managing processes for software intensive systems Master Thesis in Software Engineering 30 Credits, Advanced Level Surveying and evaluating tools for managing processes for software intensive systems Anuradha Suryadevara IDT Mälardalen University, ABB

More information

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53 Preface xvi Part I Introduction and System Engineering 1 Chapter 1 Introduction 2 1.1 What Is Software Engineering? 2 1.2 Why Software Engineering? 3 1.3 Software Life-Cycle Activities 4 1.3.1 Software

More information

A Software Engineering Model for Mobile App Development

A Software Engineering Model for Mobile App Development APPENDIX C A Software Engineering Model for Mobile App Development As we mentioned early in the book (see Chapter 1), to successfully develop a mobile software solution you should follow an engineering

More information

Assuming the Role of Systems Analyst & Analysis Alternatives

Assuming the Role of Systems Analyst & Analysis Alternatives Assuming the Role of Systems Analyst & Analysis Alternatives Nature of Analysis Systems analysis and design is a systematic approach to identifying problems, opportunities, and objectives; analyzing the

More information

Software Engineering. Software Development Process Models. Lecturer: Giuseppe Santucci

Software Engineering. Software Development Process Models. Lecturer: Giuseppe Santucci Software Engineering Software Development Process Models Lecturer: Giuseppe Santucci Summary Modeling the Software Process Generic Software Process Models Waterfall model Process Iteration Incremental

More information

CS 6361, SPRING 2010 Advanced Requirements Engineering Web Based Meeting Scheduler- Project Plan

CS 6361, SPRING 2010 Advanced Requirements Engineering Web Based Meeting Scheduler- Project Plan 1 W E B B A S E D M E E T I N G S C H E D U L E R S Y S T E M Project Plan Version 4.0 CS 6361 ADVANCED REQUIREMENTS ENGINEERING, SPRING 2010 UNIVERSITY OF TEXAS AT DALLAS R E Q U I R E M E N T S E N G

More information

Requirements Engineering Process

Requirements Engineering Process Software Engineering Requirements Engineering Process Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To describe the principal requirements engineering activities and d their

More information

Business Analyst Work Plan. Presented by: Billie Johnson, CBAP CSM

Business Analyst Work Plan. Presented by: Billie Johnson, CBAP CSM Business Analyst Work Plan Presented by: Billie Johnson, CBAP CSM Agenda Topic Introduction Overview of a Business Analysis Work Plan Initiating a Business Analysis Effort Components of the Business Analysis

More information

POSITIVE TRENDS IN REQUIREMENT ENGINEERING PRACTICES FOR HIGHER SOFTWARE QUALITY

POSITIVE TRENDS IN REQUIREMENT ENGINEERING PRACTICES FOR HIGHER SOFTWARE QUALITY POSITIVE TRENDS IN REQUIREMENT ENGINEERING PRACTICES FOR HIGHER Dr. Rajinder Singh* SOFTWARE QUALITY Abstract : In this competitive world, customer satisfaction is the utmost important thing for any organization

More information

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process

More information

To Ameliorate Quality in Software Development Projects By Using Contemporary Agile Bug Tracking System

To Ameliorate Quality in Software Development Projects By Using Contemporary Agile Bug Tracking System To Ameliorate Quality in Software Development Projects By Using Contemporary Agile Bug Tracking System V. Nithya 1, S. Lavanya 2, G. Gokila Deepa 3 1,2 Students/M.Tech IT, 3 AsstProfessor, Dept of Information

More information

Requirements engineering and quality attributes

Requirements engineering and quality attributes Open Learning Universiteit Unit 2 Learning Unit 2 Requirements engineering and quality attributes Contents Introduction............................................... 21 2.1 Important concepts........................................

More information

Process Methodology. Wegmans Deli Kiosk. for. Version 1.0. Prepared by DELI-cious Developers. Rochester Institute of Technology

Process Methodology. Wegmans Deli Kiosk. for. Version 1.0. Prepared by DELI-cious Developers. Rochester Institute of Technology Process Methodology for Wegmans Deli Kiosk Version 1.0 Prepared by DELI-cious Developers Rochester Institute of Technology September 15, 2013 1 Table of Contents 1. Process... 3 1.1 Choice... 3 1.2 Description...

More information

Agile Project Management with Scrum

Agile Project Management with Scrum Agile Project Management with Scrum Resource links http://www.agilealliance.org/ http://www.agilemanifesto.org/ http://www.scrum-master.com/ 1 Manifesto for Agile Software Development Individuals and interactions

More information

A system is a set of integrated components interacting with each other to serve a common purpose.

A system is a set of integrated components interacting with each other to serve a common purpose. SYSTEM DEVELOPMENT AND THE WATERFALL MODEL What is a System? (Ch. 18) A system is a set of integrated components interacting with each other to serve a common purpose. A computer-based system is a system

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Benefits of Test Automation for Agile Testing

Benefits of Test Automation for Agile Testing Benefits of Test Automation for Agile Testing Manu GV 1, Namratha M 2, Pradeep 3 1 Technical Lead-Testing Calsoft Labs, Bangalore, India 2 Assistant Professor, BMSCE, Bangalore, India 3 Software Engineer,

More information

Development. Lecture 3

Development. Lecture 3 Software Process in Modern Software Development Lecture 3 Software Engineering i Practice Software engineering practice is a broad array of principles, concepts, methods, and tools that must be considered

More information

Software Requirements, Third Edition

Software Requirements, Third Edition j Microsoft Software Requirements, Third Edition Karl Wiegers and Joy Beatty Contents Introduction Acknowledgments xxv xxxi PART I SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHO Chapter 1 The essential software

More information

LEAN AGILE POCKET GUIDE

LEAN AGILE POCKET GUIDE SATORI CONSULTING LEAN AGILE POCKET GUIDE Software Product Development Methodology Reference Guide PURPOSE This pocket guide serves as a reference to a family of lean agile software development methodologies

More information

Nova Software Quality Assurance Process

Nova Software Quality Assurance Process Nova Software Quality Assurance Process White Paper Atlantic International Building 15F No.2 Ke Yuan Yi Road, Shiqiaopu, Chongqing, P.R.C. 400039 Tel: 86-23- 68795169 Fax: 86-23- 68795169 Quality Assurance

More information

Information system for production and mounting of plastic windows

Information system for production and mounting of plastic windows Information system for production and mounting of plastic windows MARCEL, MELIŠ Slovak University of Technology - Faculty of Material Sciences and Technology in Trnava, Paulínska 16 street, Trnava, 917

More information

Computer Science Department CS 470 Fall I

Computer Science Department CS 470 Fall I Computer Science Department CS 470 Fall I RAD: Rapid Application Development By Sheldon Liang CS 470 Handouts Rapid Application Development Pg 1 / 5 0. INTRODUCTION RAD: Rapid Application Development By

More information

A. Waterfall Model - Requirement Analysis. System & Software Design. Implementation & Unit Testing. Integration & System Testing.

A. Waterfall Model - Requirement Analysis. System & Software Design. Implementation & Unit Testing. Integration & System Testing. Processing Models Of SDLC Mrs. Nalkar Sanjivani Baban Asst. Professor, IT/CS Dept, JVM s Mehta College,Sector 19, Airoli, Navi Mumbai-400708 Nalkar_sanjivani@yahoo.co.in Abstract This paper presents an

More information

Effective Peer Reviews: Role in Quality

Effective Peer Reviews: Role in Quality Effective Peer Reviews: Role in Quality Anil Chakravarthy (Anil_Chakravarthy@mcafee.com) Sudeep Das (Sudeep_Das@mcafee.com) Nasiruddin S (nasiruddin_sirajuddin@mcafee.com) Abstract The utility of reviews,

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

CDC UNIFIED PROCESS PRACTICES GUIDE Purpose The purpose of this document is to provide guidance on the practice of Modeling and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements.

More information

General Problem Solving Model. Software Development Methodology. Chapter 2A

General Problem Solving Model. Software Development Methodology. Chapter 2A General Problem Solving Model Software Development Methodology These focus on understanding what the problem is about Chapter 2A Concerned with understanding more about the nature of the problem and possible

More information

Umbrella: A New Component-Based Software Development Model

Umbrella: A New Component-Based Software Development Model 2009 International Conference on Computer Engineering and Applications IPCSIT vol.2 (2011) (2011) IACSIT Press, Singapore Umbrella: A New Component-Based Software Development Model Anurag Dixit and P.C.

More information

CREDENTIALS & CERTIFICATIONS 2015

CREDENTIALS & CERTIFICATIONS 2015 THE COMMUNITY FOR TECHNOLOGY LEADERS www.computer.org CREDENTIALS & CERTIFICATIONS 2015 KEYS TO PROFESSIONAL SUCCESS CONTENTS SWEBOK KNOWLEDGE AREA CERTIFICATES Software Requirements 3 Software Design

More information

Foundations for Systems Development

Foundations for Systems Development Foundations for Systems Development ASSIGNMENT 1 Read this assignment introduction. Then, read Chapter 1, The Systems Development Environment, on pages 2 25 in your textbook. What Is Systems Analysis and

More information

The Role of Software Models in Developing New Software Systems; A Case Study in Project Management

The Role of Software Models in Developing New Software Systems; A Case Study in Project Management Proceedings of the Tenth Asia-Pacific Conference on Conceptual Modelling (APCCM 2014), Auckland, New Zealand The Role of Software Models in Developing New Software Systems; A Case Study in Project Management

More information

Measurement Information Model

Measurement Information Model mcgarry02.qxd 9/7/01 1:27 PM Page 13 2 Information Model This chapter describes one of the fundamental measurement concepts of Practical Software, the Information Model. The Information Model provides

More information

Do you know? "7 Practices" for a Reliable Requirements Management. by Software Process Engineering Inc. translated by Sparx Systems Japan Co., Ltd.

Do you know? 7 Practices for a Reliable Requirements Management. by Software Process Engineering Inc. translated by Sparx Systems Japan Co., Ltd. Do you know? "7 Practices" for a Reliable Requirements Management by Software Process Engineering Inc. translated by Sparx Systems Japan Co., Ltd. In this white paper, we focus on the "Requirements Management,"

More information

Expert Reference Series of White Papers. Intersecting Project Management and Business Analysis

Expert Reference Series of White Papers. Intersecting Project Management and Business Analysis Expert Reference Series of White Papers Intersecting Project Management and Business Analysis 1-800-COURSES www.globalknowledge.com Intersecting Project Management and Business Analysis Daniel Stober,

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Requirements Definition and Management Processes

Requirements Definition and Management Processes Software Engineering G22.2440-001 Session 1 Sub-Topic 1 Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute

More information

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0 NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5

More information

Basic Unified Process: A Process for Small and Agile Projects

Basic Unified Process: A Process for Small and Agile Projects Basic Unified Process: A Process for Small and Agile Projects Ricardo Balduino - Rational Unified Process Content Developer, IBM Introduction Small projects have different process needs than larger projects.

More information

Implementing Traceability In Agile Software Development

Implementing Traceability In Agile Software Development Implementing Traceability In Agile Software Development Department of Computer Science Sweden Date: 2009-02-02 Ver. 1.0.5 Department of Computer Science Lund University, SE-221 00 Lund, Sweden www.lth.se

More information

Partnering for Project Success: Project Manager and Business Analyst Collaboration

Partnering for Project Success: Project Manager and Business Analyst Collaboration Partnering for Project Success: Project Manager and Business Analyst Collaboration By Barbara Carkenord, CBAP, Chris Cartwright, PMP, Robin Grace, CBAP, Larry Goldsmith, PMP, Elizabeth Larson, PMP, CBAP,

More information

White Paper: Designing Resourceful Graphical User Interfaces (GUIs) for Healthcare Applications

White Paper: Designing Resourceful Graphical User Interfaces (GUIs) for Healthcare Applications Accelerate Development Reduce Time to Product Automate Critical Tasks White Paper: Designing Resourceful Graphical User Interfaces (GUIs) for Healthcare Applications The ASHVINS GROUP, Inc. 6161 Blue Lagoon

More information

Neglecting Agile Principles and Practices: A Case Study

Neglecting Agile Principles and Practices: A Case Study Neglecting Agile Principles and Practices: A Case Study Patrícia Vilain Departament de Informatics and Statistics (INE) Federal University of Santa Catarina Florianópolis, Brazil vilain@inf.ufsc.br Alexandre

More information

An Analysis of the B2B E-Contracting Domain - Paradigms and Required Technology 1

An Analysis of the B2B E-Contracting Domain - Paradigms and Required Technology 1 An Analysis of the B2B E-Contracting Domain - Paradigms and Required Technology 1 Samuil Angelov and Paul Grefen Department of Technology Management, Eindhoven University of Technology, P.O. Box 513, 5600

More information

A Comparison of SOA Methodologies Analysis & Design Phases

A Comparison of SOA Methodologies Analysis & Design Phases 202 A Comparison of SOA Methodologies Analysis & Design Phases Sandra SVANIDZAITĖ Institute of Mathematics and Informatics, Vilnius University Abstract. Service oriented computing is a new software engineering

More information

SA Tool Kit release life cycle

SA Tool Kit release life cycle Release management Release management process is a software engineering process intended to oversee the development, testing, deployment and support of software releases. A release is usually a named collection

More information

AN OVERVIEW OF SYSTEMS ANALYSIS: SYSTEMS ANALYSIS AND THE ROLE OF THE SYSTEMS ANALYST. Lecture 1. 21.10.2014, Tuesday

AN OVERVIEW OF SYSTEMS ANALYSIS: SYSTEMS ANALYSIS AND THE ROLE OF THE SYSTEMS ANALYST. Lecture 1. 21.10.2014, Tuesday AN OVERVIEW OF SYSTEMS ANALYSIS: SYSTEMS ANALYSIS AND THE ROLE OF THE SYSTEMS ANALYST Lecture 1 21.10.2014, Tuesday 2 A Series of Lectures 1.The Role of the Systems 2.Project Planning and Project Management

More information

This alignment chart was designed specifically for the use of Red River College. These alignments have not been verified or endorsed by the IIBA.

This alignment chart was designed specifically for the use of Red River College. These alignments have not been verified or endorsed by the IIBA. Red River College Course Learning Outcome Alignment with BABOK Version 2 This alignment chart was designed specifically for the use of Red River College. These alignments have not been verified or endorsed

More information

SOFT 423: Software Requirements

SOFT 423: Software Requirements SOFT 423: Software Requirements Week 3 Class 1 Finish Elicitation & Start Analysis SOFT 423 Winter 2015 1 Last Class Questionnaires Document Inspection Requirements Stripping Use Cases Scenarios SOFT 423

More information

Applying Agile Methods in Rapidly Changing Environments

Applying Agile Methods in Rapidly Changing Environments Applying Agile Methods in Changing Environments 7/23/2002 1 Applying Agile Methods in Rapidly Changing Environments Peter Kutschera IBM Unternehmensberatung GmbH Am Fichtenberg 1, D-71803 Herrenberg Steffen

More information

EQUELLA Whitepaper. Performance Testing. Carl Hoffmann Senior Technical Consultant

EQUELLA Whitepaper. Performance Testing. Carl Hoffmann Senior Technical Consultant EQUELLA Whitepaper Performance Testing Carl Hoffmann Senior Technical Consultant Contents 1 EQUELLA Performance Testing 3 1.1 Introduction 3 1.2 Overview of performance testing 3 2 Why do performance testing?

More information

SOFTWARE REQUIREMENTS

SOFTWARE REQUIREMENTS SOFTWARE REQUIREMENTS http://www.tutorialspoint.com/software_engineering/software_requirements.htm Copyright tutorialspoint.com The software requirements are description of features and functionalities

More information

The objective of Software Engineering (SE) is to build high quality software. within a given time and with a predetermined budget (Sommerville, 2007).

The objective of Software Engineering (SE) is to build high quality software. within a given time and with a predetermined budget (Sommerville, 2007). 1. Introduction 1.1. Problem Outline The objective of Software Engineering (SE) is to build high quality software within a given time and with a predetermined budget (Sommerville, 2007). Often, though,

More information

Requirements Engineering for Web Applications

Requirements Engineering for Web Applications Web Engineering Requirements Engineering for Web Applications Copyright 2013 Ioan Toma & Srdjan Komazec 1 What is the course structure? # Date Title 1 5 th March Web Engineering Introduction and Overview

More information

Computing & Communications Services

Computing & Communications Services 2010 Computing & Communications Services 2010 / 10 / 04 Final Kent Percival, M.Sc., P.Eng. Defining the Value of the Business Analyst In achieving its vision, key CCS partnerships involve working directly

More information

Connecting with Computer Science, 2e. Chapter 13 Software Engineering

Connecting with Computer Science, 2e. Chapter 13 Software Engineering Connecting with Computer Science, 2e Chapter 13 Software Engineering Objectives In this chapter you will: Learn how software engineering is used to create applications Learn some software engineering process

More information

Suunto 2.0 web - Quality Assurance Plan

Suunto 2.0 web - Quality Assurance Plan Suunto 2.0 web - Quality Assurance Plan T-76.4115 Software Development Project: Iteration 2 Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing

More information

Workflow Management Standards & Interoperability

Workflow Management Standards & Interoperability Management Standards & Interoperability Management Coalition and Keith D Swenson Fujitsu OSSI kswenson@ossi.com Introduction Management (WfM) is evolving quickly and expolited increasingly by businesses

More information

Fourth generation techniques (4GT)

Fourth generation techniques (4GT) Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some

More information

Software Engineering. Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti

Software Engineering. Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti Software Engineering Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical

More information

CHAPTER 11 REQUIREMENTS

CHAPTER 11 REQUIREMENTS Lecture Software Engineering CHAPTER 11 REQUIREMENTS Lecture Software Engineering Topics Determining What the Client Needs Overview of the Requirements Workflow Understanding the Domain The Business Model

More information

Printshop Workflow Automation System

Printshop Workflow Automation System Fictitious Corp. Software Project Plan Revision 1 Printshop Workflow Automation System CEN4021 Spring 2010 Professor: Masoud Sadjadi Paul White 16 th February 2010 TABLE OF CONTENTS 1 Overview... 3 1.1

More information

WHITEPAPER. Managing Design Changes in Enterprise SBM Installations

WHITEPAPER. Managing Design Changes in Enterprise SBM Installations WHITEPAPER Managing Design Changes in Enterprise SBM Installations By Tom Clement Serena Software, Inc. October 2013 Summary This document explains how to organize your SBM maintenance and development

More information

Classical Software Life Cycle Models

Classical Software Life Cycle Models Classical Software Life Cycle Models SWEN 301 Trimester 1, 2015 Lecturer: Dr Hui Ma Engineering and Computer Science Lecture slides make use of material provided on the textbook's companion website Motivation

More information

Towards Collaborative Requirements Engineering Tool for ERP product customization

Towards Collaborative Requirements Engineering Tool for ERP product customization Towards Collaborative Requirements Engineering Tool for ERP product customization Boban Celebic, Ruth Breu, Michael Felderer, Florian Häser Institute of Computer Science, University of Innsbruck 6020 Innsbruck,

More information

Information Management & Data Governance

Information Management & Data Governance Data governance is a means to define the policies, standards, and data management services to be employed by the organization. Information Management & Data Governance OVERVIEW A thorough Data Governance

More information

Methodology: Agile development of safety critical systems Annex D1.1.d to deliverable D1.1

Methodology: Agile development of safety critical systems Annex D1.1.d to deliverable D1.1 Collaborative Large scale Integrating Project Open Platform for EvolutioNary Certification Of Safety critical Systems Methodology: Agile development of safety critical systems to deliverable D1.1 Work

More information

FEAWEB ASP Issue: 1.0 Stakeholder Needs Issue Date: 03/29/2000. 04/07/2000 1.0 Initial Description Marco Bittencourt

FEAWEB ASP Issue: 1.0 Stakeholder Needs Issue Date: 03/29/2000. 04/07/2000 1.0 Initial Description Marco Bittencourt )($:(%$63 6WDNHKROGHU1HHGV,VVXH 5HYLVLRQ+LVWRU\ 'DWH,VVXH 'HVFULSWLRQ $XWKRU 04/07/2000 1.0 Initial Description Marco Bittencourt &RQILGHQWLDO DPM-FEM-UNICAMP, 2000 Page 2 7DEOHRI&RQWHQWV 1. Objectives

More information

MEng, BSc Applied Computer Science

MEng, BSc Applied Computer Science School of Computing FACULTY OF ENGINEERING MEng, BSc Applied Computer Science Year 1 COMP1212 Computer Processor Effective programming depends on understanding not only how to give a machine instructions

More information

The role of integrated requirements management in software delivery.

The role of integrated requirements management in software delivery. Software development White paper October 2007 The role of integrated requirements Jim Heumann, requirements evangelist, IBM Rational 2 Contents 2 Introduction 2 What is integrated requirements management?

More information

A Framework for Integrating Software Usability into Software Development Process

A Framework for Integrating Software Usability into Software Development Process A Framework for Integrating Software Usability into Software Development Process Hayat Dino AFRICOM Technologies, Addis Ababa, Ethiopia hayudb@gmail.com Rahel Bekele School of Information Science, Addis

More information

Metadata-Based Project Management System. A Case Study at M-Files Corporation. Iulia Adomnita

Metadata-Based Project Management System. A Case Study at M-Files Corporation. Iulia Adomnita Metadata-Based Project Management System. A Case Study at M-Files Corporation Iulia Adomnita University of Tampere School of Information Sciences Computer Science M.Sc. Thesis Supervisors: Timo Poranen,

More information

Using Simulation to teach project management skills. Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca

Using Simulation to teach project management skills. Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca Using Simulation to teach project management skills Dr. Alain April, ÉTS Montréal alain.april@etsmtl.ca Agenda of the workshop 1 The software project management theory overview (40 minutes) 2 Why use SDLC

More information