Open access

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

Written By

Po-Hsun Cheng, Heng-Shuen Chen, Wen-Chen Chiang and Hsin- Ciang Chang

Submitted: March 5th, 2012 Published: October 17th, 2012

DOI: 10.5772/51985

Chapter metrics overview

1,843 Chapter Downloads

View Full Metrics

1. Introduction

Although social workers provide diverse assistance, the incidence of suicide is still high in Taiwan [20]. However, due to cultural characteristics, people who own suicidal ideation often reluctant to seek help as well as passively wait for help. The social networking (SN) becomes one of the social tools. Some users utilize it to interact with their friends and express their mood or feelings in the SN.

Several real suicide cases are rescued by notifying from the messages of the SN [1] [2] , however, the evidence is not enough for endorsing amount of the budgets to emerge the suicide prevention (SP) process to the SN. Therefore, it is a problem for decision-makers to decide which user groups are the targets for the SP in the SN, what kind of the messages are keys for the SP and have to be extracted from the SN [10] , when is the best time to emerge the SP process to the SN, which region is the best place for trial, and which SN is the best adopting platform? The decision-making is not only medical-oriented, but also technology-oriented.

This chapter illustrates an explicit decision support process for management of software requirements elicitation and analysis. As Shi, et al.[15] illustrates their research outcomes by utilizing the Unified Modeling Language (UML) as the basis of their decision support system to help decision-makers to distinguish regional environmental risk zones. Similarly, Sutcliffe, et al.[19] tries to visualize the requirements by user-centred design (UCD) methods in their visual decision support tools to support public health professionals in their analysis activities. Our proposed process, Extensible Requirements Elicitation and Analysis Process (XREAP) [5] , is revised from part of the use case driven approach [7] [9]. Therefore, it is necessary for an analyst to understand the UML [8] visualization knowledge.

On the other hand, Perini and Susi extend their decision support system research to the environmental modelling and software field [11]. Their research approach is to hold interviews of producers, technicians anddomain experts as well as acquisition of domain documentation. Meanwhile, they also try to analyse actor roles and strategic dependencies among actors, 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 for four cities in Europe.

Based on the knowledge sharing concept, Shafiei [14] and his team members develop a multi-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 possible 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 multiple sources, lead to cost-effective use of drugs, improve patients’ quality of life, and optimize 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 next higher e-Health generation.

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 requirements 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 with our proposed process.


2. Background

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 can be regarded as the motivation for suicide.

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 available 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. These countries, for example, at least include Lithuania (31. 5), South Korea (31. 0), Japan (24. 4), Russia (23. 5), Finland (18. 3), Belgium (17. 6), France (17. 0), Sweden (15. 8), South Africa (15. 4), and Hong Kong (15. 2) [20]. Therefore, the suicide behaviour is one of the implicit social problems for many countries.

Based on the above, it is necessary to reduce the suicidal ideation in order to decrease the occurrence of suicide. Shneidman, et al.[16] proposed a three-level prevention model to do exactly that. The model is divided into three program response categories: prevention, intervention and postvention. Within this three-level prevention model, prevention is to increase the protection factor and decrease the risk factor. The research team tries to focus on the second level of the three-level prevention model and analyses, whether moving SP to SN can elicit the high-risk group so that early detection can lead to early treatment.


3. Decision support process

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 managers. Therefore, the TSPC’s chairman called for a brainstorm meeting to invite a group of enthusiastic 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 alternative 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 resources. 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 alternatives 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 networking, 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 explore whether moving the SP to the SN is feasible. Because the XREAP is an exhausted approach 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 software-development process and acts as a role for eliciting and analysing the software requirements 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.

In Summary, the research team utilizes the XREAP tool to assist us to elicit, collect, and analyse the all possible requirements from the TSPC managers, users of social networking, information 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 analysis 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

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 requirements 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 consider the specific requirement for alternatives, feasibility, and decision-making. To facilitate 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.

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 exceptions might be disregarded by the analyst during the system analysis phase and be inserted 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 compensate 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 divide-and-conquer methodology to decomposite the original problem to several independent 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 suicide prevention toward social networking” into “whether moving suicide prevention toward 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

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.


