Solution Spec

Requirements Specification
for
UW-IT Portal
Prepared by AE 1
Alice Chen, Ana De Las Alas, Logan Selley

1. Executive Summary
Include a brief executive summary that provides an overview of current issues and how your
system will address them.
UW-IT’s current system layout causes a lot of problems not only for users but for themselves.
There are three separate websites, Knowledge Navigator, BI Portal, and also UW profile.
Having three separate websites and design schemes increases costs and makes changes to
the system seem even more daunting (Pietrzak & Portwood, 2019). Furthermore, problems
include: there are three entirely separate portals, but a lot of their functions are related. The
current system lacks information about portal tools and how to use the tools. Outdated UI/UX
design is also one of the main issue and it causes users/stakeholders to be confused by the
issue. Knowledge Navigator on the other hand, it is different from other two websites. And the
main use for Knowledge Navigator is that to search about the definition for a term. It seems that
not a lot of users would use it because it does not have much use to them. Our systems
addressed most of the problems. We added the advanced search bar function to addresses the
issue of users struggling to find the reports that they are looking for. The advanced search bar
function allows users to add as many filters as they would like and narrow down the reports that
appears in the search results. After you search something, each of the three portals will be
shown as tabs on the top of the screen. This allows stakeholders to easily jump back and forth
between different portals. In the welcome page, there will be categories displayed on the
dashboard, such as ‘favorites,’ ‘recently viewed,’ and ‘suggested reports.’ This will help users
gain easy access to the reports they constantly view. Instead of making Knowledge Navigator a
separate website, current if you want to know a definition of a term, you can hover over the text
and it will show the definition and a link to Knowledge Navigator.
2. Introduction
2.1 Purpose
Describe the scope of the system that is covered by this SRS, particularly if this SRS describes
only part of the system or a single subsystem.
This system essentially describes a modification to the current system where the three
existing portals that represent the front-end of UWIT are combined into a single portal with
minimal changes to UWIT’s back-end. This solution does not involve any changes to the
database or the data being presented (UW IT Connect).
2.2 Scope
Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals. Relate the software to corporate goals or business strategies. It
is ok to reuse information you developed as part of your Vision and Scope and Business Case
Documents.
This new portal aims to combine UWIT’s three existing portals into a singular one with all
the same functionality while also redesigning and improving the new portal’s design in a way
that would both encourage new users to use the many available features and allow existing
users to access the data they seek faster than ever before. For UWIT, this solution would result
in a massive decrease in server maintenance and upgrades, not only cutting costs but allowing
the department to focus more on the users themselves instead of the portals (WebFX, 2019).
2.3 Assumptions and Dependencies

List any assumptions that could affect the system described in this SRS. These could include
third-party or commercial components that you plan to use, issues around the development or
operating environment. The project could be affected if these assumptions are incorrect, are not
shared, or change. Also identify any dependencies the project has on external factors, such as
software you intend to use.
Assumptions:
● Users/Stakeholders would benefit from and desire a consolidated system
● Users/Stakeholders would like to be able to search terms/info from all 3 portals
concurrently
● Users/Stakeholders will use features if they know about them and are convenient
to use
Dependencies:
● The backends of the portals overlap in a way that is not too obstructive to
consolidation
● Users/Stakeholders will be quick to learn new tools and a new UI if they are
well-designed
● Algorithms for search and suggested reports will be accurate and useful
2.4 Current State

