Docstoc

IEEE Software Requirements Speci

Document Sample
IEEE Software Requirements Speci Powered By Docstoc
					Final Project: Overview
              Document
                                 for


Small-Business Unified
  Database Operations
   with Online Access

           Prepared by Alex Bonomo
                         Grace Park
                        Paul Servino
                 Supritha Sundaram
                          Neil Tilley
                       Hanako Ueda
                        Richard Van
                        Max Vujovic

          for CS 130 Spring ’09, UCLA



                        June 4, 2009
Final Overview Document for Small-Business Unified Database Operations                                                                         Page ii



Table of Contents
Table of Contents .......................................................................................................................... ii
1. Release Note ..............................................................................................................................1
    1.1       Planned Functionality Implemented ............................................................................................ 1
    1.2       Planned Functionality Not Implemented ..................................................................................... 2
    1.3       Future Functionality to be Implemented ..................................................................................... 3
2. Design and Planning ................................................................................................................5
    2.1       Design Overview ......................................................................................................................... 5
    2.2       Specification Changes ................................................................................................................. 5
    2.3       Accuracy of Planning .................................................................................................................. 6
3. Known Issues ............................................................................................................................6
4. Project Review ..........................................................................................................................6
    4.1       Team and Organization Problems ............................................................................................... 6
    4.2       Software Engineering Practices Used ......................................................................................... 7
5. Important Lessons ...................................................................................................................7
Final Overview Document for Small-Business Unified Database Operations                          Page 1




1. Release Note — ―What have you accomplished?‖

1.1 Planned Functionality Implemented
The project successfully accomplished creating a small-business unified database operations
application with online access. This entailed constructing an easy-to-use web interface that
connected to a structured and properly linked SQL database. It is of a generic enough
architecture to be adopted by any small, middle-man business, such as a wholesaler that needs to
account for its inventory supply of goods and products being purchased from suppliers and sold to
customers – in this case, retail store outlets. For this implementation it specifically serves the
needs of a flower wholesale, purchase, and delivery enterprise.

The web interface employs a design that is both simple and robust. It is simple by virtue of its
basic menu, clean appearance, and selected use of colors and highlighting. It is robust because it
is not restrictive in many input fields to a particular format and will continue to operate (with the
option to edit prior input) even when entered inputs have not complied with specific necessary
formatting. It is also robust because it anticipates many orderings of users wanting to conduct
database searches and provides those sort preferences on appropriate pages. The objective
achieved was to have an interface that was intuitive and sufficient – as simple as possible but no
simpler.

The application provides several critical features. First it allows the generation of reports. Reports
appear both in web-display and in MS Excel spreadsheet formats, with the option to produce a
hard-copy printout version. Reports are customizable by date ranges. They track aggregate and
individual customer and supplier histories. Furthermore, with minor reconfiguration they can be
adapted with the addition of accounting features to generate sales and purchase receipts,
invoices, and billing.

Second the product adheres to a hierarchical authority architecture. Differentiated authorization
levels control access by various users to classes of operations and classes of data, with the most
sensitive business information accessible only by the Administrator level, or simply not appearing
to users with fewer privileges such as the read-only level. Database entries marked for deletion
permanently leave the database only action of the Administrator, whereas users with write
privileges can mark items for deletion or recover items from the Trash Can with an Undelete
option, until the time the Administrator empties the Trash Can.

Third the database runs with real-time updates. The fundamental algorithm of this product is the
accurate count of contents in the inventory, which operates on a rolling basis with constant
decreases from shipments and steady additions from purchases. This inventory count algorithm is
realized both in the aggregate count of all products and in calculated amounts of individual stock
items and products. Updates occur immediately upon submitting input and are visible to all users
logged-on at the time upon their next page refresh. The inventory calculation as well as other
functionalities is able to complete without drawing away, or tying up, resources for a time.

1.1.1 Features different from Requirements Statements

The creation of this product led to a small number of features implemented differently from the
requirements originally identified. One requirement in section 3.8.3 was an electronic and
automatically generated version of a set of customs documents with the name CustClear. This
Final Overview Document for Small-Business Unified Database Operations                         Page 2


was purposed to be one of several features under Reports Generation, alongside a host of other
report types, and strongly desired by the client. The other report types were successfully
implemented, both as webpage and spreadsheet displays and in printable form. However, the
reporting functions were altered slightly not to include CustClear features. This resulted from
insufficient clarity about the requirements for generating these forms correctly and inadequate
client feedback about this feature, one that is needed in the European Union but unfamiliar to a
programming team based in Southern California.

