**3. Decision support process**

(XREAP) [5] , is revised from part of the use case driven approach [7] [9]. Therefore, it is nec‐

On the other hand, Perini and Susi extend their decision support system research to the en‐ vironmental modelling and software field [11]. Their research approach is to hold interviews of producers, technicians anddomain experts as well as acquisition of domain documenta‐ tion. Meanwhile, they also try to analyse actor roles and strategic dependencies among ac‐ tors, goal-analysis and plan-analysis. Furthermore, Schlobinski, *et al*. [13] illustrates the user requirements that are derived from a UCD process to engage diverse user representatives

Based on the knowledge sharing concept, Shafiei [14] and his team members develop a mul‐ ti-enterprise collaborative decision support system for supply-chain management and show their idea is feasible. This evidence shows that the collaborative knowledge sharing is a pos‐ sible route to promote the quality of the decision-making. Further, Cercone and his partners predict that their e-Health decision support system can find and verify evidence from multi‐ ple sources, lead to cost-effective use of drugs, improve patients' quality of life, and opti‐ mize drug-related health outcomes [3]. That is, a series of the knowledge and evidence can be collected, shared and reused further for related fields as well as promote our health life to

Our proposed process includes functions to elicit the diverse requirements from users by utilizing the XREAP tool, analyses all requirements on-line, transforms the final require‐ ments into use case diagram, and provides on-demand complexity metric. Essentially, the process can elicit sufficient sources for user requirements and provide enough complexity information for decision makers. In conclusion, we can straightforwardly understand the complexity between the diverse user requirements and even make an appropriate decision, whether it is the right time to move one of the specific SP activities toward one of the SN's

A definition of suicide from [12] is death from injury, poisoning, or suffocation in which there is evidence that the injury was self-inflicted and that the deceased intended to kill him/ her-self. The generation of suicidal behaviour is from suicidal ideation, which means any self-reported thoughts of engaging in suicide-related behaviour. Therefore, everyone who commits suicide will have suicidal ideation before s/he commits suicide;so suicidal ideation

As the official report from the World Health Organization (WHO) [18] said that the world almost one million people die from suicide every year. That is, one death every 40 seconds in 2011. Surprisingly, a global map of suicide rates is drawn by the most recent year availa‐ ble as of 2011, which is also provided by the WHO, discloses that the suicide rate is beyond 16 per 100, 000 people in some countries. That is, one suicides oneself every 40 seconds.

essary for an analyst to understand the UML [8] visualization knowledge.

for four cities in Europe.

4 Decision Support Systems

next higher e-Health generation.

with our proposed process.

can be regarded as the motivation for suicide.

**2. Background**

The mission of the Taiwan Suicide Prevention Centre (TSPC) is tried to decrease the suicide rate. However, it was found that adolescents and young adults, for example, aged 15 to 24, are difficult for the TSPC to intervene to help them from the viewpoint of the TSPC manag‐ ers. Therefore, the TSPC's chairman called for a brainstorm meeting to invite a group of en‐ thusiastic scholars and participants to find some feasible solutions to reduce the suicide rate of Taiwanese adolescents and young adults in 2010 [6]. Although there are several alterna‐ tive solutions for the TSPC to promote the suicide prevention capacity, it is hard for the TSPC to decide which solution is the best one and worthwhile to invest substantial resour‐ ces. Note that these alternatives are belonging to the preliminary decision, not final decision, in the TSPC meeting.

It is worth mentioning that the social networking, such as the Facebook, is one of the alter‐ natives in the TSPC meeting. Anyhow, the social-networking service includes diverse online social platforms such as the Facebook, the Twitter, and the Google+. Hence it is necessary for us to be carefully considerate whether moving suicide prevention toward social net‐ working, to propose our analysis outcomes, and to assist the TSPC chairman to make a final decision.

This study utilizes a requirements elicitation and analysis process, the XREAP [5] , to ex‐ plore whether moving the SP to the SN is feasible. Because the XREAP is an exhausted ap‐ proach to elicit the requirements from the execution domain, the outcomes of the XREAP tool will illustrate the overview of the required requirements. Therefore, the implicit needs will be extracted from the XREAP process, and the decision-makers will own most options and situations for further decision-making.