Include a brief description of the current state to help frame the issue or problem you are trying
to solve. The current state should include the stakeholders involved in the current process, a
brief bullet point overview of the existing process and the list of current issues. Include a
diagram of the current process if this helps articulate the current state.
UWIT’s current system layout causes a lot of problems not only for users but for
themselves. Having three separate websites and design schemes increases costs and makes
changes to the system seem even more daunting. These three portals all serve similar
functions, but there is little overlap between how each portal is structured as they were all
developed independently of each other. This causes the users to think of the portals as entirely
separated systems for different types of users when in reality they are best used together. This
mentality causes users to self-isolate themselves to a preferred portal and write off the other two
as not for them, causing them to miss out on the data and functionality provided by the other
portals (Panel Discussion, 2019). These outdated and different UI designs also work to hide
features and tools from the users even in the portals that they do use. While the UIs may have
been cutting edge at the time of their creation, they haven’t kept with current design standards
and now seem anything but intuitive to the average user (Collaborations).
3. System Description
3.1 System Overview
Describe the system or solution. For example, state whether your system is an add-on or
modification to a system, a replacement for certain existing systems, or a new, self-contained
product. Include a simple diagram that shows the major components of the overall system,
subsystem interconnections, and external interfaces can be helpful.
Our proposed solution is a combination of the three existing portals that would replace all
three services. The biggest step of this solution is a new UI that would be required to effectively
integrate all the functionality and tools of the three portals. We believe that this new and
improved UI will be not only intuitive enough to not scare off new users, but condensed enough
to allow experienced users to access the data they are looking for faster than ever before. One
key aspect of this is the implementation of a universal search across all portals that would serve
to be the main avenue in which users find the data they are looking for. The search function
would also contain an advanced mode that would serve users that wanted more control over the
results that would be displayed. The other way users could access their reports would be
through the displayed ‘favorite’ and ‘suggested’ reports on the users’ customized homepage.
These features would allow users to revisit data or find new interesting reports with a single
click. Perhaps the biggest benefit of this solution is the massive reduction in system
maintenance time and costs, which allows UWIT to put those resources elsewhere.
3.2 Key Users

Identify the various users or stakeholders that you anticipate will use this product. Describe the
characteristics of each user or stakeholder group.
Stakeholder Desired Benefits Measured by
Department heads / Improved Reduction in time to

Faculty productivity search for
data/reports
Research Easier to find reports Increased ease in

Administration with the data they finding specific
are looking for reports with specific
data
HR Quick access to Reduction in time to
specific data/reports access specific
often-used reports
3.3 Design and Implementation Constraints