On a different, and minor, point, in section 3.10 the requirements document proposed the need to
handle special orders – those of an unusual size, of an uncommon product, or of expedited
handling – in a particular way. However, the approach to managing special cases was shifted,
with the intent instead of giving clients using this product the most discretion how they would want
to handle the class of special cases for their business and, more importantly, for the purpose of
maintaining a unified, simple, and consistent interface for all transactions. For these reasons,
indicating special orders was given a check box that employees might use – instead of a
secondary ordering procedure – with a comment box to give freedom about special-case details
specific to the business. Trial customer feedback confirmed this to be a more beneficial approach
rather than the application giving too much guidance in this area.

1.2 Planned Functionality Not Implemented
While the application handles numerous basic functionalities successfully, this version does not yet
address special case issues mentioned in the requirements document. They are the following:

First, section 3.12 discussed the importance of adequate back up procedures for the database.
These should include a second server at a preferably offsite location and should be a customizable
function to allow the Administrator to backup selected database portions, for example transactions
for the preceding business day, week, month, or year. The backup feature was not added yet to
the Administrator menu.

Second, section 3.13 explained the need to resume operating after a time the product is
unavailable, for any number of reasons including Internet connectivity loss, taking the database
offline, a power outage, or an offsite employee out of wireless range who still conducts business
transactions. In these circumstances the business continues operations in an off-line mode and
must update the database at a later time. The two components – an end-user driven display of the
ordering system, and a function to re-synchronize the database with transactions that have been
completed – were outside the time scope of the project.

Third, section 5.2 listed an additional level of employee classification, by employee department.
With this feature, certain types of (for example) accounting information would be visible only to
employees classified in that department. This is an appropriate feature to add for businesses of a
size that require it. However, for the purposes of our current client, no such specialized employee
views were necessary because, for one thing, this business type for flower sales and, for another,
the small business size (<40 employees) do not warrant separate departments at this time. Thus
the department classification requirement was not added in this release.

Fourth, section 5.5 identified the need for multilingual interface display, for businesses located
internationally. Further detail is given in this document under section 1.3.7. The priority in release
version 1.0 was to complete a working model in English that was testable by the programmers.
Running the first version in English facilitated identifying all messages and words that would be
necessary to display, before using vital project development time seeking correct translations of
messages that not end up being used. Multilingual display would be a readily available feature in a
future release.
Final Overview Document for Small-Business Unified Database Operations                          Page 3



Fifth, section 6 focused on security measures, to avoid compromise or corruption of the database.
A partial list of these measures were implemented, such as preventing unauthorized access. In
this case, permanent data loss by a malicious read-user or employee level attack is avoided
because of sanitized input and because of a non-Administrator’s ability only to mark items for
deletion but not remove from database. However, a timed inactivity logout not implemented. This
absence is a moderately critical issue. On the one hand, this poses a security risk at the
employee level of only adding invalid or duplicated data to the database, or altering non-business-
critical data of a logged-in employee's user profile. On the other hand, an inactivity timeout is
particularly critical however at the Administrator level because of its full access to employee and
business operation database information. Without proper authentication, unauthorized
Administrator access at an unattended user terminal could result in permanent data loss. An
inactivity logout timer is one effective loss-prevention tool that would in large measure attend to
this issue.

1.3 Future Functionality to be Implemented
The following is a comprehensive list of ideas that were brainstormed during the design phase, but
our group felt that it would be too ambitious to implement given our restricted time frame.

1.3.1 Coding Compliance with Section 508 and Disability Access Standards

Adhering to conventions to pass web-page validators and disability access conventions gives
special needs users equal levels of interaction with our software. Aspects to modify include full
navigation of pages by screen readers for the blind, wise color layout selections (or ability to turn
off color selections) for users with color-blindness, full ranged screen re-sizing or large print
options for the visually impaired, identifying all table displays with row and column headers,
marking scripting language with functional text that can be read by assistive technology, providing
a method that permits users to skip repetitive navigation links, and avoiding display of any
flickering images.

1.3.2 Filter Customers by ‘Called by Phone’ status

Phone calls are not made through the program, but a telephone list appears in the program. Each
salesperson can then mark off the customers they have called and at what time. This function is
also used to include/exclude certain customers and phone numbers from appearing on the list
without actually removing them from the database."

1.3.3 Online Ordering System

Create an additional user-access level, giving external users of the business the ability to place
orders directly online.

1.3.4 Complete User Manual

Write up a user manual in great detail about all functionality of the product.

