Miki: a wiki for synchronous modeling of software requirements

Eliciting a high quality requirements model that can be traced down to implementations is a challenge. Keeping models updated for evolving software systems is a further challenge. Formal modelling methods are one approach - but one that is too rigid and costly for many small software engineering companies [1]. We propose a light-weight alternative, using a wiki as the synchronous bridge between requirements capture and more formal modeling features of the IDE such as Eclipse

Using problem descriptions to represent variabilities for context-aware applications

This paper investigates the potential use of problem descriptions to represent and analyse variability in context-aware software products. By context-aware, we refer to recognition of changes in properties of external domains, which are recognised as affecting the behaviour of products. There are many reasons for changes in the operating environment, from fluctuating resources upon which the product relies, to different operating locations or the presence of objects. There is an increasing expectation for software intensivedevices to be context-aware which, in turn, adds further variability to problem description and analysis. However, we argue in this paper that the capture of contextual variability on current variability representations and analyses has yet to be explored. We illustrate the representation of this type of variability in a pilot study, and conclude with lessons learnt and an agenda for further work

Composing features by managing inconsistent requirements

One approach to system development is to decompose the requirements into features and specify the individual features before composing them. A major limitation of deferring feature composition is that inconsistency between the solutions to individual features may not be uncovered early in the development, leading to unwanted feature interactions. Syntactic inconsistencies arising from the way software artefacts are described can be addressed by the use of explicit, shared, domain knowledge. However, behavioural inconsistencies are more challenging: they may occur within the requirements associated with two or more features as well as at the level of individual features. Whilst approaches exist that address behavioural inconsistencies at design time, these are overrestrictive in ruling out all possible conflicts and may weaken the requirements further than is desirable. In this paper, we present a lightweight approach to dealing with behavioural inconsistencies at run-time. Requirement Composition operators are introduced that specify a run-time prioritisation to be used on occurrence of a feature interaction. This prioritisation can be static or dynamic. Dynamic prioritisation favours some requirement according to some run-time criterion, for example, the extent to which it is already generating behaviour

A Study of the Relationship Between Teachers’ Perception Towards the Principal’s Transformational Leadership Style and Teachers’ Job Satisfaction at St. John’s Private High School, Pathein, Myanmar

This study was intended to determine the relationship between teachers’ perceptions towards the principal’s transformational leadership style and teachers’ job satisfaction at St. John’s Private High School, Pathein, Myanmar. The research was quantitative and correlational in design and used the Multifactor Leadership Questionnaire (MLQ) and the Minnesota Satisfaction Questionnaire (MSQ). Means and Standard Deviation, and the Pearson Product Moment Correlation Coefficient were used to analyze the data for testing the hypothesis. The 60 respondents from St. John’s Private High School completed the questionnaire. This study found that the level of teachers’ perception towards the principal’s transformational leadership style was high, the teachers were overall highly satisfied with their job. The result of the Pearson correlation coefficient for the r-value was .675 with a significance value of .001. The result showed that teachers had a positive relationship between the principal’s transformational leadership style and job satisfaction at St. John’s Private High School, Pathein, Myanmar. The study provided the researcher with valuable insight and knowledge into the role of the principal's transformational leadership style and teachers' job satisfaction practiced in the school

The Impact of Organizational Learning and Organizational Innovation on Organizational Performance: A Case of an Internet Service Provider in Myanmar

This independent research has three main objectives: (1) to examine the factors impacting organizational performance, (2) to examine the impact of organizational learning on organizational innovation, (3) to help management to encourage and support organizational learning and oganizational innovation among employees. The researcher used quantitative questionnaires distributed to 141 people and interviewed 13 people. The researcher employed Simple Linear Regression and Multiple Linear Regression to analyze data from the questionnaire and contents analysis for the interviews. The quantitative findings indicated that organizational innovation has more impact on organizational performance than organizational learning. Moreover, the researcher found that organizational learning impacts organizational innovation while the qualitative findings implied that the organization should promote organizational learning and innovation to improve organizational performance. Based on the findings, it is recommended that (1) the organization should establish better and proper reward policies for new ideas and innovations proposed by employees and (2) it should provide more well-designed wellness programs to retain employees and create multiple recruiting strategies to attract talents and (3) the organization should encourage employees to improve their professional competencies actively

On the structure of problem variability: From feature diagrams to problem frames

Requirements for product families are expressed in terms of commonality and variability. This distinction allows early identification of an appropriate software architecture and opportunities for software reuse. Feature diagrams provide intuitive notations and techniques for representing requirements in product line development. In this paper, we observe that feature diagrams tend to obfuscate three important descriptions: requirements, domain properties and specifications. As a result, feature diagrams do not adequately capture the problem structures that underlie variability, and inform the solution structures of their complexity. With its emphasis on separation of the three descriptions, the problem frames approach provides a conceptual framework for a more detailed analysis of variability and its structure. With illustrations from an example, we demonstrate how problem frames analysis of variability can augment feature diagrams

Are your lights off? Using problem frames to diagnose system failures

This paper reports on our experience of investigating the role of software systems in the power blackout that affected parts of the United States and Canada on 14 August 2003. Based on a detailed study of the official report on the blackout, our investigation has aimed to bring out requirements engineering lessons that can inform development practices for dependable software systems. Since the causes of failures are typically rooted in the complex structures of software systems and their world contexts, we have deployed and evaluated a framework that looks beyond the scope of software and into its physical context, directing attention to places in the system structures where failures are likely to occur. We report that (i) Problem Frames were effective in diagnosing the causes of failures and documenting the causes in a schematic and accessible way, and (ii) errors in addressing the concerns of biddable domains, model building problems, and monitoring problems had contributed to the blackout

Towards explaining rebuttals in security arguments

The satisfaction of software security requirements can be argued using supporting facts and domain assumptions. Sometimes, these facts or assumptions may be questioned, as more knowledge about vulnerabilities becomes available. This results in rebuttals that can be derived from the new information. In this paper, we outline an extension of our OpenArgue tool with an explanation facility that makes a rebuttal more transparent by showing, step by step, why the original security argument does not hold. We achieve this by using the output of the Alligator theorem prover, which constructs explicit and checkable proof objects. We illustrate the feasibility of this approach by applying it to an existing case study of a PIN entry device which involves a security argument that has been rebutted. The output of the prover enables us to unpack the logical reasoning behind the rebuttal at a much greater level of detail. This promises to be useful for argument explanation

An aspect-oriented approach to relating security requirements and access control

Affecting multiple parts in software systems, security requirements often tangle with functional requirements. In order to separate crosscutting concerns and increase modularity, we propose to represent security requirements as aspects that can be woven into functional requirements. Using problem frames to model the functional requirements, weaving is achieved by composing the modules representing security aspects with the requirement models. Moreover, we provide guidance on how such security aspects are structured to implement a particular access control solution. As a result, such security aspects become reusable solution patterns to refine the structure of security-related problem