Spreadsheet 2.0
Product Requirements Document Update
We have some new information on the requirements for Spreadsheet 2.0.
Clarification: Rows and columns
In the "A1" notation, A represents the column and 1 the row. Also,
rows are 1-based (there is no row 0).
Requirement: Dynamic Speadsheet
The spreadsheet should dynamically resize itself to accomodate the data
the user enters. For example, users should be able to set cells at
any location (A5, A9, A893, ...) without having to reinitialize the spreadsheet
or explicitly set its size. On the other hand, the spreadsheet should
not use memory that's not needed. Since we want to embed the spreadsheet
library in a small device, the spreadsheet should strive to minimize its
use of memory whenever possible. This means that allocating memory
for a 10000x10000 array of Cells is not a viable solution. We should
allow as many cells as the user has memory for.
As implied above, the maximum size of the spreadsheet is unlimited.
Users can enter any row between 1..INT_MAX (defined in limits.h).
We should also plan for 1..INT_MAX columns as well, even though the current
input notation only allows for 26 columns.
Requirement: Client Interface
The client interface that we hand off to our embedded system customer should
be "easy to use". Objects should manage their own memory. The
C++ interface should provide a simple way to create a Spreadsheet object,
set values, and get individual values. The set and get operations
should be no slower than O(log n) time. There should be a way for
the client to find out the current size of the spreadsheet (max row, max
col). Once a Spreadsheet object is destroyed, all the associated
cells and other objects should be destroyed as well.
The C++ interface should also provide a simple way to set functions
for cells by passing in a string representing the function's text.
There should be a corresponding function to retrieve the text of a function
as a string. (The client code will use this to let users edit the
functions.) In a future version of our product, clients may want
to make use of our function parser. (For example, to do syntax-directed
editing of the function.)
Clients will want to copy Spreadsheet objects using standard C++ syntax:
"Spreadsheet x = y". They will also want to be able to copy individual
cells without having to know whether they currently contain a function
or a value; the exact method isn't important as long as it's simple and
easy to use. Finally, they need to be able to add their own functions
to the framework, so adding new functions is also part of the client interface.
Clients should not have to perform downcasts for normal operations.