1.3.5 Continued Customer Support

Maintain the product and answer any questions that arise following the completion of the project
and CS course.
Final Overview Document for Small-Business Unified Database Operations                           Page 4


1.3.6 Accounting

Implement billing and invoicing functionality in the application to an extent for it to manage funds,
currency exchange rates, costs, sales, expenses, etc.


1.3.7 Multilingual Interface Display

With the current client based in Italy, create a language flag that when clicked ON will change the
language of the website to Italian. Further extension to other languages for widespread usage as
a more generic Small-Business Application.

1.3.8 Price List of the Month

Implement, as something the client wanted, but which would have required obtaining our client’s
inventory list, in order to place specials on each box of flowers.

1.3.9 Statistical Analysis Tools

Create a set of tools to run statistical analysis on the database, to see sales and figures

1.3.10 Hotkeys

Remove dependency on the mouse.

1.3.11 Automated Purchase Input for Regular Customers

Have the application pre-populate fields for regular customers, with orders that such customers
commonly place.

1.3.12 Support for Stealing/Fraud

Create a page to handle special cases that will have effects on the database

1.3.13 Shipping in Parts

Currently, customers can buy in parts, and this feature can accommodate when a customer
desires that the flowers be delivered in intervals of time, in staggered fashion.

1.3.14 Handling Flowers Spoiling

Create a page to handle special cases that will have effects on the database

1.3.15 Configuration Task

Create an automatic scheduler that will place recurring orders

1.3.16 Input Supplier Product List into Application Database for Client

We need to get the supplier product lists of our client first; would also require language
interpretation (refer section 1.3.7)
Final Overview Document for Small-Business Unified Database Operations                           Page 5


1.3.17 Multiple Shopping Carts

Placing orders for more than one employee at a time.

1.3.18 Cross-Browser Compatibility

Dealing with browser issues of IE, Safari, etc. and making sure the content fits to screen.

1.3.19 Currency Exchange Rates

Since client is based in Italy and is an importer/exporter, need to have a currency exchange rate
converter

1.3.20 User Adding Additional Fields

If the user needs to add more description or special fields, but this would modify the database.


2. Design and Planning

2.1 Design Overview
The design of our document encompassed two design patterns; the repository model and client-
server design. These design patterns were chosen because they best fit our PHP framework. The
application’s design was adequate because it allowed us to implement key features we were
aiming for. While coding, we followed the design document, and there was relatively minimal
confusion among the members on different aspects of the implementation.

2.2 Specification Changes
Both the requirement and design specification documents were the result of extensive planning
and review sessions prior to any implementation starting. We were pleased to find the investment
worthwhile, which resulted in developing a product almost wholly faithful to the level of detail given
in these documents. A small number of issues were different from the specifications, as follows:

First, section 2.9 describes implementing an Action Log. The function of the Action Log is to serve
in part as a secondary security measure. It is a traceable record that can identify the sources of
unwanted changes or assist reinstating replaced values for reversible changes. Parts of this
Action Log feature were implemented in alternative ways, for example by adding time stamps and
user signatures to last changes in an order and in order creations. However a single chronological
log listing was left off as an Administrator-level menu item in this first release, since it was not in
the priority of creating a functioning application.

Second, section 3 detailed numerous product testing products and standards to meet, mostly that
involved repeatable and regressive tests using a testing protocol suite. Again, the priority to create
a product with enough features to make it operating took precedence over learning to use a new
software package to test the work that had been done. This resulted in extensive manual testing
and single level testing, but was aided by virtue of the fact that most web page interfaces had
independent operation from one another and lessened the need after programming changes for
repeated testing on interface pages that were unaffected.
Final Overview Document for Small-Business Unified Database Operations                         Page 6


The rest of the features given in the specification document accurately described the form taken in
this product for it first release.

2.3 Accuracy of Planning
We now discuss the difference between plan and reality in the implementation process. To begin,
the preliminary implementation schedule, as presented in our Design document, was unrealistic.
The plan originally called for distributing work over the limited period of four weeks in an even
manner. We did not account for our varying schedules, breaks for midterms and other
assignments, and the unexpected problems that arise in every programming project. To
summarize, our plan was at a level of detail that precluded schedule variations.

In actuality, we followed a much different model of pacing our work. There were periods of time
when everyone was working in groups, finishing much more than anticipated in the schedule. At
other times coding was set aside as we dealt with other commitments. Our actual progress
involved resolving the issues deemed most critical at the given time, then breaking into groups and
implementing those tasks at hand before moving on.


