Transcript-Specific Expression Profiles Derived from Sequence-Based Analysis of Standard Microarrays

Background: Alternative mRNA processing mechanisms lead to multiple transcripts (i.e. splice isoforms) of a given gene which may have distinct biological functions. Microarrays like Affymetrix GeneChips measure mRNA expression of genes using sets of nucleotide probes. Until recently probe sets were not designed for transcript specificity. Nevertheless, the reanalysis of established microarray data using newly defined transcript-specific probe sets may provide information about expression levels of specific transcripts. Methodology/Principal Findings: In the present study alignment of probe sequences of the Affymetrix microarray HGU133A with Ensembl transcript sequences was performed to define transcript-specific probe sets. Out of a total of 247,965 perfect match probes, 95,008 were designated ‘‘transcript-specific’’, i.e. showing complete sequence alignment, no crosshybridization, and transcript-, not only gene-specificity. These probes were grouped into 7,941 transcript-specific probe sets and 15,619 gene-specific probe sets, respectively. The former were used to differentiate 445 alternative transcripts of 215 genes. For selected transcripts, predicted by this analysis to be differentially expressed in the human kidney, confirmatory real-time RT-PCR experiments were performed. First, the expression of two specific transcripts of the genes PPM1A (PP2CA_HUMAN and P35813) and PLG (PLMN_HUMAN and Q5TEH5) in human kidneys was determined by the transcriptspecific array analysis and confirmed by real-time RT-PCR. Secondly, disease-specific differential expression of single transcripts of PLG and ABCA1 (ABCA1_HUMAN and Q5VYS0_HUMAN) was computed from the available array data sets and confirmed by transcript-specific real-time RT-PCR. Conclusions: Transcript-specific analysis of microarray experiments can be employed to study gene-regulation on the transcript level using conventional microarray data. In this study, predictions based on sufficient probe set size and foldchange are confirmed by independent mean

The Care Work of Access

Current approaches to AI and Assistive Technology (AT) often foreground task completion over other encounters such as expressions of care. Our paper challenges and complements such task-completion approaches by attending to the care work of access—the continual affective and emotional adjustments that people make by noticing and attending to one another. We explore how this work impacts encounters among people with and without vision impairments who complete tasks together. We find that bound up in attempts to get things done are concerns for one another and how well people are doing together. Reading this work through emerging disability studies and feminist STS scholarship, we account for two important forms of work that give rise to access: (1) mundane attunements and (2) noninnocent authorizations. Together these processes work as sensitizing concepts to help HCI scholars account for the ways that intelligent ATs both produce access while sometimes subverting people with disabilities

Characterisation of protein-truncating and missense variants in PALB2 in 15 768 women from Malaysia and Singapore

Funder: National University Cancer Institute, Singapore; FundRef: http://dx.doi.org/10.13039/501100011105Background: Rare protein-truncating variants (PTVs) in partner and localiser of BRCA2 (PALB2) confer increased risk to breast cancer, but relatively few studies have reported the prevalence in South-East Asian populations. Here, we describe the prevalence of rare variants in PALB2 in a population-based study of 7840 breast cancer cases and 7928 healthy Chinese, Malay and Indian women from Malaysia and Singapore, and describe the functional impact of germline missense variants identified in this population. Methods: Mutation testing was performed on germline DNA (n=15 768) using targeted sequencing panels. The functional impact of missense variants was tested in mouse embryonic stem cell based functional assays. Results: PTVs in PALB2 were found in 0.73% of breast cancer patients and 0.14% of healthy individuals (OR=5.44; 95% CI 2.85 to 10.39, p<0.0001). In contrast, rare missense variants in PALB2 were not associated with increased risk of breast cancer. Whereas PTVs were associated with later stage of presentation and higher-grade tumours, no significant association was observed with missense variants in PALB2. However, two novel rare missense variants (p.L1027R and p.G1043V) produced unstable proteins and resulted in a decrease in homologous recombination-mediated repair of DNA double-strand breaks. Conclusion: Despite genetic and lifestyle differences between Asian and other populations, the population prevalence of PALB2 PTVs and associated relative risk of breast cancer, are similar to those reported in European populations

Global patient outcomes after elective surgery: prospective cohort study in 27 low-, middle- and high-income countries.

