2- Project Management

Learning objectives:
1. Identify the role requirements gathering plays in the systems development
life-cycle.
2. Develop new requirements for a current software system, application, or
website that you use regularly.
Overview
For a project, sometimes timelines are tight, budgets are thin, and there are a lot of
moving parts. What can you do to maximize your chances that your project is a success?
Thankfully, there is a process known as “requirements gathering” that can help with a
project being delivered within an agreed-upon budget and time, with an acceptable level
of quality.
This assignment will give you an opportunity to step into the shoes of an information
systems project manager and think through the process of requirements gathering.
What is a “project” and what are
“requirements”?
The Project Management Institute (PMI, 2021) defines a project as a “temporary”
endeavor “in that it has a defined beginning and end in time, and therefore defined scope and
resources”. A project is not a routine operation, rather it is a specific set of activities that
aim to accomplish a specific goal that are non-recurring, i.e., unique and not routine to
everyday operations. A project can be to “build a building” or “develop an application
that shows funny cat pictures”. It’s a temporary endeavor with a defined start and end
date. A project is not operational work, like ‘pick up the garbage every Monday and
Wednesday’, or ‘perform quality assurance checks on the vehicles that leave the
production’ – these are examples of non-temporary endeavors that fall into the topic of
‘operations’.
Projects have a defined scope, which refers to the project objectives and the
requirements to complete a project. Requirements for a project focus on the “what
needs to be done in this project” part of the scope.
Why Define Requirements?
Imagine I gave you the task of “add mobile support to canvas.fiu.edu” and I left the
instructions at that. You and I may have different interpretations of what that means,
and if you work on adding mobile support to the website without more clarity and
approval on what that means, there is a chance that my expectations will not be met
with the output that you produce.
Why is “requirements gathering” important?
At the core, requirements gathering is used to manage expectations so that your
stakeholders understand what it is that they are going to get as an output of a project. If
due diligence is done with requirements gathering, you’re more likely to have a
successful project. Project success comes from completing a project within scope, within
budget, and within a specified amount of time (all while accounting for project quality).
The project scope includes the ‘requirements gathering’ component of project
management, and if the documented project requirements align with what your project
stakeholders want, then the chances of them being satisfied with your project output
goes up, thus, in turn, increasing the likelihood that your project is a success. If there is a
mismatch of expectations between the output of a project and what your stakeholders
expect, the project can be considered a failure (and sometimes you’ll have to re-do
whatever it is that was worked on to meet the expectations of your stakeholders – this
can come at a cost and can introduce delays to the timeline of a project too).
The image below sums up the importance of requirements gathering as a tool to manage
expectations and deliver an
excellent project:
How do you figure out the requirements?
A project manager or a business analyst typically leads the efforts for requirements
gathering. The process of gathering requirements is often like detective work. To gather
requirements, a project manager or business analyst will utilize a number of tools and
means to obtain information, or clues, from stakeholders (people with an interest or
involvement in the project that is being worked on). He or she will interview various
stakeholders, hold meetings with customers, conduct research, brainstorm with
stakeholders and customers, prototype, survey users, hold focus groups, observe others,
take notes on what users have identified that they want, and on what they do not want,
etc.
For this assignment, you will not be doing normal requirements gathering, rather I want
you to think about any software, system, or website that you use and think about what
you would like to add to it if you had a say in software/website/application
development. A good way to focus your thoughts around this is to first identify which
software/website/application you want to consider for this assignment, and then ask
yourself the question “What would I add to this if I had a say in the matter?”. If you are
unsure after asking yourself that question and letting your thoughts marinate for a bit,
take a look at the competition of that software/website/application, and see what those
offerings have that the one you originally identified doesn’t.
Note that requirements gathering is a lengthy subject of its own, thus this assignment is
meant to introduce you all to this so that you are well equipped to be involved in the
requirements gathering process one day.