Describe any items or issues that will limit the options available to developers. These might
include: corporate or regulatory policies, hardware limitations, interfaces to other applications,
specific technologies, tools, and/or databases to be used
The design of the portal is limited by the guidelines of UW branding, as well as being
FERPA and WCAG accessibility standards compliant. Beyond the design, the portal has to
interact with the database that holds all of the data/reports that it presents (Divisions).
4. User Interfaces
Advanced Search Bar:
The advanced search bar function allows users to add as many filters as they would like and
narrow down the reports that appears in the search results. This becomes useful when a user
knows exactly what type of report he or she is looking for. This page can be reached after
clicking an advanced search button near the search bar shown at the top of the home page.
Favorite/bookmark:
This page demonstrates how each of the three portals will be shown as favorite/bookmarks on
the top of the screen. This allows stakeholders to easily jump back and forth between different
portals. The tabs feature will be useful for users who are familiar with using just one of the
portals because the user can just remain on the portal they are used to when using the system.
It also has search feature to allow users/stakeholders to search their bookmarked reports in a
shorter time.
Search results:
The results displayed after a search is made will be separated into three columns depending on
where the report or information was grabbed from. For instance, the reports taken from the BI
Portal will be listed under the BI Portal tab.
Dashboard/homepage:
This page illustrates the personalized dashboard shown on the home page when the user
successfully logs into the system. There will be categories displayed on the dashboard, such as
‘favorites,’ ‘recently viewed,’ and ‘suggested reports.’ This will help users gain easy access to
the reports they constantly view.
Report page after run a report
Hover over a unknown term:
This page shows what it looks like after a user runs a report. If a user finds an unknown term,
instead of going into Knowledge Navigator to search for the term, hover over the text and it will
show the definition and a link to Knowledge Navigator.
5. System Adoption
Describe what changes and activities are necessary to drive the successful adoption or usage of
your new system. i.e. in person training, online documentation, marketing etc. Be sure to include
the measures you will use to measure the success of the system and that provide feedback for
future releases.
We must follow through with certain steps in order to ensure a smooth system adoption. One of
the most important components of this project is to notify users of this transition to a new
system. To do this, we plan to have a banner that pops up on the user’s page after logging into
any of the three portals. The banner will explain how the current portal can be accessed from a
new system after a certain date. Users can click a button on the banner to learn more about the
system transition. Additionally, we plan to send emails to the UW departments and programs
that use these portals to inform their faculty and staff members of the projected move. Once the
new consolidated system is up and running, we plan to have a message that pops up on the
sites of the old three portals that redirects the user to the appropriate site to access the new
system (Lernell, 2016).
In order to help users navigate through the new system, there will be pop-up messages on the
page that will give users a mini tutorial of the system. These tutorial messages will only pop up
the first time the user logs into the new site and will have an option for the users to click out of
the tutorial. As the users are still getting used to the new system, there will be a help tab on the
menu bar of the system that will give answers to a list of frequently asked questions and will
provide contact information of UW-IT employees who can help troubleshoot any issues users
have.
Our team plans to measure the success of the new system in different ways. We will look into
the data analytics of user activity on the system and identify how much time users spend to find
the report they need. We can measure whether the user has found a desired report by checking
to see if the user ran or downloaded the report (AJ, 2016). We also plan to have a tiny window
that pops up in the corner of the screen and prompts users to rate their experience on the new
system from 1 to 5 stars. This will give UW-IT a better understanding of how users are liking the
new system. Rating the system will be an optional choice that users can make. Lastly, to
provide feedback for future releases, we plan to display notifications of changes on banners that
would appear at the top of the screen (Lernell, 2016).
6. System Requirements
This section details key functionality or behavior for your new system. Requirements should be
easily tracked so be sure to include a unique identifier.
Given scope of this system, it is expected that you would have at least 10-15 functional
requirements detailed.

Requirements should use the format we reviewed in class. [optional precondition] [optional
trigger event] the system shall [expected system response].

6.1 Functional Requirements
6.1.1 Functional Requirement 1
These are the software capabilities that must be present in order for the user to carry out the
services provided by the feature, or to execute a particular use case. Include how the product
should respond to anticipated error conditions or invalid inputs.

Requirements should use the format we reviewed in class. [optional precondition] [optional
trigger event] the system shall [expected system response].

1. If the researcher ran into a term that they don’t know about, they want to find out what
the term means on this report, they can hover over the word and click on the word using
the mouse. This will redirect them to a small pop-up window and shows the term and
there will be a link to knowledge navigator to see what the related to the term.
2. If the professor does not know what report they are looking for exactly, they can use the
feature of the advanced search. They can click on the advanced search button and a
short list of question will pop up to locate what kind of the report that they are looking for.
3. If a student is looking for certain trends in grades for admitted students in the iSchool,
the student can use the advanced search to look for reports based on grades and then
compare them to see the pattern for grades for admitted students.
4. If a department chair is looking into how many students they accepted in the new Info
cycle, they can use the the advanced search bar and select BI portal if they want to run
the report in a specific website. This will redirect them to a page where they can put
additional information where they can add additional filters such as gender and class
standing in order to get a better understanding of the report.
5. If the government wants to look into information regarding the performance of
international students vs. domestic students, they can find grade reports and use the
advanced search to filter out international students and domestic students
simultaneously and compare their performances based on different time periods or other
filters.
6.1.2 Functional requirement 2 etc…
6.2 Use Cases
Describe the detailed use cases that the new system will support. Be sure to include Use Case
diagrams to illustrate the actors each use case interacts with. Given scope of this system, it is
expected that you would have at least 1 0-15 uses cases detailed. Uses cases should be detailed at
the ‘Blue’ or Sea level. Blue level use cases should describe the following: Use Case Name and
description, Trigger, Actor(s), Preconditions, Minimal Guarantee, S uccess Guarantees, Flow of
Events, and any Extensions.