BACKGROUND: As global initiatives increase patient access to surgical treatments, there remains a need to understand the adverse effects of surgery and define appropriate levels of perioperative care. METHODS: We designed a prospective international 7-day cohort study of outcomes following elective adult inpatient surgery in 27 countries. The primary outcome was in-hospital complications. Secondary outcomes were death following a complication (failure to rescue) and death in hospital. Process measures were admission to critical care immediately after surgery or to treat a complication and duration of hospital stay. A single definition of critical care was used for all countries. RESULTS: A total of 474 hospitals in 19 high-, 7 middle- and 1 low-income country were included in the primary analysis. Data included 44 814 patients with a median hospital stay of 4 (range 2-7) days. A total of 7508 patients (16.8%) developed one or more postoperative complication and 207 died (0.5%). The overall mortality among patients who developed complications was 2.8%. Mortality following complications ranged from 2.4% for pulmonary embolism to 43.9% for cardiac arrest. A total of 4360 (9.7%) patients were admitted to a critical care unit as routine immediately after surgery, of whom 2198 (50.4%) developed a complication, with 105 (2.4%) deaths. A total of 1233 patients (16.4%) were admitted to a critical care unit to treat complications, with 119 (9.7%) deaths. Despite lower baseline risk, outcomes were similar in low- and middle-income compared with high-income countries. CONCLUSIONS: Poor patient outcomes are common after inpatient surgery. Global initiatives to increase access to surgical treatments should also address the need for safe perioperative care. STUDY REGISTRATION: ISRCTN5181700

From object-oriented to goal-oriented requirements analysis

