Team Stochastic
Central Washington University
Requirements Specification
Document
Project Name: Cluster
Sampling for Tail Estimation of Probability
(CSTEP)
Editor:
Eric Brown
Authors:
Alan Chandler
Eric Brown
Nathan Wood
Temourshah Ahmady
Faculty Advisor:
Dr. James Schwing
Client:
Dr. Yvonne Chueh
Due Date:
12/08/10
Contents
1
Introduction .......................................................................................................................4
1.1
Project Overview ........................................................................................................................... 4
1.2
Project Scope ................................................................................................................................ 4
1.3
Document Preview ........................................................................................................................ 4
2
Project Overview ................................................................................................................6
2.1
Stakeholders ................................................................................................................................. 6
2.2
Problem ......................................................................................................................................... 6
2.2.1
Current Solution .................................................................................................................... 6
2.2.2
Justification ........................................................................................................................... 6
2.3
Features ........................................................................................................................................ 6
2.4
Constraints .................................................................................................................................... 7
3
Development and Target Environments ...............................................................................8
3.1
Development Environments ......................................................................................................... 8
3.2
Target Environments..................................................................................................................... 8
4
System Model .....................................................................................................................9
5
User Interaction ................................................................................................................ 10
5.1
6
User’s Point of View .................................................................................................................... 10
Functional Requirements .................................................................................................. 11
Requirement F1 ...................................................................................................................................... 11
Requirement F2 ...................................................................................................................................... 11
Requirement F3 ...................................................................................................................................... 11
Requirement F4 ...................................................................................................................................... 11
Requirement F5 ...................................................................................................................................... 11
Requirement F6 ...................................................................................................................................... 12
Requirement F7 ...................................................................................................................................... 12
Requirement F8 ...................................................................................................................................... 12
Requirement F9 ...................................................................................................................................... 12
Requirement F10 .................................................................................................................................... 12
Requirement F11 .................................................................................................................................... 13
Requirement F12 .................................................................................................................................... 13
Requirement F13 .................................................................................................................................... 13
Requirement F14 .................................................................................................................................... 13
Requirement F15 .................................................................................................................................... 13
Requirement F16 .................................................................................................................................... 13
Requirement F17 .................................................................................................................................... 14
Requirement F18 .................................................................................................................................... 14
Requirement F19 .................................................................................................................................... 14
Requirement F20 .................................................................................................................................... 14
Requirement F21 .................................................................................................................................... 14
Requirement F22 .................................................................................................................................... 15
Requirement F23 .................................................................................................................................... 15
7
Nonfunctional Requirements ............................................................................................ 16
Requirement NF1 .................................................................................................................................... 16
Requirement NF2 .................................................................................................................................... 16
Requirement NF3 .................................................................................................................................... 16
Requirement NF4 .................................................................................................................................... 16
Requirement NF5 .................................................................................................................................... 16
Requirement NF6 .................................................................................................................................... 17
Requirement NF7 .................................................................................................................................... 17
Requirement NF8 .................................................................................................................................... 17
Requirement NF9 .................................................................................................................................... 17
Requirement NF10 .................................................................................................................................. 17
Requirement NF11 .................................................................................................................................. 17
8
Feasibility ......................................................................................................................... 19
8.1
Introduction ................................................................................................................................ 19
8.2
Versions....................................................................................................................................... 19
8.2.1
Bare Bones .......................................................................................................................... 19
8.2.2
Enhanced Version ............................................................................................................... 19
9
Conclusion ........................................................................................................................ 20
10
Appendices ....................................................................................................................... 21
Appendix I: System Block Diagram ......................................................................................................... 21
Appendix II: Use Case Diagram ............................................................................................................... 22
1 Introduction
In business and insurance practice, evaluating the adequacy of reserves is very important when
valuation actuaries calculate the probability distributions of involved financial random outcomes. A
faster research system would assist the actuaries and academic studies to project insurance financials
on a stochastic interest rate or equity return basis. This research system will be desktop-based
application made from a combination of C++, Lua, and C#.
The main goal of this project is to provide the actuaries with a more efficient research tool to make
stochastic modeling more accurate and reliable. This application will reduce the amount of time
currently spent on calculations. It will let the statisticians at actuaries and academic studies of actuarial
sciences to estimate and analyze the probability of a large block of business in a short amount of time.
The output of this program, which will be cluster samples for tail estimation of probability, helps the
valuation actuaries to analyze and guide decisions on economic values for various lines of business.
1.1 Project Overview
One of the challenges of estimating the probability distribution of financial outcomes for large insurance
businesses is the run time. Estimating and analyzing the probability of a large block of business is often
too time consuming to be practical. Modelers at actuaries reduce the number of runs or group assets
into asset categories to reduce the run time for each scenario. This way of estimating the probability
distribution of large financial outcomes is not reliable. Additionally, under- or over-estimating large
financial outcomes may lead to poor judgment and even fail the entire business.
1.2 Project Scope
The project is a desktop standalone application. Generally, it will go through three phases to perform its
task; it will have a graphical user interface that interacts with the user to get his/her preferences for the
interest rate path, size of the sample scenarios, and the distance formula choices built-in the system.
Secondly, the system will read stochastically generated scenarios in vector form from a spreadsheet.
Finally, it will estimate the tail probability as cluster samples based on the user selected distance
formula and output the required run-time for the distance sampling process, list of sample scenarios,
and the probability of sample scenarios. The program’s out plays a vital role in professional judgment of
actuaries to evaluate the adequacy of reserves.
1.3 Document Preview
Purpose – This requirements specification document describes the functions and requirements
specified for the CSTEP system. We need to create CSTEP for valuation actuaries to analyze and
project insurance financials on a stochastic interest rate (mainly cluster sampling for tail
estimation of probability).
Scope – The CSTEP system reads stochastically generated scenarios from an Excel spreadsheet
and estimate the probability of tail as cluster samples by using one of the three distance formula
that is built-in the system. Finally, the system output the required run-time for the distance
sampling process, list of selected sample scenarios, and probability of selected sample scenarios.
4
The output of the system will play a vital role in professional judgment of actuaries to evaluate
the adequacy of reserves.
Intended Audience – The intended audiences of this document are our team, client, and those
who work as valuation actuaries evaluating the adequacy of reserves of insurance companies.
Client: Dr Yvonne C. M. Chueh is our client. She is an Associate Professor in the Mathematics
Department at Central Washington University.
End Users: All statisticians and actuarial experts who judge and evaluate a company’s financial
strength can benefit from this application as it relates to projecting insurance financials on a
stochastic interest rate.
Researchers: Researchers who are doing academic and industrial studies on actuarial sciences
can also use our project.
The major sections of this document are as follow:
Project Overview- This section extends on the topics described in the introduction sections and
provides background information on the factors affecting the scope of the project and its
requirements.
Development and Target Environments – This section covers the contents of the hardware and
software resources necessary to build and run the system.
System Model – This section presents a high-level view showing the major components of the
existing and proposed system and their relationships with each other.
User Interaction – This section describes how the system interacts with the user.
Functional Requirments – This section covers all the functional requirements of the CSTEP
system and provides a detailed, clear, and unambiguous description about each functional
requirement.
Nonfunctional Requirements – This section covers all the nonfunctional requirements of the
CSTEP system and provides a detailed, clear, and unambiguous description about each
nonfunctional requirement.
Feasibility – This section explain the feasibility of the system.
Appendices – This section describes the system block and use cases diagrams that we as a team
have developed for requirement specification of our project.
5
2 Project Overview
Begin this section with a carefully written introduction paragraph(s) previewing and summarizing the
section's contents
This section will introduce the clients, stakeholders and intended users, immediately followed with a
detail of the scope of our project and more in depth requirements. We will describe the problem as it
pertains to our clients, and how we will solve the problems, our client is having. Provided with this
section will also be a list of features our project will support and utilize in the final stages. Following this
element, our paper describes the constraints that we will face on our project for the next quarter.
2.1 Stakeholders
Our client is Dr. Yvonne Chueh who is a professor in the mathematics department at Central Washington
University. The stakeholders in the project are Dr. Chueh, and Central Washington University. The
intended users would be mainly actuaries working at large insurance companies who need to determine
probabilities for large clusters of data. Other intended users would be researchers trying to determine
even more extreme cases than the actuaries do of insurance companies.
2.2 Problem
2.2.1 Current Solution
The current solution for estimating tail probabilities for hundreds of thousands of data points is
throwing the data into Microsoft Excel spreadsheets. After plugging in all of this data the actuaries then
run the distance formula, and wait for Excel to sort through a hundred thousand plus data points to. The
actuaries currently using this method to complete their work are misusing their valuable time in
crunching all of these numbers, and having to wait for the completely inefficient Excel spreadsheets to
calculate the values. This is a problem we can make much more efficient for the actuaries.
2.2.2 Justification
To accomplish this we will use Visual Studio 2008 to develop a program, which will perform the same
tasks in an efficient and user-friendly manner. The program will take in the data points in multiple
formats, run the specified formula, and finally output the results into a format of the users choosing. We
must create this program because nothing much like it has ever been created before. With this
successful completion of this program, actuaries will be able to complete their tasks much more
efficiently, and be able to spend time on different things.
2.3 Features
The main features would be a GUI interface, which would allow more efficient running of the formulas.
The user interface would also allow the user to input data from the format they have it in, and modify
the results as they see fit. Another feature would be the output of the data brought in by the user, and
modified by the program.
6
2.4 Constraints
There are several constraints that we need to deal with when tackling this project including:
compatibility of files with our program, different processor capabilities, and time. Our system also needs
to be as reliable as possible because otherwise the users will not accurately be able to complete their
jobs.
7
3 Development and Target Environments
Computer hardware specifications and operating systems define the environments software runs on.
Recognizing the development and target environments and understanding the differences between the
two helps developers recognize the probable limitations on the software when running in a target
environment. This section addresses the environments for this project, identifying the development
environments, the target environments, and the software’s limitations when running in either type of
environment.
3.1 Development Environments
Developers typically use up-to-date computer models and operating systems to develop software. For
this project, the developers will be using computers with multi-core processors, at least two gigabytes of
memory, and Windows Vista or 7 installed. With these specifications, most every program can run
without an issue. Multi-core processors allow several programs to run concurrently without slowing
down, and unless several large applications are running, even this project’s software will have few
memory constraints. Even if 100 megabytes of memory is allocated to hold a large population, the
development environments will certainly cooperate.
3.2 Target Environments
Target environments are any computer systems a target user will run this project’s software on. As
stated later in the non-functional requirements, target users will be using 32-bit or 64-bit versions of
Windows XP, Vista, or 7 to run the software. While all these operating systems themselves will not limit
the software, they may be running on hardware that will. Knowing these limitations will shape the
software as the developers ensure that it meets the requirements.
If Windows Vista or 7 are running on a computer with less than two gigabytes of memory or Windows
XP is running on a computer with less than one gigabyte of memory, the operating system will leave only
a little memory for applications, and a program needing 100 megabytes of memory may not get it. Also,
a system with a single-core processor slower than two gigahertz will likely not run the software as
quickly as desired. During testing, developers will need to determine through stress testing on various
systems how much memory will be necessary to hold large populations and how long processing will
take on slower processors.
8
4 System Model
As of now, we have completed the prototype GUI of the software, but have not completed design of our
system model. We are currently considering different designs, such as Model View Controller.
.
GUI
Data Processor
9
5 User Interaction
This section describes the actions of the CSTEP system from the user’s point of view. One of the goals of
the CSTEP program is to make it easier for actuaries to estimate the adequacy of reserves of insurance
companies. In order to attain this goal, we designed the CSTEP system user interface based on the
standard of user-centered design so that they can interact with the system clearly and simply. To look at
the CSTEP system from the user’s point of view, we analyze a use case of the system.
5.1 User’s Point of View
The following use case describes how the user expects to interact with the program:
1.
2.
3.
4.
Import the data
Select the algorithm formula
Process the data
Export the output
User expects the CSTEP program to read the user’s data from excel spreadsheet in svn format and
process it based on the user’s choice of three different algorithm based formulas that we will build into
the system, and finally the program should export the resulted data as output.
The system user interface has a homepage and four tab pages. The homepage is a windows form that
has the name of the system at the top and five buttons; New Samples, Preexisting Samples,
Documentation, Quit, and About. This page is the start of the program that gives several options for the
user on how to use the program.
10
6 Functional Requirements
Requirement F1
Priority: Essential
Source: Client
Description: The program should be able to process data using the Significance Method.
Requirement F2
Priority: Essential
Source: Client
Description: The program should be able to process data using the Euclidian Distance Method.
Requirement F3
Priority: Essential
Source: Client
Description: The program should be able to process data using the present value distance method.
Requirement F4
Priority: Essential
Source: Team
Description: The program should be able to read CSV files.
Requirement F5
Priority: Essential
Source: Client
Description: The program should have the ability to select the number of results.
11
Requirement F6
Priority: Essential
Source: Client
Description: The program should issue performance warnings if too much data is entered.
Requirement F7
Priority: Essential
Source: Team
Description: The user must be able to select the row and column that is the upper left corner of their
data.
Requirement F8
Priority: Essential
Source: Team
Description: The user must be able to select the size of each scenario by entering data into text boxes.
Requirement F9
Priority: Essential
Source: Team
Description: The user must be able to select the size of each scenario by selecting it in the spreadsheet.
Requirement F10
Priority: Essential
Source: Team
Description: The user should be able to select the number of scenarios by entering it in a text box.
12
Requirement F11
Priority: Essential
Source: Client
Description: V will be the weight factor for how influential a year is.
Requirement F12
Priority: Optional
Source: Client
Description: The program should have adjustable constants in the equation editor
Requirement F13
Priority: Preferable
Source: Client
Description: The program’s equations must be modifiable without recompiling the C++ code.
Requirement F14
Priority: Optional
Source: Client
Description: The program should be able to “nest” or “subdivide” the incoming data.
Requirement F15
Priority: Essential
Source: Team
Description: The program should be able to output its data as CSV.
Requirement F16
Priority: Essential
13
Source: Client
Description: The program should be able to graph the probability of each outputted scenario.
Requirement F17
Priority: Optional
Source: Team
Description: The program should split the nests in the output data.
Requirement F18
Priority: Preferable
Source: Client
Description: The program should estimate the amount of time left as processing proceeds.
Requirement F19
Priority: Essential
Source: Client
Description: If text or blank fields appear in the input, specific error messages should be generated.
Requirement F20
Priority: Essential
Source: Team
Description: The user must be able to select the size of each scenario by entering it in a text box.
Requirement F21
Priority: Preferable
Source: Team
14
Description: The program should issue performance warnings if multiple instances of it are running at
the same time.
Requirement F22
Priority: Optional
Source: Team
Description: The user should be able to edit the universe from within the program.
Requirement F23
Priority: Essential
Source: Team
Description: The program should have documentation that details its features. In particular, the
documentation should be able to walk users through all the use cases.
15
7 Nonfunctional Requirements
Requirement NF1
Priority: Essential
Source: Client
Description: The program must accept up to 128 years of input.
Requirement NF2
Priority: Preferable
Source: Client
Description: The program must accept up to 1024 years of input.
Requirement NF3
Priority: Essential
Source: Client
Description: The program must run on Windows XP, on both 32-bit and 64-bit versions.
Requirement NF4
Priority: Essential
Source: Client
Description: The program must run on Windows Vista, on both 32-bit and 64-bit versions.
Requirement NF5
Priority: Essential
Source: Client
Description: The program must run on Windows 7, on both 32-bit and 64-bit versions.
16
Requirement NF6
Priority: Essential
Source: Client
Description: The program should be able to process 10,000 scenarios into 50 results in 5 minutes or less
on a Turion X2.
Requirement NF7
Priority: Essential
Source: Client
Description: The program should be able to produce up to 1024 outputs.
Requirement NF8
Priority: Optional
Source: Client
Description: The program should be able to produce up to 131,072 outputs.
Requirement NF9
Priority: Essential
Source: Client
Description: The program should be able to have 12 significant digits of precision in all its calculations.
Requirement NF10
Priority: Essential
Source: Client
Description: The program should be able to process up to 131,072 input scenarios.
Requirement NF11
Priority: Preferable
17
Source: Eric Brown
Description: The program should be able to process up to 8,388,608 input scenarios.
18
8 Feasibility
8.1 Introduction
Beginning the project our team decided that to sufficiently our clients’ needs on the project we would
need to fulfill a minimum set of requirements. The requirements listed in this document are an
accumulation of those requirements we first gathered mixed with more that we have gathered along
the way. In compiling this list, we have discovered that our project is in fact quiet feasible, and we will
easily be able to do this within the time limit.
8.2 Versions
8.2.1 Bare Bones
The bare bones version of our project is a user interface that will accept as input a file containing data
points. This file could be in multiple forms of spreadsheets and contain approximately 100,000 data
points each containing roughly 30 entries. The user can then view these points and edit them from
within our program with a series of mouse clicks. The user can also edit the selection size, the universe
size, and the amount of nests in this section. Selecting these changes then brings up more options,
which allow the manipulation of data by the formulas provided. Following the manipulation of data by
the formulas, the program will output the data that is a result of the formulas. Finally, the users can
select a format to output the data to so they can use it for further research.
8.2.2 Enhanced Version
This version will be much the same as the first version with a few added features. These features would
include the capability to modify the formulas to the user’s needs. The enhanced version would also take
in any form of spreadsheet, and work on multiple platforms to reach the most users. Finally, this version
would allow users to choose the amount of nested samples that they chose for output.
19
9 Conclusion
Requirements are a pivotal part of a project this size and the requirements will ensure that our group
creates a project that meets the standards we agreed upon for this project. The sections we have
detailed within this document have given a full description of what requirements we have gathered, and
how they will affect our project. Following these requirements will enable us to create a project that full
meets the needs of all stakeholders.
20
10 Appendices
Appendix I: System Block Diagram
21
Appendix II: Use Case Diagram
Graphical User Interface
Import, Process
and Export Data
Process Previously
Imported Data and Export
User
View Previous
Results
Data Processor
Access
Documentation
22