1.
Title: Accessing Enrollment Data
Description: How a user would go about finding and accessing data through the
search bar on the portal
Primary Actor: UW staff member user (i.e. data analyst, department head, etc.)
Preconditions: Use case begins from the opening page of the website, the user’s
homepage
Stakeholders: Staff member, UW-IT, UW consolidated portal
Level: Summary
Preconditions: - User knows what scale of metadata he would like to obtain

(enrollment data from one department vs. one course vs. all
of UW)
- User is aware of search bar feature
Postconditions: - Use case ends once the user has arrived at the data he
intended to obtain
Main 1. User selects the search bar at the top of the home page and
Success enters his search query
Criteria/Scenario: 2. User is brought to a page of results from all 3 portals
including both data and metadata
3. User selects the most promising result and is brought to the
page containing the data he was searching for
Extensions: Search result may point user to knowledge navigator to define the
term, but can access relevant reports to that term from knowledge
navigator.
User may not be satisfied with the initial report they selected and
can either re-enter the search query or go back to the results page
using their browser
Frequency of Numerous times each day

Use:
Triggers: - intuitive naming
- results ordered by relevance
- successful browsing
Relationships: Consolidated portal holds data from EDW and other sources. UW-IT
maintains portal. Universal search bar connected to all 3 platforms
(UW Profiles, BI portal, Knowledge Navigator). User discovers data
and reports through search queries.
Flow of Events: User logs in → User clicks search bar at top of home page → User
types in search → User sees results separated by where data came
from → User clicks on promising result → User views data he needs
2.
Title: Analysing Data
Description: How a user would go about finding the right data and analysing the
data from charts/report that they found
Primary Actor: data analyst, department head and UW staff
homepage, there is search bar
Postconditions: Use case ends once the user has arrived at the data they searched
for and able to analysing it using the current report/chart
Main 1. User selects the advanced search bar at the top of the page and
Success enters their search query
Scenario: 2. User is brought to a page of results including different charts and
graphs that they can use to analysing their data.
3. User selects the most promising chart/graph, the page opens up
and shows more details.
navigator.
User may not be satisfied with what they selected and can either
re-enter the search query or go back to the results page using their
browser

Use:
Relationship: UWIT can create charts, graphs and reports depends on the data
they got from EDW and other sources.
Triggers: - successfully access the report/chart/graph

- able to read or analysing data from the report/chart/graph
they selected
Flow of Event: User log in -> main page -> click search bar -> put in specific data
they want to look at -> user sees result come up -> user pick on
promising result -> user able to use this data/download the analysis.
3.
Title: Checking favorite/bookmarked reports
Description: How a user would go about finding and accessing

favorite/bookmarked reports through favorite
Primary Actor: Department chairs
homepage
Level: Summary
Preconditions: - User have already used the UWIT websites before

- User is aware of favorite/bookmark feature
- User have bookmarked reports
Postconditions: - Use case ends once the user has arrived at the page
contains all the bookmarked favorite reports
Main 1. User log in to their account
Success 2. User go into the homepage
Criteria/Scenario: 3. User see the bookmark section at the home page
4. User select a report they are looking for
OR
5. User select the heart icon at the top of the every page after
they sign in
6. User is brought to a page of bookmarked reports
page containing the data he was looking for
Extensions: User may want to go to their favorite/bookmarked during any time of

their browsing through report. They can access the favorite report
page anytime through clicking the heart icon on the top of every
page, next to the User information icon.

