Recently, a prospective client of my software company asked me to develop a computer system to support the electronic commerce branch of his company. The client's company sells office equipment, with an inventory ranging from copiers, telephones, and FAX machines, through computers, printers, scanners, to general supplies, such as paper, envelopes, pens, pencils, etc. Their inventory also includes office furniture. Recently, they decided to start offering their products over the Internet. It is obvious that such an electronic commerce-type system is needed almost immediately.

The system should be accessible to a large number of Internet shoppers and allow for browsing and searching of the inventory. Of course, it should allow the user to select a number of items for purchase and then place an order with the use of the customer's credit card. Ideally, the system should also allow keeping track of the placed order.

The administrators of the system should be able to define and maintain the inventory and print reports.

Of course, my company with its talented staff of designers and programmers is capable of developing such a system. However, my company decided to develop as generic a system as possible, in anticipation of similar requests in the future.

After a few initial meetings with the customer, I have determined that the system must be really flexible. I also included specific requirements to make the system as generic as possible. My initial assessment of the requirements outlining the concept of such a system is presented later in this document.

As the development of the product must be rushed, I have setup the following deadlines, listed in the table below.

Table 1: Project Deadlines

After a few informal meetings with the customer, I have concluded that additional functions might be added to the enrollment system later. Thus, the initial assessment of the requirements is as follows:

Initial requirements outlining the concept of the system:

1. The system must allow an inventory controller (administrator) to define and enter into the system new categories of inventory items. Each category may be described by any number of attributes (strings or numbers). For example, the product catalog identifier, name, and some of its features would be described as strings, and the quantity in stock and price would be represented as numbers.
2. The administrator should be able to define a hierarchy among the existing categories of inventory items. For example, it should be possible to define a Computer Equipment category and then add Desktop Computer , Laptop , Peripherals , etc. as sub-categories . Similarly, it should be possible to define the Telecommunication Equipment category, comprised of Telephones , FAX Machines , etc.
3. Optionally, the administrator should be allowed to define and enter into the system the relationships existing among the categories already present in the system. For example, it should be possible to specify that a given printer is suitable for a given type of computers.
4. The existing category definitions, including their attributes, hierarchies and relationships (if implemented) should be stored as metadata .
5. The administrator should be able to enter, delete, and update inventory items, their classifications and/or attribute values.
6. A restocking subsystem should allow for updates of product quantities.
7. A reporting subsystem should allow for printing reports of the status of the inventory.
8. The Internet customer should be able to browse categories and items, possibly selecting some of them for purchase .
9. If possible, a search capability should be provided. The Internet customer would then be able to search for a specific item using a collection of string attributes.
10. The Internet user should be able to place a credit card order for the selected items. Optionally, the user should be able to keep track of the order (placed, processing, shipped).
11. The system should allow multi-user access , protecting against an incorrect concurrent access. The system should maintain suitable authorization data and enforce access validation.
12. The system must have an easy-to-use user interface (UI) with several screens suitable for each type of the system's functionality, suitable for all types of users (customers, administrators, managers).
13. The system must be Web-enabled (accessible from a common Web browser) for all users.
14. The system should use a permanent data store (a relational database) to keep all of the data.
15. The system should use accepted standards whenever possible (HTML, CGI, ODBC, Servlets, JDBC, SQL, etc.). The project should be coded in either C++ or Java, possibly including other scripting languages (e.g. JavaScript and PHP).
16. Although the system should be secure , relying on accepted security standards, such as SSL, the first prototype is not expected to support SSL. However, wherever necessary, user authentication should be implemented (by checking user id and password).

1. StarUML a very good, open-source implementation UML 2.0.
2. Bouml is a good implementation of basic UML diagrams. Also, it is good for re-engineering.
3. Fujaba (From UML to Java and Back) from the University of Paderborn in Germany.
4. Umbrello is a part of the KDE environment on Linux systems.
5. Objecteering is a commercial UML modeling software. A free version is available.

1. The Unified Modeling Language User Guide (2nd Ed.), by Grady Booch, Ivar Jacobson, James Rumbaugh, Addison-Wesley, 2005.
2. The Unified Modeling Language Reference Manual (2nd Ed.), by James Rumbaugh, Ivar Jacobson, Grady Booch, Addison-Wesley, 2004.
3. Uml Distilled: Applying the Standard Object Modeling Language (3rd Ed.), by Martin Fowler, Addison-Wesley, 2003.
4. UML 2.0 in a Nutshell, by Dan Pilone, O'Reilly & Associates, 2005.
5. UML 2 and the Unified Process, 2nd Ed, by Jim Arlow and Ila Neustadt, Addison-Wesley, 2005.
6. The Unified Software Development Process, by Ivar Jacobson, Grady Booch, and James Rumbaugh, Addison-Wesley 1999.
7. Use Cases: Patterns and Blueprints, by Gunnar Overgaard and Karin Palmkvist, Addison-Wesley, 2004.
8. Requirements Analysis and System Design (2nd Ed.), by Leszek A. Maciaszek, Addison Wesley, 2005.
9. Writing Effective Use Cases, by Alistair Cockburn, Addison-Wesley, 2000.
10. Advanced Use Case Modeling: Software Systems, by Frank Armour, Addison-Wesley, 2000.
11. The Art of Objects: Object-Oriented Design and Architecture, by Yun-Tung Lau, Addison-Wesley, 2000.
12. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Ed.), by Craig Larman, Prentice Hall, 2004.
13. Use Cases: Requirements in Context, by Daryl Kulak, Eamonn Guiney and Erin Lavkulich, Addison-Wesley, 2000.
14. Software Engineering, by Ian Sommerville 8th edition, Addison-Wesley 2006.
15. Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, 1995.
16. Design Patterns in Java, by Steven John Metsker and William C. Wake, Addison-Wesley, 2006.
17. Object-Oriented Modeling and Design, by James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorenson, Prentice Hall, 1991.
18. Object-Oriented Analysis and Design With Applications. 2nd edition, by Grady Booch, Addison-Wesley, 1994.
19. Object-Oriented Software Engineering: A Use Case Driven Approach, by Ivar Jacobson, Addison-Wesley, 1994.