Gathering Application Requirements

A part of creating the architecture is the act of gathering and distilling requirements for the application. In general, you work from four types of requirements:

• Business requirements: The reasons your business needs this application going into the future

• User requirements: The behaviors and qualities that users of the application request

• Functional requirements: The behaviors that the application needs to embody

• Nonfunctional requirements: Application requirements that do not correlate directly to a function of the application, such as performance

You will use only a partial list of requirements for the P.T. Monday Coffee Company's new application. It is not my intention to build and deploy an entire operations site, only portions of the infrastructure relevant to the Web Service patterns. Further, I only list those requirements that relate to those patterns. This approach should simplify and shorten the requirement lists substantially.

Gathering the Business Requirements

Table 2-1 lists the business requirements for the new application. The business requirements, in many cases, restate the company vision and direction. Documenting and capturing business requirements are a vital portion of architecture, so those requirements placed on the system can correlate directly to a business reason.

Table 2-1: Business Requirements

ID	BUSINESS REQUIREMENT
B1	The application shall have the ability to integrate into the reseller's value chain.
B2	The application shall have the ability to integrate bean suppliers into the company's value chain.
B3	The application shall enable the company to decrease its dependency on individual bean suppliers.
B4	The application shall increase direct customer service without contacting a customer service representative.
B5	The application shall decrease the manual processing of customer information and orders.
B6	The application shall increase the ability to manage seasonal fluctuations through better price management.
B7	The application shall provide the ability to manage a remote distribution company for a separate locale.

Often, you represent business requirements in use-case diagrams that both summarize the requirements and graphically represent them for easy access. Figure 2-1 shows a use-case diagram with the proper actors and summarized requirements.

Figure 2-1: Business requirements for the P.T. Monday Coffee Company application

Several of the business drivers for the system point you toward Web Services. The key word to look for is integration . This application needs to work with partner computers in a variety of ways. Your direct partners could be influenced to go toward a proprietary or platform-specific solution, but the unspecified restaurant chains that you will work with are different. It is unlikely that as the P.T. Monday Coffee Company grows it will have the influence to alter a large chain's computing directions away from open standards, such as Web Services. There will be additional reasons to select Web Services as the integration technology as you move through the functional and nonfunctional requirements of the system.

This application facilitates direct sales by retaining and accessing personalization information and exposing the order-to-fulfillment process to the direct consumer. The application aids resellers with a programmatic interface to ordering and various business processes in addition to the advantages given by the direct sales improvements. Internally, process improvements occur in the order fulfillment arena through increased ability to automate the coordination and purchase of unroasted coffee beans from growers. Enhancements extend to the shipping department to help plan and automate distribution through the local truck routes and third-party shippers. Finally, the management staff gains increased visibility to the business processes, their status, and quicker exposure to weaknesses in the value chain (such as a decrease in demand resulting in excess beans).

Gathering the User Requirements

User requirements give a concrete list of behaviors and functionality that users within the company, as well as external users such as direct Web purchasers , expect to see from your application. A comprehensive list of user requirements would take pages for the application. Table 2-2 lists the requirements that you will focus on throughout the book.

Table 2-2: User Requirements

ID	REQUIREMENT	USER
U1	The application shall have Web-based access to the customer profile for update directly by customers.	Direct/Reseller
U2	The application shall allow customers to access the current order status through a programmatic mechanism and through a user interface.	Direct/Reseller
U3	The application shall enable a customer to access product catalog and sale information through a user interface and programmatically.	Direct/Reseller
U4	Customers shall be able to view current invoices and payment schedules.	Direct/Reseller
U5	Customers shall be able to change billing options and make payments through a Web-based interface.	Direct/Reseller
U6	Direct orders from customers shall require credit card information.	Direct
U7	Approval and authorization for credit card usage shall be required for the placement of direct sales orders.	Direct
U8	Customers shall have the option of automated and manual selection of the shipping method.	Direct/Reseller
U9	The application shall notify management when the outstanding quantity of orders for beans exceeds the amount of beans in the warehouse.	Management
U10	The application shall notify management when there is a substantial amount of excess beans in the warehouse.	Management
U11	Managers shall have the ability to run monthly and weekly reports on throughput.	Management

Like business requirements, use-case diagrams help depict the web of user requirements. Figure 2-2 shows the user requirements.

Figure 2-2: User requirements for the P.T. Monday Coffee Company application

Considering that Table 2-2 is just the tip of the iceberg for user requirements, it does provide a glimpse into some of the challenges the application faces. For example, several processes require both Web-based access and programmatic access from customers. Further, there are several dynamic processes identified in the latter portion of the table, such as the ability to automate the selection of a shipping company and the ability to automate a bean-ordering system.

Gathering the Functional Requirements

Functional requirements for an application capture the intended behaviors of the application. These requirements show the application capabilities that are required to fulfill the user requirements. Although this section does not express all of the application's functional requirements, it expresses enough for you to continue on the course of your application architecture. Table 2-3 lists some of the functional requirements.

Table 2-3: Functional Requirements

ID	REQUIREMENT
F1	The Web-based forms shall provide a secure mechanism for updating customer personalization information.
F2	The Web-based forms shall be accessible from Internet Explorer, Personal Digital Assistants (PDAs) that run Microsoft operating systems, and cell -phones that have Web Markup Language (WML)-compliant functionality.
F3	The application shall provide programmatic access to submit orders, observe the fulfillment process, and pay invoices.
F4	The Web-based forms shall provide a secure mechanism for invoice payment.
F5	The Web-based forms shall provide a secure mechanism for placing direct sales orders with immediate payment and scheduling direct sales orders with an automatic payment mechanism.
F6	The Web-based forms shall provide a personalized order history.
F7	The Web-based forms shall provide access to order status.
F8	The external Application Programming Interface (API) to the system shall be accessible to all current programming languages and platforms.
F9	The inventory management system shall automatically request additional beans from suppliers based on management-configured parameters for the definition of low supplies and grower preferences.
F10	The inventory management system shall notify management via email when either excess roasted and unroasted beans are available or a low-inventory situation occurs.
F11	The inventory management system shall notify management via email when a low-inventory situation is resolved or if manual intervention is required.

Several of the functional requirements fall into the category of business processes. These business processes are often viewable by application users. For example, a customer that orders several pounds of coffee would often like to know when its order is roasted and shipped. This response mechanism should aid the company in reducing curiosity calls to the customer service department. In a more advanced system, you could add business intelligence to predict the expected shipment date. The Ship Order and the Generate Delivery Route processes could use third-party services from the shipper and an Internet-based route finder.

Gathering the Nonfunctional Requirements

Table 2-4 lists the qualities and constraints of your application in the form of nonfunctional requirements. There are always some nonfunctional requirements that you can assume to be in existence, but for this case, many of these assumptions are actually lower priorities than the business, functional, and user requirements. Although it is true that you want your system to perform well, performance is well below the need to embrace open standards for integration points. Integration with external systems and flexible business processes are also priorities in the final application. For succinctness, I omitted several of the obvious requirements and retained those that stand out in this application.

Table 2-4: Nonfunctional Requirements

ID	REQUIREMENT
NF1	The application shall embrace open standards for the external API.
NF2	The application shall not require duplicated logic within the application.
NF3	The application must choose low-cost options and open-source software whenever that software does not compromise the stability of the application.

These requirements should not leave any doubt that there is a place for Web Services in your application. As with the other requirements included in the text, I have omitted the bulk of the nonfunctional requirements.