Systems Analysis and Design Assignment

This Systems Analysis and Design assignment focuses on various core concepts in software development. It requires students to construct an Event Table detailing system events and their triggers, sources, and responses. They must then create a Domain Model Class Diagram to represent the key entities within the system. A Design Class Diagram is needed to illustrate the system's structure and relationships between classes. Further tasks involve developing a Use Case Diagram to visualize user interactions with the system and providing detailed descriptions for specific use cases like 'Create Supplier'.

System Analysis and Design
[Name]
Course Code
Institution

Introduction
In today’s software development projects, project teams constantly face a combination of old and
new types of risks, which includes shortfalls in real-time performance of project tasks, unrealistic
budgets and schedules, project scope creeps ,wrong analysis of requirements of the intended
system, changing system or customer requirements which needs to be implemented with speed to
ensure projects complete successfully. Organizations therefore have to carefully select
approaches in developing their core information systems. For most organizations, an ideal
approach to the development of a critical system is one which adapts to the changing
technological and systems requirements. A methodology that is responsive to business changes.
Among the numerous existing development methodologies, Adaptive or Agile software
development methodologies stands out for such organizations, as they enable them to rapidly
change they IS during development. With most organizations facing unpredictability and
dynamism in emergent business-process requirements, agile methodologies play a critical role in
the development of information systems for such organizations (Alliance, 2016).
Adaptive software development methodologies are highly iterative, and are characterized by
constant evolution of the requirements and solutions through development collaborations
between self-organization cross-functional teams (Alliance, 2016). Adaptive approaches promote
constant and continuous inspection, teamwork, rapid adaptation, accountability and self-
organization (Alliance, 2016). These set of engineering best practices facilitates aligning
development with business goals and requirement, while facilitating rapid delivery of high-
quality software (Alliance, 2016). The principles adopted by various adaptive methodologies are
outlined in the Agile Manifesto.

There are a number of adaptive methodologies that can be used in various projects, and in
particular the development of the envisioned system at Comfort Quilts Limited. Key among them
includes Scrum, Extreme Programming (XP), Adaptive Software Development (ASD), and
Feature Driven Development (FDD) among others (Satzinger, Jackson and Burd, 2011). The
nature of business processes at Comfort Quilts Limited necessitates that an adaptive
methodology be used in the development of the system. This is partly because requirements are
likely to change especially with the planned move to change suppliers; changing suppliers may
put new demands to the system at the company, necessitating the system to be aligned to the new
business processes. Also the intended expansion of product offerings may result in changes to
the systems requirements, which have to be implemented on the system being developed.
Although all the aforementioned agile methodologies can be applied to the development at
Comfort Quilts, the selection of the particular method is pegged on the finer details of each of the
main approaches. Since all agile methodologies subscribe to the philosophies outlined in the
Agile Manifesto, they all facilitate rapid adaptation to changing customer requirements. For this
project the ideal method is Scrum agile methodology.
Scrum
Scrum is one of the agile approaches; a framework for managing projects with an emphasis on
iterative progress, accountability, incremental development of the system and teamwork
(Schwaber, 2004). The methodology enhances the capability of the project team to respond to
changing requirements, and maximizes cooperation through improved communication
(Schwaber, 2004). The approach can be scaled from a small project to an entire organization.
This approach is the best suited for the development of the system at Comfort Quilts Limited
since the organization already has a clear goal for the project, but uncertainties exists as to

whether the requirements would change, within the project without changing the goal. Such a
situation is ideal for scrum development since it ideally require development to start with what is
known, and track progress, tweaking the requirements as need arises to achieve the desired goal.
The methodology is founded on three pillars; adaptation, inspection and transparency (Schwaber
and Beedle, 2002).
A traditional software development approach would not be ideal for the system development at
Comfort Quilts. Convectional methodologies do not factor in changing requirements in the phase
of project execution. On the contrary, agile approaches such as scrum understand today’s
complex business processes and volatility of the operating environment, which may require
changes before the final solution is delivered (Kniberg, 2015). The guiding principles outlined in
the Agile Manifesto puts particular emphasis on collaboration, flexibility to adapt emerging
business realities , collaboration and autonomy of teams (Schwaber and Beedle, 2002).
Where Scrum is taken as the methodology of choice, roles have to be indentified for the main
project stakeholders. Scrum specifies three main roles in a project, The Product Owner, Scrum
Master and Team.
Scrum Roles
 Product Owner: The stakeholder with the role of Product Owner has the ultimate
