June 8, 2010
INFO 627
Requirements Engineering and Management
Assignment 3: SRS
Retail Allocation System for Urban Outfitters Inc
Gerrit Groot Bluemink
Fiona Luong
Christen Sylvester
Software Requirements Specification
Project Name: Retail Allocation System
Company Name: Urban Outfitters Inc
Team Members:
Gerrit Groot Bluemink
Fiona Luong
Christen Sylvester
2010 Urban Outfitters Inc
Revision History
Date / Revision / Description / Author06/08/2010 / 1.0 / Initial Version / GB, FL, CS
Contents
1. Introduction
1.1 Purpose
1.2. Scope
1.3 References
1.4 Assumptions and Dependencies
1.4.1 General System Assumptions:
1.4.2 Historical Data Conversion Assumptions:
1.4.3 Ongoing Data Load Assumptions:
1.4.4 Outgoing Data Feed Assumptions:
1.4.5 Data Archiving Assumptions:
2. Software Product Overview
2.1 System Scope
2.2 System Architecture
2.2.1 External View of Software Product
2.2.2 Internal View of Software Product
2. 3Feature Overview
3. System Use
3.1 Support For User Workflows
3.2 Actor Survey
3.2 Use-Case Model and System Events
3. 3System Interfaces
4. Specific requirements
4.1 System Use-Cases
4.2 System Functional Specification
4.3System Domain Models
4.3.1 Internal Domain Model
4.3.2 Data Models
4.4 Non-Functional Requirements
4.4.1 Usability
4.4.2 Reliability
4.4.3 Performance
4.4.4 Maintainability
5. SUPPLEMENTARY REQUIREMENTS
5.1 Project management strategy
5.1.1 Staffing & Resources
5.1.2 Communication & Interaction
5.1.3 Support Expectations
5.1.4 Project Delivery & Quality
5.1.5 Project Acceptance Criteria
5.2 Systems Security and Audit
5.3 Assumptions and Dependencies
5.4 Requirements Traceability
6. Online User Documentation and Help System Requirements
7. Design Constraints
8. Purchased Components
9. Interfaces
9.1 User Interfaces
9.2 Hardware Interfaces
9.3 Software Interfaces
9.4 Communications Interfaces
10. Licensing Requirements
11. Applicable Standards
Glossary
1. Introduction
1.1 Purpose
The purpose of this software requirements specification (SRS) is to establish the major requirements necessary to implement the SAS Merchandise Allocation System for the retail business channel of Urban Outfitters, Inc. (UOI). The overall objective of this software implementation project is to support UOI’s goal of getting the right merchandise to the right stores at the right time, every time. This document consists of both functional requirements and non-functional for the allocation project. The project requirements will define, in general terms, the setup of the new allocation system as part of UOI’s larger retail merchandising system consisting of interfaced upstream and downstream supply chain and enterprise resource planning systems.
1.2. Scope[1]
The scope of this SRS includes the following functionality: creating and saving allocation models, evaluating allocation models against one another during an allocation, creating allocations based on [size scale percentage, assortment plan, store item history, a combination of sales history and assortment plan], saving allocations in progress, saving notes to allocations, scheduling allocations, allocating to multiple stores at a time, allocating multiple PO’s at a time, allocating multiple products at a time (using product group functionality), allocating from multiple DC’s and backstock locations, specifying store defaults and constraints, deleting allocations (in a short time frame such as 30 seconds or less), updating allocations after they’ve been released, creating/updating/deleting [custom store groups, alternate merchandise hierarchies, store size scales], accounting for lost sales, receiving purchase order change notifications, viewing allocator and allocation model performance, and setting allocation system security. This previously mentioned functionality is grouped into phase 1.
What is not included in phase 1 and is not included in the scope of this document, is the store-to-store transfer of inventory functionality. This functionality allows the store to access store transfer requests submitted by the allocation analyst. After the store has completed its transfer request, it can acknowledge its shipment so that the correct inventory is updated in Island Pacific. The store-to-store transfer functionality is included in phase 2.
1.3 References
- Problem and Context Analysis documentation
- Vision Document
1.4 Assumptions and Dependencies
This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions which the viability of the software described by this SRS may be based. The assumptions are organized in the following manner:
- 1.4.1 General System Assumptions
- 1.4.2 Historical Data Conversion Assumptions
- 1.4.3 Ongoing Data Load Assumptions
- 1.4.4 Outgoing Data Feed Assumptions
- 1.4.5 Data Archiving Assumptions
1.4.1 General System Assumptions:
The following table highlights assumptions about the general construction and use of the allocation system.
GENERAL SYSTEM ASSUMPTIONSService provider will deliver an allocation system that will serve as the system of record for all allocation-related activities, including but not limited to allocation management, reporting and analysis and allocation modeling activities.
Urban will request a moderate level of modifications from the base data model – areas of expansion may include a module for the creation of alternate hierarchies. The service provider will provide documentation of customizations.
Web-based clients will be able to access the application via a secure browser session. Desktop clients will be able to access the application via a remote session (Citrix or remote desktop). Office integration will use a secure data transport protocol.
Urban Outfitters will have access to both a test and production instance of the application and database.
Urban Outfitters will require direct SQL access to the databases.
Service provider will furnish an Entity Relationship Diagram (ERD) for the database after implementation. In addition, updated versions will be provided as changes are made to the solution over time.
The allocation system will support a multi-brand implementation (currently Urban Outfitters, Anthropologie, and Free People) which maintains a master merchandise view that supports enterprise-wide reporting and analysis, but that allows brand-level analysis and maintains privacy between brands where appropriate.
A brand’s own audience should be its primary view into the database, but sales data from other brands should still be available for comparison, analysis, and selection. For example, Free People may want to use the sales history for a similar tank top that was carried by Anthropologie as the sales basis for the allocation of the Free People tank top.
The system will be constructed to easily support expansion of the data model to include new data elements as well as additional brands in the future.
1.4.2 Historical Data Conversion Assumptions:
The following table highlights the general guidelines and assumptions that will be followed in the conversion of historical sales data from Island Pacific to the new allocation system.
HISTORICAL DATA CONVERSION ASSUMPTIONSNo formal database will be migrated, but rather a host of different source system historical data elements will be extracted and loaded to build tables in the allocation database.
Approximately 2 years of daily history will be converted to the line item detail level for retail sales (currently planned to take data starting from 6/1/2008 to present). UOI may adjust this date forward depending on the system implementation timeline.
18 months of merchandise and assortment plan data will be converted and imported (currently planned to take data starting from 12/1/2008 to present). UOI may adjust this date forward depending on the implementation timeline.
It should be assumed that no unique purchase order key exists (for distros). A purchase order ID is provided by the order management system (IP), but because of duplication issues where PO numbers are reused, PO records should not be considered unique. Other keys such as PO receipt date and vendor ID will be available. Data transformations may be required to establish unique consistent keys during the historical load of data.
All historical customer records being loaded will have the agreed-upon data validation rules applied to them prior to loading.
The exact format of the files to be provided in conversion are not known at this time but can be assumed to be in variety of formats, including but not limited to: text, XML, delimited (comma, pipe, etc.), and fixed-width.
1.4.3 Ongoing Data Load Assumptions:
The following table highlights the general guidelines and assumptions that will be followed in the ongoing load of data into the new allocation system.
ONGOING DATA LOAD ASSUMPTIONSThe primary mechanism for delivery of data to the allocation system will be a daily batch load of files from numerous source systems.
The load process will support a variety of formats, including but not limited to: text, XML, delimited (comma, pipe, etc.) and fixed-width.
All file transmission will occur via agreed upon secure transport protocols – it can be assumed SFTP or similar technology will be used for all batch file transports.
The delivery of all files will require some type of automated acknowledgement – this may include individual emails, summary reports, or dashboard views.
Automated notification and reporting on import results will be available upon the import of data, including detailed field-level reports to ensure proper data quality.
1.4.4 Outgoing Data Feed Assumptions:
The following table highlights the general guidelines and assumptions that will be followed in the outgoing data feeds from the new allocation system.
OUTGOING DATA FEED ASSUMPTIONSThe primary mechanism for delivery of data from the allocation system will be a real-time batch of files triggered by specific events in the allocation system.
The export process will support a variety of formats, including but not limited to: text, XML, delimited (comma, pipe, etc.) and fixed-width.
All file transmission will occur via agreed upon secure transport protocols – it can be assumed SFTP or similar technology will be used for all batch file transports.
The allocation system will receive delivery confirmations from the warehouse management system upon successful import of batch files.
1.4.5 Data Archiving Assumptions:
The following table highlights the general guidelines and assumptions that will be followed in the automated archiving and retention of data in the allocation system.
DATA ARCHIVING ASSUMPTIONSData should never be deleted, but moved from the active data store to offline media.
Detail data such as transactions, allocations and method usage history should be archived, however aggregations may be required. Archiving is to be implemented in accordance with business needs and industry best practices.
2. Software Product Overview
This section provides an overview of the software as a product (or package). The survey is used by various people interested in the purpose and the behavior of the system, such as the customer, users, architects, use-case authors, designers, use-case designers, testers, managers, reviewers, and writers.
2.1 System Scope
The new allocation system is a stand-alone product that has dependencies on other existing systems. It is the main system that enables the allocation team to accurately apportion the merchandise to the correct stores at the right time. Allocation is the business function that stocks stores with new merchandise and also replenishes stores with items that are low in stock. In phase I, the allocation system is used only by users located in the home offices. In phase II, the system scope will be expanded to include usage by store managers at the retail stores. This will allow store-to-store transfers to occur in a timely manner and inventory to be kept up to date with the new inter-store transfer module that will be added. This implies that for phase II, the version of the system available for the store’s point of sale system (POS) should support touch-screen technology. POS computers at the stores usually do not have a mouse for click-and-point functionality. Although the allocation system is a stand-alone product, it heavily depends on sales and inventory data fed from the main ERP system Island Pacific and the Buyer's Workmate for PO data. It will also need to interface with NSB Planning for store plan data. Full details on external interfaces can be found in section 2.2.1 External Product view.
The implementation of the new system includes acquiring new hardware. The new servers will most likely be dedicated hardware because UOI wants to ensure that no other applications on the servers will interfere with performance. The details of the hardware and their specifications can be found in section 9.2 Hardware Interfaces.
2.2 System Architecture
2.2.1 External View of Software Product
*= Phase I-Phase II is the time period between the implementation of phase I and II that the Pro-Clarity and Merchant Analysis systems will slowly phase out of the allocator's daily use. In the beginning of Phase I, these two systems will most likely continued to be used until the new system has proven its reliability and users are acclimated to the new system.
** = The entering of converted store plan data is a planner activity. However, in the case of Free People, planner and allocator are both the same person. For Anthro and UO, the planner will enter this store plan data into NSB Planning.
(1)NSB Planning feeds the chain plan data into ITR Buyer’s Workmate. The buyer takes this rolled up data (i.e. women’s, men’s) as a baseline to perform assortment planning on a granular level (i.e. women’s in dollar amounts is divided into assortments of tops, bottoms, accessories, etc).
(2)Once a buyer submits a purchase order to Island Pacific, it also feeds the PO data to the new allocation system and the SPIN data warehouse.
(3)When the purchase order is submitted, the buyer also submits an order in Island Pacific for hang tags which is placed via Island Pacific to CheckNet.
(4)NSB Planning feeds the new allocation system converted store plan data for the store plan allocation method.
(5)Island Pacific (ERP) system feeds the new allocation system with updated inventory and sales data for the system to perform allocation analysis and calculations. The new allocation system also feeds released distro data into Island Pacific.
(6)Once an allocation is released in the new allocation system, the data will feed to Manhattan WMS (warehouse management system) and the distribution center will be notified of packaging and shipping to the retail stores.
(7)Distribution center receivers also uses Manhattan to scan in receipts of merchandise received from manufacturers/factories, which updates inventory data in Island Pacific.
(8)Tradestone PLM is a product lifecycle management system that handles purchase orders and communication back and forth between vendors. Updates and canceled POs data feed into Manhattan so the distribution center knows what and when to expect merchandise.
(9)While allocating, the allocators can also retrieve images of the merchandise from the image library. These images should automatically be attached to the line item in the distro. At the very least images will be available for retrieval if not attached.
(10)Allocators will continue to use Pro-Clarity and Merchant Analysis in the early phases of the new system for reporting.
- In Phase II, a new module/extension will be available for stores to better manage store transfer requests.
- In Phase II, a focus on a richer, better UI is planned to induce work enticement and easier navigation to improve productivity.
2.2.2 Internal View of Software Product
The following diagram provides an internal view of the main system components and their relation to the system management module. There is a total of eight modules displayed.
2. 3Feature Overview
Allocation Models:
1.Ability to create a sequenced set of allocation business rules as an allocation model. Allocation models are saved configurations consisting of one or more rules that spell out how apparel or merchandise will be distributed to an array of stores. Allocators should be able to create these models when allocating a specific product. An example of a sequenced set of rules is: first allocate to stores that have just opened for product XYZ until their need is completely met; secondly, allocate to the top selling stores.
2.Ability to save an allocation model for future use. When creating a set of business rules for a new allocation, allocators should be able to save the set as a model and use that model for future allocations.
3.Ability to set defaults and constraints for retail stores at the store and/or store group level. Stores have constraints and an example of a constraint is the upper limit of product they can receive due to the amount of space in the store. Setting constraints on a specific store prevents an allocation that a store cannot handle.
4.Ability to set allocation defaults and constraints for merchandise styles down to size level. An example of a default is when an allocator can set a minimum quantity of 1 for every size of a product. This ensures that the stores will not get broken sizes (aka they will get at least one of every size even if the allocation says to give it zero size larges.)
Allocation Productivity
5.Ability to save an "allocation-in-progress". For lengthy purchase orders, an allocator might start working an allocation and want to finish it at a later date/time. This feature allows them to save without having to process the allocation.
6.Ability to allocate by store group/cluster. There are hundreds of stores and having to allocate to each one individually can be a time consuming process. This feature allows one to choose a store group (store groups are created in feature 24) and make an allocation with it. An example of a store group might include "brand new store group" and underneath this group with be all of the new stores. When an allocator wants to allocate product XYZ to just the new stores, instead of having to allocate to all 20 stores individually, he/she can just select the group "brand new store group".
7.Ability to allocate by product group. A purchase order might hypothetically contain many products and each of these products can be categorized into product groups. So for example, multiple PO's might consist of 100 line items each. 30 of those items from the various PO's might be of product group "bedding" and the remainder might belong to group "shirts". Instead of having to go to each individual PO to select all 30 line items, the allocator can just select the PO's and specify "allocate all items belong to group "bedding".