IWNF02_E - Agile Software Engineering

Project Report

Prof. Ejeagwu Martin

8th March 2025

Student’s Name: Muhsin Abdullahi

Study Program: Software Development

Matriculation Number: 92126349

Link to confluence: https://muhsinabdullahi.atlassian.net/wiki/x/AgAaAQ

Link to Jira:
https://muhsinabdullahi.atlassian.net/jira/software/projects/MUH/boards/2/backlog?atlOrigin=eyJpIjoiZ
GZmN2JhZmY3OTc0NDJjZjllNWNjNWRjMzRiMjdjOGYiLCJwIjoiaiJ9

Link to Figma.

Development mode link: https://www.figma.com/design/yUaNBipXbgmgnWe8ocR7cH/LMS-

Prototype?node-id=1-2&m=dev&t=znd2a4oHtliTspEA-1

Prototype mode link: https://www.figma.com/proto/yUaNBipXbgmgnWe8ocR7cH/LMS-

Prototype?node-id=1-2&t=znd2a4oHtliTspEA-1
Table of Contents:
1. Introduction ...................................................................................................................................... 1

1.1 Background and Problem Definition: .......................................................................................... 1

1.2 Project Objectives:...................................................................................................................... 1

1.3 Approach and Methodology: ....................................................................................................... 1

1.4 Structure of the Report: .............................................................................................................. 1

2. Stakeholder Analysis and Table Construction .................................................................................. 2

3. Requirements Engineering ............................................................................................................... 5

3.1 System Context .......................................................................................................................... 5

3.2 Sources of Requirement ............................................................................................................. 5

3.3 Elicitation Technique .................................................................................................................. 6

3.4 Conducting the requirements elicitation activity using the selected technique............................. 6

3.5 Eliciting Requirements from Documents ..................................................................................... 7

3.6 Eliciting Requirements from Existing Systems ............................................................................ 8

3.7 Requirements Documentation .................................................................................................... 9

4. Functional and Non-Functional Requirements and Business Rules ................................................. 9

5. AI-Powered Features for the LMS .................................................................................................. 10

6. NordWest Vision for Digital Transformation and User-centric Requirements .................................. 11

6.1 User-story ................................................................................................................................. 11

6.2 Product Vision .......................................................................................................................... 12

7. Communicating Concepts to Stakeholders with Use Case Diagram ............................................... 12

8. Communicating Product Roadmap and Release Plan to stakeholders ........................................... 13

9. Agile Team and Development Technologies .................................................................................. 14

9.1 Scrum Team ............................................................................................................................. 14

9.2 Agile Ceremonies ..................................................................................................................... 14

9.3 Development Plan and Technologies ....................................................................................... 15

10. Personal Reflection ...................................................................................................................... 15

11. Conclusion ................................................................................................................................... 15

ii
12. List of References: ....................................................................................................................... 17

iii
1. Introduction
1.1 Background and Problem Definition:

NordWest University wants to digitalize its learning environment, through developing a transformation
strategy to enhance user experience across all interactions, this project will make it become the leading
private university in Germany. Strategies include building a robust Learning Management System (LMS)
designed to address the needs of both lecturers and students at various stages of their academic
journey. The system aims to support the university’s goal of making educational experiences smoother,
more accessible, and tailored to users’ needs.

1.2 Project Objectives:

The backbone of the LMS design is the "Lecturer Lifetime Journey," a framework through which the
must-have user stories (the walking skeleton) can be identified and formulated. NordWest University
identified four main stages of interaction: meetMyStudent, teachMyStudent, testMyStudent, and
gradeMyStudent. Each stage represents a set of tasks and processes where digital technologies
essential to the academic experience are integrated to provide an intuitive user experience.

In the meetMyStudent phase, lecturers can organize their students, upload a course introduction video,
and engage with students on teams. In the teachMyStudent phase, lecturers can have a more digital
experience where they can use digital tools to upload teaching materials in various formats, creating a
centralized repository that students can access anytime and view course details. The testMyStudent
phase allows lecturers to create a diverse range of examination questions. Finally, in the
gradeMyStudent stage, automatic grading can be activated for multiple-choice questions and lecturers
to easily evaluate and publish students’ results.