Use:
Triggers: - Click the heart icon
- Save favorite report
(UW Profiles, BI portal, Knowledge Navigator). User re-discovers
data and reports through saved bookmarks/favorite features.
Flow of Events: User logs in → User clicks bookmark in the home page → User go
to a different page → User sees all their favorite reports are in one
page→ User clicks on promising result → User views data he needs
4.
Title: Comparing performance of International vs. Domestic Students
Description: How a user would go about finding the right data and comparing the
data from charts/report that they found
Primary Actor: Government official

for and able to analysing it using the current report/chart
navigator.
browser
Frequency of Biweekly
Use:
they got from EDW and other sources. User obtains data through
queries.

they selected
promising result -> user able to use this data/download the analysis.
5..
Title: Finding Trends in Grades for Admitted Students
Description: How a user would go about finding certain reports and comparing
results
Primary Actor: Students
homepage
Stakeholders: Staff member, UW-IT, UW consolidated portal, Students
Level: Summary

of UW)
intended to obtain and compared it successfully
4. User opens reports for different years and see trends in how
grades change
navigator.
User can export reports and use other applications to perform data
analysis on it.
Frequency of Numerous times each week

Use:
→Users analyzes data→ User notices trends in data
6.
Title: Adding to Favorites
Description: How a user would go about finding the right report and favoriting it.
Primary Actor: Department chair
for and marked it as a favorite.
4. User clicks on heart icon to add it to his/her favorites
navigator.
browser

Use:
Relationship: Specific reports are bookmarked by the user.

- Report added to favorites
promising result -> clicks on heart icon.
7.
Title: Finding the Meaning of a Term
Description: How a user would go about finding the meaning of a term
Primary Actor: UW staff member (i.e. data analyst, department head, etc.)
homepage
Level: Summary

of UW)
- User is aware of hover feature
Postconditions: - Use case ends once the user has arrived at the definition of
the term
4. User hovers over the term in the report and is able to view
the pop-up window.
navigator.

Use:
Relationships: User discovers data and understands meanings of words through

Knowledge Navigator.
from → User clicks on promising result → User hovers over specific
term → Pop up window appears with definition
8.
Title: Knowledge Navigator
Description: How a user would utilize Knowledge Navigator to find the definition
of a term
Primary Actor: Student
homepage, Knowledge Navigator tab is next to the search bar
Postconditions: Use case ends once the user learns the definition
Main 1. User selects the Knowledge Navigator tab.

Success 2. Type the term on the website
Scenario: 3. Obtain results related to the term
Extensions: If a user desires to return to the portal they can do so through the
Knowledge Navigator website.
User can change phrasing to find different iterations of a phrase.

Use:
Relationship: User discovers Knowledge Navigator and finds definitions for terms
on it.

they selected
Flow of Event: User log in -> main page -> click Knowledge Navigator tab -> Inputs
term and search -> Click on desired option
9.
Title: Finding Certain Report for Class
search bar on the portal and printing it
Primary Actor: Student
homepage
Stakeholders: Staff member, UW-IT, UW consolidated portal , student
Level: Summary

of UW)
intended to obtain and printed it out
4. User prints out report
navigator.
using their browser
Frequency of Numerous times each month

Use:
and reports through search queries. User prints out data.
→ User prints out report
10.
Title: Obtaining Demographics of Freshmen Class
Description: How a user would go about finding the right data.
Primary Actor: UW First Year Programs
for.
navigator.
browser

Use:
they got from EDW and other sources.
promising result -> user able to use this data

7. Accessibility Requirements
Describe the detailed accessibility requirements your system will support. You can review the
WebAIM's WCAG 2 Checklist for guidance on what should be addressed.

We have designed our system to meet several accessibility requirements and to ensure our
system is inclusive of as many stakeholders as possible. We plan to provide alternative text for
each photo or image we have on the platform. We
also intend to use semantic markup in as many places on the application as we can so that we
can communicate the meaning of our content to a browser. Additionally, we will work to make
our content clear to readers. We plan to have a contrast ratio of at least 7 to 1 for text and
images of text. This will aid in separating foreground details with background details (Kyrnin,
2019). Lastly, we plan to have hover features on the application that are compatible with screen
readers. This will keep our application usable for those utilizing screen reader tools (WebAIM,
2018).