4. Results

This research utilizes the grounded theory to prove the correction rate of the XREAP tool. The success of the XREAP approach can be indirectly proven by the comparison results of traditional method and the XREAP tool. The XREAP tool is a method for requirements elicitation and analysis. Alternatively, it can be adopted to list the problem variables, extract the implicit problems, and analyze the at-hand solutions.

The more association lines among actors and use cases, the more complex relationship with the requirements of the specific problem-solving. For example, a use case diagram with twenty association lines among its actors and use cases is absolutely complex than the other use case diagram with only five association lines.

As the use case diagram shown in Figure 4, the decision-makers can count on the numbers of the association lines among actors and use cases. That is, there are seven use cases and six actors that are associated with eleven directed association lines and five <<include>> dependency lines, one <<extend>> association line, and three generalization relationship linesfor implementing a virtual suicide prevention gatekeeper, Socio-Health, in the Facebook environment. Note that this case study only covers the adolescents and young adults in Taiwan.

The statistical table of shape items is also shown in Table 1 and the final score of the complexity calculation of the Socio-Health problem is 58. Note that the shape item of the use case is categorized as three levels: generic use case(s), included use case(s), and extended use case(s). A generic use case can include and/or extend one more use case. Therefore, the generic use case might own higher complexity weight than the included and extended use case(s). Based on our implementation experiences, the complexity of most included use cases is higher than the one of most extended use cases. Similarly, the shape item of the actor is also categorized into six levels: related to one use case, related to 2~4 use cases, related to 5~8 use cases, related to at least nine use cases, and generalized. The corresponding weights are assigned by their implementation complexities.

Table 2 shows the problem complexity assessment range for the analyst to estimate the final calculation of the XREAP tool. Based on the Table 2, the complexity score is below 100 is categorized as tiny problem and correspondingly easy to handle.

Based on complexity assessment for such a use case diagram, we can decide to execute these implementation tasks. Correspondingly, the generic decision-making by intuition for the same task might be also similar to the result for utilizing the XREAP tool and consider this task is a small task. However, our proposed process provides a visual and standard diagram for decision-makers to make their decision through understanding of their problems.

Shape ItemsWeightNumberCalculation
Use caseGeneric use case(s)515
Included use case(s)3515
extended use case(s)212
ActorRelated to one use case122
Related to 2~4 use cases212
Related to 5~8 use cases313
Related to 9+ use cases500
Association lines11111
<<include>> dependency line2510
<<extend>> association line212
Generalization relationship line133
Calculation of complexity weight58

Table 1.

Statistical table of shape items for utilizing XREAP tool

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

Table 2.

Problem complexity assessment range


5. Discussion

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-conquer, complexity assessment, and decision-making guidelines.

5.1. Limitation of the XREAP tool

As the utilization of the XREAP tool to make some decisions for several projects, we found some pros and cons. They are listed in Table 3 for the analyst further reference. Furthermore, the XREAP tool owns some limitations. For example, the mind brainstorm function supports graphical user interface for user requirements by categories. That is, every PMI item can provide a number of the entries. However, the arrangement of the requirements’ map is not so concise that some of the requirements might be overlapped each other, and the screen will be too small to browse while every PMI item is more than 15 entries.

Is cross-platformIs a bit slow during execution
Is visualizationIs not beautiful on graphic user interface
Supports mind brainstorm functionIs not easy for utilization
Can transfer from requirements to a use case diagramCannot reverse transfer from a use case diagram to requirements
Can exchange use case diagram with the XML metadata interchange standardCan only exchange with the Star UML tool
Can be utilized as a decision support toolDoes not yet include the calculation function of the complexity assessment

Table 3.

Pros and cons of the XREAP tool

5.2. The ratio of requirements elicitation

