Project Requirements

We gathered the requirements using an iterative approach. We began creating requirements using the minutes collected from our very first meeting. However, these requirements were for multiple projects and our mentors believed that this was not feasible. Hence in the following meeting with our client, we chose one project and was provided with an initial set of requirements by our client. Unfortunately these requirements were difficult to process. This prompted us to develop our own version of the requirements. Then following discussions with our client, we made modifications to the requirements and finalised the MoSCoW rating to develop the following list:

Functional Requirements (Updated)

ID Requirements MoSCoW rating
RQ1 The application must be a data dictionary editor Must Have
RQ2 The application must be able to create a data dictionary (logical and physical) for the required system e.g. for a customer system or for a payroll system Must Have
RQ3 The application should be able to load the data dictionary for OpenEyes into the application Could Have
RQ4 The application should ensure that the data dictionaries can handle the versioning of systems Should Have
RQ5 The application should ensure that the data dictionary items can be mapped to other items of another system or version Should Have
RQ6 The application should allow the extraction of data dictionary data The client decided that they no longer required this feature Should Have
RQ7 The application should be able to compare data models Should Have
RQ8 The application could be able to load XML schema data The client opted to stick with manual input and focus on the main functionality of the application Could Have
RQ9 The application should allow a data dictionary to be mapped to other data dictionaries Should Have
RQ10 The application must have a screen for loading data dictionaries Must Have
RQ11 The application must have a screen that enables the maintenance of a single data dictionary (adding and removal of columns) Must Have
RQ12 The application must have a screen for loading data Must Have
RQ13 The application must have a screen that gives access to the default mapping tool Must Have

Non-Functional Requirements

ID Requirements MoSCoW rating
RQ14 The application must accept systems and data dictionaries as its data (content for the application) Must Have
RQ15 The application must define a data model for our data dictionary Must Have
RQ16 The data dictionary should have have the ability to be augmented (can grow in size) Should Have

Use-Cases

After developing the requirements, we implemented use case analysis in order to help us understand the system we are designing. The use cases enabled us to generate initial ideas as to how particular functionalities can be achieved. We explored the interaction between the system and the users of the application.

Personas

Scenarios

Typical users for our application would be technical teams within the healthcare industry. Examples of this are:

"Jason needs to compare the column names for "Date of Birth" in the latest OpenEyes data dictionary and the latest data dictionary for the Royal College of Ophthalmologists' NOD. He can do this by creating a mapping between the two data points using the mapping tool within Maple which will show a clear relationship between Date of Birth from both systems. He can then compare what he needs."

"Pete has just noticed that there is an additional data point within the OpenEyes data dictionary he is using which isn't within the data points display in Maple. He can add this by adding a single data point on the data points display page for the version of OpenEyes he is working on."

"The team working on the OpenEyes system have moved on to a new version. They can mark this within Maple by marking the old version as inactive and creating a new, active version with the data points that they need."