The first object-oriented analysis techniques were proposed more than 10 years ago. The Object-Oriented Systems Analysis (OOSA) technique The growing influence of object-oriented programming on programming practice has led to the rise of a new paradigm for system and software requirements analysis, popularly known as object-oriented analysis (OOA). This paradigm adopts ideas from object-oriented programming and blends them with ideas from semantic data modeling and knowledge representation (notably semantic networks) into a modeling framework that is more powerful than traditional techniques such as data flow diagrams, structured analysis, and the like. COMMUNICATIONS OF THE ACM Requirements Analysis Goal-oriented and object-oriented analysis should be seen as complementary, the former focusing on the early stages of requirements analysis … the latter on late stages. 32 January 1999/Vol. 42, No. 1 COMMUNICATIONS OF THE ACM tice of systems analysis was characterized 10 years ago by a mixed bag of isolated modeling techniques (data flow diagrams, ER diagrams, state transition diagrams) that were used to capture the rich information that needs to be modeled, analyzed and understood before a software system is actually built. These techniques generally offered little help for structuring requirements models, to ensure that they were readily understandable, extensible and amenable to analysis. In contrast to this situation, OOA techniques offer a coherent framework which integrates a comprehensive set of modeling concepts for capturing declarative, behavioral, and interactive aspects of a system. 1 In addition, OOA techniques strongly support two structuring mechanisms, generalization and aggregation, in terms of which a modeler can organize and manage the immense amount of information captured by her models. A final important reason for the popularity of OOA techniques rests with the popularity of OO programming itself. Earlier requirements analysis techniques were inspired by, and founded on, structured programming concepts. In a programming world that is increasingly turning to object orientation, such techniques seemed out of date and had to be replaced. Since OOA techniques are intended for requirements analysis, 2 the models built in terms of these techniques comprise models of a real-world environment within which the new system will eventually operate, that is, an environment consisting of people, work processes, material things, software systems and the like. For example, Any modeling technique &quot;colors&quot; the view of its users because it offers only a limited number of primitive concepts for modeling its intended subject matter. The kinds of information that can be captured by the analyst are then characterized by precisely these concepts. The purpose of this article is to offer a sketch of the concept of the softgoal, for modeling and analyzing non-functional requirements, and to show how this can contribute toward a foun- Non-functional requirements (or quality attributes, qualities, or more colloquially &quot;-ilities&quot;) are global qualities of a software system, such as flexibility, maintainability, usability, and so forth. Such requirements are usually stated only informally, are often controversial (for example, management wants a secure system but staff desires user-friendliness), are difficult to enforce during design and implementation, and are diffcult to validate. Not surprisingly, unmet quality requirements constitute an important failure factor for software development projects. Modeling the World Since computer applications must ultimately be useful in the real world, modeling a part of that world, the application domain, has been a major preoccupation in several areas of computer science, such as data modeling in databases, knowledge representation in artificial intelligence (AI) and requirements modeling in software engineering. Over the years, hundreds of notations, often referred to as conceptual or semantic models, have been proposed for such modeling tasks. In general, a conceptual model comprises a collection of: • Primitive terms, which specify a set of basic building blocks for constructing symbol structures; • Structuring mechanisms for assembling and organizing symbol structures; • Primitive operations, for constructing and querying symbol structures; • General integrity rules, which define the set of consistent symbol structure states, or changes of states. These are accompanied by interpretation rules and usage guidelines. For example, Peter Chen&apos;s original ER model offers Entity, Relationship and Attribute as primitive terms, supports a limited form of classification (because entities and relationships are instances of entity and relationship types), offers primitive operations for creating new entity or relationship types or instances thereof, and supports cardinality constraints for relationships, such as &quot;every child has up to two parents.&quot; An important extension of the model, the Extended Entity-Relationship model, supports all the features of the ER model and also offers generalization and aggregation for structuring purposes. The ER model was proposed at the first Very Large Databases conference in 1975. The ER model is one of the first semantic data models because it assumes that the domain to be modeled consists of entities and relationships, unlike the relational model, which makes no assumptions at all about the domain. In the field of AI, semantic networks were proposed almost 10 years earlier by Ross Quillian&apos;s Ph. D. dissertation (completed in 1966), as suitable symbolic models of human memory. Semantic networks are directed, labeled graphs whose nodes represent concepts while links represent binary relationships. Quillian&apos;s proposal actually supported generalization as a structuring mechanism, and also provided for inheritance of attributes. Semantic networks were upgraded with procedural attachments and other facilities to form frame-based knowledge representation languages. Along a different path, they were combined with a logical sublanguage for specifying formal properties of defined classes and/or tokens. Description logics, a popular form of knowledge representation language today, originated from this line of research. In software engineering, Douglas Ross proposed the Structured Analysis and Design Technique (SADT ™ ) in the mid-1970s as a &quot;language for communicating ideas&quot; Requirements engineering was born in the mid1970s, partly thanks to Ross and his SADT proposal, and partly thanks to others who established through empirical study that &quot;the rumored &apos;requirements problems&apos; are a reality.&quot; The case for world modeling during requirements analysis was eloquently articulated Satisficing Softgoals Imagine that you have been asked by your client to conduct a requirements analysis for a new system 3 intended to support various office functions within its organization, including scheduling meetings. Right from the start, the client is very clear that any new system should be highly usable, flexible and adaptable to the work patterns of individual users and that its introduction should create as little disruption as possible. You understand that your task calls for modeling the objects and activities in the operational environment of the new system, including people, office procedures, information items being created or used and the like. You also know that other stakeholders in the project need to be consulted, such as the office staff for whom the new --goal G is satisficed when all of G1,G2,…,Gn are satisficed and there is no negative evidence against it; --goal G is unsatisficed and there is one of G 1,G2,…,Gn is unsatisficed and there is no positive evidence for it. --goal G is satisficed when one of G 1,G2,…,Gn is satisficed and there is no negative evidence against it; --goal G is unsatisficeable if all of G 1,G2,…,Gn are unsatisfieceable and there is no positive evidence for it. --goal G 1 contributes positively to the satisficing of goal G2. --goal G 1 contributes negatively to the satisficing of goal G2. system is intended. But how are you going to deal with the client&apos;s objectives of having a usable and flexible system? You realize that these objectives are all-important, but unfortunately get little guidance from your favorite OOA technique on what to model and how to include these objectives in your analysis. To bring flexibility and usability into the requirements analysis process, we first need some way to represent them, along with their respective interrelationships. For purposes of illustration, we adopt the Non-Functional Requirements (NFR) framework, which centers around the notion of softgoal The concept of goal is used extensively in AI where a goal is satisfied absolutely when its subgoals are satisfied, and that satisfaction can be automatically established by an algorithm. To support the relative, ill-defined, tentative and contradictory nature of non-functional requirements, however, we need a looser notion of goal. Softgoals are goals that do not have a clear-cut criterion for their satisfaction. We will say that softgoals are satisficed 4 when there is sufficient positive and little negative evidence for this claim, and that they are unsatisficeable when there is sufficient negative evidence and little positive support for their satisficeability. Sometimes the evidence is sufficiently strong for the decision for softgoal satisficeability to be made automatically without human intervention. In other cases, when there is weak or conflicting evidence, the decision may have to be made interactively by the stakeholders in the requirements analysis process. In analyzing non-functional requirements, one does not analyze softgoals independently of one another, but rather in relation to each other. Two obvious types of relationships are the AND and OR goal relationships comparable to the ones traditionally used in AI planning. There can also be other, looser relationships in which one softgoal subsumes, prevents, or contributes to the fulfillment of another. For this discussion, we will only use the four relationships shown in Non-functional requirements analysis. This form of analysis begins with softgoals that represent non-functional requirements agreed upon by the stakeholders, say Usability, Flexibility, etc. Then one refines these by using decomposition methods. These methods may be generic, derived from general expertise about flexibility, security, and the like. They may also be domain-specific (specific to meeting scheduling), or even project-specific (decided upon jointly by the stakeholders of a project). Let&apos;s consider Flexibility (of the new system) for illustration purposes. This softgoal might be decomposed to two other softgoals: the first, FlexibleWorkPatterns[staff], calls for flexibility in the work patterns allowed by the new system for all staff, while the second, FutureGrowth, calls for a system architecture that can accommodate future growth. Along similar lines, the FlexibleWorkPatterns softgoal is further decomposed to SharingOfInformation, and TaskSwitching, among staff. Using such an analysis, the softgoal tree structure for Flexibility is created, as shown in The goal tree structure in the lower half of the Conclusion We have placed OOA techniques within the context of other notations and methods intended to model aspects of the real world. On that basis, we have argued that adoption of an alternative set of primitive modeling concepts, such as those of softgoal and goal, can lead to a rather different kind of analysis than those advocated by OOA techniques. Moreover, this kind of analysis is very important because it deals with non-functional requirements and relates them to functional ones. As readers may have already concluded, goal-oriented analysis focuses on the description and evaluation of alternatives and their relationship to the organizational objectives behind a software development project. As many within the requirements engineering research community have argued, capturing these interdependencies between organizational objectives and the detailed software requirements can facilitate the tracing of the origins of requirements, and can help make the requirements process more thorough, complete, and consistent. Preliminary empirical studies suggest that goal-oriented analysis can indeed lead to a more complete requirements definition than OOA techniques can. Moreover, our own experiences in analyzing the requirements and architectural design for a large (telecommunications) software system confirm that goal-oriented analysis can greatly facilitate and rationalize early phases of the software design process. Of course, OOA techniques still have a place within a requirements analysis process even if one adopts goal-oriented analysis. After all, OOA models define the objects and activities mentioned in the detailed requirements for the new system. So goaloriented analysis and OOA should be seen as complementary, the former focusing on the early stages of requirements analysis and on the rationalization of the development process, the latter on late stages of requirements analysis. The KAOS methodology gives an excellent sample of how the two types of analysis coexist and complement each other. Traditionally, requirements analysis practice has been driven by the programming paradigm of the day. Thus, in the days of structured programming, structured analysis ruled, whereas today interest is shifting to OOA. Given the importance of requirements analysis to the success of any large software development project, perhaps it is time to turn things around: suppose we let the concepts and techniques of goal-oriented analysis drive the design and implementation techniques that follow. What would such a software development methodology look like? Perhaps it will be based on software architectures that share some of the characteristics of human organizations and be grounded in the concepts of agent, goal, and of course softgoal. Actually, agent programming is gaining in popularity as the programming paradigm for network computing, so the possibility of a new development methodology grounded on goal-oriented analysis and agent-based design and implementation may not be as farfetched as it might seem. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Reference