3. Known Issues
At the time of this product release, a number of issues are known to need further work. They are
the following:

       ―Read‖ versus ―Read/Write‖ authorization level distinction is not fully tested or implemented
        on all pages of the site.
            o Options such as ―Edit‖ and ―Delete‖ should be hidden from unauthorized users
                instead of redirecting to the login page. Currently the application simply requests a
                user with a higher authorization level to login.
       Checking length of input data fields is not implemented on all pages.
       Customers and suppliers should have an email address field.
       Missing ―Back‖ button within web pages that avoids a ―Resubmit a form‖ warning: When a
        user searches for any object and clicks ―View‖, ―Edit‖, or ―Delete‖ on the list page beside
        the object information, the browser’s Back button from the next page asks to resubmit a
        form.
       The format of dates is not consistent across all pages. Sometimes a time is unnecessarily
        displayed.


4. Project Review
In this section we discuss the overall experience of working through a complete business product
life cycle. We approach this from the viewpoint of the team members involved and by assessing
the most and least helpful software tools that assisted creating the product.

4.1 Team and Organization Problems
Every team deals with problems that involve unifying their members' different outlooks and ideas.
Our team also initially faced this, before we discovered a team dynamic. Our main problems
involved organizing our schedules, and working to allow any team member's unexpected
commitments into our schedule without hindering the project. There were several instances where
Final Overview Document for Small-Business Unified Database Operations                        Page 7


none of us could concur on a single path of implementation or the definition of some operations.
Certain times, there was miscommunication between team members and we approached the
same job with two different ideas of implementation.

4.1.1 Potential Solutions

The problems stated above were not setbacks to us because we dealt with them in a timely
fashion and resolved them quickly. When faced with organizational problems, we held a group
meeting, addressed the problem, collected opinions from every team member, debated the pros
and cons of each solution, and derived a final solution. Our main strengths were communication
and respecting each other's opinions. Spending a great amount of time with each other helped us
grow accustomed to each other's opinions and helped us solve any issues that rose in a fairly
small amount of time.

4.2 Software Engineering Practices Used

4.2.1 Software Engineering Practices Recommended

We recommend having a frequent meeting because it helped us in the first few weeks to form our
ideas, concepts, and thoughts into a unified perspective. Since we had a large group which
contained of eight people, every one of us had different point of views. Once the goal were
developed then every one of us were on the same page and knows exactly what to do.
Furthermore, the meetings helped us to clarify certain things such as terms and confusions.

We recommend the UML (Design Pattern) even though it was not an easy task to do. However,
once we came up with the design, we basically followed our design and finished the product
without encountering any major conflict.

We recommend pair programming because it helped us catch bugs while coding and learn some
coding style or coding techniques from each other. Furthermore it adds the effectiveness of
coding because many of us were not familiar with PHP, since only few on the team began with a
good knowledge of PHP. Fortunately, we were able to find solutions without reading books about
PHP and find the solutions individually.

4.2.2 Software Engineering Practices Not Recommended
We do not recommend testing the product based on manual testing solely. Initially, we wanted to
implement the automated testing into the code, and followed the procedure of testing such as unit
testing, integration testing, system testing, and regression testing. However, we did not have time
to incorporate the automated testing since it required further readings and learning for which we
did not have the luxury of time. Due to the time restrain, we ended up with manual testing.


5. Important Lessons
There were several lessons learned during the course of this project. For many, this was a first
time experience completing a project in Computer Science. Our main lesson was learning how to
work well with people. This came down to three main points: first, a consensus of dedication to the
project, second, communication and third, the initiative to learn. Every member of our group was
consistently dedicated to completing the project and delivering the product. We fed off the positive
feedback from the other members, as well as food, to maintain our can-do attitudes. Without this
Final Overview Document for Small-Business Unified Database Operations                        Page 8


positive sentiment, it is doubtful we could have completed the amount of work we did in the time
available.

In terms of communication, our group learned to communicate with each other about our ideas on
the project and other logistic problems in a concise and clear way. Using whiteboards and general
open discussion about issues broadened our understanding. The Wiki-page, the SVN comments,
and email lists were vital in keeping our team coordinated.

The third lesson was taking the initiative to learn something new. Many of us were inexperienced
with the programming involved, and all of us put in effort to learn. This involved taking the time to
understand what we were doing and adding to the product at our level of contribution. Many times
we had to refocus on what our customer’s needs and requirements were. This was a vital review to
avoid creating a wrong piece of software and making sure we understood exactly what was being
asked of us.

				
DOCUMENT INFO