Fundamentally, the requirements elicitation is the first phase in our decision-making process. As most of the decision-makers known, the higher ratio of requirements elicitation is obtained, the better quality of decision-making will be executed. If decision-makers are eager for the highest quality of their decision-making, it is necessary for them to try to focus on the requirements elicitation phase. Fortunately, our proposed methodology can elicit required information from users by utilizing the XREAP tool. Meanwhile, the implicit information for persons, actions, tenancies, environment and equipment can be elicited by the XREAP tool as possible as it could extract from user requirements by both PMI and APC methods. Furthermore, all requirements are listed within a tabular frame in the XREAP tool, and it is convenient for the decision-makers to browse and review. As compared with other decision-making tools, we believe the XREAP tool can supply the exhaustive capability to elicit user requirements.

5.3. Divide-and-conquer

If the problem is too large to solve, it is feasible for problem-solvers to utilize the divide-and-conquer approach to decompose the problem into several smaller problems. If the smaller problem is still too large to handle, problem-solverscan divide such a problem again until they can cope with the scope of the problem. The divide-and-conquer methodology is widely used in several fields such as computer science. Similarly, the decision-makers are problem-solvers. Therefore, decision-makers can try to analyze the small problems one by one and integrate all solutions into a total solution for original problem.

5.4. Complexity assessment

Generally speaking, the complexity assessment is not an easy task. As our proposed methodology illustration, the complexity can be counted for the numbers of the actors and use cases in the final use case diagram. The more actors and use cases, the more complex interwoven network for requirements will be presented. Although the roughly count of the use cases and actors might be too simple to convey the complexity of the requirements, such a computation method is easy for decision-makers to confirm the existing input requirements quickly and repeatedly. However, it is possible for researchers to propose better complexity assessment for the XREAP tool in the future. Based on the complexity assessment results, decision-makers can conveniently make their decision.

5.5. Decision-making guidelines

Although the XREAP tool is one of the simple software for eliciting requirements, it can become a supplement to improve the decision-making quality for decision-makers. Normally, it is necessary for decision-makers to refer the decision-making guidelines that are gathered by other decision-makers. As the popularity of the Internet, it is possible for decision-makers to share and revise their decision-making guidelines in the cloud. Based on the knowledge management experiences from the healthcare field in 2008 [4] , it is feasible to share, revise and manage the specific knowledge through the network. That is, if the decision-making guidelines are utilized and revised by most decision-makers, then the optimal decision-making process will be generated.


6. Conclusion

It is a smart behaviour for decision-makers to spend more time to realize the whole views of the problems and solutions before they make wise decisions. However, an effective decision analysis tool is hard to obtain. The XREAP software is an optional choice for assisting decision-makers. As the tool results said, the SP service can be spread through SN, and it explores and assists the potential subjects who present the trend of suicide ideation.