8. Security Requirements
Describe the detailed security requirements your system must support.

While designing our system, we considered multiple security measures that would help ensure
that our user’s information can remain protected. For starters, in order to access any
information one must login through their UW net-id. Furthermore, our system will leverage two
factor authentication to ensure that the user is who they claim to be. In addition, there will be an
automatic log-out that takes place after a set amount of idle time. This feature makes sure that
users do not have to worry about leaving their account logged on. Finally, we plan on providing
users with detailed account activity in order for them to be able to trace when and where they
accessed the system and what actions took place during that period.
9. Architecture
Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must coexist. Be sure to call out those items that will be custom developed and those that will
be purchased and installed locally or hosted externally.
As the project is a web platform, the software should operate on any operating system,
including but not limited to Windows XP - 10, MacOS and Linux. The website itself should be
compatible and tested with all mainstream web browsers including Chrome, Firefox, Safari,
Microsoft Edge, and Opera. Beyond these basic client requirements, the project doesn’t require
any other custom software or hardware in order to function.
10. Appendix
10.1 Glossary
Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the
entire organization, and just include terms specific to a single project in each SRS.
BI Portal: operation reporting system that connects users to the UW Enterprise Data
Warehouse and provides reports and visualizations
EDW: stands for Enterprise Data Warehouse, warehouse holding data about the University of
Washington
Knowledge Navigator: a map of the data ecosystem that gives context to data from the UW
Enterprise Data Warehouse
Minimum Guarantee: the smallest guarantee a system can offer to its stakeholders, found in a
use case
Preconditions: certain circumstances about the state of a system that must be met before a
use case can begin
Requirements: conditions that must be met in order for a project to be deemed a success
Stakeholder: an actor who is affected by or uses a system or product
Success Guarantee: a guarantee offered by the system when the use case follows through
successfully
Use Case: a planning tool used to identify and organize the requirements of a system or
application
UW-IT ERA: Enterprise Reporting and Analytics branch of UW-IT, employees deal with
operational reporting, managing metadata repositories, working with analytical cubes
UW Profiles: platform that holds institutional dashboards containing broad, holistic data about
the UW
10.2 References
List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough information so that the reader
could access a copy
AJ. (2016). 6 Great Metrics to Measure ERP Success. Profit Solutions International.
Retrieved from https://psierp.com/6-great-metrics-measure-erp-success/.
Collaborations. (n.d.). UW Information Technology. University of Washington. Retrieved
from https://www.washington.edu/uwit/collaborations/.
Divisions. (n.d.). UW Information Technology. University of Washington. Retrieved from
https://www.washington.edu/uwit/divisions/.
IT Governance. (n.d.). UW Information Technology. University of Washington. Retrieved
from https://www.washington.edu/uwit/it-governance/.
Kyrnin, Jennifer. (2019). Why Use Semantic HTML? Lifewire. Retrieved from
https://www.lifewire.com/why-use-semantic-html-3468271.
Lernell, Colin. (2016). How to Communicate Product Changes to Your Users. UserVoice.
Retrieved from http://community.uservoice.com/blog/how-to-communicate
-product-changes-to-your-users/.
Panel Discussion. (2019). Stakeholder Panel Discussion. INFO 380.
Pietrzak, B., & Portwood, M. (2019). Enterprise Reporting and Analytics. INFO 380
Lecture. R etrieved from https://canvas.uw.edu/courses/1271667/files/55478223/
download? wrap=1.
Soltech. (2019). How Long Does It Take To Build Custom Software? Soltech. Retrieved from
https://soltech.net/how-long-does-it-take-to-build-custom-software/.
UW IT Connect. (2016). IT Connect About Us. University of Washington. Retrieved from
http://itconnect.uw.edu/work/data/about/.
Wardynski, J. (2017). How Long Does it Take to Build Custom Software for a Business?
Brainspire. Retrieved from http://info.brainspire.com/blog/how-long-does-it-take-to-build
-custom-software-for-a-business.
WebAIM. (2018). WebAIM’s WCAG 2 Checklist, WebAIM. Retrieved from
https://webaim.org/standards/wcag/checklist.
WebFX. (2019). How Much Should a Website Cost in 2019? WebFX. Retrieved from
https://www.webfx.com/How-much-should-web-site-cost.html.
10.3 Example written use case
Title: Accessing Enrollment Data