What do requirements even look like?
Imagine that you’ve been tasked with serving as a project manager for the development
of a website. Think for a moment about what is on a website. A website has content,
images, page structures, theming elements, security components, etc.
Knowing this, below is an example of what a requirement for a website could look like:
Sample requirement
Note: your requirements cannot be “Mobile support for ‘insert website
name here’”- they need to be different from the example I shared.
Requirement Title: Mobile support for Canvas.fiu.edu
o What: A user interface that is specific to mobile devices (tablets and
smartphones) on the canvas.fiu.edu website.
o Where: Canvas.fiu.edu
o When: If a user connects to the canvas.fiu.edu website, or navigates
to any page on the canvas.fiu.edu website, the page will display in a
mobile format by default.
o Why: To provide mobile users with a user interface that works best
for a mobile device with tactile inputs (touch screen).
o Assumptions:
1.
1.
1. A user is using a mobile device that uses tactile input via
a touch screen.
2. A user is using a common web browser – Google Chrome,
Mozilla Firefox, Safari, Edge, to visit the website on their
mobile device.
3. Minimal user interface styling changes will be required to
accommodate the most used mobile devices from 2015
onward.
4. The configuration of a mobile-specific interface will not
create any obstacles with achieving compliance with Web
Content Accessibility Guidelines 2.1 Links to an
external site. of Level AA.
•
o Exclusions:
1.
1.
1. Specific support for non-common web browsers such as
Opera, AOSP browser, or Samsung Internet.
2. A complete redesign of the user interface to
accommodate mobile devices. Styling will be based on
the desktop and tablet variant of the website.
3. Specific support for dual-screen devices.
4. Specific support for pen-interfaces for a mobile device.
The sample requirement above includes many important details as to what “mobile
support for Canvas.fiu.edu” really means.
Assignment Instructions:
Create 2 requirements for any software, application, or website that you use
regularly using the template below. Refer to my example of “Mobile support for
Canvas.fiu.edu” from the section above for guidance. Need ideas on what can be a
requirement? Check out – https://simplicable.com/new/requirements-examples
Links to an external site. for a starting point (if needed).
Note: your requirements cannot be “Mobile support for ‘insert website
name here’”- they need to be different from the example I shared.
Template for each requirement (includes minimum length
requirements for each section):
Requirement Title: The name of your requirement
o What: Describe what your requirement is for. (minimum 1-2
sentences)
o Where: Describe where this requirement is found (is it on a website,
is it within an app, is it on a sensor, etc.) – (minimum 1-2 sentences
or just one word if appropriate for the requirement)
o When: Describe when your requirement becomes relevant. For
your requirement, think through at what point the user will interact
with this (is it when a user opens an app, is it when they click on
something specific within the app, is it at a certain point in time, is it
in response to something else that happens, is it when they sign-in
for the first time, etc.) – (minimum 1-2 sentences)
o Why: Describe why the requirement is important. (minimum 1-2
sentences)
•
o Assumptions:
1.
1.
1. Describe at least 2 assumptions for the requirement.
Assumptions are things that you assume to be true or
false that should be considered in the context of your
requirement. For example, the user will have an active
internet connection, the user will have a device that is at
least 5 years old, etc. In my former experience as a
project manager, I would take a moment to think through
all that could happen with a project, and I would use that
to help inform any assumptions that I document. An
assumption can be an expectation, a norm, a tradition,
etc. (minimum 2-3 sentences total for the entire
assumptions section)
•
o Exclusions:
1.
1.
1. Describe what your requirement does not include. When
answering this, think about “what will this not do”. For
example, if I am working on a website and I am looking to
add a log-in feature, the specific requirement for the
login feature should not include the ability to sign-in with
your Google account if I do not want it to have that
feature, thus I should specify that. (minimum 1-2
sentences total for the entire exclusions section)
Evaluation rubric – also known as “how will I be
graded on this”
• You are evaluated on % completion based on template and assignment
instructions.
o For example, each individual requirement has 6 parts that are
required (what, where, when, why, assumptions, and exclusions).
o If a submission is turned in that has 2 requirements and 10/12 parts
completed, the score is scaled as appropriate.
o Your requirements need to be realistic – this means that you cannot
make up imaginary information systems concepts. If those are
present in the submission, you will not receive credit for that
respective component of the assignment, thus the score will be
scaled.
• Your requirements do not need to be for the same
software/application/website. One can be for one
software/application/website, and the other can be for another
software/application/website.
• If the minimum length requirement that is detailed in the instructions above
for one of the sections is not met, then you will not receive credit for that
respective section.
o For example, if I ask for 1-2 sentences for the “why” section and
you submit one word then you will not receive credit for that
specific part.
• Please submit this as a Word document or as a PDF – these are the file types
that work well with Canvas (.pages is incompatible).
• Please submit both requirements on a single document – not as separate files.
• If you submit this in a format that is not like the template, there is a 1 point
deduction for not following instructions.
Note – This is an assignment where you will need to think out of the box and think
critically. I encourage you to do a deep dive on the internet and learn about new areas
related to information systems as you work on this (that will help you learn more about
information systems and help with your understanding of technology concepts in general
– it’s a win-win situation for your professional development). Working on this assignment
on the day that it is due is not advised as it may require research on your part to
formulate your thoughts around this. Be sure to plan accordingly so that you set yourself
up for success.