From object-oriented to goal-oriented requirements analysis

The first object-oriented analysis techniques were proposed more than 10 years ago. The Object-Oriented Systems Analysis (OOSA) technique The growing influence of object-oriented programming on programming practice has led to the rise of a new paradigm for system and software requirements analysis, popularly known as object-oriented analysis (OOA). This paradigm adopts ideas from object-oriented programming and blends them with ideas from semantic data modeling and knowledge representation (notably semantic networks) into a modeling framework that is more powerful than traditional techniques such as data flow diagrams, structured analysis, and the like. tice of systems analysis was characterized 10 years ago by a mixed bag of isolated modeling techniques (data flow diagrams, ER diagrams, state transition diagrams) that were used to capture the rich information that needs to be modeled, analyzed and understood before a software system is actually built. These techniques generally offered little help for structuring requirements models, to ensure that they were readily understandable, extensible and amenable to analysis. In contrast to this situation, OOA techniques offer a coherent framework which integrates a comprehensive set of modeling concepts for capturing declarative, behavioral, and interactive aspects of a system. 1 In addition, OOA techniques strongly support two structuring mechanisms, generalization and aggregation, in terms of which a modeler can organize and manage the immense amount of information captured by her models. A final important reason for the popularity of OOA techniques rests with the popularity of OO programming itself. Earlier requirements analysis techniques were inspired by, and founded on, structured programming concepts. In a programming world that is increasingly turning to object orientation, such techniques seemed out of date and had to be replaced. COMMUNICATIONS OF THE ACM Since OOA techniques are intended for requirements analysis, 2 the models built in terms of these techniques comprise models of a real-world environment within which the new system will eventually operate, that is, an environment consisting of people, work processes, material things, software systems and the like. For example, Any modeling technique &quot;colors&quot; the view of its users because it offers only a limited number of primitive concepts for modeling its intended subject matter. The kinds of information that can be captured by the analyst are then characterized by precisely these concepts. The purpose of this article is to offer a sketch of the concept of the softgoal, for modeling and analyzing non-functional requirements, and to show how this can contribute toward a foun- Non-functional requirements (or quality attributes, qualities, or more colloquially &quot;-ilities&quot;) are global qualities of a software system, such as flexibility, maintainability, usability, and so forth. Such requirements are usually stated only informally, are often controversial (for example, management wants a secure system but staff desires user-friendliness), are difficult to enforce during design and implementation, and are diffcult to validate. Not surprisingly, unmet quality requirements constitute an important failure factor for software development projects. Modeling the World Since computer applications must ultimately be useful in the real world, modeling a part of that world, the application domain, has been a major preoccupation in several areas of computer science, such as data modeling in databases, knowledge representation in artificial intelligence (AI) and requirements modeling in software engineering. Over the years, hundreds of notations, often referred to as conceptual or semantic models, have been proposed for such modeling tasks. In general, a conceptual model comprises a collection of: • Primitive terms, which specify a set of basic building blocks for constructing symbol structures; • Structuring mechanisms for assembling and organizing symbol structures; • Primitive operations, for constructing and querying symbol structures; • General integrity rules, which define the set of consistent symbol structure states, or changes of states. These are accompanied by interpretation rules and usage guidelines. For example, Peter Chen&apos;s original ER model offers Entity, Relationship and Attribute as primitive terms, supports a limited form of classification (because entities and relationships are instances of entity and relationship types), offers primitive operations for creating new entity or relationship types or instances thereof, and supports cardinality constraints for relationships, such as &quot;every child has up to two parents.&quot; An important extension of the model, the Extended Entity-Relationship model, supports all the features of the ER model and also offers generalization and aggregation for structuring purposes. The ER model was proposed at the first Very Large Databases conference in 1975. The ER model is one of the first semantic data models because it assumes that the domain to be modeled consists of entities and relationships, unlike the relational model, which makes no assumptions at all about the domain. In the field of AI, semantic networks were proposed almost 10 years earlier by Ross Quillian&apos;s Ph. D. dissertation (completed in 1966), as suitable symbolic models of human memory. Semantic networks are directed, labeled graphs whose nodes represent concepts while links represent binary relationships. Quillian&apos;s proposal actually supported generalization as a structuring mechanism, and also provided for inheritance of attributes. Semantic networks were upgraded with procedural attachments and other facilities to form frame-based knowledge representation languages. Along a different path, they were combined with a logical sublanguage for specifying formal properties of defined classes and/or tokens. Description logics, a popular form of knowledge representation language today, originated from this line of research. In software engineering, Douglas Ross proposed the Structured Analysis and Design Technique (SADT ™ ) in the mid-1970s as a &quot;language for communicating ideas&quot; Requirements engineering was born in the mid1970s, partly thanks to Ross and his SADT proposal, and partly thanks to others who established through empirical study that &quot;the rumored &apos;requirements problems&apos; are a reality.&quot; The case for world modeling during requirements analysis was eloquently articulated Satisficing Softgoals Imagine that you have been asked by your client to conduct a requirements analysis for a new system 3 intended to support various office functions within its organization, including scheduling meetings. Right from the start, the client is very clear that any new system should be highly usable, flexible and adaptable to the work patterns of individual users and that its introduction should create as little disruption as possible. You understand that your task calls for modeling the objects and activities in the operational environment of the new system, including people, office procedures, information items being created or used and the like. You also know that other stakeholders in the project need to be consulted, such as the office staff for whom the new --goal G is satisficed when all of G1,G2,…,Gn are satisficed and there is no negative evidence against it; --goal G is unsatisficed and there is one of G 1,G2,…,Gn is unsatisficed and there is no positive evidence for it. --goal G is satisficed when one of G 1,G2,…,Gn is satisficed and there is no negative evidence against it; --goal G is unsatisficeable if all of G 1,G2,…,Gn are unsatisfieceable and there is no positive evidence for it. --goal G 1 contributes positively to the satisficing of goal G2. --goal G 1 contributes negatively to the satisficing of goal G2. system is intended. But how are you going to deal with the client&apos;s objectives of having a usable and flexible system? You realize that these objectives are all-important, but unfortunately get little guidance from your favorite OOA technique on what to model and how to include these objectives in your analysis. To bring flexibility and usability into the requirements analysis process, we first need some way to represent them, along with their respective interrelationships. For purposes of illustration, we adopt the Non-Functional Requirements (NFR) framework, which centers around the notion of softgoal The concept of goal is used extensively in AI where a goal is satisfied absolutely when its subgoals are satisfied, and that satisfaction can be automatically established by an algorithm. To support the relative, ill-defined, tentative and contradictory nature of non-functional requirements, however, we need a looser notion of goal. Softgoals are goals that do not have a clear-cut criterion for their satisfaction. We will say that softgoals are satisficed 4 when there is sufficient positive and little negative evidence for this claim, and that they are unsatisficeable when there is sufficient negative evidence and little positive support for their satisficeability. Sometimes the evidence is sufficiently strong for the decision for softgoal satisficeability to be made automatically without human intervention. In other cases, when there is weak or conflicting evidence, the decision may have to be made interactively by the stakeholders in the requirements analysis process. In analyzing non-functional requirements, one does not analyze softgoals independently of one another, but rather in relation to each other. Two obvious types of relationships are the AND and OR goal relationships comparable to the ones traditionally used in AI planning. There can also be other, looser relationships in which one softgoal subsumes, prevents, or contributes to the fulfillment of another. For this discussion, we will only use the four relationships shown in Non-functional requirements analysis. This form of analysis begins with softgoals that represent non-functional requirements agreed upon by the stakeholders, say Usability, Flexibility, etc. Then one refines these by using decomposition methods. These methods may be generic, derived from general expertise about flexibility, security, and the like. They may also be domain-specific (specific to meeting scheduling), or even project-specific (decided upon jointly by the stakeholders of a project). Let&apos;s consider Flexibility (of the new system) for illustration purposes. This softgoal might be decomposed to two other softgoals: the first, FlexibleWorkPatterns[staff], calls for flexibility in the work patterns allowed by the new system for all staff, while the second, FutureGrowth, calls for a system architecture that can accommodate future growth. Along similar lines, the FlexibleWorkPatterns softgoal is further decomposed to SharingOfInformation, and TaskSwitching, among staff. Using such an analysis, the softgoal tree structure for Flexibility is created, as shown in The goal tree structure in the lower half of the Conclusion We have placed OOA techniques within the context of other notations and methods intended to model aspects of the real world. On that basis, we have argued that adoption of an alternative set of primitive modeling concepts, such as those of softgoal and goal, can lead to a rather different kind of analysis than those advocated by OOA techniques. Moreover, this kind of analysis is very important because it deals with non-functional requirements and relates them to functional ones. As readers may have already concluded, goal-oriented analysis focuses on the description and evaluation of alternatives and their relationship to the organizational objectives behind a software development project. As many within the requirements engineering research community have argued, capturing these interdependencies between organizational objectives and the detailed software requirements can facilitate the tracing of the origins of requirements, and can help make the requirements process more thorough, complete, and consistent. Preliminary empirical studies suggest that goal-oriented analysis can indeed lead to a more complete requirements definition than OOA techniques can. Moreover, our own experiences in analyzing the requirements and architectural design for a large (telecommunications) software system confirm that goal-oriented analysis can greatly facilitate and rationalize early phases of the software design process. Of course, OOA techniques still have a place within a requirements analysis process even if one adopts goal-oriented analysis. After all, OOA models define the objects and activities mentioned in the detailed requirements for the new system. So goaloriented analysis and OOA should be seen as complementary, the former focusing on the early stages of requirements analysis and on the rationalization of the development process, the latter on late stages of requirements analysis. The KAOS methodology gives an excellent sample of how the two types of analysis coexist and complement each other. Traditionally, requirements analysis practice has been driven by the programming paradigm of the day. Thus, in the days of structured programming, structured analysis ruled, whereas today interest is shifting to OOA. Given the importance of requirements analysis to the success of any large software development project, perhaps it is time to turn things around: suppose we let the concepts and techniques of goal-oriented analysis drive the design and implementation techniques that follow. What would such a software development methodology look like? Perhaps it will be based on software architectures that share some of the characteristics of human organizations and be grounded in the concepts of agent, goal, and of course softgoal. Actually, agent programming is gaining in popularity as the programming paradigm for network computing, so the possibility of a new development methodology grounded on goal-oriented analysis and agent-based design and implementation may not be as farfetched as it might seem. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Reference

