please do the the attached part of the main project and take a look at the example. JUST THIS PART OF THE PROJECT. I attached the main idea of the projectClassroom Scheduling
There are 2 main sections to this application; administration and generation. Administration would set
the rules, classes, professors, rooms and other settings and configurations for the application.
Generation would generate a schedule of professors teaching classes in given rooms given the rules and
constraints.
Administration
Some items would need to evolve from semester to semester, while others would mostly remain
unchanged for longer periods of time.
Each semester, rules, classes, professors and other items may need to be copied from a previous
semester.
Classes, professors, and rooms are fairly straight forward. They just need creat/edit/update/delete
functionality. Classes may include the section for each class as an atomic item, or the class may have
sub items to represent the sections.
The administrator will assign professors to teach certain classes, so the classroom scheduling will be
combinatorial of Class/Professors X room X time.
Rules
The rules will need to be much more dynamic. Since rules have to be very flexible, it may need its own
rule language to be defined, or the design should include plug-ins to allow quick and easy addition of
new situations. Either way proper design patterns should be employed.
Rules have varying degrees of granularity to be applied. A rule may be that Teacher X does not want to
teach Class Z after 7pm on M/W/ or Fridays. The rule could also be relaxed to simply say that no teacher
should teach any class after 7pm on M/W/F.
Types of rules
Intra Class/Teacher/Room Rules
Intra Class/Teacher/Room Rules are rules that do not involve other combinations of classes, teachers
and rooms.
Examples of rules
•
Teacher X does not want to teach on M/W/F before 4, or on T/TH after 5
Inter Class/Teacher/Room Rules
Inter Class/Teacher/Room Rules are rules that do not involve other combinations of classes, teachers
and rooms.
Examples of rules
•
Teacher Y cannot teach 3 classes back to back
•
•
•
Class Z should not be at the same time as Class Y ( this may be a specific section or all sections )
Class Z should follow Class Y (this may be a specific section or all sections)
Teacher X and Teacher Y should teach on the same days or times preferable.
Rule weighting
Some rules can be relaxed if necessary, so a weighting system may need to be incorporated. An infinite
weight might indicate the rule has to be enforced and no schedule can ever violate this rule. A low
number would indicate that it’s not desirable, but we could allow this under some circumstances. When
comparing different schedules, a lower total weighted value would therefore be the more appropriate
schedule.
Generate Schedule
When all the rules a given, the user can begin generating schedules. Since this will likely be a timeconsuming process the scheduler should likely save the state of a given job. That way if the process
needs to stop then it could restart where it left off. The administrator may want to be able to view
schedules that are created as the process begins running.
Stretch Goals
•
•
•
Distributed processing to speed the lookup through the search space
Containerization. Being able to spin up 50 servers to work in a distributed manner could help
solve the problem quickly.
Multiple users with different views and responsibilities. Some users may only be able to view
the completed schedule. Others may only be able to edit classes etc.
[Project Name]
Software Requirements Specification
Software Requirements Specification
For
[Project Name]
[Issue Date]
[Version Number]
Prepared by:
Author1, Author2, etc.
Last Modified: 2/19/2020
Page 1 of 12
[Project Name]
Software Requirements Specification
Table of Contents
REVISION HISTORY …………………………………………………………………….. 3
1
1.1
1.2
1.3
1.4
1.5
1.6
2
2.1
2.2
2.3
2.4
3
INTRODUCTION ………………………………………………………………………………. 4
Overview …………………………………………………………………………………………………. 4
Goals and Objectives ……………………………………………………………………………….. 4
Scope……………………………………………………………………………………………………….. 5
Definitions ……………………………………………………………………………………………….. 5
Document Conventions…………………………………………………………………………….. 6
Assumptions…………………………………………………………………………………………….. 6
GENERAL DESIGN CONSTRAINTS …………………………………………………… 7
Product Environment ………………………………………………………………………………. 7
User Characteristics…………………………………………………………………………………. 7
Mandated Constraints ……………………………………………………………………………… 7
Potential System Evolution ………………………………………………………………………. 8
NONFUNCTIONAL REQUIREMENTS …………………………………………………. 8
3.1
Usability Requirements ……………………………………………………………………………. 8
3.2
Operational Requirements ……………………………………………………………………….. 8
3.3
Performance Requirements ……………………………………………………………………… 9
3.4
Security Requirements …………………………………………………………………………….. 9
3.5
Safety Requirements ………………………………………………………………………………… 9
3.6
Legal Requirements …………………………………………………………………………………. 9
3.7
Other Quality Attributes ………………………………………………………………………….. 9
3.8
Documentation and Training ……………………………………………………………………. 9
3.9
External Interface ……………………………………………………………………………………. 9
3.9.1
User Interface …………………………………………………………………………………… 10
3.9.2
Software Interface …………………………………………………………………………….. 10
4
SYSTEM FEATURES ………………………………………………………………………. 10
4.1
Feature: ………………………………………………………………………………………. 11
4.1.1
Description and Priority …………………………………………………………………….. 11
4.1.2
Use Case: ………………………………………………………………………………. 11
4.1.3
Additional Requirements …………………………………………………………………… 11
4.2
Feature: ………………………………………………………………………………………. 12
4.2.1
Description and Priority …………………………………………………………………….. 12
4.2.2
Use Case: ………………………………………………………………………………. 12
4.2.3
Additional Requirements …………………………………………………………………… 12
Last Modified: 2/19/2020
Page 2 of 12
[Project Name]
Software Requirements Specification
Revision History
Version
Date
Last Modified: 2/19/2020
Name
Description
Page 3 of 12
[Project Name]
1
Software Requirements Specification
Introduction
1.1 Overview
This section provides an overview of the requirements document and the system
specified. After reading this section the reader should understand the purpose of the
document and have a general idea what the proposed system will do.
The design of this template assumes there will be a separate project document and quality
assurance test plan that will address issues such as schedule, cost, development methods,
development phases, deliverables and testing procedures. If there are other sources of
product requirements such as prototypes, user guides or user interface storyboards they
should be mentioned and referenced in this section.
You may want to identify the intended audience for the document and describe the
individual sections of the document.
Example:
This document defines the requirement for the Innovative Publishing system that is being
developed for UMKC Faculty. The purpose of this document is to represent the system
requirements in a readable way so that clients and stakeholders can understand them and
verify them for correctness but with enough detail that developers can design and
implement a software system from them.
This document doesn’t address project issues such as schedule, cost, development
methods, development phases, deliverables and testing procedures. Those are addressed
in a separate project document and quality assurance test plan.
The Innovative Publishing system is a web-based tool for publishing content on the
Internet. It provides a way for authors to get direct and specific feedback from readers
while imposing minimal additional work for authors and readers.
1.2 Goals and Objectives
Making the goals and objectives of the product explicit guides developers and give
direction to the project. During the development of even a small system developers make
hundreds of tiny decisions (consciously and unconsciously) not specifically addressed by
the formal requirements. Knowing the goals and objectives will help them make the best
decisions for the product.
Goals and objectives also help keep the project on track. Without a clear set of goals and
objectives the scope of the project can grow or shift as new information arrives. Shifting
the focus of the project isn’t bad as long as it is done open and explicitly with everyone in
agreement.
Example:
The three main goals of the innovative publishing product are:
Last Modified: 2/19/2020
Page 4 of 12
[Project Name]
Software Requirements Specification
1. Provide a simple mechanism for readers to offer feedback to authors on content.
The rational is that more readers will offer feedback if the process is easy.
2. Use feedback from readers to add value to the content and improve the experience
of other readers without intervention from the author. For example, book reviews
on Amazon are instant free content that increases the value of the site.
3. The system shouldn’t require any extra effort on the part of the author or other
publishing agent.
1.3 Scope
The scope defines the boundaries of the product – what it will and will not do. Clients
and other stakeholders need a clear understanding what to expect. It’s at the boundaries
of the system where there is the most opportunity for misunderstandings regarding what
is and is not going to be implemented.
System features are described below so The system features section below does specify
exactly what will be included in the system; however, it is not presented in a way that
makes clear functionality at the boundaries of the system.
Example:
The innovative publishing system will solicit feedback from readers including written
comments. Aggregate feedback from readers may be offered directly to other readers (i.e.
articles might be rated), but unedited comments from readers will not automatically be
made available to other readers. The reason for this is the quality of unedited comments is
hard to control.
1.4 Definitions
This section defines potentially unfamiliar or ambiguous words, acronyms and
abbreviations. If terms such as “shall”, “should” and “may” are used to indicate
importance the meaning of these terms should be defined here.
Example:
Use case – describes a goal-oriented interaction between the system and an actor. A use
case may define several variants called scenarios that result in different paths
through the use case and usually different outcomes.
Scenario – one path through a use case
Actor – user or other software system that receives value from a use case.
Role – category of users that share similar characteristics.
Product – what is being described here; the software system specified in this document.
Project – activities that will lead to the production of the product described here. Project
issues are described in a separate project plan.
Shall – adverb used to indicate importance; indicates the requirement is mandatory.
“Must” and “will” are synonyms for “shall”.
Should – adverb used to indicate importance; indicates the requirement is desired but not
mandatory.
Last Modified: 2/19/2020
Page 5 of 12
[Project Name]
Software Requirements Specification
May – adverb used to indicate an option. For example, “The system may be taken offline
for up to one hour every evening for maintenance.” Not used to express a
requirement, but rather to specifically allow an option.
Controls – the individual elements of a user interface such as buttons and check boxes.
1.5 Document Conventions
This section describes presentation conventions use in the document.
Example:
Portions of this document that are incomplete will be marked with TBD. Each TBD item
will have an owner and estimated date for resolving the issue.
1.6 Assumptions
In this section list any assumptions on which the requirements, as they are described here,
depend. Assumptions are conditions, usually outside the control of the performing
organization, that are taken for granted.
Be careful to only document assumptions that are outside the control of the performing
organization. For example, the following is not a valid assumption for the requirements
document: “We assume that all requirements will be documented.” You might be
assuming this but there is no point in documenting it as an assumption here because it is
something that is primary within the scope and control of the performing organization.
The purpose of this section is to document assumptions that are outside the control of the
performing organization—conditions that should be noted because someone will be
taking responsibility for ensuring they hold.
A distinction can also be made between assumptions that pertain to the requirements and
those that pertain to the project as a whole. The software project management plan is the
most logical place to document assumptions that pertain to the project as a whole.
Example:
It is assumed that the client has an ODBC compliant database installed and this database
will be accessible from the machine where the system will run.
It is assumed that the web hosting ISP will allow server-side scripts to access the file
system.
Last Modified: 2/19/2020
Page 6 of 12
[Project Name]
Software Requirements Specification
2 General Design Constraints
2.1 Product Environment
Most software systems don’t exist in isolation. They interact with other systems and are
part of a larger system or environment. This section describes the boundaries between the
proposed system and its environment. The product context may include other
hardware/software systems or a general business context. It may be helpful to specify the
product environment with a block diagram that shows the major interfaces between the
system under development and its environment.
If the system will use an existing database management system describe the interface
here.
Note the user interface, which characterizes an interface between the system and its
environment, is described below.
Example:
The innovative publishing system will be a component of the existing online course
management system used in the computer science department at UMKC. The online
course management system has built-in support for authentication. The innovative
publishing system will use the existing course management system to identify and
authenticate readers. The online course management system also includes a relational
database which will be used through the JDBC/ODBC interface.
2.2 User Characteristics
It’s important for developers to have a complete and accurate image of the end users.
Even when the requirements of the user interface are described in detail the developer
will still make many tiny design decisions during design and implementation. Knowing
the general characteristics of the end users will help the developer make better decisions.
If the specific users of the system are know list them here. More likely there will be user
roles or categories of uses. For each group of users list their responsibilities, characterize
their knowledge of the domain and describe their characteristics including technical
sophistication, background and education.
Prioritize users if necessary. This is especially important when user characteristics
conflict. For example, if the system must accommodate experience users as well as
novices it is important to know which should be given priority in case it’s not possible to
accommodate both groups.
2.3 Mandated Constraints
Ideally requirements will be specified in terms of functionality needed and developers
will have free rein to design and implement a solution. In practice there are constraints on
the eventual design and implementation.
Last Modified: 2/19/2020
Page 7 of 12
[Project Name]
Software Requirements Specification
Constraints may be mandated technologies. For example, the client may specify that a
specific database management system, programming language, and/or operating system
be used.
Constraints limit design and implementation options.
Constraints might be absolute, desirable or optional. If constraints aren’t absolute the
motivation for the constraint should also be given.
2.4 Potential System Evolution
The resulting software system should be maintainable and extensible. Knowing the types
of anticipated changes aids significantly in establishing an architecture that will
accommodate the types of expected changes. This section suggests ways the system is
likely to be extended or modified in the future.
3 Nonfunctional Requirements
Nonfunctional requirements are properties the system must have. Nonfunctional
requirements tend to be orthogonal to functional requirements. For example a system
may have the nonfunctional requirement that it be offline no more than 15 minutes at a
time and not more than ½ hour each week. The realization of this requirements isn’t
limited to one spot in the code. This nonfunctional requirement crosscuts some or all
functional requirements.
3.1 Usability Requirements
It’s hard to image a software system that doesn’t have usability as one of its highest
nonfunctional quality requirements. It’s not enough to just say that the system should be
usable though. Usability requirements must be stated in a quantifiable and testable way.
One method of specifying usability requirements is to specify efficiency, effectiveness
and satisfaction goals for specific scenarios of use (section 4) carried out by
representative users (section 2.2). A simpler alternative is to design a survey to measure
user satisfaction and get consensus on who will take the survey and what will be
considered an acceptable aggregate score.
3.2 Operational Requirements
This section describes the general characteristics of the physical environment for the
product.
Example:
The users’ environment is noisy so the system shouldn’t depend on the user hearing
audible output.
Last Modified: 2/19/2020
Page 8 of 12
[Project Name]
Software Requirements Specification
3.3 Performance Requirements
The main performance characteristics are speed and capacity (memory). Performance
requirements are usually stated as a function of the number of concurrent users. Use this
section to state the performance requirements of the system as a whole. If specific
transactions have their own performance requirements state these requirements below
along with the description of the feature.
Example:
System startup time should be less than 3 seconds. With 30 concurrent users no operation
should take more than 5 seconds and 95% of the operations should take less than 2
seconds.
3.4 Security Requirements
Access to data and features may be limited to specific users. There may also be a
requirement to keep an audit trail of system use. This section describes the security
requirements including the levels and what needs to be protected.
3.5 Safety Requirements
The system may affect the safety of the larger environment. For example, there are limits
on the intensity of stray electromagnetic radiation from electronic devices used in
hospitals. Potential safety concerns should be investigated and documented in this
section.
3.6 Legal Requirements
Some security and safety requirements may also be legal requirements. For example,
federal law protects confidentiality of medical records.
Example:
Student social security numbers will not be visible to other students.
3.7 Other Quality Attributes
There are specific sections above for non-functional quality attributes such as security,
performance, etc. In this section describe any other non-functional quality attributes such
as portability, availability, etc.
3.8 Documentation and Training
An important part of the total system is the documentation and training that is provided
with the system. This section should describe the types and quantity of documentation
and training that will be provided with the product.
3.9 External Interface
External interfaces may be user interfaces or software interfaces.
Last Modified: 2/19/2020
Page 9 of 12
[Project Name]
Software Requirements Specification
3.9.1 User Interface
The requirements document shouldn’t contain design or implementation details. The
logical user interface should be described here. The description here shouldn’t
unnecessarily constrain design and implementation options.
The general personality of the interface should be described here. For example, should
the interface convey a conservative, professional, authoritative or fun attitude? What is
the look and feel? Style? User characteristics were given above in section 2.2 but it may
be helpful to characterize the average user here as adult, teenager or child.
User interfaces may contain a mixture of media types. It may be helpful to describe the
desired/permissible user interface in terms of media elements.
Should the interface be intuitive or will training be provided. If training is required what
types of training will be provided (online help, separate user manual, formal classroom
training).
Ease-of-use requirements should be stated in a way that can be verified. For example,
“the product should be easy to use” isn’t verifiable because it’s impossible to define
“easy” in a measurable way. Must better is “75% of users will be able to use 80% of the
features within 20 seconds without prior training”.
3.9.2 Software Interface
The software interfaces may be locally addressable API’s or remote interfaces using
technologies such as web services.
Example:
The operations defined by use case 4-7 below will also be available programmatically via
XML over HTTP. The exact protocol is described the WSDL document at xyz.
4 System Features
The core requirements of the system are listed in this section. This template recommends
organizing requirements by features rather than use cases. Features are system behaviors
from the user’s point-of-view. The requirements of a feature are described by one or
more use cases plus any additional narration that is necessary
Features should be ranked and listed in priority order. Priority is determined by cost, risk
and value. To prevent arguments over the exact values of these measures this template
recommends using the values: high, medium and low. There should be a written
understanding how the priorities listed here are used to determine what order features are
delivered and what determines essential features, desirable features and optional features.
If you are following a time-boxed or incremental development process, any formula used
to consider what order to implement features should consider not only the priority
defined by cost, risk and value but the features impact on the design and architectures of
Last Modified: 2/19/2020
Page 10 of 12
[Project Name]
Software Requirements Specification
the system. It may be beneficial to implement a low priority feature before a higher
priority feature if it is an important architecture component.
4.1 Feature:
Example Title: Feature: Lecture Rating
Including the title in the heading causes it to show up in the table of contents above. This
makes it easy to find the requirements associated with a feature.
Note, it may be better to organize requirements into separate groups or subcategories. For
example, if there are different user interfaces for different user classes it may be helpful
to organize the user interface specifications above and the features in this section into
separate categories, one for each class of user. Categories may also be defined by mode
or function.
4.1.1 Description and Priority
A short description provides an introduction helpful for understanding the detailed
requirements in the next two sections.
Each feature should include estimates for: cost, risk and value. The developer estimates
cost and risk, the user estimates the value of the feature.
Example:
Cost: medium
Risk: low
Value: high
4.1.2 Use Case:
Example Title: Use Case: Rate Lecture
Each use case should have a short descriptive title that provides a convenient label for
discussing the use case.
A use case captures the system requirements in the form of dialog between the system
and actor. There may be more than one use case for each feature.
4.1.3 Additional Requirements
Include in this section additional functional and non-functional requirements not
specified in the use case(s) above.
Last Modified: 2/19/2020
Page 11 of 12
[Project Name]
Software Requirements Specification
4.2 Feature:
4.2.1 Description and Priority
Cost:
Risk:
Value:
4.2.2 Use Case:
4.2.3 Additional Requirements
Last Modified: 2/19/2020
Page 12 of 12
Roo Balance
Software Requirements Specification
Software Requirements Specification
For
Team 1
September 23, 2010
Version 1
Prepared by:
Casey Droneburg
Last Modified: 09/23/10
Page 1 of 8
Roo Balance
Software Requirements Specification
Table of Contents
1 INTRODUCTION ……………………………………………………………. 4
1.1 Overview …………………………………………………………………………………….4
1.2 Goals and Objectives …………………………………………………………………….4
1.3 Scope …………………………………………………………………………………………4
1.4 Definitions…………………………………………………………………………………..4
2 GENERAL DESIGN CONSTRAINTS …………………………………….. 5
2.1 Roo Balance Application Environment …………………………………………….5
2.2 User Characteristics ……………………………………………………………………..5
2.3 Mandated Constraints ………………………………………………………………….5
3 NONFUNCTIONAL REQUIREMENTS ………………………………….. 5
3.1 Operational Requirements …………………………………………………………….5
3.2 Performance Requirements …………………………………………………………..6
3.3 Security Requirements ………………………………………………………………….6
3.4 Documentation and Training………………………………………………………….6
3.5 External Interface…………………………………………………………………………6
3.5.1 User Interface ………………………………………………………………………..6
3.5.2 Software Interface ………………………………………………………………….6
4 FUNCTIONAL REQUIREMENTS ………………………………………… 7
4.1 Required Features ………………………………………………………………………..7
4.1.1 Use Case: 1 ……………………………………………………………………………7
4.1.2 Use Case: 2 ……………………………………………………………………………7
4.2 Optional Features ………………………………………………………………………..8
4.2.1 Use Case: 3 ……………………………………………………………………………8
4.2.2 Use Case: 4 ……………………………………………………………………………8
Last Modified: 09/23/10
Page 2 of 8
Roo Balance
Software Requirements Specification
Revision History
Version
Date
Name
Description
1
09/23/10
Casey Droneburg
Initial Document
Last Modified: 09/23/10
Page 3 of 8
Roo Balance
Software Requirements Specification
1 Introduction
1.1 Overview
The Roo Balance application will be a mobile app available to smartphone users with an
iOS platform, essentially iPhone, iPad and iPod touch users. The application will provide
access to a Roo Bucks account, a stored value account provided to UMKC One Card ID
holders. The app will allow Roo Bucks account holders to check their balance and see
where they can use their Roo Bucks.
This document provides information on the requirements for the Roo Balance software
application. Project goals, scope and definitions are given in the introduction. Design
constraints and application environment are described in the following section. Nonfunctional requirements are outlined for later verification. Functional requirements are
given to show the system features and expected user interaction.
Project constraints will be included in separate documentation. The Software Project
Management Plan will give specifics on project budget and schedule. A separate Test
Plan document will address test specifications and procedures.
1.2 Goals and Objectives
The main objective of this project is to allow students a way to access their Roo Bucks
account information from a smartphone. The Roo Balance application is expected to:
1. Provide a mobile interface with UMKC.ManageMyID.com to access account
information.
2. Function in a simple and intuitive manner.
3. Provide students with locations to use their Roo Bucks.
1.3 Scope
The Roo Balance application will provide users with the ability to access information
about Roo Bucks from a mobile device using the iOS platform. Users will be able to
check their Roo Bucks account balance by logging in to their ManageMyID.com account
through the app. Users will also be able to see locations that accept Roo Bucks without
logging in to their account.
1.4 Definitions
Roo Balance Application – the product that is being described here; the software
system specified in this document.
Project – activities that will lead to the production of the Roo Balance application.
Client – the person or organization for which this Roo Balance application is being built.
Last Modified: 09/23/10
Page 4 of 8
Roo Balance
Software Requirements Specification
User – the person or persons who will actually interact with the Roo Balance
application.
Use case – describes a goal-oriented interaction between the system and an actor. A
use case may define several variants called scenarios that result in different paths
through the use case and usually different outcomes.
Scenario – one path through a user case
Actor – user or other software system that receives value from a user case.
Developer – the person or organization developing the system, also sometimes called
the supplier.
Stakeholder – anyone with an interest in the project and its outcomes. This includes
clients, customers, users, developers, testers, managers and executives.
2 General Design Constraints
2.1 Roo Balance Application Environment
The Roo Balance product will include a mobile app designed to work on an iOS platform.
This application will interface with a proxy server of our design. This proxy server will
interface with the umkc.managemyid.com website. The proxy server will allow more
efficient maintenance of the software system.
Roo Balance
User Interface
iOS Application
Roo Balance
Proxy Server
Manage My ID
Website
2.2 User Characteristics
Roo Bucks Users: UMKC students, faculty or staff who own a smartphone. Students are
working on their college education and as smartphone owners are likely proficient with
mobile applications.
2.3 Mandated Constraints
The application will run on an iOS platform. This platform was chosen based on
experience with Objective-C and team consensus.
3 Nonfunctional Requirements
3.1 Operational Requirements
Last Modified: 09/23/10
Page 5 of 8
Roo Balance
Software Requirements Specification
Usability: 95% of users will not need to read the user manual to be able to use the
application.
3.2 Performance Requirements
Maintainability: Changes made to the Manage My ID website can be adopted without
altering the iOS application.
3.3 Security Requirements
The Roo Balance app has two features. For the first feature, Use Case 1, Roo Bucks
account security is provided by secure login to the managemyid website. Login
information input via the Roo Balance app will not be stored. For the second feature,
Use Case 2, no security is required and access to Roo Bucks locations is available to all
users.
3.4 Documentation and Training
The Roo Balance application will be delivered to users as a download without
documentation or training. A user guide and system documentation will be provided to
project stakeholders.
3.5 External Interface
3.5.1 User Interface
The user interface will be eye-catching and visually appealing. When users access their
Roo Bucks accounts, the interface will provide a smooth transition with the Manage My
ID website which has a straightforward, understated look and feel.
The interface will be intuitive. As a mobile app it will be streamlined and simple to use.
No training will be provided and it is expected that 95% of users will be able to use the
app without any training.
3.5.2 Software Interface
The Roo Balance proxy server will serve as an interface between the iOS application and
Manage My ID website. It will enable interaction between the user and the remote
website.
Last Modified: 09/23/10
Page 6 of 8
Roo Balance
Software Requirements Specification
4 Functional Requirements
4.1 Required Features
4.1.1 Use Case: 1
Description: User Login / Check Roo Bucks Balance
Actors: student or any Roo Bucks user
Value = high
Cost = high
Basic Path
1. User clicks icon for Roo Bucks application.
2. System prompts user to select an option: View Account or View Locations.
3. User clicks View Account option.
4. System prompts user to enter user e-mail and password.
5. User enters correct user e-mail and password and clicks Login.
6. System displays Account Summary with Roo Bucks balance with options to
logoff or view transactions.
7. User clicks Logoff.
8. System exits.
Alternate Path
1. User clicks icon for Roo Bucks application.
2. System prompts user to select an option: View Account or View Locations.
3. User clicks View Account option.
4. System prompts user to enter user e-mail and password.
5. User enters incorrect user e-mail and/or password and clicks Login.
6. System displays error message: “Invalid Email Address and / or Password for
user@wrongaddress.com ….. Or you may have exceeded the number of
consecutive attempts allowed. Please try again later.”
7. User may choose to login again, returning to step 1, or exit.
8. System exits.
4.1.2 Use Case: 2
Description: Find Where to Spend Roo Bucks
Actors: student or any Roo Bucks user
Value = high
Cost = medium
Last Modified: 09/23/10
Page 7 of 8
Roo Balance
Software Requirements Specification
Basic Path
1. User clicks icon for Roo Bucks application.
2. System prompts user to select an option: View Account or View Locations.
3. User clicks View Locations option.
4. System displays Roo Bucks locations, possibly on more than one screen, with an
exit option.
5. User clicks exit.
6. System exits.
4.2 Optional Features
4.2.1 Use Case: 3
Description: Check Roo Bucks Recent Transactions
Actors: student or any Roo Bucks user
Value = medium
Cost = high
Basic Path
1. Following Login [Use Case 1 Step 6]: System displays Account Summary with Roo
Bucks balance with options to logoff or view transactions.
2. User clicks View Transactions.
3. System displays recent transactions with option to logoff.
4. User clicks Logoff.
5. System exits.
Last Modified: 09/23/10
Page 8 of 8
Purchase answer to see full
attachment
Why Choose Us
- 100% non-plagiarized Papers
- 24/7 /365 Service Available
- Affordable Prices
- Any Paper, Urgency, and Subject
- Will complete your papers in 6 hours
- On-time Delivery
- Money-back and Privacy guarantees
- Unlimited Amendments upon request
- Satisfaction guarantee
How it Works
- Click on the “Place Order” tab at the top menu or “Order Now” icon at the bottom and a new page will appear with an order form to be filled.
- Fill in your paper’s requirements in the "PAPER DETAILS" section.
- Fill in your paper’s academic level, deadline, and the required number of pages from the drop-down menus.
- Click “CREATE ACCOUNT & SIGN IN” to enter your registration details and get an account with us for record-keeping and then, click on “PROCEED TO CHECKOUT” at the bottom of the page.
- From there, the payment sections will show, follow the guided payment process and your order will be available for our writing team to work on it.