Furthermore, the XREAP tool is a requirements engineering utility that is based on the XREAP concept and is designed by Java programming language [5]. It is suitable for soft‐ ware-development process and acts as a role for eliciting and analysing the software re‐ quirements from users as well as generates a series of use case diagrams for further design [17]. Here our research team tries to adopt the XREAP tool in the decision support process, to generate a complex use case diagram, and to assist the TSPC managers to decide.

Explicitly, The XREAP tool owns four states and the presenting state, including another four sub-states such as TreeView, GridView, UseCaseDiagram, and XMLView. Meanwhile, the editing state includes two sub-states: TreeEditor and GridEditor. That is, the analyst can maintain the requirements between TreeView and GridView states and then transform to a use case diagram as well as save as the XML text format. The XML text format can also be read as the input file of the XREAP tool for further revising. The following sections illustrate

Whether Moving Suicide Prevention Toward Social Networking: A Decision Support Process with XREAP Tool

http://dx.doi.org/10. 5772/51985

7

Firstly, the PMI thinking style is shown in Figure 2 and categories the requirements by three views of points, including plus, minus, and interesting. This method will not only collect the stakeholder's requirements, but also elicit the implicit requirements that do not mention by users. The first step of the PMI thinking is concentrated on the plus view of points. That is, the analyst must focus on the positive facet of the user requirements and record all require‐ ments from users, and all possible derived needs. Similarly, the analyst has to utilize the

On the other hand, the APC thinking includes three parts: alternatives, possibilities, and choice. That is, the analyst has to focus on the requirements, actors, and use cases to con‐ sider the specific requirement for alternatives, feasibility, and decision-making. To facili‐ tate the alternative generation, the APC thinking suggests at least ten progressive questions for further analyze and is shown in Figure 3. The illustration of detail processing is also

same thinking process to achieve the minus and interesting facets, respectively.

**Figure 2.** Graphical user interface for user requirements by categories

listed as below.

these approaches, respectively.

**3.2. Input requirements**

In Summary, the research team utilizes the XREAP tool to assist us to elicit, collect, and ana‐ lyse the all possible requirements from the TSPC managers, users of social networking, in‐ formation technologies, health promotion concepts, and social environment. That is, the XREAP tool is acted as a decision support process tool.

#### **3.1. Execution procedures**

This step utilizes at least two approaches. The first method enhances the requirements anal‐ ysis integrity by plus-minus-interesting (PMI) and alternative-possibilities-choice (APC) thinking styles. The second one bases on both UML and Extensible Markup Language (XML) standards to cope with all activities. To understand the execution procedures of the XREAP tool, Figure 1 utilizes the UML state diagram to illustrate the execution procedures of the XREAP tool.

**Figure 1.** Execution procedures of the XREAP tool

Explicitly, The XREAP tool owns four states and the presenting state, including another four sub-states such as TreeView, GridView, UseCaseDiagram, and XMLView. Meanwhile, the editing state includes two sub-states: TreeEditor and GridEditor. That is, the analyst can maintain the requirements between TreeView and GridView states and then transform to a use case diagram as well as save as the XML text format. The XML text format can also be read as the input file of the XREAP tool for further revising. The following sections illustrate these approaches, respectively.

#### **3.2. Input requirements**

[17]. Here our research team tries to adopt the XREAP tool in the decision support process,

In Summary, the research team utilizes the XREAP tool to assist us to elicit, collect, and ana‐ lyse the all possible requirements from the TSPC managers, users of social networking, in‐ formation technologies, health promotion concepts, and social environment. That is, the

This step utilizes at least two approaches. The first method enhances the requirements anal‐ ysis integrity by plus-minus-interesting (PMI) and alternative-possibilities-choice (APC) thinking styles. The second one bases on both UML and Extensible Markup Language (XML) standards to cope with all activities. To understand the execution procedures of the XREAP tool, Figure 1 utilizes the UML state diagram to illustrate the execution procedures

to generate a complex use case diagram, and to assist the TSPC managers to decide.

XREAP tool is acted as a decision support process tool.

**3.1. Execution procedures**

6 Decision Support Systems

of the XREAP tool.

**Figure 1.** Execution procedures of the XREAP tool

