Scenario Template
KIT506 Sample Structured Scenarios for Assignment 2 starting point
1/9
Selected Scenarios for RAP
Use Case #8: User_views_ResearcherList
Requirement:
Upon application start up, the user shall be presented with an interactive list of
researchers (consisting of both staff and research students), known hereafter as the
Researcher List view.
Overview:
The users views the researcher list when the application first loads. This list should
display names in the format ‘Family Name, Given Name (Title)’, as in ‘Einstein, Albert
(Dr)’. In addition to using the list to access researcher details, the user can also filter
the list, either by a researcher’s employment level (including ‘student’) or (if time
available in project) partial name match, or both. For basic filtering, the user should
be able to list all researchers, students only, level A, level B, level C, level D or level
E. If implementing name matching then the list contents would be restricted to show
only those staff whose given name or family name contains the text entered by the
user. Partial matches that span combinations of given and family name do not need
to be supported, so look for matches within both names independently.
Preconditions:
1. RAP database exists and is populated with data
Scenario:
Action Software Reaction
1. User starts application 1. MainView created with ResearcherListView and
adjacent ResearcherDetailView visible
2. System retrieves basic researcher details from
database: name, title and current employment level
3. Researchers are sorted alphabetically by family name
4. System shows names in ResearcherListView
2. User selects an employment level
(including the ‘students only’ or ‘all’
options) from a dropdown list of levels
1. System updates current set of filters to include
selected level
2. System creates temporary list of researchers based
on current set of filters (level or name, if present)
3. System refreshes the ResearcherListView with the
filtered list
3. User modifies text in filter-by-name text
field
1. No reaction; not supporting automatic refresh of list
contents
4. User presses enter key inside filter-by-
name text field
1. System updates current set of filters to include given
text or, if search text is blank, removes any existing text
from set of filters
2. System creates temporary list of researchers based
on current set of filters (level or name, if present)
3. System refreshes the ResearcherListView with the
filtered list
5. User selects researcher in list See UC16 User_selects_Researcher
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
2/9
Scenario Notes:
Actions 1 is a precondition for all others. The other actions may occur in any order,
although it is more typical for Action 3 to be followed by Action 4 (the user pressing
enter to trigger name-based filtering). The reaction to Actions 2 and 4 produces the
intersection of the two filters.
Post Conditions:
ResearcherListView displays all or a subset (particular level or with matching names)
of researcher names
Required Views: (GUIs)
ResearcherListView
Exceptions:
1. If the database is inaccessible or another unexpected error occurs then the
system should respond with a message to this effect, requesting that the user
close and restart the software. (In a later release the system should be made
robust to such exceptions and be able to reload the database without being
restarted.)
Use Cases utilised
UC16_User_selects_Researcher
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
3/9
Use Case #16: User_selects_Researcher
Requirement:
When the user selects a name in the list the researcher details view will be
displayed.
Overview:
Selecting a researcher’s name in the ResearcherListView will show their details (and,
ultimately, their list of publications) in the ResearcherDetailView. The details shown
will vary depending on whether the researcher is staff or student. Each detail will
have a label in the display. All researchers will have: name; title; school/unit;
campus; email; photo (this is stored as the URL of an image); current job title;
commenced with institution; commenced current position; tenure; number of
publications. Staff will also have the following displayed: 3-year average of
publications per year; publication performance; and supervisions. Students will also
have the following displayed: degree; and supervisor name. Staff-specific fields are
left blank for students, while student-specific fields are left blank for staff.
The following data need to be derived from the information in the database:
Current Job Title is derived from their current position’s level: student is
Student; A is Postdoc; B is Lecturer; C is Senior Lecturer; D is Associate Professor;
E is Professor
Commenced with institution is the start date of their earliest position
Commenced current position is the start date of their current position
Tenure is the time in (fractional) years since the researcher commenced with the
institution
3-year Average is the total number of publications in the previous three whole
calendar years, divided by three. For example, if the current calendar year is
2015 then the average is over the period spanning 2012, 2013 and 2014
A staff member’s performance is their three-year average for publications
divided by the expected number of publications given their employment level,
expressed as a percentage with one decimal place shown. The expected number
of publications per year for each level is as follows: A, 0.5; B, 1; C, 2; D, 3.2; E, 4.
Supervisions is the number of students the staff member is currently or has
previously supervised
It would enhance the application if the ResearcherDetailsView also includes a table
of a staff member’s previous positions and those positions’ start and end dates (this
is not required for students).
Preconditions:
1. HRIS database exists and is populated with data
2. ResearcherListView is visible
Scenario:
Action Software Reaction
1. User selects staff name in
ResearcherListView
1. System retrieves from the database any additional
details about the researcher member, including photo
and publications list
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
4/9
2. System calculates basic derived values, including
current job title, commencement dates, tenure
3. If selected researcher is staff then three-year
average for most recent three whole calendar year
period and performance are calculated, as well as
total number of supervisions. ‘Show Names’ button
adjacent to number of supervisions made visible if
number of supervisions is not zero
4. If selected researcher is staff then details of all
previous positions held are loaded from database and
added to small table in ResearcherDetailView
5. If selected researcher is student then supervisor’s
name is retrieved from database. Table of positions,
list of supervisions and ‘Show Names’ button are
hidden
6. System enlarges application window size if too
small to display ResearcherDetailView
7. UC34_User_views_Publications is triggered
2. User clicks ‘Show Names’ button next to
number of supervisions
See UC29_User_expands_Supervisions
3. User clicks ‘Cumulative Count’ button See UC32_User_views_CumulativeCount
Scenario Notes:
Action 1 must occur before Actions 2 or 3, which are independent of each other.
Action 2 is only possible if the displayed researcher is a member of staff.
Post Conditions
ResearcherDetailView displays details of selected researcher and
PublicationsListView displays that researcher’s publications
Required Views: (GUIs)
ResearcherListView
ResearcherDetailsView
CumulativePublicationsView
PublicationsListView
Exceptions:
1. If the database is inaccessible or another unexpected error occurs then the
system should respond with a message to this effect, requesting that the user
close and restart the software. (In a later release the system should be made
robust to such exceptions and be able to reload the database without being
restarted.)
2. If the selected researcher is staff and has not published within the three-year
window then performance should be shown as ‘n/a’
Use Cases utilised
UC8_User_views_ResearcherList (precondition)
UC29_User_expands_Supervisions
UC32_User_views_CumulativeCount
UC34_User_views_Publications
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
5/9
Example low fidelity prototypes
You do not need to follow these designs in your application
Doe, Jane (Dr)
Doe, Jane (Ms) Jane Doe
Doe, Jane (Dr)
Doe, Jane (Ms)John Smith
Smith, John (Dr)
Smith, John (Dr) John
Smith, John (Dr)
Smith, John (Mr)
MainMenu
ResearcherListView
ResearcherDetailView
(including PublicationsListView)
Show:
students only
A
B
C
D
E
all researchers
ResearcherListView
MainView
Filter by name: j
PublicationDetailView
PublicationsListView
(detail elsewhere)
Name: Jane Doe
Title: Dr
Unit: Engineering & ICT
Campus: Hobart
Email: jane. .au
Current job: Senior Lecturer
Commenced with institution: 18/01/2011
Commenced current position: 01/01/2014
Previous positions:
18/01/2011 31/12/2013 Lecturer
Tenure: 4.6 years Publications: 9
3-year average: 2.6 Performance: 116.7%
Supervisions: 1
Degree: Supervisor:
ResearcherDetailsView
Show Names
Cumulative Count
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
6/9
Sample UML models
Note that these would have been one per page in your submission
Research DatabaseView
Bidirectional dependency is because views pass messages back to controllers
Control
Example package diagram
Researcher
-id: integer
+GivenName: string
+FamilyName: string
+Title: string
+School: string
+Campus: string
+Email: string
+Photo: URL
+GetCurrentJob(): Position
+CurrentJobTitle(): string
+CurrentJobStart(): Date
+GetEarliestJob(): Position
+EarliestStart(): Date
+Tenure(): float
+PublicationsCount(): integer
Position
+level: EmploymentLevel
+start: Date
+end: Date
+Title(): string
+ToTitle(l: EmploymentLevel): string
EmploymentLevel
<
+Student
+A
+B
+C
+D
+E
occupies
11..*
Staff
+ThreeYearAverage(): float
+Performance(): float
Student
+Degree: string
supervises
1 0..*
Publication
+DOI: string
+Title: string
+Authors: string
+Year: Date
+Type: OutputType
+CiteAs: string
+Available: Date
+Age(): integer
Many of these operations could
become attributes if the associated
data is calculated when the model
is loaded from the database
OutputType
<
+Conference
+Journal
+Other
has
Control::PublicationsControllerControl::ResearcherController
displayed list
master list
main list
This additional collection will become clear
when we study WPF and data binding
uses
Details have been omitted from
‘imported’ control classes
Researcher includes an integer ID,
which comes from the database
(you were not expected to include
this in your Assignment 1 designs)
Research package
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
7/9
ResearcherController
+LoadReseachers()
+FilterBy(level: EmploymentLevel)
+FilterByName(name: string)
+LoadResearcherDetails()
PublicationsController
+loadPublicationsFor(r: Researcher): Publication[]
uses
Control package
These control classes will probably need additional methods to those shown
ERDAdapter
+fetchBasicResearcherDetails(): Researcher[]
+fetchFullResearcherDetails(id: integer): Researcher
+completeResearcherDetails(r: Researcher): Researcher
+fetchBasicPublicationDetails(for: Researcher): Publication[]
+completePublicationDetails(p: Publication): Publication
+fetchPublicationCounts(from: Date, to: Date): integer[]
Adapter provides access to the
Employment and Research Database
and can load collections of
Researchers and Publications (or
individual items)
PublicationAdapter
This set of operations is for an optimised pattern of
database retrievals, where objects containing the bare
minimum of details are loaded first, then their details
are filled in later, as needed.
Optional: these could probably be rolled into the ERDAdapter;
they would contain similar operations to what I’ve shown in
the ERDAdapter at the moment
ResearcherAdapter
Database package
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
8/9
ResearcherListView
ComboBox
researcher type drop down
ListBox
names list
ResearcherDetailView
MainView
View package
PublicationsListView
PublicationsDetailView
CumulativePublicationsView
ListBox
supervisions list
positions list
ListBox ListBox
You were not expected to include these library classes in your design
You will have more View classes than shown here
KIT206/506 Sample Structured Scenarios for Assignment 2 starting point
9/9
alt
[r is Staff]
: User
: ResearcherListView : ResearcherController : ERDAdapter : ResearcherDetailView r : Researcher
1 : select entry
2 : LoadResearcherDetails()
3 : r := completeResearcherDetails()
4 : update details()
Would actually be a sequence
of properties settings
5 : updated model
6 : SetModel()
7 : CurrentJobTitle()
8 : job title
9 : CurrentJobStart()
10 : start date
11 : Tenure()
12 : tenure
13 : PublicationsCount()
14 : count
15 : ThreeYearAverage()
16 : average
17 : Performance()
18 : performance
When you actually implement this
using WPF and data binding there
will be far fewer method calls
involved as these methods will be
properties of each Researcher object
19 : GetPositions()
20 : list of positions
21
UC16_User_selects_Researcher
: User
: MainView : ResearcherListView : ResearcherController : ERDAdapter
1 : starts system
2
<
UC8_User_views_Researchers
3 : LoadReseachers()
4 : fetchBasicResearcherDetails()
5 : researchers6 : researchers
7 : selects entry in Filter By list
8 : FilterByLevel()
9 : list updated
10 : presses enter in name filter field
11 : FilterByName()
12 : list updated
There will probably be some common, private filtering
method called in both of these interactions