search bar on the portal
Primary Actor: UW staff member user (i.e. data analyst, department head, etc.)
homepage
Level: Summary

of UW)
intended to obtain
navigator.
using their browser

Use:
Minimal Users will have more tools to aid them when accessing different
Guarantee types of metadata
Success Users know exactly how to search for a certain report or piece of
Guarantee information. Users can more efficiently obtain metadata
Image Source: Valacich, Modern Systems Analysis and Design

Solution Spec

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Solution Spec

Uploaded by

Copyright:

Available Formats

Requirements Specification

Alice Chen, Ana De Las Alas, Logan Selley

2.3 Assumptions and Dependencies

2.4 Current State

3.2 Key Users

Stakeholder Desired Benefits Measured by

Department heads / Improved Reduction in time to

Research Easier to find reports Increased ease in

3.3 Design and Implementation Constraints

Advanced Search Bar:

Hover over a unknown term:

6.1 Functional Requirements

6.1.1 Functional Requirement 1

6.1.2 Functional requirement 2 etc…

6.2 Use Cases

Stakeholders: Staff member, UW-IT, UW consolidated portal

Preconditions: - User knows what scale of metadata he would like to obtain

Frequency of Numerous times each day

Primary Actor: data analyst, department head and UW staff

Frequency of Numerous times each day

Triggers: - successfully access the report/chart/graph

Description: How a user would go about finding and accessing

Primary Actor: Department chairs

Stakeholders: Staff member, UW-IT, UW consolidated portal

Preconditions: - User have already used the UWIT websites before

Extensions: User may want to go to their favorite/bookmarked during any time of

Frequency of Numerous times each day

Primary Actor: Government official

Triggers: - successfully access the report/chart/graph

Title: Finding Trends in Grades for Admitted Students

Primary Actor: Students

Stakeholders: Staff member, UW-IT, UW consolidated portal, Students

Preconditions: - User knows what scale of metadata he would like to obtain

Frequency of Numerous times each week

Primary Actor: Department chair

Frequency of Numerous times each day

Relationship: Specific reports are bookmarked by the user.

Triggers: - successfully access the report/chart/graph

Description: How a user would go about finding the meaning of a term

Stakeholders: Staff member, UW-IT, UW consolidated portal

Preconditions: - User knows what scale of metadata he would like to obtain

Frequency of Numerous times each day

Relationships: User discovers data and understands meanings of words through

Main 1. User selects the Knowledge Navigator tab.

User can change phrasing to find different iterations of a phrase.

Frequency of Numerous times each day

Triggers: - successfully access the report/chart/graph

Stakeholders: Staff member, UW-IT, UW consolidated portal , student

Preconditions: - User knows what scale of metadata he would like to obtain

Frequency of Numerous times each month

Description: How a user would go about finding the right data.

Primary Actor: UW First Year Programs

Frequency of Numerous times each day

10.3 Example written use case

Title: Accessing Enrollment Data

Stakeholders: Staff member, UW-IT, UW consolidated portal

Preconditions: - User knows what scale of metadata he would like to obtain

Frequency of Numerous times each day

Image Source: Valacich, Modern Systems Analysis and Design

You might also like