Firstly, the PMI thinking style is shown in Figure 2 and categories the requirements by three views of points, including plus, minus, and interesting. This method will not only collect the stakeholder's requirements, but also elicit the implicit requirements that do not mention by users. The first step of the PMI thinking is concentrated on the plus view of points. That is, the analyst must focus on the positive facet of the user requirements and record all require‐ ments from users, and all possible derived needs. Similarly, the analyst has to utilize the same thinking process to achieve the minus and interesting facets, respectively.

**Figure 2.** Graphical user interface for user requirements by categories

On the other hand, the APC thinking includes three parts: alternatives, possibilities, and choice. That is, the analyst has to focus on the requirements, actors, and use cases to con‐ sider the specific requirement for alternatives, feasibility, and decision-making. To facili‐ tate the alternative generation, the APC thinking suggests at least ten progressive questions for further analyze and is shown in Figure 3. The illustration of detail processing is also listed as below.

Explanation (E): it asks for an analyst to describe the specific requirement again in order to confirm that the analyst understands the user illustration.

pensate the aforementioned drawback, try to elicit all possible requirements from users, and

Whether Moving Suicide Prevention Toward Social Networking: A Decision Support Process with XREAP Tool

http://dx.doi.org/10. 5772/51985

9

In order to minimize the problem-solving scale, the decision-makers can utilize the di‐ vide-and-conquer methodology to decomposite the original problem to several independ‐ ent sub-problems. That is, decision-makers can integrate all sub-problems' solutions into one solution and make their final decision. For example, the social networking is a large field and includes several famous social websites such as the Facebook, the Twitter, the Google+, etc. Therefore, we can divide our original problem from "whether moving sui‐ cide prevention toward social networking" into "whether moving suicide prevention to‐ ward the Facebook social networking", "whether moving suicide prevention toward the Twitter social networking", and "whether moving suicide prevention toward the Google

As shown in Figure 4, a use case diagram is transformed from the XREAP grid collection format. In order to simplify the decision scope, we utilize the divide-and-conquer method to decompose our original problem and only consider the Facebook social networking part in this chapter. Therefore, Figure 4 shows the use case diagram of "whether moving suicide prevention toward the Facebook social networking. "Note that the human icon represents an actor, the oval icon means use case, and the line represents the association between actors and use cases. Normally, the use case diagram is one-to-one mapping to the XREAP grid collection phase. Note that the use case diagram also reflects the original requirements listed

**Figure 4.** Use case diagram of whether moving suicide prevention toward the Facebook social networking

The analyst can modify the use case diagram. However, the reverse flow is not allowed by the XREAP tool. That is, the analyst has to roll back to the grid collection phase to revise the

maintain the requirements' integrity during system analysis phase.

+ social networking. "

**3.3. Export use case diagram**

in the XREAP tree collection phase.

Assumption (A): the analyst has to confirm the specific requirement's executive constraint.

Viewpoint (V): the analyst has to consider the specific requirement by different view of points.

Problem (P): the analyst might propose any questions for specific requirement.

Review (R): the analyst bases on the E, A, V, and P illustrations to consider again for specific requirement.

Design (D): the analyst summaries the R illustration and proposes a solution to handle the specific requirement.


**Figure 3.** Sample collection of use requirements by grid

Note that the APC processing focuses on the specific requirement that is categorized by the PMI method. If an analyst finds any new requirement during the APC's first five steps, the analyst should insert a fresh requirement to the requirements list. Then the analyst can elicit the actor from the specific requirement. Every actor also needs PMI and APC processing as well as it is possible to find some implicit actors. At last, the analyst can derive the use case from the specific requirements by treating the PMI and APC thinking. Similarly, it is also possible for an analyst to discover some implicit use cases during the whole processing.

This kind of the analysis means prevents an analyst only to elicit the favorable requirements from users and ignores the implicit requirements inadvertently. Ordinarily, most of the ex‐ ceptions might be disregarded by the analyst during the system analysis phase and be in‐ serted during the programming phase, even maintenance phase. Such a conventional analysis processing might waste a lot of time revising the system architecture and let the system weaker than original version. Accordingly, the PMI and APC processing can com‐ pensate the aforementioned drawback, try to elicit all possible requirements from users, and maintain the requirements' integrity during system analysis phase.