1.3 Approach and Methodology:

NordWest University wants the LMS to be robust and usable, to make activities seamless, the LMS
should integrate various digital technologies that simplify access and increase usability for both lecturers
and students. For lecturers unfamiliar with digital tools, the LMS includes quick-access buttons for
regular events and also, an option to switch to student view. NordWest University also wants the LMS
integrated with AI-powered technology that evaluates students’ answers and assigns grades based on
lecturer settings, features like the lecturer's dashboard and customizable student management tools will
help the system provide a comprehensive and user-friendly experience.

1.4 Structure of the Report:

This report documents the development of NordWest University’s LMS, covering the entire process from
stakeholder identification to system development. It begins by identifying key stakeholders, such as

1
lecturers, students, university administration, and the IT team. A stakeholder table will be created to
categorize them based on their influence and interest, ensuring their needs are properly managed.

Next the requirement engineering process will be detailed, and requirements will be gathered from
stakeholders, existing systems, and supporting documents. Elicitation techniques like interviews,
document analysis, and system archeology will be used to ensure that requirements are completely
collected, which will be documented in Confluence.

The user story mapping, product vision, and roadmap will then be presented, concepts will also be
illustrated to stakeholders using a UML diagram. This report will also detail the Scrum team and Agile
development process, Scrum ceremonies will be documented in Jira. A release plan and product
versioning will also be specified.

Finally, the product development process will be described, highlighting the planned technologies, and
mockups to visualize the LMS to stakeholders before full implementation.

2. Stakeholder Analysis and Table Construction

To begin a project, you must first identify stakeholders and then prioritize them in a convenient way
(Majumdar et al., 2014, p. 17). According to PMBOK GUIDE (2021), a stakeholder is “an individual,
group, or organization that may affect, be affected by, or perceive itself to be affected by a decision,
activity, or outcome of a project, program, or portfolio” (p. 8). In the case of this project, the stakeholders;
are those who will interact with the system, and influence its success, such as the lecturers, who will
manage classes, grade students, and upload materials. The students; who will access the learning
materials, view grades, and attend virtual classes. NordWest University management; who are the
sponsors of the project. The decision-makers; responsible for accepting the final product. IT and
development team; individuals equipped with business and technical expertise, responsible for the
development, maintenance, and providing feedback to the management on issues concerning product
quality, project budget, schedule, and scope. Regulatory Bodies; organizations responsible for setting
educational standards and ensuring users’ data security like the General Data Protection Regulation
(GDPR).

Stakeholder prioritization is the process of determining which stakeholders should receive the most
attention, resources, and communication. This is done by evaluating stakeholders based on their level
of interest, influence, and potential impact on the project’s success (www.teamhub.com). The
power/Interest matrix is used for prioritizing stakeholders, where their level of influence and interest in
the project is assessed so that decisions can be made on who to manage closely, keep satisfied, keep
informed, and also who to give minimum effort (www.projectmanagement.com). The stakeholders we
have identified come from different domains and thus have distinct roles and objectives, if stakeholders

2
have different interests and concerns on specific aspects or parts of the project, then how can they be
compared? For instance, evaluating the interest of a lecturer and that of a developer concerning the
project, and prioritizing based on that is not only inaccurate but misleading. Because they come from
different domains and are concerned with different aspects of the project, hence they cannot be
prioritized on a single priority scale. However, individuals from the same domain can be compared and
ranked and assigned a priority level.

When given a list of cross-domain stakeholders, we must first

1. Categorize them into domains.

Lecturers Students University IT Development Regulatory

Management Teams Bodies

This way one can focus on the influence and interests of each group without forcing cross-domain
comparisons.

2. Prioritize individuals within each domain

Rank stakeholders based on their interests (how much they are impacted) and power (how much
influence they have over the project). For example:

University Management Domain

Stakeholder Power Interest

Vice Chancellor High High
Head of University Digital High High
Transformation
Finance Manager High Moderate

Using a Power-Interest Matrix for each domain, stakeholders can be ranked and prioritized with
accuracy.

3. Cross-Domain Analysis

In this step, the level of interest and influence or dominance of stakeholders in each phase of the project
is assessed, in other words, their role in achieving project objectives in each phase of the project.

 Lecturers: The LMS is designed based on their lifecycle, their interest and support are crucial in
