Context and Motivation: The notion of goal and goal models is ideal for the alternative systems. Goal models provide us different alternatives during goal oriented requirements engineering. Question/Problem: Once we find different alternatives, we need to evaluate these alternatives to select the best one. Ideas: The selection process consists of two main parts. In first part of the selection process among alternatives, we will use techniques in which we establish some evaluation criteria. The evaluation criteria are based on leaf level goals. Stakeholders are involved to contribute their opinions about the evaluation criteria. The input provided by various stakeholders is then converted into quantifiable numbers using fuzzy triangle numbers. After applying the defuzzification process on fuzzy triangle numbers we get scores (weights) for each criteria. In second part, these scores are used in the selection process to select the best alternative. Contribution: The two steps selection process helps us to select the best alternative among many alternatives. We have described the process and applied it to “cyclecomputer” selection case study.
Decision making process is about the selection of best option among all the alternatives. In almost all decision making problems, we have multiple criteria for selection among the alternatives. The problems involving mul- tiple criteria are called Multi Criteria Decision Making (MCDM) problems. Decision making can be challenging because of conflicting stakeholders interests there is the uncertainty and vagueness of selected criteria. There may be different criteria but some are more important than others and tend to dominate the decision [
In Goal Oriented Requirements Engineering (GORE), there is a great emphasis on alternative system proposals. Goal refinements help us in finding alternatives and during requirements elaboration process many alternatives are considered. The qualitative and quantitative analysis of these alternatives helps to choose the best one. In alternative selection we have to decide about the best option according to stakeholders needs.
In the context of GORE we need the support and methodology for identifying and managing the criteria for alternative’s selection process. Finding the criteria based on GORE require high level goals to be analyzed till leaf goals are achieved i.e., requirements. These leaf level goals help us in establishing the criteria which are used in the selection process among alternatives. The criteria are based on stakeholders needs and preferences and therefore stakeholders opinions need to be involved in selection process. It helps to identify the importance of requirement according to stakeholders understandings and needs. Based on these criteria we apply qualitative and quantitative reasoning techniques for the selection of alternative system proposals.
The general procedure of selection among alternatives consists of the following steps:
1. Finding acceptance criteria;
2. Involving stakeholders opinions;
3. Finding scores of each criteria;
4. Evaluating alternatives based on accepted criteria scores;
5. Making a selection.
In this paper we consider the case study of selecting one among four alternatives of “cyclecomputer”. We use GORE to explore and establish the acceptance criteria. The acceptance criteria are then prioritized based on the stakeholders interests for determining which of these are more important than others. It serves two purposes: first involving the stakeholders opinions in selection process and second finding the relative importance of these criteria. The output is then given as input to Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) which selects the best alternative among the candidates.
The remainder of this paper is organized in the following sections: next section gives the literature review on topics used in our approach. Section 3 describes the proposed methodology. Section 4 introduces the “cycle- computer” project and gives details of implementing proposed methodology for mentioned project. Section 5 discusses the related work on decision making and alternatives selection in GORE. Finally, last section con- cludes this paper.
The idea of goals emphasizes the understanding of organizational context for a new system [
Requirements engineering must address the contextual goals, functionalities to achieve these goals and con- straints restricting how these functions are to be designed and implemented [
GORE concerns are classified into two major categories i.e., goal analysis and goal evolution. Goal analysis is the process of exploring gathered documents, ranging from information about the organization, (i.e., enterprise goals) to system specific information (i.e., requirement) for the purpose of identifying, organizing and classify- ing goals [
Fuzzy numbers have been widely used in engineering disciplines because of their suitability to represent im- precise and vague information. Fuzzy numbers depict the physical world more realistically than single-valued numbers. Among the fuzzy number Triangular Fuzzy Number (TFN) is capable of aggregating the subjective opinions [
A triangular fuzzy number (TFN) is described by a triplet (L, M, H), where M is the modal value, L and H are the left (minimum value) and right (maximum value) boundary respectively. We use TFN to represent stake- holder opinions for criteria which are established through goal models.
The Technique for Order of Preference by Similarity to Ideal Solution (TOPSIS) is a multi criteria decision analysis method. It is used to compare a set of alternatives based on weighted scores of each criterion. In this method two alternatives are hypothesized: positive ideal alternative and negative ideal alternative and then best alternative is selected which is close to the positive ideal solution and farthest from negative ideal alternative [
1. Constructing a decision matrix;
2. Normalizing the decision matrix;
3. Finding the positive ideal and negative ideal alternatives;
4. Calculating the separation measures for each alternative;
5. Calculating the relative closeness to the ideal alternative.
First of all we have to explore different alternatives during GORE and for this we use goal models obtained during GORE. AND/OR diagrams which are the essential output artefact of these goal models are used in the exploration phase of alternatives. Once we found different alternatives, we need to evaluate these alternatives to select the best one. The alternatives are compared based on the weighted criteria. The criteria are weighted using fuzzy numbers and stakeholders opinions are taken as input and then converted to fuzzy numbers. By using the fuzzy numbers we can convert the qualitative information of stakeholders into quantitative one. The proposed methodology consist of following steps and is shown in
1. Establishing high level goal(s);
2. Establishing the criteria based on leaf level goals (directly assignable to agents: humans or system agents);
3. Identify relevant stakeholders and take their opinions for above established criteria as inputs;
4. Calculate relative importance of each criterion by applying TFN and defuzzification process;
5. Normalize the scores;
6. Identifying the alternatives;
7. Evaluate alternatives using TOPSIS based on scores of each criteria;
8. Rank alternatives.
The “cyclecomputer” system is used as case study for our work which is developed in our research group. This system will be attached to a bicycle, will process data from various sensors, and will communicate with a stan- dard PC. A cyclist will be supported while riding the bike, for maintenance issues, for tour preparations, or to enhance the safety using the bike e.g., besides the normal cycling activities one could use the “cyclecomputer” as a medical device which will support people having of health problems. It can be used for professional cyclist or just for entertainment purposes. One of the results of the requirements engineering phase is a goal model [
Step 1 Establishing High level Goals: Though there are many goals related to “cyclecomputer” but for space and simplicity considerations we take following identified goals for high level “cyclecomputer” goal:
Achieve [Entertainment Service Satisfied], Achieve [Compition Service Satisfied],
Achieve[Training Service Satisfied], Achieve[Tour Management Service Satisfied].
Step 2 Refine Goals to Leaf Levels (establish criterion for each goal): The above mentioned goals are refined using GORE until they are assignable to agents i.e., human agents or software agents. These leaf levels goals are used as criteria for alternative selection. Quality goals which include non-functional requirements and often serve selection criteria are also refined using GORE. The goals along with their subgoals and short description are presented in
Step 3(a) Identifying Stakeholders: Though there are number of stakeholders in “cyclecomputer” but the relavant stkeholders for our goals described in
1. Medical Cyclist: People who need a defined training/exercise due to any disease e.g., a heart disease. Medical cyclist can use pulse measurement, blood pressure, calory consumption by “cyclecomputer” device.
2. Doctor (medical): The doctor will cooperate with a patient to set-up the correct training cycles. The cycles are dependant on the patients constitution.
3. Touring Cyclist: People who like to ride the bicycle for long trips (>100 km) and they need specific services for their tours. The trips might take more than one day.
Goals | Sub goals till leaf level goals | Description |
---|---|---|
Entertainment Service Satisfied | Mic | The cycle computer should support Mic service. |
Data storage | The cycle computer should support data storage for fun services. | |
Audio service | The cycle computer should record and play audio data. | |
Competition Service Satisfied | User accounts | The cycle computer should have a user management i.e., Many cyclists should be able to use the same physical device. User specific data needs to be password protected |
Transferable to web | Track data should be transferred to a Web-portal to enable online competition/comparison. | |
Online modus | The competition mode should be used “online” (while riding the bike). | |
Offline modus | The competition mode should be used offline | |
Training Service Satisfied | Initial checkups | The cycle computer should offer an initial check-up to assess the drivers capabilities. |
Technical riding capabilities | Frame quality level should be analyzable and visible i.e., show the condition of the frame, interpret the frame condition by a coloured icon. The quality level should be visualized by the time until the frame might break. The cyclist should see the current speed of the cycle. The cyclist should be informed when the oil in the shocks should be changed | |
Fitness level | The cycle computer should analyze the cyclist. The cyclist should be informed about his heart beat. | |
Calories consumption | The calorie consumption should be shown e.g., current calorie consumption, calorie consumption per tour, the calorie consumption for a specified time frame | |
Tour Management Service Satisfied | Route planning | The cycle computer should offer route planning. The planning should be done based on topographic maps. Routing should consider the current weather forecast |
Weather info | The cyclist should see the current environmental temperature. The temperature of the last 5 days should be analyzable. | |
Tour details | The cycle computer should provide complete details of the tours The cyclist should be informed about the current height (above sea level). A cumulative value should be shown by ascended and descended meters. | |
Navigation | The cyclist should be able to navigate to a given location. The location could be a point of interest, e.g., a hotel. The cyclist should be informed about his global position on a map. | |
Trip suggestions | The cycle computer should offer trip tips for professional sports cyclists e.g., gear change tips, speed tips based on the (known) route. |
4. Trainer (sports): Create training plans, follow training plans, analyse the cyclist.
Step 3(b) Stakeholders Opinions Accumulation: We take three stakeholders, professional cyclist(SH1), fun cyclist (SH2), health and fitness cyclist (SH3). These stakeholders are asked to give their judgements against each criterion in
Step 4(a) Calculate the Relative Importance Using TFN: The different importance degrees of each criterion assigned by stakeholders is calculated using TFN. TFN is used to aggregate the subjective opinions of a stakeholder using fuzzy set theory. The TFN is represented by triplet (L, M, H) L being the smallest value, H being the largest value and M represents the geometric mean.
Step 4(b) Apply Defuzzification Process on TFN: After calculating TFN for each criterion we apply
Ordinal scale | Actual numbers |
---|---|
Very high importance (VHI) | 1 |
High importance (HI) | 0.75 |
Low importance (LI) | 0.5 |
Very low importance (VLI) | 0.25 |
No importance (NI) | 0.001 |
Goals | Sub goals till leaf level goals | Ordinal scale | Numerical values | ||||
---|---|---|---|---|---|---|---|
SH1 | SH2 | SH3 | SH1 | SH2 | SH3 | ||
Entertainment Service Satisfied | Mic | H | VH | H | 0.75 | 1 | 0.75 |
Data storage | H | VH | H | 0.75 | 1 | 0.75 | |
Audio service | LI | VH | LI | 0.75 | 1 | 0.75 | |
Compition Servie Satisifed | User accounts | VH | H | H | 1 | 0.75 | 0.75 |
Transferable to web | VH | H | H | 1 | 0.75 | 0.75 | |
Online modus | VH | H | H | 1 | 0.75 | 0.75 | |
Offline modus | VH | H | H | 1 | 0.75 | 0.75 | |
Training Service Satisfied | Initial checkups | H | H | VH | 0.75 | 0.75 | 1 |
Technical riding capabilities | VH | LI | VH | 1 | 0.5 | 1 | |
Fitness level | H | LI | VH | 0.75 | 0.5 | 1 | |
Calories consumption | H | LI | VH | 0.75 | 0.5 | 0.75 | |
Tour Management Service Satisfied | Route planning | VH | H | LI | 1 | 0.75 | 0.5 |
Weather info | H | H | H | 0.75 | 0.75 | 0.75 | |
Tour details | H | LI | LI | 0.75 | 0.5 | 0.5 | |
Navigation | VH | H | H | 1 | 0.75 | 0.75 | |
Trip suggestions | H | VLI | H | 0.75 | 0.25 | 0.75 |
defuzzification process. Defzzuification process is used to convert calculated TFN values into quantifiable values. Defuzzificatio process is represented by the Equation (2) which is derived from [
where
When
where
Equation (5) represents left end boundary value:
Equation (6) represents right end boundary value.
If we take only preference value and ignore the risk tolerance, defuzzification value can be calculated using the Equations (7) or (8):
Step 5 Normalizing Values Obtained by Defuzzification Process: After defuzzification process the values are normalized by using the Equation (9):
where “m” represents number of criteria.
Step 6 Cyclecomputer Alternatives: We selected four alternatives for evaluation: CM213C, CM404, HAC4Pro, Germin Edge 305. The preliminary analysis results of these selected alternatives are given in Appendix.
Criteria | TFN | Defuzzification | Normalized scores |
---|---|---|---|
Mic | (0.75, 0.825, 1) | 0.84 | 0.067 |
Data storage | (0.75, 0.825, 1) | 0.84 | 0.067 |
Audio service | (0.75, 0.825, 1) | 0.84 | 0.067 |
User accounts | (0.75, 0.825, 1) | 0.84 | 0.067 |
Transferable to web | (0.75, 0.825, 1) | 0.84 | 0.067 |
Online modus | (0.75, 0.825, 1) | 0.84 | 0.067 |
Offline modus | (0.75, 0.825, 1) | 0.84 | 0.067 |
Initial checkups | (0.75, 0.825, 1) | 0.84 | 0.067 |
Technical riding capabilities | (0.5, 0.793, 1) | 0.771 | 0.062 |
Fitness level | (0.5, 0.721, 1) | 0.735 | 0.059 |
Calories consumption | (0.5, 0.655, 0.75) | 0.639 | 0.051 |
Route planning | (0.5, 0.721, 1) | 0.735 | 0.059 |
Weather info | (0.75, 0.75, 0.75) | 0.75 | 0.060 |
Tour details | (0.5, 0.572, 0.75) | 0.598 | 0.048 |
Navigation | (0.75, 0.825, 1) | 0.84 | 0.067 |
Trip suggestions | (0.25, 0.520, 1) | 0.569 | 0.046 |
Step 7 Evaluate Alternatives Using TOPSIS
Step 7(a) Constructing Decision Matrix: For “m” number of alternatives and “n” number of criteria we construct a m * n matrix. Values in the matrix are entered according to
Step 7(b) Normalizing Decision Matrix and Constructing Weighted Normalize Decision Matrix: The decision matrix is normalized according to Equation (10):
and then multiplied with each criterion score to get the weighted normalized decision matrix.
Step 7(c) Determine the Positive Ideal and Negative Ideal Alternatives: Positive ideal and negative ideal alternatives are determined using the Equations (11) and (12) respectively:
positive ideal alternative: (0.04, 0.05, 0.03, 0.02)
negative ideal alternative: (0.01, 0.01, 0.01, 0.01)
Step 7(d) Calculating the Separation Measures: separation measures for both positive and negative ideal alternatives are measured using Equations (13) and (14):
Alternative fulfilling criterion | 9 |
---|---|
Alternative partially fulfilling criterion | 7 |
Alternative minimally fulfilling criterion | 3 |
Alternative not fulfilling criterion | 0.25 |
Step 7(e) Calculating Closeness to Ideal Solution: the relative closeness to the ideal solution is calculated using the Equation (15):
Step 7(f) Ranking and Selecting: Finally the ranking is done and the alternative closet to 1 is selected as the best alternative.
Alternatives selection is ongoing research in the area of GORE. On the other hand methods like AHP [
[
[
Wiegers [
AGORA [
When stakeholders are more (plus four) and have to select among many alternatives, this method becomes dif- ficult to handle and goal graph becomes cumbersome.
We used the Fuzzy set concepts to evaluate the importance of criteria for each goal. Weight for each criterion is calculated based on stakeholder opinions. These weights display stakeholder priorities for all requirements. The interaction of stakeholders at early phase of requirements engineering helps to capture the rational (by docu- menting the preferences) for the decisions and to identify inconsistencies at the early phase of requirements en- gineering. The method gives a systematic structure to calculate the fuzzy weight of each criterion. The subject- tive weights assigned by stakeholders are normalized into a comparable scale. The performance measures of all alternatives on criteria are visualized using TOPSIS which accounts for both the best and worst alternatives si- multaneously.
In this paper an approach is presented to use the goal model of goal-oriented requirements engineering to es- tablish the acceptance criteria. After that we apply the TFN and defuzzification process to get scores for each criterion. In the final step TOPSIS method is used to evaluate the alternatives and for selection of the best alter- natives. TOPSIS method uses the score obtained by TFN and defuzzification process. The proposed methodol- ogy can be used against both the functional and non-functional requirements.
The methodology is explained by “cyclecomputer” case study where we establish 16 acceptance criteria and stakeholders opinions are collected for these criteria. After calculating the score of each criterion we take four criteria (for space considerations) and based on these evaluated four alternatives. This approach is promis- ing for ranking the criteria and using this ranking for alternative selection because we take the stakeholders opi- nions and most importantly developers’ considerations for preference and risk tolerance into account. The formalization of the approach, its full integration into goal oriented requirements engineering and the validation by additional examples are future research topics.
We acknowledge support for the Article Processing Charge by the German Research Foundation and the Open Access Publication Fund of the Technische Universit Ilmenau.
ArfanMansoor,DetlefStreitferdt,Franz-FelixFüßl, (2015) Alternatives Selection Using GORE Based on Fuzzy Numbers and TOPSIS. Journal of Software Engineering and Applications,08,346-359. doi: 10.4236/jsea.2015.87035
Feature | CM213C | CM404 | HAC4Pro | Germin Edge 305 |
---|---|---|---|---|
Price [? | 12 | 70 | 250 | |
Speed [Miles] | yes | yes | yes | yes |
Speed [KM] | yes | yes | yes | yes |
Speed digits [xxx] | 3 | 3 | 3 | 3 |
Speed digits [xxx] | 1 | 1 | 1 | 1 |
Average speed | yes | yes | ||
Wireless Speed Sensor | no | no | yes | n/a |
Daytime AM/PM | yes | yes | yes | yes |
Daytime 24h | yes | yes | yes | yes |
Date day/month/year | no | no | yes | yes |
Alarm clock | yes | |||
Stopwatch | yes | |||
Tire 1 Size | yes | yes | yes | yes |
Tire 2 Size | yes | no | yes | yes |
Sum-up Tire 1 and Tire 2 | yes | no | yes | |
Tire Size digits | 4 | 4 | 4 | |
Tire Size min [mm] | 500 | |||
Tire Size max [mm] | 3000 | |||
Overall distance | 5 | 5 | 5 | |
Overall distance digits [xxx,] | 5 | 5 | 5 | |
Overall distance digits [,xxx] | 1 | 1 | 1 | |
Overall riding time | yes | |||
Set overall distance | no | no | yes | Set overall distance |
Daily distance | yes | yes | yes | Daily distance |
Daily distance digits [xxx] | 3 | 3 | 3 | Daily distance digits [xxx] |
Daily distance digits [xxx] | 2 | 2 | 2 | Daily distance digits [xxx] |
Daily distance reset after [h] | 12 | 12 | Daily distance reset after [h] | |
Daily riding time | no | no | yes | Daily riding time |
Distance digits | 5 | 5 | Distance digits | |
Distance [Miles] | yes | yes | yes | Distance [Miles] |
Distance [KM] | yes | yes | yes | Distance [KM] |
Distance backup, battery change | yes | no | no | Dist backup, battery change |
Max battery Change time [sec] | 15 | 0 | Max battery Change time [sec] | |
Low battery warning | no | no | yes | Low battery warning |
Battery life [months] | 10 | |||
Pedal Frequency | yes | no | yes |
Max. Pedal Frequency | no | no | yes | |
---|---|---|---|---|
Min. Pedal Frequency | no | no | yes | |
Auto Turn off after [sec] | 300 | 300 | 300 | |
Auto Turn on, on tire turn | yes | yes | yes | |
Heartbeat Sensor | no | no | yes | |
No of Buttons | 2 | 4 | 5 | |
Height Sensor | no | no | yes | |
Height min [m] | −200 | |||
Height max [m] | 9000 | |||
Height in m | yes | |||
Height in feet | yes | |||
Daily height | yes | |||
Daily ascend | yes | |||
Daily descend | yes | |||
Set overall height | yes | |||
Show gradient (up/down) | yes | |||
Set Gradient min | 0.0% | |||
Set Gradient max | 99.0% | |||
Show average gradient | yes | |||
Show max gradient | yes | |||
Show min gradient | yes | |||
Varo-meter … | ||||
Current ascend value | yes | |||
Current descend value | yes | |||
Max ascend | yes | |||
Max descend | yes | |||
Average ascend | yes | |||
Average descend | yes | |||
No of ascends | yes | |||
No of descends | yes | |||
GPS | no | no | no | yes |
Auto Lap | no | no | no | yes |
Virtual partner | no | no | no | yes |
Temp Sensor | yes | |||
Temp Celsius | yes | |||
Temp Fahrenheit | yes | |||
Max Temp | yes | |||
Min Temp | yes | |||
PC-Connection | no | no | yes |
PC Analysis SW | no | no | yes | |
---|---|---|---|---|
Fitness … | ||||
Sex | no | no | yes | |
Body weight | no | no | yes | |
Complete weight | no | no | yes | |
Age | no | no | yes | |
Set heartbeat 1 min. level | no | no | yes | |
Set heartbeat 1 max. level | no | no | yes | |
Set heartbeat 2 min. level | no | no | yes | |
Set heartbeat 2 max. level | no | no | yes | |
Ride by heartbeat zone | no | no | yes | |
Heartbeat alarm (outside zone) | no | no | yes | |
Check cool down heartbeat | no | no | yes | |
Time in riding zone | no | no | yes | |
Time above riding zone | no | no | yes | |
Time below riding zone | no | no | yes | |
Fitness level | no | no | yes | |
Current calorie consumption | no | no | yes | |
Overall calorie consumption | no | no | yes | |
Current performance in Watts | no | no | yes | |
Average performance | no | no | yes | |
Max. performance | no | no | yes | |
Compare training sessions | no | no | yes | |
Countdown timer 1 | no | no | yes | |
Countdown timer 1 max [min: sec] | no | no | 99:59 | |
Countdown timer 2 | no | no | yes | |
Countdown timer 2 max [min: sec] | no | no | 99:59 | |
Firmware upgradeable | no | no | yes | |
Sleep mode | no | no | yes | |
Ski mode (use device for skiing) | no | no | yes | |
Backlight | no | no | yes | |
Display size | 128 × 160 4-level-grayscale | |||
Waterproof [m] | 30 | |||
Operation temp min [˚C] | −20 | |||
Operation temp max [˚C] | +60 | |||
Algorithms … | ||||
Calculate heartbeat zone by Sex, age, fitness level | yes | |||
Measure, Ruhepuls“ | yes |