In order to minimize the problem-solving scale, the decision-makers can utilize the di‐ vide-and-conquer methodology to decomposite the original problem to several independ‐ ent sub-problems. That is, decision-makers can integrate all sub-problems' solutions into one solution and make their final decision. For example, the social networking is a large field and includes several famous social websites such as the Facebook, the Twitter, the Google+, etc. Therefore, we can divide our original problem from "whether moving sui‐ cide prevention toward social networking" into "whether moving suicide prevention to‐ ward the Facebook social networking", "whether moving suicide prevention toward the Twitter social networking", and "whether moving suicide prevention toward the Google + social networking. "

#### **3.3. Export use case diagram**

Explanation (E): it asks for an analyst to describe the specific requirement again in order to

Assumption (A): the analyst has to confirm the specific requirement's executive constraint. Viewpoint (V): the analyst has to consider the specific requirement by different view of

Review (R): the analyst bases on the E, A, V, and P illustrations to consider again for specific

Design (D): the analyst summaries the R illustration and proposes a solution to handle the

Note that the APC processing focuses on the specific requirement that is categorized by the PMI method. If an analyst finds any new requirement during the APC's first five steps, the analyst should insert a fresh requirement to the requirements list. Then the analyst can elicit the actor from the specific requirement. Every actor also needs PMI and APC processing as well as it is possible to find some implicit actors. At last, the analyst can derive the use case from the specific requirements by treating the PMI and APC thinking. Similarly, it is also possible for an analyst to discover some implicit use cases during the whole processing.

This kind of the analysis means prevents an analyst only to elicit the favorable requirements from users and ignores the implicit requirements inadvertently. Ordinarily, most of the ex‐ ceptions might be disregarded by the analyst during the system analysis phase and be in‐ serted during the programming phase, even maintenance phase. Such a conventional analysis processing might waste a lot of time revising the system architecture and let the system weaker than original version. Accordingly, the PMI and APC processing can com‐

Problem (P): the analyst might propose any questions for specific requirement.

confirm that the analyst understands the user illustration.

points.

requirement.

8 Decision Support Systems

specific requirement.

**Figure 3.** Sample collection of use requirements by grid

As shown in Figure 4, a use case diagram is transformed from the XREAP grid collection format. In order to simplify the decision scope, we utilize the divide-and-conquer method to decompose our original problem and only consider the Facebook social networking part in this chapter. Therefore, Figure 4 shows the use case diagram of "whether moving suicide prevention toward the Facebook social networking. "Note that the human icon represents an actor, the oval icon means use case, and the line represents the association between actors and use cases. Normally, the use case diagram is one-to-one mapping to the XREAP grid collection phase. Note that the use case diagram also reflects the original requirements listed in the XREAP tree collection phase.

**Figure 4.** Use case diagram of whether moving suicide prevention toward the Facebook social networking

The analyst can modify the use case diagram. However, the reverse flow is not allowed by the XREAP tool. That is, the analyst has to roll back to the grid collection phase to revise the specific sources of the requirements' illustration and then further transform a new use case diagram to replace the original diagram. Although such a modification procedure of the XREAP tool is not so convenience, anyhow, it urges the analysts to reconsider and confirm their requirements carefully, not unceremoniously.

task is a small task. However, our proposed process provides a visual and standard diagram

Shape Items Weight Number Calculation

Association lines 1 11 11 <<include>> dependency line 2 5 10 <<extend>> association line 2 1 2 Generalization relationship line 1 3 3 Calculation of complexity weight 58

> Problem Complexity Score Possible Assessment Less than 100 Tiny problem 101~200 Small problem 201~300 Medium problem 300~400 Large problem Greater than 400 Huge problem

Based on our empirical outcomes, the following arguments will focus on five significant concerns: limitation of the XREAP tool, the ratio of requirements elicitation, divide-and-con‐

quer, complexity assessment, and decision-making guidelines.

Generic use case(s) 5 1 5 Included use case(s) 3 5 15 extended use case(s) 2 1 2

Whether Moving Suicide Prevention Toward Social Networking: A Decision Support Process with XREAP Tool

http://dx.doi.org/10. 5772/51985

11

Related to one use case 1 2 2 Related to 2~4 use cases 2 1 2 Related to 5~8 use cases 3 1 3 Related to 9+ use cases 5 0 0 Generalized 1 3 3

for decision-makers to make their decision through understanding of their problems.

Use case

Actor

**Table 1.** Statistical table of shape items for utilizing XREAP tool

**Table 2.** Problem complexity assessment range

**5. Discussion**