achieving project success, highly impacted by usability and features like task assignment and
grading tools.
 Students: End-users, whose power is moderate but are highly affected by the LMS, are
concerned with the usability, appealing UI design, and fast response of the system, their
experience defines the LMS’s success in terms of learning outcomes.
3
  University Administration: Decision-makers who are the sponsors and most powerful
stakeholders in the project, highly concerned with the quality, budget, schedule, and scope of
the system.
 IT Teams: These are teams of experts, responsible for gathering requirements and implementing
them, and also ensuring the system fulfills stakeholder requirements.
 Regulatory Bodies: Organizations that enforce project compliance with educational and legal
standards.

All these groups are high priority, but their influence varies based on project phase:

4. Constructing Stakeholder Table

The stakeholder table should reflect each group’s role, influence, and importance in different phases.

Name Stakeholder Domain Interest Power Classification Role in Project Priority Phase

Mr. Head of University High High Key Directs the Planning

James Digital Manage Stakeholder Transformation
Transformatio ment process and
n approves
funding.

Cara Developer IT Team High High Key Implements Implementation

White Stakeholder stakeholders’
requirements.

Mr. Wong Lecturers Lecturers High High Key Help in defining Design,
Stakeholder requirements, Acceptance
the design of the
LMS, and
approving the
developed
system.

Mahmoud Students Students High Moderate Keep Informed Also essential in Acceptance
the acceptance
phase because
they are the
end-users.

GDPR Regulatory Regulator Moderat High Keep Satisfied They enforce Throughout
Bodies e compliance with
educational
standards in the
system.

4
Using this stakeholder table, we can clearly identify stakeholders along with their domains, roles in the
project, and the phases in which they are most active. This approach helps prioritize stakeholders based
on their relevance to specific project stages.

3. Requirements Engineering

Requirements elicitation is a core activity of requirements engineering, it is the process of acquiring the
knowledge that forms the basis from which a system is developed (Pohl & Rupp, 2015, p. 19).To elicit
requirements expeditiously and systematically, four steps must first be conducted (IU Requirements
Engineering Coursebook):

1. Determine system context.

2. Identify sources of requirements.

3. Select appropriate Elicitation techniques.

4. Elicit requirements using the techniques.

3.1 System Context

In the first step, the material and immaterial aspects of the system are analyzed, these include the
environment in which the system operates and its dependencies, and also stakeholders that will directly
interact with the system in development (Pohl and Rupp, 2015, p. 11). In this project, the system context
will include: Lecturers, Students, University Management, IT Development Team, Regulatory Bodies,
and system dependencies in the operation landscape, for example, databases, web servers, etc.
Determining the system context helps construct the system boundary and context boundary.

3.2 Sources of Requirement

In the second step, the sources of requirements are identified, according to Pohl and Rupp (2015) typical
sources of requirements include:

 Stakeholders are people or organizations that directly or indirectly influence the system's
outcome. In this project, the people who wield this power are the Lecturers, Students, University
Administration, IT Development Team, and Regulatory Bodies.
 Documents: They contain useful information on past or similar projects that can provide
requirements.
 System in operation: These can be legacy or predecessor systems as well as competing systems
that can provide real-time information.

5
3.3 Elicitation Technique

Depending on the source of requirements, the project situation, and the nature of the requirements, an
appropriate elicitation technique or a combination of elicitation techniques must be selected (Tiwari &
Rathore, 2017). The requirements elicitation process for stakeholders requires selecting a suitable
elicitation technique that effectively uncovers the knowledge and requirements of stakeholders, even
under certain conditions and constraints. This involves applying the technique consciously and in a
fashion suitable to the situation at hand with the intention of eliciting requirements as completely and
comprehensibly as possible (Pohl & Rupp, 2015, p. 24). Pohl and Rupp (2015) further added that
“elicitation techniques serve the purpose of identifying the conscious, unconscious, and subconscious
stakeholder requirements” (p. 24). When selecting a suitable elicitation technique, the first important
step is to perform constraints analysis such as identifying risk factors and distinguishing between
conscious, unconscious, and subconscious stakeholder requirements (Pohl & Rupp, 2015, p. 24). This
way, it becomes easy to accurately choose the right technique to elicit stakeholder requirements.

