Systems Design and
Development
INFS1602/2602 Week 5
Announcements
Solutions Architect – The deadline for your Individual
Assignment 3 is Monday, 25 March, 11:59 PM (submission link in
the Assessment Hub on Moodle)
• Please check your Group Code on Moodle
• Submit your file name as Group Code_IA3_TutorName.docx
Project consultations will continue online on Flex Week
• Tutors will circulate a link
• You can book a slot to consult with your tutor on IA3 if required
• This is voluntary and entirely optional
• If you booked a slot, please make sure you show up!
Individual Assignment #3 Briefing
Monday 25 March 11:59hrs – Submit via Turnitin on Moodle
1200 (+-10%) words (Excluding references & appendices)
Deliverables:
• Requirements Specification
• Use-Case Diagram (with one use-case description in the appendix)
• System Interface and Scenario Walkthrough
Let’s take a stroll down
memory lane…
Recap : Process Improvement-Key Terms
Output rate: amount of
products/ services produced
by a business process per
unit of time
Throughput rate (aka flow
rate): rate at which units flow
through a specific activity in
the process.
Process capacity: maximum
output rate of a business
process per unit of time
Capacity utilization:
percentage of process
capacity that is actually used
(output rate/ process
capacity)
Lead time: average time
required for a process to
unfold (from start to end)
Activity time: average time
required for a specific activity
in the process
Activity resource
requirements: average unit of
resources required for a
specific activity in the
process
Recap: Principles for Improving
Business Processes
Outcome-Based Improvements (4 principles):
1. Elimination of unnecessary outcomes
2. Substitution of outcomes with more effective/ efficient outcomes
3. Digitization of outcomes
4. Harmonization of outcomes
Activity-Based Improvements (7 principles):
1. Elimination of activities
2. Moving from a push to a pull principle
3. Elimination of Bottlenecks
4. Automation of Activities
Recap: Principles for Improving
Business Processes (2)
Activity-Based Improvements (7 principles):
5. Parallel Routing of activities
6. Substitution of activities
7. Increasing the probability of more efficient pathways
Resource-Based Improvements (2 principles):
1. Integration of resources
2. Assignment of resources
Recap: Gap Analysis Template
Current State Desired State Location Remedies Benefits
Cinema
currently
prints a
receipt and a
movie ticket
separately
Completely
electronized
ticket/receipt
Send e-version of
ticket/receipt to
student via
app/email
(electronization
of outcomes)
Usher shows
customers to
seats
- Reduced
printing costs
- Reduced
probability of
losing ticket
Customer can
find their own
seats
Reallocate
usher to
other tasks
(elimination
of activity)
- Reallocation
of staff to
more value-
adding
activities
and so on…
Recap: MCQ Activity
INFS1602/2602 Course layout
Week Topic Deliverables
1 Introduction to Information Systems and Business Processes N/A
2 Strategic Analysis and Competitive Advantage Individual Assignment (SL)
3 Business Process Analysis N/A
4 Business Process Improvement Individual Assignment (BA)
5 Systems Design and Development N/A
6 Flexibility Week: No Class Individual Assignment (SA)
7 Project Scheduling and Budgeting N/A
8 IS Security and Ethics Individual Assignment (PM)
9 Emerging Trends in Information Systems (Recorded) N/A
10 Course Review Group Project
Reading Guide: Textbook Chapter 12
Agenda
Overview of Systems Development
Gathering of Systems Requirements
Modelling Use-Cases
Creating a Visual Representation of a System with Wireframes
The Process of Solution Development
Solutions in Information Systems typically center on the
development of a system
Systems Development follows the Software Development Life
Cycle (SDLC)
SDLC refers to the systematic process of designing, developing,
testing, and deploying a system that can support business needs
The Systems Development Life Cycle
(SDLC)
It is like “building a house”
1. Start with a basic idea
2. Idea is fleshed out in a simple sketch that is shown to the
customer and refined
3. Various iterations of negotiation and refinement happen until
the sketch becomes a picture that depicts what the
customers want
4. Blueprints that depict specifically what the deliverable is are
created
5. System is created using the blueprints
The Four Phases of the SDLC
1. Planning: Fundamental process of understanding why a
system should be built and determining how to build it
2. Analysis: Addresses who will use the system, what the
system will do, where and when it will be used
3. Design: How the system will operate in terms of the
hardware, software, data, procedures and people will be
needed
4. Implementation: Actual development of the system
Our focus today will be on Phases 2 and 3
Structured Design: Waterfall
Methodology
The “original” method
Development proceeds in sequence
from one phase to the next
Pros: Clear system requirements, prevents
“scope creep” and changes
Cons: Difficulty to specify design in advance, length of time
between analysis phase and actual system delivery
RAD: Phased Development
RAD: Software development methodology that
• Emphasizes Rapid Prototyping
• Prioritizes Speedy Feedback
• Favors Iterative Development over Extensive Planning
General Analysis Phase:
• Categorizes Requirements into Multiple Versions
• Focuses on Fundamental Requirements Initially
• Subsequent Phases Depend on Previous Phase's Outcomes
Pros of Approach: Swift Delivery of Usable System to Users
Cons to Be Aware of: Potential for Incomplete System to manage user expectations
Agile Development
Based on the 12 Principles of the Agile Manifesto
Eliminating modelling and
documentation for speed, flexibility
and reduced costs, but may be
disjoint with the reality of
contemporary systems development
Consist of two main variants:
1. XP (eXtreme Programming)
2. Scrum
Agenda
Overview of Systems Development
Gathering of Systems Requirements
Modelling Use-Cases
Creating a Visual Representation of a System with Wireframes
What are Requirements?
In the Analysis phase, the objective is to transform general ideas
about what the system would do into a detailed requirements
definition (i.e., a list of requirements)
A requirement is a statement of what the system must do or
what characteristic it must have
The requirements definition is what is presented to an approval
committee, who decides if the project is to continue
The Requirements Definition
The requirements definition is a
straightforward report that lists
functional and non-functional
requirements:
1. Functional Requirements: What
must the system do (e.g., search
for an article)
2. Non-functional Requirements:
Behavioral properties of the
system (e.g., need to access the
system via a smartphone)

