BISM3222 Information Analysis and Systems Design
Individual PROJECT
OVERALL ASSESSMENT WEIGHTING: 50%
DUE DATE and TIME: 11 MAY 2020 AT 12:00 (noon)
Overview
The Project requires you to design and create a business information system prototype to be
used to solve a problem in the agricultural sector, then test it on users, re-design based on
feedback, and reflect on future possibilities for your system.
The Project is to be completed individually, as you as an individual are being assessed against
the learning objectives. Among all the assignments submitted, there should be no ideas or
prototypes that solve the same problem in the same way.
The overall idea is to simulate a small system or part of a larger system (a slice) that what
would be required to start-up a business or address a major issue for an agricultural business.
The system must simultaneously make money (or at least save the money that is needed to
implement and maintain your system) and solve a serious problem. Although people have
technically been doing this since the beginning of commerce, some further examples can be
found in this article by the Forbes Technology Council (see
https://www.forbes.com/sites/forbestechcouncil/2017/10/02/solving-social-problems-11-
ways-new-tech-can-help/#5e8eb23658e8). An overview of agriculture can be found on the
Department of Agriculture website (https://www.agriculture.gov.au/ ) and a report and links
(https://www.crdc.com.au/precision-to-decision ).The Queensland State Government
provides a list of what they consider useful tools and you may find useful for starting idea
generation (available at https://www.business.qld.gov.au/industries/farms-fishing-
forestry/agriculture/overview/tools-software ).
The ultimate aim of the Project is for you to gain first-hand experience in systems analysis and
design by actually becoming the actor/s under examination, and then reflecting upon the totality
of your experience. As such, students will examine, experience, and reflect upon many things
from many angles with respect to a central topic – a set of activities that if performed well sets
the foundations for becoming an Analyst-Designer.
Furthermore, as this is specifically an Information Systems course, the business idea and
prototype should include novel approaches to gathering, analysing, and producing information,
the result of which should lead to specific actions based on these insights. At the same time
your foundation knowledge and skills need to be solid. Therefore, the project will be
undertaken using two methodologies side-by-side.
It is expected that students in the course talk about the Project with each other, and even discuss
their potential solutions particularly in tutorials. However, the final Project is a unique
collection of ideas, diagrams, solutions, experiences, and personal reflections and, as such, the
final product MUST be completed solely by each student. The best practice to avoid
misconduct is not to look at another student’s file(s) and not to show your solution to other
students. In case where an assignment is perceived to not be a unique work, a loss of marks and
other implications can result. If a student is unsure about the degree of similarity among
projects, he or she should discuss this issue with the lecturer during office hours. For further
information about academic integrity and plagiarism and the consequences, please visit
http://ppl.app.uq.edu.au/content/3.60.04-student-integrity-and-misconduct
Project Signpost
The Project will start in the first tutorial and run for approximately ¾ length of the course. Since
the idea of the Project is to continuously build out the System and refine it, with new
instructions and challenges each week until completion, the following represents a weekly
overview of what is required. Specifics for each week will be presented primarily in the
tutorials, with lectures serving as an informational ‘lead-in’. This means that this document
only serves as a guide or roadmap for the Project, so that students know generally what is
coming at different points, which also allows those students who like to plan and tinker
beforehand to do so. However, this also means that coming to lectures and tutorials is
absolutely vital to passing the course. Should you miss a tutorial for a reason that would be
approved for an extension, please email the lecturer before the next tutorial for advice on how
to proceed.
The entire Project process will basically be as follows:
Elicit personal values problem focus => create long-term system vision =>
investigate requirements => create information system concept => prototype the system
=> test the system with users => gather feedback and refine system => redesign
accordingly => reflect on future of system and its possibilities => collate and submit
diagrams and report
Week 2 – Values, Social Problem Focus Goal
Tutorial Activities:
In week 2, the students will begin the tutorial by eliciting core values from each other via a
shortened version of what is known as Repertory Grid and Laddering. This process gets
students to map out and better understand their own values. The goal here is for each student
to be as honest as possible since this will set the stage for the rest of the Project – it will be
extremely difficult for a student to focus and stay on track if he or she begins working on
something that they do not believe in. However, if the student chooses to give ‘safe’ answers
then they will learn a valuable lesson early.
Students will then immediately identify a serious (or as close as they can get to it) problem in
the agricultural sector that they would like to solve with the help of an information system.
The idea here is to find such a problem that also aligns with their core values elicited in the
previous step, brainstorm, get a very rough idea of an information system that could possibly
solve the problem, and consider what and how information will be used in the system to
solve the problem (feedback loops are extremely advantageous here).
Finally, students will have the option to choose a 1) long-term project goal of approximately
2 years, or 2) Big Hairy Audacious Goal (BHAG – will be covered in lecture). The trade-off
with the first option, as in real life, will be that a long-term project goal will be easier to
manage, however, it will likely require less work, be less impressive, etc., and is therefore
likely to attract lower marks compared to projects that have BHAGs. Regarding choosing a
BHAG, the trade-off is that projects will be much more difficult to manage, however, if done
well, are likely to attract higher marks compared to projects that do not have BHAGs.
Follow-on Project Action:
Fill in the template provided on Blackboard, which will be the target for the rest of the
Project.
Week 3 – Pitching the Project Approach
Tutorial Activities:
Students will come up with what is known as a ‘pitch’ in the start-up world, and activities
will closely resemble what might be seen at a mini-hackathon. The idea is for students to
start articulating, very concisely, the outline of their vision from the previous week into a
workable business idea.
This will be a high-intensity tutorial where students will need to think quickly and refine the
idea as fast as possible, making sure that the idea is always aimed at the Goal or BHAG, and
is a workable business idea. A major part of this will be determining how the idea will
realistically bring in revenue or save money to fund itself if part of a bigger business, but
also very important are other areas of a Business Model Canvas such as value proposition,
key partners, etc. – people will not pay for something if there is no value proposition.
The end result should be a polished and concise pitch that serves as a focusing lens for the
Project and helps to start generating new ideas about how it might be designed. It will also be
at this point that students will need to crystalize their Project plans and ensure no conflicts
with other projects (details on how to do this will be provided in lecture and/or tutorial). This
will mean that there is an Advice Point in next week’s tutorial.
Follow-on Project Action:
Refine pitch as needed. Transfer pitch to template. Ensure originality of specific Project.
Fill in “method” section of template to explain what development methodology might be
used for the Project, why it is particularly suited to this particular project, and why the other
approaches might not be appropriate. Optionally, students can come up with their own
‘composite’ approach and justify that. OR if none of these approaches would be appropriate,
explain why. Note: you will be undertaking an Agile approach. However, within this
approach there are many options. So, at the end of the project you should be able to comment
on your recommended approach and adjust this section being more informed.
Week 4 – Investigating Requirements (Advice Point 1)
Tutorial Activities:
In this tutorial students will officially begin their analysis and design activities, which will be
referred to as the Design Sprint, or just “Sprint”.
Students will come up with the Sprint questions, which are the questions that will be used to
guide requirements analysis. These questions will be the result of first brainstorming the
various challenges that their idea might face on its way to implementation, and then
considering how these challenges might be overcome (and if they even can be overcome).
Then students will come up with a user story map that will be used to visualize categories of
user activities, company (theirs) activities, etc., considering what could or should take place
between the moment just before someone discovers their product or service, to the end result.
Finally, you will create a 3-screen concept that will visually illustrate what the product does
in a way that is as self-explanatory as possible. So basically, if students have to explain the
specifics beyond what is presented, it is not that good. A perfect concept is one that can
simply be looked at by anyone and most people would quickly be able to explain it back to
the student.
It should be noted that it would be greatly beneficial to the student during this step to
investigate the requirements from multiple angles (technological, psychological,
sociological, etc.). The idea is to really consider the audience, what they need, and how they
might approach your product. This will likely be multifaceted and needs to be thought about
carefully. This is where feedback loops would make the Project excel.
We will also be examining and practicing some more traditional information requirement
techniques during the tutorial time.
Follow-on Project Action:
Fill in template with long term goal / BHAG along with sprint questions. Transfer user story
map (along with targeted area) as well as concept ‘screenshots’ to template. Depending on
how you do this, the screenshot can be something you have done using a digital program or
pictures you have taken of their paper drawings. It’s up to you, it just needs to be able to be
clearly seen so it can be marked.
You will need to complete the documentation for the systems requirements as part of the
traditional approach. These will need to be updated as you progress through the project.
Week 5 – User Journey and Storyboarding
Tutorial Activities:
In this tutorial, students will finalize their concepts, come up with a user test flow which is
what will eventually be tested, and then create a hand drawn 6-cell storyboard. The goal of
this week is to come up with a storyboard that could be handed off to any designer and they
could immediately get started working on it rather than having to explain to them what
something means or clear up confusion.
The tutorial will also practice modelling techniques.
Follow-on Project Action:
Document the models for your project.
Reflect and consider possible pain points in user test flow that might not have considered
prior to the final storyboard and refine if necessary. Transfer pain points and storyboard to
template.
Week 6 – Prototyping
Tutorial Activities:
Students will create an actual, interactive prototype of their system based on the storyboard.
A list of acceptable prototyping software will be published on Blackboard after class testing
during this tutorial. This will allow for student input, testing of new software at this date and
practice of testing software requirements. You must provide tested access to the markers.
The higher the fidelity of the prototype, the better testing will go, and generally make the
students’ lives easier. The lower the fidelity, the worse testing will go, and the less time
students will have to make revisions. There is obviously a trade-off here too as well as a
point of diminishing returns, so time management and concentration are key for this step.
The aim of this tutorial will be to hash out things out such as what online software to use
and why, trade-offs among the software, and other considerations.
The tutorial will also practice other modelling techniques.
Follow-on Project Action:
Create live, interactive prototype. This will require quite at least a solid day of highly
focused and concentrated work, but likely longer.
Continue to document the model for your project.
Weeks 7 and 8 – User Testing and Feedback (Week 8 Advice Point)
Tutorial Activities:
Students will design user tests and, during the following week, go out and actually test their
prototypes with live users. The users can be anyone, however, the students must consider
how likely each person will be to provide quality feedback. Students must include up to a
couple of sentences the suitability for each user. Example one, the role of the user is works in
this area of agriculture and would use this type of software. Example 2, the user is a student
that has successfully passed HCI design course(s). For each user: name, role, contact number
and signature must be included in the report. This is a major consideration that will be
discussed and worked on in the tutorial. Note: tutors will be contacting some users randomly
for verification and where they believe verification is necessary. Please ensure that you
obtain user consent and inform them that their details will only be shared with the marker for
grading purposes.
The ultimate aim here is to find trends and insights.
Follow-on Project Action:
Test live prototype on live users, making sure to record (if possible) audio and screen for
later reference, and taking detailed notes on not only pros and cons provided by the user, but
also answers to follow up questions on obvious user reactions during the test.
Refine prototype as needed, documenting changes, and transfer to template.
Make changes to the models and documentation.
Week 9 – Architecture and Deployment
Tutorial Activities:
Discuss possibilities for architecture and deployment of application. This will be a deep-dive
into the various pros and cons of contemporary application development languages,
frameworks, and/or libraries, as well as possible systems that the application could be
deployed to.
Further guidance will be provided in lecture and tutorial, however, students that are highly
keen can consider this step during any point in the Project – the earlier, the better.
Follow-on Project Action:
Transfer architecture and deployment strategy to report. NOTE: There will be no deployment
in this course.
Week 10 – Real-World Considerations and Reflection (Final Advice Point)
Part of the Tutorial Activities this week:
Discuss most important insights and/or lessons learned during the course up to this point. For
example, what real-world considerations presented in the course might need to be accounted
for that are not typically considered outside of this class? Is there anything that the students
experienced that did not exactly line up with what they expected, were told to expect, or
what they might have learned in another course? What exactly were these, and how exactly
were (or could) they be handled? How did any of this or the student’s experience align or
misalign with those discussed in readings and classes? What did the student learn about
themselves in the course of the Project? Etc.
The insights can be anything, but they should above all else be about this particular project
(i.e. they are not some generic string of words that could be used to talk about any other
project). The best ones demonstrate lessons learnt (growth) of what was good and what
should not be done again. This is to be about ½ page.
Follow-on Project Action:
Complete Project Report ready for submission.
Final Project Report must have a professional presentation and use a12pt font with numbered
pages. The content must appear in the following order:
Cover Page
Table of contents
System Vision
Problem Description (half a page in report and supported by Project Template
Tutorial 1submitted separately)
User Story Map (supported by Project Template Tutorial 3)
System Capabilities (up to 1 page high level capabilities and a short
explanation about the target area from the user story map)
Business Benefits (supported by Project Template Tutorial 2)
Project Plan used for your project and justification (1 page)
What you would do differently next time (1/2 page) and implementation plan (up to 1
page)
System Requirements (Functional and Non-Functional) (note high weighting)
Reference List
Appendices (note the number of examples required)
Please use a drawing tool for the diagrams and cut and paste into Word. In addition,
each diagram may have assumptions underneath if needed. Furthermore, the diagrams
must have a readable font size and not require the marker to tilt their head to mark
(check Turnitin after submission).
a. One Use Case Diagrams (must be of the target area (will be discussed in
class))
b. One Use Case Description (select one of the main use cases from your target
area use case diagram)
c. An Activity Diagram of the above Use Case Description
d. One Systems Sequence Diagram (prototype must largely match)
e. One Domain Model Class Diagram
f. The Prototype login details
g. User interface and design storyboard with brief justification (merge from
template)
h. Completed User Feedback template (merge into this file and you may scan a
copy of the table with the users’ signatures and include as a picture)
i. Completed User Feedback forms for each user
A separate file must be submitted for the completed templates (one merged
PowerPoint) as Turnitin will not enjoy the templates. Merge together and ensure
presentable.
Submission
The assignment must be submitted electronically through Blackboard. Files submitted as email
attachments will not be accepted. Late submission will result in the reduction of marks.
Detailed submission instructions will be provided closer to the due date.
Marking Rubric
The project will be graded on its scope, usability, maintainability, consistency, credibility, and
suitability toward solving the agricultural problem, how well project pieces are linked and
integrated, as well as the quality. This is evidenced by how well the student ties together all
of the required outputs. The student will also be graded as to how well they have followed the
analysis and design procedures demonstrated during the course and the quality of the final
presentation. For details, refer to the marking rubric attached to the assignment.
You will be marked considering the two following main sections:
• Correct use of diagrams notation: Each diagram MUST comply with the notation learned
in tutorials. Although other notation conventions exist, it is considered correct the one used
in tutorials and written in the tutorial material.
• Correct logic and consistency with the business case: Apply a consistent logic to solve the
agricultural problem is essential. Logic means that each assumption made and what each
diagram describe MUST be considered in all the diagrams as the purpose of the assignment
is solve an agricultural problem. For example, if the solution includes the implementation
of a new way of tracking stockfeed, the diagrams CANNOT include other systems that can
contradict this solution.
Consultation
To ensure that equal and sufficient amount of time is allocated to every student, the average
consultation time (during busy consultation periods) will be limited to 10 minutes per student.
However, in circumstances when there are no other students are waiting, a longer consultation
time is possible. Similarly, to ensure fair treatment to all students, tutors will not be giving
step-by-step guidance on your Project files/works and/or do the Project for you – your Project
is YOUR Project, and YOU are ultimately responsible, not someone else.
Questions regarding your assignment will only be answered if they are general in nature.
Additionally, the course coordinator will be attending some of the tutorials to assist tutors at
advice points. Three have been identified in this document. Others may be added and will be
announced on Blackboard. You must come prepared to advice points for feedback to be
given. This will be further detailed prior to advice points. The time available will be limited
to ensure all students requesting advice are seen. As these are advisory extensions will not be
available unless there are exceptional circumstances.
Extension Application Procedure
Requests for extension of the assignment are to be submitted as per the ECP. Please also refer
to the Faculty’s late assignment policy. Neither course coordinators nor lecturers can grant
assessment extensions to students.
Submission Date
Submission date: 11 May 2020 at 12:00
For each day (including Saturday and Sunday) after the 11 May 2020, a penalty of 5% of the
marks will be deducted until the assignment is submitted. For example, if the assignment is
submitted after 12:00 on 11 May 2020, there would be a 5 % penalty. Or as another example,
if the assignment is submitted after 12:00 on 13 May 2020, there would be a 15 % penalty.