The table below contains some techniques that are best suited for stakeholder requirements elicitation
in this project, it highlights their characteristics and the conditions in which they are best suited.

Elicitation Technique Characteristics Usage

Interview One-on-one discussions, open- Interviews can be used to elicit
ended in nature detailed needs and
expectations of stakeholders
like lecturers, and
administration.
Survey/Questionnaires Closed-ended in nature, written Surveys can be used to gain
questions for feedback. insights into what the students
most prioritize by formulating
close-ended questions tailored
to the response the
requirements engineer desires.
Focus Group Group discussions for Focus group is perfect for
brainstorming. getting diverse perspectives
from stakeholders, especially
the IT development team, so
that ideas can be brainstormed
by experts who have knowledge
of how the system should look
like.

3.4 Conducting the requirements elicitation activity using the selected technique

The final step is to use the selected elicitation technique, create the environment for the elicitation
activity, and formulate tailored and specific questions for each stakeholder. The table below outlines the
stakeholders involved in the LMS project and the elicitation techniques best suited to gather their

6
requirements. Each technique is selected based on the stakeholder's role, level of interaction with the
system, and the type of information they can provide. Additionally, example questions are also posed to
each stakeholder to demonstrate how these techniques are applied to uncover functional, non-
functional, and quality requirements of the system.

Stakeholders Elicitation Techniques Example Questions

Lecturers Interviews Q1. "What challenges do you
face when managing student
assignments and grades?"
Q2. “What features do you
think would improve your ability
to organize and teach courses
digitally?"
Focus Group Q1. “What LMS functionalities
are most essential for your
teaching process?”
Students Survey/Questionnaire Q1. “How would you want the
process of submitting an
assignment to be?”
Q2. “Would you prefer an
appealing customizable user
interface over an intuitive, easy-
to-use one?”
Focus Group Q1. “What would make the LMS
easier to use for managing your
studies?"
University Administration Interview Q1. “What are the essential
features the LMS must
implement to satisfy the
University’s digital
transformation goal?”
Q2 “What metrics would you
use to evaluate the success of
the LMS?"
IT and Development Teams Focus Group Q1. “What technical constraints
should be considered in LMS
implementation?"
Q2. “What system architecture
would best support scalability
and reliability of the LMS?"

3.5 Eliciting Requirements from Documents

When important information is available in documents, document-centric elicitation techniques are used
to extract it in a structured way. These techniques reuse solutions and experiences documented during
the development of existing systems, such as legacy systems. By analyzing legacy system
documentation, it is possible to identify the functions and technical structure that worked well, as well

7
as any limitations. This provides a helpful reference for designing the new system (Pohl & Rupp, 2015,
p. 28).

In addition, regulatory documents such as laws, policies, and standards play a crucial role in defining
system requirements. They establish the legal and ethical guidelines that the system must follow,
covering aspects like data privacy, security, and accessibility. By following these regulations, the
development process ensures that sensitive information remains protected, the system is secure, and
all compliance requirements are met.

The table below explains the elicitation techniques used for analyzing these documents, why they are
suitable, and the objectives of applying them to the LMS project.

Requirement Source Elicitation Technique Application Aim

Legacy/Competitor System Archeology This is a technique that - Identify features and
System extracts useful functionalities of the
information that is legacy system.
required to build a new - Understand the
system from the technical architecture
documentation or and its constraints.
implementation code of - Analyze gaps or
a legacy system or a areas for improvement
competitor’s system in the new LMS.
(Pohl & Rupp, 2015, p.
28).
Laws and Policy Perspective-Based This technique - Understand laws and
Documents Reading involves analyzing the regulations affecting
document from the the LMS.
perspective of relevant - Ensure compliance
stakeholders, such as with GDPR and
legal advisors or educational standards.
compliance officers - Identify rules for data
(Pohl & Rupp, 2015, p. privacy, security, and
28). accessibility.

3.6 Eliciting Requirements from Existing Systems

