Nina is a postgraduate student at the University of Southampton. She is a curious person and has a lot of different interests. Therefore, she studied multiple subjects. She heard other students that they are looking for a supervisor, but she wants something more: she wants an excellent one! Continue reading “Storyboard”
Persona 3: John
John is a professor in the University of Southampton, he is an academic researcher, he believes that finding a good and suitable research group members would have a great results. Hence, he is happy to join a platform like MeetingOfMinds.
Persona 2: Stave
He is an iPhD student and finished his first year and already has a supervisor for his PhD thesis. Satve is active in the social media and willing to share his experience in finding the proper supervisor.
Persona 1: Garkie
When Garkie begun her second semester of the MSc program, she started looking for a supervisor for her summer thesis, she found this process is difficult. She has heard about a new platform which can help her in this process. Therefore:
The following three personas of MeetingOfMinds platform have been introduced and defined here and they will be used in our scenarios posts. We have considered that our users are either post-graduate student or professors at the University of Southampton. We described the academic interests, learning and research style and supervision style for each persona. Also, we have described that each user fit in which position of Rogers adoption curve ( as covered in the Social Enterprise lecture ). In addition, we specified the ‘type of user’ by describing the main goal of each persona from using MeetingOfMinds, we take benefits from the Flickr diagram discussed in the the Social Enterprise lecture to design each type which also covered in our earlier post ( please click here to view it ) in the Social Network section when we talked about how our project being a social network.
Continue reading “Persona’s: Different Users of “MeetingOfMinds””
Activity diagrams are probably the most important UML diagrams for doing business modeling in software development, it is generally used to describe the flow of different activities and actions. These can be both sequential and in parallel. They describe the objects used, consumed or produced by an activity and the relationship between the different activities. [1]
Continue reading “Activity Diagram: The Flow of Activities and Actions of “MeetingOfMinds””
In this post we are introducing the designs of our web-based application MeetingOfMinds. We focused on reflecting the functionality of our platform while designing the mockups, hence, we kept the colors and layouts very simple.
Continue reading “Designing our web-based application: Mockups of MeetingOfMinds”
Use Case diagram is the useful UML diagrams especially for highlighting the functions of the system, different roles and how these roles interact with the system. Hence,it aims to present the high level view of the system particularly for stakeholders.
In the case of “MeetingOfMinds” application, we have three actors who are: Student, Professors and Administrator and each of them has different interface in which he will be able to interact with the application and use the services ( functions ) provided. We has used Smart Draw online tool to build the Use Case Diagrams for the “MeetingOfMinds” application.
The following diagrams describe the four main functions of “MeetingOfMinds” application.
Continue reading “Use Case Diagrams: The Main Functions of “MeetingOfMinds””
After identifying the application purpose and target group, based on these we developed a set of requirements that should be met on the application. But before the actual development of the software, we needed to decide what is essential for the first version of it [1] and what features are recommended for the future work. Thus, we chose to prioritize the requirements. We used the MoSCoW technique to do so. This way, we selected an appropriate set of requirements from the overall set in order to develop cost-effective software that respects its purpose. We, also, identified the desired or nice to have features in the future versions. A brief description of the MoSCoW technique we applied can be found below: Continue reading “Application Requirements”