Non-Functional Requirements
Non-functional requirements describe four types of
characteristics regarding the system:
1. Operational: Physical and technical requirements
2. Performance: Issues related to speed, capacity and reliability
3. Security: Issues related to who has access to the system and
under what circumstances
4. Cultural and Political: Cultural and political factors that affect
the system (e.g., multi-language support, how many
characters in a last name)
Challenges of Determining
Requirements
1. Lack of access to actual users
2. Specification of requirements may be inadequate
(sometimes even users don’t know what they want)
3. Some requirements cannot be anticipated beforehand
4. Verifying requirements can be difficult
Requirements Gathering Techniques
Effective requirements gathering techniques can help to:
Avoid (costly) surprises late in the development process
Build political support for the project and develop rapport with users
Five common ways of collecting information:
1. Interviews
2. Joint Application Development (JAD) sessions
3. Questionnaires
4. Document analysis
5. Observation
Agenda
Overview of Systems Development
Gathering of Systems Requirements
Modelling Use-Cases
Creating a Visual Representation of a System with Wireframes
The Issue with Requirements Definition
A textual list of requirements is difficult to read and visualize (e.g.,
which function is used by which user, which function belongs to
which system)
Therefore, we typically use a use-case diagram to communicate the
main functions of a system to the client
Advantages of Use-Case Diagrams
• Easy to draw
• Provides an overview of the system/s to be developed in a simple and
straightforward manner
A Sample Use-Case Diagram
Use-Case Diagram – Modelling Notation
1. Actor – person or external system that
interacts with the subject
2. Use-Case – a function of the system
3. Boundary – the scope of a system
4. Association – an interaction between
actor and use case
Use-Case Diagram - Relationships
1. Include relationship – when one function is included
within another system function*
*Including function points to included function
2. Extend relationship – when one function is
optional to another system function**
**Optional function points to base use case
3. Generalization relationship – when an actor is
a more specialized instance of a generalized one***
***Specialized actor points to generalized actor
Identifying the Elements of a Use-Case Diagram
Step 1: Review Requirements Definition
• Look at the list of required functions
Step 2: Identify Use-Cases
• Place and draw use-cases based on the functions specified
Step 3: Identify Actors
• Who uses the system? How will they interact (CRUDE – Create, Read, Update,
Delete, Execute)?
Step 4: Identify System Boundaries
• How many systems do you need? Group use-cases by systems
Step 5: Review Use-Case Diagram
• Check to see that you have not missed anything from your requirements
definition
An Example – An Automated Library
Management System
A system is set up by a university library to support, searching,
borrowing and book-maintenance activities.
Consider the following information to draw a use-case diagram:
There are two groups of actors: Borrowers and Librarians
Borrowers can borrow, return and search for books using the system
Librarians use the system to process overdue loans and maintain
the book collection
Before the borrower (i.e., a student) is allowed to borrow a book,
his/her details must be checked against details stored by the
Registrar’s Office’s Student Information System
Step 1: Place and Draw Use Cases
Borrow
Books
Search
Collection
Return
Books
Process
Overdue
Loans
Maintain
Collection
Step 2: Place and Draw Actors
Borrow
Books
Search
Collection
Return
Books
Process
Overdue
Loans
Maintain
Collection
<>
Student
Information
SystemBorrower
Librarian
Library Management System
Step 3: Draw System Boundaries
Borrow
Books
Search
Collection
Return
Books
Process
Overdue
Loans
Maintain
Collection
<>
Student
Information
SystemBorrower
Librarian
Library Management System
Step 4: Draw Associations
Borrow
Books
Search
Collection
Return
Books
Process
Overdue
Loans
Maintain
Collection
<>
Student
Information
SystemBorrower
Librarian
Creating Descriptions of Use Cases
There is a need to provide more information about your system and its
functions
Every use case has to be matched with a Use-Case Description
Elements of a Use-Case Description:
1. Use-Case Name/ID – Name of function and unique ID
2. Brief Description – Brief overview of what the function is for
3. Actors – The users/systems who are associated with this function
4. Pre-conditions – Conditions that must be met before the function is
used
5. Basic Flow – Sequence of operations under normal conditions
6. Extensions – Exceptions to the basic flow and how to handle them
7. Post-conditions – The intended outcome of the use-case
Sample Use-Case Description
In-Class Activity #1
INFS1602/2602 Week 2
The School of ISTM’s Capstone Course
The School of Information Systems and Technology Management is
developing a capstone course that is meant to reinforce the knowledge
acquired by a student during his/her undergraduate candidature. To help
the students prepare for their final exam, which covers a broad range of IS
topics, the unit coordinator decides to set up a browser-based quiz
exercise training system.
A user can request a quiz from the system. Based on this request, the
system will pick a set of questions from its question bank, and compose
them together to make a quiz. It then scores the user’s answers and
reports the results. The system is also able to provide hints if the user
requests it.
In addition to users, we also have tutors who can add questions to the
question bank. However, the unit coordinator must review each question to
make sure that they are relevant and not too trivial.
Model this system using a use case diagram.
Agenda
Overview of Systems Development
Gathering of Systems Requirements
Modelling Use-Cases
Creating a Visual Representation of a System with Wireframes
What is Wireframing?
Wireframing is a way to design a system at the structural level. It
is an essential part of interaction design
A wireframe is commonly used to lay out content and
functionality on a screen, which takes into account system
functions and user procedures
Wireframes are used early in the development process to
establish the basic structure of a page before visual design and
content is added
How are Wireframes Used?
Wireframes are visual representations of an interface,
used to communicate the following:
1. Structure: How will pieces of a system be put
together?
2. Content: What will be displayed on the user
interface?
3. Informational Hierarchy: How is information
organized and displayed
4. Functionality: How does the user interface work?
5. Behavior: How does the system interact with
the user, and how will it behave?
Who Uses Wireframes?
Business analysts / consultants use wireframes to show how use cases
“flow” (i.e., how will the system work?)
Graphic designers use wireframes as part of the user interface /
experience development process
Developers use wireframes to get a clearer picture of what they will need
to code
Clients use wireframes to get an early preview of the solution that will be
delivered (i.e., solicit end user feedback at an early juncture)
How to Create Wireframes?
Before you begin… there are TWO questions that you will have to
address:
1. What tool to use?
2. What level of fidelity (i.e., degree of exactness)?
Considerations when addressing these questions:
Time/Costs
Purpose of wireframing
Stage of development
Tools for Wireframing (1)
1. Sketching (physical or electronic)
• Paper app
(https://www.fiftythree.com/paper)
• PowerPoint
• Pen & Paper
Tools for Wireframing (2)
2. Stenciling
• Use templates to provide a
representation what interface
will look like on a screen
3. (Wireframing) Software
• e.g., Figma, UXPin,
Axure, Photoshop
• Simplifies the wireframing
process, but be wary of costs
and learning curve
• https://www.youtube.com/watch?v=6t_dYhXyYjI
Deciding on a Tool…
1. Sketching: Quick and easy to modify, but duplication of work
is unavoidable and there is no version control
2. Stenciling: Quick, standardized and more professional
looking, but design is constrained by what the stencil offers
3. Non-Purpose Specific Software (e.g., PowerPoint,
Photoshop): No learning curve, but elements tend to look very
basic
4. Wireframing Software (e.g., Figma, UXPin): Tailored tools and
variety of options available, but has a learning curve and may
be costly
Different Levels of Fidelity (1)
1. Block Diagrams
• Most basic form of wireframes
• Quick sketch of layout and types of content/functions
Different Levels of Fidelity (2)
2. High-Fidelity Text & Color
• Instead of “blocks” insert actual text, font, sizing, buttons,
background and colors
• Closer to look-and-feel of end product, but more time consuming to
develop
Different Levels of Fidelity (3)
3. High-Fidelity Media and Interactions
• Incorporate photos, videos, thumbnails
• Interactions and clickthrough link can be incorporated as well
(https://wireframepro.mockflow.com/view/mockflow-
website#/page/a6542737092e429f96da69847c9aed21)
• Most time-consuming to develop
and more appropriate when system
design is relatively mature (i.e.,
precise feedback is needed)
Storyboarding (Presenting your
Wireframes)
1. Pick the most exciting use-case(s) from your use-case
diagram (i.e., what would most differentiate your system)
2. Create wireframes for all the screens (and interactions)
based on the basic flow documented in your use-case
description
3. Wireframes for screens related to extensions are optional
4. Organize and present your wireframes in the form of a
storyboard (i.e., sequence of diagrams illustrating your basic
flow)
In-Class Activity #2
INFS1602/2602 Week 2
Downloading an In-Class Activity from
Moodle
This activity is meant to give you a sense of how a storyboard is created
with wireframes. In this case, you do NOT need to create the wireframes
because the storyboard you are creating is based on a function on Moodle
(i.e., downloading an mp3 alternative format version of an in-class activity),
an existing system. You can simply use screenshots and assume the
screenshots are wireframes that you created.
Note: For your group project and other systems development projects, you
will be required to create the wireframes because there is no existing
system (or the existing system will have to be modified extensively).
Your Task: Create a storyboard, with screenshots, of all the steps a student
needs to take in order to download the MP3 alternative format version of
last week’s ICA2 from our Moodle site.
Key Takeaways
1. The generic phases of systems development (SD) and three
distinct SD approaches
2. How to gather and specify system requirements
3. How to draw use-case diagrams and create use-case
descriptions
4. The purpose and nature of wireframes, and how to create a
storyboard with wireframes
See you next
week!