An existing system, such as a predecessor or competitor system, can also be used as a source of insight
for designing the system under development. By analyzing these systems, stakeholders can identify
effective features and functionalities and areas that need improvement. Stakeholders can also inspect
these systems through real-time interactions, observing how they are used in practice. This way, implicit
knowledge can be identified, the IT Team can gain an impression of the existing system, and the system
can be developed with new changes and functionalities.

The table below shows the elicitation technique suitable for gaining requirements from existing system,
its characteristics, and the objective of the stakeholders when it is used

8
 Source of Elicitation Technique Characteristics Objective
Requirement
Existing System Observation Involves stakeholders -Observe how IT staff
inspecting existing currently manage
systems to observe LMS-related tasks, like
real-world interactions maintenance or user
and workflows. support.
-Identify implicit
knowledge about how
users interact with the
system.

3.7 Requirements Documentation

After a requirement has been identified, it must be documented (Pohl & Rupp, 2015, p. 33). In this
project, confluence will be used to document the findings from the elicitation activity. These findings will
be categorized as functional (specific actions the LMS should perform) and non-functional (quality
requirements). The link to confluence is provided on the title page.

4. Functional and Non-Functional Requirements and Business Rules

According to Pohl and Rupp (2015), functional requirements are the functionality that the system to be
developed offers (p. 8), meaning what the system must do and the features it needs to have. In this
project, functional requirements are core actions and processes that the LMS must support. Below are
examples of functional requirements.

ID Description Priority
FR001 The lecturer must have access to the list of all the High
students that take his/her course.
FR002 The students can view all the upcoming live sessions High
and the responsible lecturer through a timetable.
FR003 The LMS provides automatic grading for tests and High
quizzes.

Non-functional requirements describe the desired qualities of the system to be developed that are not
covered by functional requirements (Pohl & Rupp, 2015, p. 8). They ensure that the system performs
well, is secure, and meets usability standards.

ID Description Type Priority

NFR001 The system must comply with GDPR Security High
and data privacy.
NFR002 All pages must load within 2 seconds Performance High
under normal usage.

9
 NFR003 Student actions in the system should Usability Medium
be represented by an icon to enable
seamless navigation.

Business Rules define the constraints and conditions that the system must adhere to (Pohl & Rupp,
2015), they are not implemented like functional and non-functional requirements but impose to limit the
solution space available (p. 8).

ID Description
BR001 Students must pass at least 80% of the test to register for final exams
BR002 Students cannot retry an exam after three failed attempts
BR003 Project submission is only made through anti-plagiarism software

5. AI-Powered Features for the LMS

NordWest University aims to digitalize its learning environment to become the leading private university
in Germany, from this goal, we can infer that integrating AI-powered features into the system will make
it robust and seamless, thus achieving this goal. The table below suggests features that can be
implemented to the system, their description, priority, and ID in the list of functional requirements.

ID Feature Description Priority

FR004 Automatic grading for Lecturers can use AI to High
multiple-choice automatically grade
questions students’ exams, using
predefined input and
criteria.
FR005 Adaptive Learning This can be useful to Medium
adapt the learning
content to the students’
environment and
device.
FR006 Student Management AI can also be used to Medium
manage student tasks
and actions in the
LMS, from their course
registration, calendar
management to even
notifying students
when deadlines are
advancing.

10
6. NordWest Vision for Digital Transformation and User-centric Requirements
6.1 User-story
After stakeholder requirements have been identified, verified, and documented, it is necessary to refine
and split them into small and implementable features or functionalities that can be delivered within a
sprint (In the case agile methodology is being followed). User stories help users define their needs in a
simple form, highlighting who they are, what they want, and the benefits they want to achieve. It is also
accompanied by the business value of the function and the effort required to realize it.

The primary users of the LMS are lecturers and students, user stories will be derived from each stage
in the lecturer's lifetime journey, highlighting their needs and expectations, and also the students, who
will be in constant interaction with LMS.

Meet my Students Teach my Students

As a lecturer As a lecturer
I want to meet all my students in one place and I want to activate Microsoft Teams for virtual
organize them according to certain criteria. classes
So that I can efficiently manage tasks and So that students can attend online sessions
assignment seamlessly
Business Value: 7 Effort: 4 Business Value: 8 Effort: 8
Test my Students Grade my Students
As a lecturer As a lecturer
I want to get automatically graded multiple- I want to access, mark, and publish exam
choice questions results
So that I can save time focusing on open-ended So that students can view their performance
questions promptly
Business Value: 7 Effort: 5
Business Value: 10 Effort: 5