authority over the project. Product Owner holds the project’s vision and should
therefore constantly communicate the vision and priorities to the team in charge of
developments (Schwaber and Beedle, 2002). Although Scrum teams are autonomous,
the Product Owner has the responsibility of ensuring the vision of the project is being
achieved without micro managing the team (Kniberg, 2015). Product Owner should
be available to clarify queries that the project team may have.

 Scrum Master: although the Product Owner ensures the team is on the right track to
achieving the vision of the project, the Scrum Master is obliged to facilitate smooth
working of the team and the Product Owner (Kniberg, 2015). The main task of the
Scrum Master is to create conducive environment for the team to achieve the goals of
the project, while advising the Product Owner on ways of maximizing the team’s
ROI (Kniberg, 2015).
 Team: a Scrum team is completely self-organizing and is responsible for producing a
project’s deliverables. For a software development project, such a team would
include a mix of system analysts, software developers, analysts and testers. A scrum
team has between 3 to 9 members who determine among themselves how to carry out
tasks, and accomplish requirements for a given sprint within scrum development
approach (Schwaber and Sutherland, 2016).
The Scrum process
Development process with Scrum starts with whatever is presented as initial system
requirements, and then processed through constant evaluation, to ascertain what works and what
needs to be discarded (Schwaber and Sutherland, 2016). One pillar of the Scrum process is
communication, which is done through a series of meetings or events. The Scrum process has
four main events, which include; daily Scrum, Sprint Planning Meeting, Sprint Review and
Sprint Retrospective (Schwaber and Sutherland, 2016).
Daily Scrum: this is a short stand-up meeting, which is held daily at the same time and place
(Kniberg, 2015). The meeting is used to review the team’s work, completed the previous day and

planning of what is to be accomplished in the next 24 hours. The team members also get an
opportunity to air out any challenges encountered in the project.
Sprint Planning Meeting: A sprint is a period of time which work must be completed, mostly a
period of 30days. Each sprint results in delivery of a given usable module of software (Kniberg,
2015).
Sprint Review: This is where the team and other stakeholders meet to review a sprint and
showcase the increment achieved in the just concluded sprint (Kniberg, 2015).
Sprint Retrospective: A meeting at the end of a Sprint which allows team members to reflect on
the Sprint process. The main goal of Sprint Retrospect is continuous improvement (Schwaber
and Sutherland, 2016).

References
Alliance, S., 2016. What is Scrum? An Agile Framework for Completing Complex Projects-
Scrum Alliance. Scrum Alliance. Available at: https://www. scrumalliance. org.
Schwaber, K. and Beedle, M., 2002. Agile software development with Scrum (Vol. 1). Upper
Saddle River: Prentice Hall.
Schwaber, K., 2004. Agile project management with Scrum. Microsoft press.
Kniberg, H., 2015. Scrum and XP from the Trenches. Lulu. com.
Schwaber, K. and Sutherland, J., 2016. The scrum guide-the definitive guide to scrum: The rules
of the game, July 2011. Available on-line at: http://www. scrum. org/storage/scrumguides/Scrum
% 20Guide.
Satzinger, J.W., Jackson, R.B. and Burd, S.D., 2011. Systems analysis and design in a changing
world. Cengage learning.

PART B
Question 2: Event Table
Event Event Type Trigger Source Activity/Use
Case
System Response/
Output
Destination
Supplier
Application Internal New Supplier
Application The company Apply to be a
Supplier
Supplier
Application Supplier
Supplier approval External Supplier
Approval Supplier
Supplier
Approves
application
Supplier
Approval
Company
Management
Create Supplier External Create
Supplier
Purchase
Manager
Create
Supplier
A supplier record
in the system
Date to run
purchasing/
shipping reports
Temporary “Last day of
the month” Run Reports
individual
purchases,
individual
shipments and
purchasing/
shipping reports
Gary Tallent
Date to run a sales
report Temporary “First day of
the month”
Run a
purchasing
report
purchasing
report
Alison
Williams

Question 3: Domain Model Class Diagram
Assumption
We assume that each class has to have a unique identifier, mostly an ID , in order to properly show the
relationships
Question 4: Design Class Diagram

Question 5: Use Case Diagram

Question 6: Use Case Description (intermediate)
Use Case Name: Create Supplier
Primary Actor: Management Team/Purchase Manager
Secondary Actors: Supplier
Other Stakeholders:
Business Goal: To create a new supplier record, after approval of the application
Precondition The supplier has approved the company’s application
Success Condition A new supplier record is created on the system
Main Path
1. The company fills an application
requesting a supply to be supplying
the company
2. The supplier reviews and
approves the application
3. Management team creates a
supplier record
4. The system saves the record
Variant Paths
2. Application not approved
2b. Supplier record is not created