Analysis
With the initial requirements captured, the focus turned to analysis. Use cases were reviewed to identify requirements common to SURF and WETN. Data items were reviewed to ensure that data was available to support the use cases and any data protection issues were documented. Interactions of the portal with other systems were identified and the mapping of the data items to IMS Enterprise Service objects was defined. The analysis was captured as a set of storyboard documents, one for each use case, which the team used to guide the construction of the services and channels.
Throughout the development process it was important to identify any commonality between SURF and WETN wherever it existed. The key aim in the development of the web services was to create common services that could be used by both SURF and WETN. The WETN situation differed from SURF because the WETN development was more a case of implementing a new system than integrating existing systems and databases. The plan of implementing the portal at SURF and then cascading to WETN meant that the requirements were less well defined for WETN during this first analysis exercise. The WETN requirements would be analysed further in the Elaboration Phase with the benefit of feedback from the SURF analysis.
Use Case Analysis
Each use case was reviewed with the project partners to determine to what extent the services could already be provided by the NIIMLE outputs and what new services needed to be developed. Common services were identified where possible. The screens were reviewed to identify the data items that would be required from the student records databases.
Data Analysis
Data items were reviewed to:
-
determine whether the data existed for each partner
-
identify the location of the data at each partner if it did exist
-
identify and document any institution or business rules that governed or restricted the data that could be used
The process involved meeting with the MIS managers at the partner institutions to discuss data availability and constraints. In some cases the required data did not exist and the scope of the use case was modified accordingly or the use case abandoned.
Data Mapping
For each of the use cases, a mapping between the data fields being retrieved from the student records system and the IMS Enterprise Web services data structures was created. The IMS Enterprise Web services information models and specs were consulted to determine the best fit with the SUNIWE data. The mapping was captured in the storyboard documents, one for each use case. IMS Enterprise Web services operations that needed to be developed to support the use cases (in addition to the existing NIIMLE operations) were identified.
Interactions With Other Systems
Interactions with other systems were investigated. These centred around library and VLE systems. Details are in the project final report.
System Scope
As some use cases were ruled out through lack of data, the scope of the system narrowed until the list of use cases that were to be implemented was the following:
SURF
-
Authenticate Learner
-
Enrol Onto VLE Group
-
View and Change College Personal Information
-
View and Change University Personal Information
-
View and Launch VLE Modules
-
View College Course List
-
View Module List Module Information And E-Resources
WETN
-
Enrol Onto VLE Group
-
View and Change University Personal Information
-
View and Launch VLE Modules
-
View Module List Module Information And E-Resources
Storyboard Documents
For each remaining use case, a storyboard document was created. Each storyboard document included a section for each screen. Each screen section included:
-
a list of IMS Enterprise Web services operations required to get the data for the screen
-
a picture of the mock screen
-
a table containing details of the screen including the names of files associated with the screen, possible interactions of the user and user interface elements and actions
-
a table mapping the screen data items to the IMS Enterprise objects and database fields
The storyboard documents when complete acted as the primary reference for the developers during the rest of the development process. An example extract from a storyboard document for the Module List View screen is shown below

