The primary goals of the new system center around streamlining and (as much as possible) automating the existing process to get artisans' products into the online catalog. Specifically:

• artisans should be able to submit product information without having to go through an email-based process. As part of that change:
  • Some data-entry control will be enforced, to prevent simple mistakes (missing or invalid data).
  • artisans will be able to modify their product data, with some limitations, and with a review still required before those revisions go live. At a minimum, though, they will be able to deactivate live product listings, and activate existing-but-deactivated items as well.
• Product Reviewers will be able to make revisions directly (for simple changes, at least), and send items back for major revisions. This part of the process is loosely defined, and may need further detail and definition later in the development cycle.
• The Product Managers' data-entry tasks will be reduced significantly, at least as far as the setup of new products is concerned. The new system will take care of most or all of that.

The use-case diagram for the new process, then, looks like the following before any detailed design has taken place:

The intention is for each Artisan to be supplied with an installable application that allows them to interact with the HMS main office. That local application will connect to an Artisan gateway that will handle the Artisan-to-main-office communications, and store the incoming data from artisans as a sort of staging area for anything that's pending approval. From there, a Reviewer (and/or Product manager) application will allow Product reviewers and managers to move Artisan-supplied products into the main web store, using its native API. The logical architecture, with some rough inter-process communication flows, at this point looks like the following:

Between these diagrams and the initial concept noted earlier, there are a lot of specific user needs that have already been captured. It's possible that more will arise during development or at least planning for development (as stories for iterations are fleshed out).

The actual data structure behind artisans and their products is not known yet, only that products are distinct elements that can be owned by one and only one Artisan. More detail will be needed to implement these, as well as to determine what data moves where (and when), but the relationship between them is already diagrammable:

The current lack of information about the inner data structure of these elements also makes any sort of UI design specification difficult, if not impossible. Similarly, it will be difficult to determine any business rules that aren't already implied by the use-case and logical-architecture/data-flow diagrams. Those, too, will require more details before anything more useful can be discerned.

There are a few other varied items that could be inferred from this information and fall into one of the following pre-development steps:

• Risks:
  
  • The fact that the connection between the Review/Manage Application and the Web Store Database is one-way probably indicates some concern that the data flow needs to be carefully controlled. Realistically, it will probably be necessary for the application to be able to at least read from the database, if only so that existing products can be found and modified, rather than creating new product entries over and over again.
  • The use-case diagram shows that an Artisan can activate or deactivate a product without involving the Product Reviewer, but the architecture and flow don't have any obvious way to handle that capability. At a minimum, an examination of a connection from the Artisan gateway to the Web Store Database should be undertaken, but that's something that can happen later, during the relevant development iteration. Since the web store system has an API, it may be that the process can be managed by an API call to the Web Store Application, from the Artisan Gateway, but that hasn't been evaluated yet.

• Project-management planning data:
  
  • If the project has made it to the development shop, the odds are that all of the feasibility, cost-analysis, and other business-level examinations have been made and approved. Though there may not be any specific information needed from these results, knowing that they are probably available if a question arises is a good thing.