As a student As a student
I want to access teaching material uploaded in I want to receive an email notification when my
various formats (PDF, videos etc) exam result are published
So that I can study and prepare effectively So that I can speedily check my performance
Business Value: 7 Effort: 3 Business Value: 7 Effort: 1

11
6.2 Product Vision

The Learning Management System (LMS) for NordWest University aims to revolutionize the educational
experience of their students and lecturers, by developing a highly intuitive and efficient platform. The
platform will raise their ranking to become the best private university in Germany, attracting students
and partners from all around the world. The LMS will be designed to follow the lecturer lifecycle stages:
meetMyStudent, teachMyStudent, testMyStudent, and gradeMyStudent, and integrate it with user-
friendly features and AI-powered tools The LMS will enable seamless course management, enhance
lecturer teaching and student management, and also automate grading and result notification.

Key Goals:

Enhance student/lecturer experience through intuitive interfaces.

Improve efficiency with virtual classes, task management, and AI-driven grading.

Ensure security, compliance, and data privacy for all users.

7. Communicating Concepts to Stakeholders with Use Case Diagram

After the concepts of the LMS are developed, the next step is to communicate these concepts and flows
to the stakeholders. Unified Modeling Language (UML) is a standard modeling language that can be
used to effectively illustrate the system’s structure, interactions, and processes.

Consider the scenario where a student submits an assignment and receives a grade from the tutor.

 The student logs in to the LMS.

 Navigate to the course dashboard.
 Selects the course for which the assignment will be submitted.
 The student uploads and submits the assignment to the plagiarism detection software.
 Plagiarism software checks assignments for plagiarism.
 LMS notifies the tutor of the submitted assignment.
 The tutor receives and grades assignments.
 LMS sends a grade notification to the student.

For this concept, a Use Case Diagram will be used to illustrate key user interactions with the system.

12
Figure 1: LMS Use Case Diagram

The “Receive Grade Notification” use case has a “depends on” relationship with the “Grade Assignment”
use case because the student receives notification only after the grading is done.

8. Communicating Product Roadmap and Release Plan to stakeholders

Product roadmap details the planned development phases for the LMS, their timeline, and objectives,
while the release plan outlines the incremental releases of the system, from the early prototype to full
system deployment, integrating feedback and test results of each release to improve the next, while
adding more features and functionalities in an agile manner.

Phase Timeline Planned Features Release Version

Planning and RE Month 1 Requirements Not Applicable
gathering and planning,
stakeholder analysis.
Prototype Month 2 Initial version v1.0
Development development, early
prototype.

13
 System Development Month 3-5 Core system v1.1
functionality
development following
lecturer lifetime stages.
Integration and Testing Month 6 System testing and v2.0
Microsoft Teams
integration.
Test Launch Month 7-8 Performance feedback v2.1
and system
improvement.
Full Development Month 9 Deploying the system v3.0
to serve its purpose.

9. Agile Team and Development Technologies

9.1 Scrum Team

A Scrum team will be established to manage the LMS product development, ensuring an agile
development workflow. The key team roles are:

Role Responsibility
Product Owner Defines project goals, prioritizes backlog, and
represents stakeholders.
Scrum Master Facilitate meetings, resolve issues and obstacles,
and make sure the team works in an agile
manner.
Development Team Implements stakeholder requirements, develops
the product increment, and presents it to the
product owner for acceptance.

9.2 Agile Ceremonies

Ceremonies refer to the organized meetings agile team conducts to coordinate and improve workflow.
In this project, structured events will be highlighted to track the LMS development process. First, a sprint
meeting is held by the product owner and development team. High-priority user stories are selected
from the sprint backlog that will be delivered in exactly one sprint. A sprint begins with a daily scrum, a
meeting facilitated by the scrum master, where information is exchanged by team members on the
development progress, obstacles encountered, and how to resolve them. A sprint refers to a time period
when the product is worked on by the development team. The end of a sprint is marked by the
development of an increment, which is a product that is tested and accepted by the product owner and
relevant stakeholders. Finally, a retrospective is conducted by team members to identify what went well,
what bottlenecks were faced, and how to improve the next sprint.

