In 2012, I was invited to become part of a group developing a specification and architectural design for a digital learning environment for Scottish schools. This came to be called Glow Plus but, in the book, I have called it the iLearn system.
The iLearn system is a digital learning environment used to support learning in schools with students from age 4 to 18. It is intended to replace an existing system (Glow) that was specially built for the purpose and which includes its own applications for e-mail, etc. Glow was a closed system where it was impossible for users to introduce their own applications. It became less and less used as the facilities in freely available systems were far superior to those offered in the closed system.
One of the most important requirements for the iLearn system was that it should be an open system that could easily accommodate new features and existing services. We aimed to achieve this by designing the system so that everything was a service and that, with appropriate permissions, users could replace pre-specified services with their own service version. This approach also allowed us to deal with the complexity of integrating with existing network management systems (local areas had different policies on which web sites could be visited by school students, depending on age and content) and school administration systems. By creating a service interface to these systems, different underlying systems could be accommodated.
There are three types of service in the system:
- Utility services that provide basic application-independent functionality and which may be used by other services in the system. Utility services are usually developed or adapted specifically for this system.
- Application services that provide specific applications such as email, conferencing, photo sharing etc. and access to specific educational content such as scientific films or historical resources. Application services are external services that are either specifically purchased for the system or are available freely over the Internet.
- Configuration services that are used to adapt the environment with a specific set of application services and do define how services are shared between students, teachers and their parents.
In the course of this work, I tried to use a number of different software engineering methods including viewpoint oriented requirements, use-cases, and UML modeling. These all failed. The only approach which worked was user stories, which people without a technical background could easily relate to. The main reasons why these software engineering methods failed were firstly (and most importantly) users did not care about the system requirements and did not have time to interact with the development team. Secondly, stakeholders simply did not understand the terminology or approaches used – terms such as use-case simply made no sense to them.
The first issue, that of disengaged users, is one that is increasingly common. There is so much cheap or free software available, that users can develop their own way of working and simply do not see the point of corporate system. In some respects, this is because they do not understand issues such as security but in others, the problem is that the benefits of corporate system are not for the end-user but for the organization. It is perfectly reasonable for end-users not to wish to take time out from their normal job to discuss new systems which offer them no real benefits. Consequently, requirements engineering for systems that have a diverse user base is becoming increasingly difficult.
Use of this case study in teaching
This case study of a digital learning system can be used in a number of different ways:
- In discussions of the use of user stories as a means of deriving system requirements. User stories were extensively used here by the development team to get an overall picture of how the system might be used.
- In lectures about architecture, where the layered architecture of the system can be discussed. Elements in the architecture are implemented as replaceable services.
- In general discussions of systems of systems. This was designed as a system of systems with the digital learning system interacting with other network management and administrative systems.
- In discussions of sociotechnical systems and complexity. In this system, the technical complexity is relatively low but the governance complexity is very high.
Supporting documents
We developed and published a set of scenarios for the iLearn system (here called Glow Plus) and invited comments on them. These were published on a Scottish Government site but, unfortunately, they are no longer online. Contact me if you need further examples of the scenarios that we developed.
This is an article that describes the sociotechnical problems that we encountered when designing the iLearn environment Designing for the Don’t Cares: A story about a sociotechnical system (external link)
My original document proposing a service-oriented architecture for the iLearn system. iLearn – an architectural proposal