The three main health insurance providers each have a vast range of options available among their insurance offerings, making it difficult for the consumer to choose between them. Business Rules Engines (BREs) such as JBoss Drules use forward chaining to make decisions based on a set of business rules (Rulebase).

The aim of this project would be to create a Rulebase that would enable the consumer to choose a set of options aligned with their particular circumstances, needs and objectives. Since rules are easily maintained, the project could later form the basis of a useful website.

This is similar to NP04. Different providers have different payment options based on usage, the balance of calls versus text, amount of data downloading, etc. so it can be tricky to choose the most suitable plan. Business Rules Engines (BREs) such as JBoss Drules use forward chaining to make decisions based on a set of business rules (Rulebase).

The aim of this project would be to create a Rulebase for a BRE to enable the consumer to enter their details and preferences and receive a recommendation of which provider's payment plan they should choose. Since rules are easily maintained, it would possible to create a system that keeps up to date up with new offers, providers, etc.

There is a considerable body of literature on the research topics of program families, software product lines (SPL) and domain (requirements) engineering. Techniques such as FODA (Feature-Oriented Domain Analysis) are well-established for modelling systems at a high level but do not support specifying the requirements. An application domain such as scheduling contains a variety of software problems and solutions exhibiting common features (aka commonalities) as well as variable features (aka variabilities).   This project would allow a good student to contribute to this area by investigating a specific application domain and identifying the commonalities and the variabilities within it.

The ultimate aim of this project is to develop an effective way of specifying domain requirements in terms of the common and the variable features and in particular the quality requirements. The following approach is suggested, focusing on the domain of scheduling (generally, the allocation of resources to tasks): Study the features and the quality requirements that are common to an ample set of scheduling systems. Identify the features that are always included in such systems and the features that are considered desirable and those that are optional in that application domain. Reverse-engineer the features into a comprehensive requirements specification for a family of scheduling systems. Your specification template will be based on an existing requirements specification template, but modified to distinguish effectively the common requirements from the variable ones and to show the interdependencies of the variable requirements, based on your findings. A project that should stretch the right student.

The concept of a Stakeholder is a very important one in requirements engineering: a requirement is anything that matters to a stakeholder and stakeholders are all the people who matter in a system. In playing this proposed game, the player would enter a world populated with different types of Stakeholders and would navigate through a series of encounters and meetings to elicit and discover a target set of requirements for a target system. The target system will be one invented by the game designer and involve some unpredictable but logically coherent functionality hat they cannot be guessed by the player. The idea of the game is to illustrate the relationship between the goals, requirements, constraints, business rules and other sources of requirements for a system. It could be implemented as a single-player game enhanced with some suitable multi-media aspects, or for the very ambitious student, a multiple role player game where players have to cooperate as well as compete in order to achieve the desired result.

Even in the best-run requirements engineering projects, non-functional requirements such as Security rarely receive the attention they deserve, resulting in vague, broad requirements which are not much use. There are several reasons for this. One reason is the unavoidable confusion between the requirements and the solutions in this area; another is the lack of suitable formats or templates for expressing security requirements.

The student undertaking this project needs to have a very good knowledge of both security threats and solutions and a willingness to learn about requirements engineering, its significance, its strengths and its difficulty.

The project itself will be a knowledge-based tool to help elicit and validate the precise security requirements appropriate for a system or product, yielding testable, well-specified specifications.

Requirements specifications are often regarded as dull, monotonous and impenetrable, especially when they are specified to an acceptable level of detail. Various interesting efforts have been made to make requirements visual, but so far requirements visualization remains a goal rather than a solution. One reason for this is that system and software requirements, far from being monotonous, are multi-facetted. For example, the Volere template lists 27 different types of things that need to be included in a requirements specification, such as stakeholders, mandated constraints and risks. The Volere list doesn't some include other important aspects such as goals and user tasks.

The student undertaking this project would choose a subset of the aspects that pertain to requirements and formulate the different ways in which they relate to each other. Visualization in this context is about visualizing relationships.

The project would use and extend Shu Wan's 2009/10 FYP Postfuse.  The main work of the project would be in formulating relationships (links) between and among the various requirements aspects in the underlying requirements specification, so it suits a student with a strong capacity for conceptual thinking.