Enhancing Sexuality Education for Young Adolescents Through Serious Gaming

Adolescents in Hong Kong have become more liberal and receptive towards sex in recent decades. Research findings indicated an increase in the rate of premarital sex among Hong Kong adolescents. They also held a more permissive attitude towards premarital sex than in the past. Sex education, however, is not always well organised and delivered in schools. A recent survey indicated that Hong Kong teachers found themselves not well equipped to teach the sex education and lacked relevant learning and teaching resources. Current educational resources for sex education are mainly designed to be used in classroom. They are typically composed of presentation slides and lesson plans of group based activities. As discussion on sex is still taboo in Chinese society, self-learning resources can supplement classroom teaching. Unfortunately they are rarely offered online or tailored for mobile access. Available online resources are mostly text-based and are unattractive to the most vulnerable adolescent group. This project aims to address this gap by developing an interactive game playable on Facebook, iPad and the web to educate and equip young adolescents with reliable knowledge and positive attitudes towards sex and relationship and life skills necessary for making wise decisions regarding love and sex in a fun way. The game, titled Making Smart Choices, consists of five mini-games, adopting a Chinese user interface, offering different scenarios where players exact their decisions in their chosen virtual characters and learn in the process. The mini-games aim to help young adolescents: • to gain better self-understanding for establishing a healthy love relationship; • to learn to set and maintain intimate boundaries; • to understand about sexual impulse and considerations in deciding whether to have sex or not; • to acquire safer sex knowledge including awareness of self-protection, contraceptives, prevention of sexually transmissible diseases, and emergency contraception; and • to be aware of available options and support services in case of unplanned pregnancies. To evaluate the effectiveness and acceptance of the game among young adolescents, a series of workshops and game sessions were conducted for more than 1,100 junior students (in Secondary 1 to Secondary 3) in six co-ed secondary schools. Students’ knowledge about safer sex was collected before and after playing the game. Participants were also asked to complete a questionnaire regarding their perception of the value of the game and whether they found the game interesting and user-friendly. Focus group interviews were arranged with selected students in order to gather their detailed feedback. The collected data were analysed using SPSS and the results showed that after playing the game, students’ sex knowledge improved with a high medium effect size. The improvement was found in every junior secondary level. The survey respondents perceived that the game had helped them enhance their critical thinking, decision-making and ability to seek help regarding matters related to love and sexuality in addition to knowledge and proper attitudes towards relationship and sex. They were mostly receptive to the game, finding it fun to play with and describing the content as “interesting”, “interactive”, “informative”, “close to reality” and “applicable”