The authors would like to thank all research colleagues in the National Suicide Prevention Centre, Taipei, Taiwan. The authorsalso express thanks for partial financial support from the National Science Council, Taiwan, under grant number NSC101-2220-E017-001.


  1. 1. Alao AO. , Soderberg M. , Pohl EL. and Alao AL. Cybersuicide: Review of the Role of the Internet on Suicide. Cyberpsychology and Behavior 2006; 9(4) 489-493.
  2. 2. Biddle L. , Donovan J. , Hawton K. , Kapur N. and Gunnell D. Suicide and the Internet. British Medical Journal 2008; 336(7648) 800-802.
  3. 3. Cercone N. , An X. , Li, J. , Gu Z. and An A. Finding Best Evidence for Evidence-based Best Practice Recommendations in Health Care: The Initial Decision Support System Design. Knowledge and Information Systems 2011; 29(1)159-201.
  4. 4. Cheng PH. , Chen SJ. , LaiJS. and Lai F. A Collaborative Knowledge Management Process for Implementing Healthcare Enterprise Information Systems. IEICE Transactions on Information and Systems 2008; E91-D(6) 1664-1672.
  5. 5. Cheng PH. , Chang HC. and Chang FH. Another extensible requirements elicitation and analysis method. In: AI-Dabass D. , Tandayya P. , Yonus J. , Heednacram A. and Ibrahim Z. (eds. ) IEEE CICSyN2012: proceedings of the 4th International Conference on Computational Intelligence, Communication Systems and Networks, IEEE CICSyN2012, 24-26 July, 2012, Phuket, Thailand. Los Alamitos: IEEE Computer Society’s Conference Publishing Services; 2012.
  6. 6. Chiang WC. , Cheng PH. , Su MJ. , Chen HS. , Wu SW. and Lin JK. Socio-Health with personal mental health records: suicidal-tendency observation system on Facebook for Taiwanese adolescents and young adults. Shyu CR. (eds. ) IEEE HEALTHCOM2011: proceedings of the IEEE 13th International Conference on e-Health Networking, Applications and Services, IEEE HEALTHCOM2011, 13-15 June, 2011, Columbia, Missouri, USA. Leonia: EDAS Conference Services; 2011.
  7. 7. Fox CJ. Introduction to Software Engineering Design: Processes, Principles and Patterns with UML2. New York: Addison-Wesley;2006.
  8. 8. Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd Edition. New York: Addison-Wesley Professional; 2004.
  9. 9. Ivar J. Object-oriented Software Engineering: A Use Case Driven Approach. New York: ACM Press; 1997.
  10. 10. Manning CD. , Raghavan P. and Schutze H. An Introduction to Information Retrieval. New York: Cambridge University Press; 2008.
  11. 11. Perini A. and Susi A. Understanding the Requirements of a Decision Support System for Agriculture: An Agent-Oriented Approach. Environmental Modelling and Software Journal 2004; 19(9)821-829.
  12. 12. Rudd MD. , Joiner T. and Rajab MH. Treating Suicidal Behavior: An Effective, Time-limited Approach. New York: Guilford Press; 2004.
  13. 13. Schlobinski S. , Denzer R. , Frysinger S. , Güttler R. and Hell T. Vision and Requirements of Scenario-Driven Environmental Decision Support Systems Supporting Automation for End Users. In: Qian Z. , Cao L. , Su W. , Wang T. , and Yang H. (ed. ) Environmental Software Systems, Frameworks of Environment, IFIP Advances in Information and Communication Technology, Vol. 359. New York: Springer;2011. p. 51-63.
  14. 14. Shafiei F. , Sundaram D. and Piramuthu S. Multi-enterprise Collaborative Decision Support System. Expert Systems with Applications 2012; 39(9)7637-7651.
  15. 15. Shi W. and Zeng W. Analysis and Design on Environmental Risk Zoning Decision Support System Based on UML. In: Qian Z. , Cao L. , Su W. , Wang T. , and Yang H. (ed. ) Recent Advances in Computer Science and Information Engineering Vol. 2, Lecture Notes in Electrical Engineering, Vol. 125. New York: Springer; 2012. p. 799-804.
  16. 16. Shneidman ES. , Farberow NL. and Litman RE. The Psychology of Suicide: A Clician's Guide to Evaluation and Treatment. New York: Jason Aronson Inc. Publishers; 1977.
  17. 17. Sommerville I. Software Engineering, 9th Edition. London: Addison Wesley; 2010.
  18. 18. World Health Organizatoin. WHO: Suicide Prevention: SUPRE. http://www. who. int/mental_health/prevention/suicide/suicideprevent/en/ (accessed 17 December 2011).
  19. 19. Sutcliffe A. , Bruijn de O. , Thew S. , Buchan I. , Jarvis P. , McNaugh J. and Procter R. Developing Visualization-based Decision Support Tools for Epidemiology. Information Visualization 2012, DOI: 10. 1177/1473871612445832. (accessed 15 June 2012).
  20. 20. Taiwan Suicide Prevention Center. TSPC. http://www. tspc. doh. gov. tw (accessed 7 Janruary 2012).

Written By

Po-Hsun Cheng, Heng-Shuen Chen, Wen-Chen Chiang and Hsin- Ciang Chang

Submitted: March 5th, 2012 Published: October 17th, 2012