In Jira, user stories are documented in the sprint backlog, with each story assigned a status of To-Do,
In Progress, or Done. These statuses can be viewed and managed using the sprint board, ensuring
14
transparency in task progression. Subsequent sprint activities, such as daily scrum, sprint review, and
sprint retrospective, are documented separately as Jira issues. Each activity includes a description of
its purpose, and all planning and outcomes are recorded in the comments section for tracking and
evaluation. The Jira project link is provided on the title page.

9.3 Development Plan and Technologies

Development will follow an incremental approach, where core features are built first, followed by
enhancements.

Technologies

Component Technology
Frontend React.js for user interface
Backend Node.js for API handling
Database Mongo DB for data storage
AI-Features Python-based AI modules for automated grading

Development Approach:

Mockups and Prototyping: Early versions will be built as interactive mockups before full implementation.
These mockups will serve as prototypes, allowing stakeholders to interact with the system, explore its
functionality, and provide feedback for necessary modifications.

For this project, Figma will be used to develop an interactive mockup with six pages. A login page is set
as a starting frame so students and lecturers can enter their credentials and log in. After logging in, a
dashboard page is then displayed, containing a sidebar with a clickable button for navigation to key
pages, and key pages include a course page, schedule for upcoming live events, assignment
submission page, and an exam result page.

10. Personal Reflection

Working on this LMS project has been a valuable learning experience, allowing me to apply theoretical
knowledge to a practical system development scenario. One of the most significant aspects of this
project was understanding the importance of requirement engineering, identifying real stakeholder
needs, and implementing it into a working software.

Another key takeaway was understanding students' and lecturers interaction with the system, to come
up with an AI-powered feature to automate and improve their processes, making it efficient.

Understanding the relationships between use cases was challenging for me, especially system
processing use cases that are triggered by an actor’s action. However, breaking down each process
into smaller components and further research helped me clarify relationships and interactions

15
11. Conclusion

Software development process is plan-driven, meaning, adequate planning is required in choosing the
development approach, ensuring the framework suits the product requirement, and implementing it.
Planning is also required in the development phases, making sure that each activity aligns with the
framework chosen so that the development process can go smoothly. Planning is also required to
respond to change, deal with it, and implement it.

The development of NordWest University’s Learning Management System (LMS) provided

comprehensive insights into the structured software development process, from requirements
engineering and system modeling to agile methodologies and implementation planning. The project
highlighted the importance of stakeholder analysis, requirements elicitation techniques, and clear
documentation to ensure the system aligns and meets user needs.

It is clear that requirement engineering and agile development methodologies are vital skills in
professional software development. The ability to analyze user needs, model system behavior, and
manage iterative development cycles or sprints will be highly valuable in future studies and career
growth

The knowledge gained from this project will be directly applicable to future software development roles,
and understanding how to align stakeholder requirements with technology-driven solutions will be critical
for professional growth in the future.

16
List of References:

Majumdar, S. I., Rahman, M. S., & Rahman, M. M. (2014). Stakeholder prioritization in requirement
engineering process: A case study on school management system. Computer Science and Engineering,
4(1), 17-27. https://doi.org/10.5923/j.computer.20140401.03

Pohl, K., & Rupp, C. (2015). Requirements engineering fundamentals: A study guide for the certified
professional for requirements engineering exam—Foundation level—IREB compliant (2nd ed.). Rocky
Nook.

Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK®
guide) (7th ed.) and The Standard for Project Management. Project Management Institute.

Teamhub. (n.d.). Stakeholder prioritization analysis explained. https://teamhub.com/blog/stakeholder-

prioritization-analysis-explained/

Thamma, L. (2023). Stakeholder analysis using the power interest grid.

https://www.projectmanagement.com/wikis/368897/stakeholder-analysis--using-the-power-interest-
grid#_=_

Tiwari, S., & Rathore, S. S. (2017). A methodology for the selection of requirement elicitation techniques.
arXiv preprint arXiv:1709.08481.

17