Professional Portfolio Summary
ITS4090 Applied Systems Analysis II – Week 5 Project
This assignment expanded systems analysis into a detailed acquisition, architecture, implementation, testing, and support plan for a sporting-goods customer guidance application. I compared acquisition strategies with a weighted decision matrix, designed an n-tier architecture, identified database and security requirements, developed interface and navigation concepts, created physical process and data models, and planned programming tasks. The project also addressed unit, integration, system, security, and acceptance testing along with technical, user, and training documentation. In Week 5, the development approach was converted to Scrum with defined roles, user stories, backlog priorities, and iterative delivery. This project is especially relevant to my targeted IT support and service desk market because it connects technical systems to the people responsible for maintaining and supporting them. The documentation plan includes troubleshooting procedures, administrator materials, user instructions, and training resources, which are directly related to support work. The project also demonstrates knowledge of authentication, role-based access, databases, APIs, security controls, testing, and system integration. Those areas are important when diagnosing incidents that cross multiple services. It shows that I can look beyond a single error message, understand dependencies, document solutions for technical and nontechnical users, and work with developers, administrators, security staff, and end users.
Assignment Statement
The original assignment instructions were not retained with the available Week 5 submission. The original course work is reproduced below without replacing or inventing the missing assignment statement.
Original Week 5 Work
System Acquisition Strategy Project: Sporting Goods Customer Guidance Application
ITS4090 Applied Systems Analysis II
June 2026
Introduction
The proposed project focuses on creating a customer guidance application for a sporting goods retailer. The application will help customers locate products, navigate departments, scan barcodes, view product demonstrations, receive recommendations, and complete purchases. The goal is to improve customer satisfaction while increasing sales and reducing the time customers spend searching for products. This project continues prior work by connecting the acquisition strategy, architecture, interface design, physical models, programming tasks, testing plan, documentation plan, and Scrum conversion into one coherent solution.
The instructor feedback from Weeks 1 through 3 identified several areas that needed improvement, including stronger proofreading, more APA integration, deeper project management detail, improved architecture explanation, and more complete models. This revised Week 5 version addresses that feedback by reducing repeated content, adding clearer in-text citations, expanding the architecture and project management discussion, and replacing placeholder-style diagrams with more detailed text-based models and tables. Systems analysis should connect business needs, technical design, and implementation choices so that the final solution supports measurable business value (Dennis et al., 2021).
System Acquisition Strategy
The recommended acquisition strategy is custom in-house development. A packaged solution would not provide enough flexibility for store navigation, personalized recommendations, integrated purchasing, barcode scanning, administrative reporting, and store-specific inventory integration. Internal development allows the company to maintain stronger control over security, updates, data ownership, and future feature expansion. This strategy also supports the retailer’s need to differentiate its customer experience instead of relying on a generic commercial package.
Outsourcing could reduce some short-term development responsibility, but it would create more dependence on a vendor for system changes, integration, and maintenance. Packaged software could be faster to deploy, but the retailer would likely need major customization to support indoor navigation, product demonstration videos, barcode scanning, and recommendation services. Custom in-house development therefore provides the best long-term fit because the system is highly connected to the retailer’s internal business processes.
Decision Matrix Analysis
A weighted decision matrix was used to compare custom development, packaged software, and outsourcing. The criteria were selected because the application requires customization, security, scalability, integration, cost control, and long-term maintainability. Custom development scored highest because it provides the strongest fit for specialized requirements and internal control.
| Criteria | Weight | Custom Development | Packaged Software | Outsourced Development |
| Customization | 5 | 25 | 10 | 15 |
| Security control | 5 | 25 | 15 | 10 |
| Scalability | 5 | 25 | 15 | 20 |
| Integration capability | 4 | 20 | 12 | 12 |
| Long-term maintenance | 4 | 20 | 12 | 12 |
| Initial cost control | 3 | 12 | 15 | 9 |
| Total | 127 | 79 | 78 |
Table 1. Weighted Decision Matrix for System Acquisition Strategy
Business Need
Large sporting goods stores often contain hundreds or thousands of products across multiple departments. Customers may struggle to locate items, compare equipment, understand product differences, or identify accessories that match their needs. The proposed application provides digital guidance, product recommendations, barcode scanning, product demonstration content, and purchasing capabilities that improve the customer experience.
The application also supports business value for the retailer. Faster product location can reduce customer frustration, product recommendations can increase add-on sales, barcode scanning can reduce employee interruptions, and customer activity reports can help managers understand demand patterns. These benefits connect the system directly to operational improvement and revenue generation.
In-House Experience and Skills
The project requires a cross-functional team with technical and business skills. Required roles include systems analysts, software developers, database administrators, user interface designers, security specialists, quality assurance testers, technical writers, project managers, and retail subject matter experts. Team members must understand mobile development, web development, cloud services, API integration, database management, encryption, authentication, authorization, and secure payment processing.
Because the system handles customer accounts, purchase data, and payment activity, security experience is especially important. The team must apply secure design principles throughout the project instead of treating security as a final testing activity. This includes role-based access control, password hashing, encrypted communications, secure API design, and protection of sensitive data.
Project Management and Timeline
The original project plan followed a structured methodology with major phases for planning, analysis, design, implementation, testing, and deployment. A twenty-four-week schedule is appropriate for the initial version because the system includes database development, user accounts, search, navigation, barcode scanning, recommendations, shopping cart features, payment integration, reporting, testing, documentation, and deployment activities.
The project manager is responsible for coordinating scope, schedule, cost, quality, risk, and communication. Key risks include security vulnerabilities, integration issues, payment processing errors, inaccurate inventory data, poor usability, incomplete documentation, and schedule delays. Risk control activities include early prototypes, stakeholder reviews, unit and integration testing, security reviews, and user acceptance testing. The move to Scrum in Week 5 improves this plan by turning the work into smaller Sprints that produce usable increments and allow stakeholder feedback before the final deployment.
| Milestone | Target Weeks | Purpose |
| Requirements approval | Weeks 1-2 | Confirm business needs, system scope, users, and constraints. |
| Architecture and database design | Weeks 3-5 | Define n-tier design, data model, security design, and core integrations. |
| Interface prototype | Weeks 6-7 | Validate dashboard, navigation, scanning, cart, and account screens. |
| Core development | Weeks 8-15 | Build account, search, navigation, barcode, cart, recommendation, and reporting modules. |
| Integration and security testing | Weeks 16-19 | Verify that modules, data stores, APIs, and payment services work together securely. |
| User acceptance testing | Weeks 20-21 | Allow selected customers and employees to test realistic scenarios. |
| Training and documentation | Weeks 22-23 | Finalize user guides, employee training, administrator guides, and support procedures. |
| Deployment | Week 24 | Release the application and begin post-implementation support. |
Table 2. Revised Project Management Timeline
Architecture Design
The application uses an n-tier architecture consisting of presentation, application, data, and external service layers. This architecture improves maintainability, scalability, and security by separating responsibilities across layers. In this design, customer screens are handled in the presentation layer, business rules are handled in the application layer, customer and product data are handled in the data layer, and payment or mapping services are handled through external service interfaces.
The presentation layer includes the customer mobile application, employee interface, and administrator dashboard. The application layer includes authentication services, product search services, barcode lookup services, recommendation logic, shopping cart functions, reporting services, and security controls. The data layer stores customer records, product records, inventory records, store locations, orders, order items, and recommendations. The external service layer connects to the payment gateway, barcode data services, email or notification services, and map or location services.
+--------------------------- Presentation Layer ---------------------------+ | Customer Mobile App | Employee Inventory Screen | Administrator Dashboard | +------------------------------------|--------------------------------------+ v +---------------------------- Application Layer ----------------------------+ | Authentication | Search | Barcode Lookup | Recommendations | Cart | Reports | +------------------------------------|--------------------------------------+ v +------------------------------- Data Layer --------------------------------+ | Customer DB | Product DB | Inventory DB | StoreLocation DB | Order DB | +------------------------------------|--------------------------------------+ v +-------------------------- External Service Layer -------------------------+ | Payment Gateway | Map/Location Service | Email/Receipt Service | Security APIs | +---------------------------------------------------------------------------+
Figure 1. N-Tier Architecture for the Sporting Goods Customer Guidance Application
Operational, Performance, Security, Cultural, and Political Requirements
Operational requirements include account creation, login, product search, barcode scanning, in-store navigation, recommendations, shopping cart functions, checkout, inventory updates, and administrative reporting. The system must be available during store hours and must support both customers and employees without requiring extensive training. Clear feedback, consistency, and recognition rather than recall are important usability principles because customers will use the application while moving through a store (Nielsen, 2024).
Performance requirements include fast product searches, responsive barcode scans, quick page loading, and reliable checkout. The system should support many concurrent users during busy shopping periods. Security requirements include encrypted connections, password hashing, role-based access control, secure payment processing, audit logging, and limited employee access to customer data. Cultural and organizational requirements include a simple interface for customers with different technical skill levels and employee training so that staff members understand how the application supports rather than replaces customer service.
Interface and Navigation Design Concepts
Three interface concepts were evaluated: a dashboard interface, a menu-driven interface, and a search-centered interface. The dashboard interface is recommended because it offers the best combination of usability, accessibility, and efficiency. Customers can quickly choose search, map, cart, scan, recommendations, or account features without navigating through several nested screens.
| Interface Concept | Customer Flow | Strengths | Limitations |
| Dashboard interface | Home screen leads to Search, Scan, Map, Cart, Recommendations, and Account. | Fast access to core tools; easy for new users; supports visual icons. | Can become crowded if too many features are added. |
| Menu-driven interface | User opens menu, selects category, then selects a function. | Organized; familiar to users who expect app menus. | More taps are required; important features may be hidden. |
| Search-centered interface | User begins with a search bar and receives product, location, and recommendation results. | Efficient for customers who know what they want. | Less helpful for browsing customers or users who need guided navigation. |
Table 3. Interface and Navigation Concept Comparison
Dashboard Wireframe +--------------------------------------------------+ | Sporting Goods Guide | | [Search products...] | | | | [Scan Barcode] [Store Map] [Recommendations] | | [Cart] [Account] [Help] | | | | Featured: Running Shoes | Baseball Gloves | Bikes | +--------------------------------------------------+
Figure 2. Recommended Dashboard Interface Wireframe
Customer Navigation Flow Open App -> Login/Guest Mode -> Dashboard -> Search or Scan -> Product Detail -> Aisle/Map Location -> Add to Cart -> Checkout -> Receipt
Figure 3. Customer Navigation Flow
Physical Data Flow Diagrams
The physical data flow diagrams show how information moves among customers, employees, the application, databases, and external services. The context diagram shows the system as one process and identifies major external entities. The level 1 diagram expands the application into major physical processes and shows labeled data flows, data stores, and external services. Directional arrows and labeled flows are included to make the process more complete than a placeholder diagram.
Level 0 Context Diagram [Customer] --login/search/scan/order request--> (Sporting Goods Guidance Application) [Customer] <--product details/map/cart status/receipt-- (Sporting Goods Guidance Application) [Employee/Admin] --inventory updates/report requests--> (Sporting Goods Guidance Application) [Employee/Admin] <--reports/update confirmations-- (Sporting Goods Guidance Application) (Payment Gateway) <--payment authorization request-- (Sporting Goods Guidance Application) (Payment Gateway) --approval or decline response--> (Sporting Goods Guidance Application)
Figure 4. Physical DFD Level 0 - Context Diagram
Level 1 Physical DFD [Customer] -> 1.0 Authenticate User -> D1 Customer Data -> login result -> [Customer] [Customer] -> 2.0 Search/Scan Product -> D2 Product Data + D3 Inventory Data -> product/location results -> [Customer] [Customer] -> 3.0 Manage Cart -> D4 Order Data -> cart/order summary -> [Customer] 3.0 Manage Cart -> payment request -> [Payment Gateway] -> payment result -> 4.0 Process Order 4.0 Process Order -> update quantity -> D3 Inventory Data [Employee/Admin] -> 5.0 Maintain Inventory -> D2 Product Data + D3 Inventory Data -> confirmation [Manager] -> 6.0 Generate Reports -> D4 Order Data + D3 Inventory Data -> sales/inventory reports
Figure 5. Physical DFD Level 1 - Major Processes, Data Stores, and Data Flows
Physical Data Model
The physical data model identifies the major tables required by the application and adds implementation details such as attributes, data types, primary keys, foreign keys, and relationships. Unlike a logical model, the physical model is concerned with how the data will actually be stored in a database. This model includes Customer, Order, OrderItem, Product, Inventory, StoreLocation, and Recommendation tables.
| Table | Primary Key | Important Foreign Keys | Selected Attributes and Data Types | Cardinality |
| Customer | CustomerID INT | None | FirstName VARCHAR(50), LastName VARCHAR(50), Email VARCHAR(100), PasswordHash VARCHAR(255), CreatedDate DATETIME | One customer may have many orders and recommendations. |
| Order | OrderID INT | CustomerID INT | OrderDate DATETIME, Status VARCHAR(25), TotalAmount DECIMAL(10,2), PaymentStatus VARCHAR(25) | Many orders belong to one customer. |
| OrderItem | OrderItemID INT | OrderID INT, ProductID INT | Quantity INT, UnitPrice DECIMAL(10,2), LineTotal DECIMAL(10,2) | One order contains one or more order items. |
| Product | ProductID INT | None | ProductName VARCHAR(100), Barcode VARCHAR(50), Category VARCHAR(50), Price DECIMAL(10,2), DemoURL VARCHAR(255) | One product may appear in many order items and inventory records. |
| Inventory | InventoryID INT | ProductID INT, StoreID INT | QuantityOnHand INT, Aisle VARCHAR(20), LastUpdated DATETIME | Many inventory records connect products to store locations. |
| StoreLocation | StoreID INT | None | StoreName VARCHAR(100), Address VARCHAR(150), Department VARCHAR(50), MapCoordinate VARCHAR(50) | One store location may have many inventory records. |
| Recommendation | RecommendationID INT | CustomerID INT, ProductID INT | Reason VARCHAR(255), CreatedDate DATETIME | Many recommendations may connect one customer to many products. |
Table 4. Physical Data Model With Keys, Attributes, and Cardinalities
Logical vs. Physical Process and Data Models
Logical models focus on what the business needs the system to accomplish, while physical models focus on how the solution will be implemented using software, databases, hardware, and external services. A logical process model may show that a customer searches for a product and receives product information. The physical process model identifies the mobile application process, the product database query, the inventory database lookup, and the response returned to the customer. Logical data models identify entities and relationships, while physical data models define tables, fields, data types, primary keys, foreign keys, and implementation constraints (Shelly & Rosenblatt, 2012).
For this application, a logical model might show that customers place orders for products. The physical model expands that idea into a Customer table, an Order table, an OrderItem table, and a Product table. It also identifies that CustomerID is a foreign key in the Order table and that ProductID is a foreign key in the OrderItem and Inventory tables. This extra detail is necessary because developers and database administrators must know how the system will actually store, retrieve, and protect business data.
Application Objects
Key objects include User, Customer, Employee, Administrator, Product, Inventory, ShoppingCart, Order, OrderItem, StoreLocation, Recommendation, BarcodeScanner, and VideoDemonstration. These objects support the core business processes of searching, purchasing, recommending products, and managing store inventory. For example, the Customer object can search products and place orders, the Product object stores product details and demonstration links, and the Inventory object tracks quantity and aisle location. The BarcodeScanner object supports scanning a barcode and returning the matching Product object.
| Object | Key Attributes | Key Operations |
| User | userID, name, email, passwordHash, role | login(), logout(), updateProfile() |
| Customer | customerID, savedPreferences, purchaseHistory | searchProduct(), scanBarcode(), placeOrder(), viewRecommendations() |
| Employee | employeeID, department | updateInventory(), assistCustomer(), viewProductLocation() |
| Administrator | adminID, accessLevel | manageUsers(), manageProducts(), generateReports() |
| Product | productID, name, barcode, category, price, demoURL | displayDetails(), updatePrice(), linkDemoVideo() |
| Inventory | inventoryID, productID, storeID, quantity, aisle | checkAvailability(), decrementQuantity(), updateLocation() |
| ShoppingCart | cartID, customerID, cartItems | addItem(), removeItem(), calculateTotal() |
| Order | orderID, customerID, status, totalAmount | createOrder(), processPayment(), generateReceipt() |
Table 5. Application Objects, Attributes, and Operations
Inheritance Structure
The User class serves as the superclass for Customer, Employee, and Administrator objects. This structure prevents duplicate code because shared attributes and operations can be defined once in the User class. Customer, Employee, and Administrator inherit common attributes such as userID, name, email, passwordHash, and role. They also inherit operations such as login, logout, and updateProfile. Each subclass then adds its own application-specific attributes and operations. This is a UML generalization relationship because the subclasses are specialized types of the User superclass.
+-----------------------------+ | User | | userID, name, email, role | | login(), logout(), update() | +--------------^--------------+ | +----------------------------+----------------------------+ | | | +--------------------+ +--------------------+ +--------------------+ | Customer | | Employee | | Administrator | | preferences | | department | | accessLevel | | placeOrder() | | updateInventory() | | manageUsers() | +--------------------+ +--------------------+ +--------------------+
Figure 6. UML Inheritance Structure With Generalization Lines
UML 2.0 Class Diagram
The expanded UML class design identifies classes, attributes, operations, associations, and multiplicities among the major application objects. The relationships show that one customer may own one shopping cart, one customer may create many orders, one order contains one or more order items, each order item references one product, and each product may have multiple inventory records across store locations.
Customer 1 ---- 0..* Order Customer 1 ---- 1 ShoppingCart ShoppingCart 1 ---- 0..* OrderItem Order 1 ---- 1..* OrderItem OrderItem * ---- 1 Product Product 1 ---- 0..* Inventory StoreLocation 1 ---- 0..* Inventory Customer 1 ---- 0..* Recommendation Recommendation * ---- 1 Product
Figure 7. UML 2.0 Class Associations and Multiplicities
Programming Tasks and Schedule
The development phase will follow a structured schedule to ensure that all system components are completed and tested before deployment. The project will be divided into programming tasks that match the system architecture, data model, interface design, and business requirements.
| Programming Task | Description | Estimated Duration |
| Database development | Create Customer, Product, Inventory, StoreLocation, Order, OrderItem, and Recommendation tables with keys and permissions. | Weeks 1-2 |
| User account module | Develop registration, login, password management, and role-based access controls. | Week 3 |
| Product search and navigation | Develop product search, department maps, aisle locations, and recommendation services. | Weeks 4-5 |
| Barcode scanning module | Implement scanning, barcode lookup, product details, inventory status, and video demonstration access. | Week 6 |
| Shopping cart and purchasing | Develop cart management, order processing, payment processing, inventory updates, and receipt generation. | Weeks 7-8 |
| Reporting and administration | Develop inventory reports, sales reports, activity reports, and product maintenance tools. | Week 9 |
| Integration activities | Connect modules, APIs, data stores, and external services. | Week 10 |
| Testing and bug resolution | Perform unit, integration, system, security, and user acceptance testing. | Weeks 11-12 |
| Deployment preparation | Complete documentation, training, release planning, and support procedures. | Week 13 |
Table 6. Programming Tasks and Development Schedule
Testing Plan
Testing activities will occur throughout development to verify functionality, performance, usability, and security requirements. Software testing should not be delayed until the end of the project because early testing helps identify defects before they become more expensive to correct (IBM, 2024).
Unit Testing
Unit testing will evaluate individual program components independently. Examples include testing the login function, product search method, barcode lookup method, shopping cart calculation, order total calculation, and inventory decrement function. Developers will perform unit testing during coding activities to identify defects early.
Integration Testing
Integration testing will verify that system modules communicate properly. Testing will confirm that customer records are stored correctly, barcode scans retrieve accurate product information, shopping cart items create correct order records, inventory updates occur after purchases, and payment authorization responses are recorded correctly.
System Testing
System testing will evaluate the complete application in a controlled environment. Testing activities will verify performance, reliability, security controls, usability, navigation, error handling, and compliance with project requirements. The entire application will be tested as one integrated solution before user acceptance testing begins.
Acceptance Testing
Acceptance testing will be performed by stakeholders, employees, and selected end users. Users will complete realistic business scenarios such as searching for a baseball glove, scanning a barcode, locating the item in the store, adding it to the cart, and completing checkout. Final approval will occur after all critical defects have been resolved.
Documentation Plan
Proper documentation will support implementation, training, maintenance, and future improvements. Documentation should be written for both technical and nontechnical readers because developers, administrators, employees, and customers will use the system in different ways.
Technical Documentation
Technical documentation will include system architecture diagrams, database schemas, class diagrams, source code documentation, API documentation, security configurations, and maintenance procedures. This information will support developers and system administrators responsible for maintaining the application.
User Documentation
User documentation will provide instructions for account creation, product searches, navigation assistance, barcode scanning, shopping cart management, and purchasing functions. Screenshots, short procedures, frequently asked questions, and troubleshooting steps will be included to improve usability.
Training Documentation
Training materials will be developed for employees and system administrators. These materials will include quick-reference guides, presentation materials, practice exercises, and troubleshooting procedures designed to support system adoption. Comprehensive documentation will reduce support requirements, improve user satisfaction, and simplify future system enhancements.
Scrum Methodology Conversion
For Week 5, the project is adjusted from the original structured methodology to Scrum. Scrum organizes development into short Sprints that produce usable increments of the product. This approach helps the team respond to changing priorities, receive regular stakeholder feedback, and reduce project risk by reviewing working software throughout development. The Scrum Guide identifies the Product Owner, Scrum Master, and Developers as the core accountabilities on a Scrum Team (Schwaber & Sutherland, 2020).
Scrum Team Roles
The Scrum Team for this project will include a Product Owner, Scrum Master, Development Team, and stakeholders. The Product Owner represents the sporting goods retailer and is responsible for maintaining and prioritizing the product backlog. This person decides which features provide the greatest business value, clarifies requirements, and accepts or rejects completed Sprint work.
The Scrum Master facilitates Scrum events, removes project obstacles, and helps the team follow Scrum principles. This person does not act as a traditional command-and-control manager. Instead, the Scrum Master helps the team stay productive, protects the Sprint goal, and supports continuous improvement. The Development Team includes systems analysts, software developers, database administrators, user interface designers, security specialists, and quality assurance testers. Stakeholders include store managers, employees, customers, and executive leadership who provide feedback during Sprint Reviews.
Product Backlog and User Stories
User stories are used to express requirements from the viewpoint of the user. This keeps the backlog focused on customer and business value rather than only technical tasks. The following backlog organizes major requirements into Sprints for the sporting goods customer guidance application. Story points use a modified Fibonacci scale of 3, 5, 8, and 13 to estimate effort, complexity, risk, uncertainty, dependencies, and testing needs. User stories are useful because they support conversation and shared understanding between business users and developers (Cohn, 2004).
| Sprint | User Story | Story Points | Justification |
| Sprint 1 | As a customer, I want to create an account so that I can save preferences and purchase history. | 5 | Moderate effort because it requires registration forms, validation, database storage, and secure password handling. |
| Sprint 1 | As a customer, I want to securely log into the application so that I can access personalized features. | 3 | Lower complexity because authentication patterns are common, although security testing is still required. |
| Sprint 2 | As a customer, I want to search for products so that I can quickly locate desired items. | 5 | Moderate complexity because it requires search, filters, product database queries, and usable results screens. |
| Sprint 2 | As a customer, I want store navigation assistance so that I can locate products efficiently. | 8 | Higher complexity because it depends on store maps, inventory locations, aisle data, and navigation flow. |
| Sprint 3 | As a customer, I want to scan product barcodes so that I can instantly view product information. | 8 | Higher complexity because it requires camera access, barcode processing, error handling, and product lookup integration. |
| Sprint 3 | As a customer, I want personalized product recommendations so that I can discover products related to my interests. | 13 | High complexity because recommendation logic depends on customer preferences, order history, product relationships, and testing for useful results. |
| Sprint 4 | As a customer, I want to view product demonstration videos so that I can make informed purchasing decisions. | 5 | Moderate effort because the feature needs media links, interface integration, and reliable playback. |
| Sprint 4 | As a customer, I want to purchase products through the application so that I can complete transactions conveniently. | 13 | High complexity because it includes cart logic, order processing, payment gateway integration, inventory updates, and security controls. |
| Sprint 5 | As a store manager, I want access to sales and customer reports so that I can monitor business performance. | 8 | Higher complexity because reports require data aggregation, filtering, dashboards, and access controls. |
| Sprint 5 | As an administrator, I want to manage inventory records so that product information remains accurate. | 5 | Moderate effort because it requires create, read, update, and delete functions with validation and database integration. |
Table 7. Scrum Product Backlog, Sprint Assignments, Story Points, and Justifications
Sprint Plan and Delivery Value
Sprint 1 focuses on account management because personalization, order history, and recommendations depend on identifying the user. Sprint 2 focuses on product search and navigation because those features directly support the core customer guidance purpose of the application. Sprint 3 adds barcode scanning and recommendations, which increase customer convenience and sales opportunities. Sprint 4 adds videos and purchasing features, allowing the system to support informed buying decisions and checkout. Sprint 5 adds reporting and administration so that store managers and administrators can maintain accurate data and monitor business performance.
The story point values reflect relative effort rather than exact hours. A 3-point story is smaller and more predictable, a 5-point story has moderate development and testing needs, an 8-point story includes greater technical integration or uncertainty, and a 13-point story represents major functionality with multiple dependencies. This estimation approach helps the Scrum Team plan Sprints while still allowing flexibility as the team learns more during development.
Conclusion
The proposed sporting goods customer guidance application provides a scalable and user-friendly solution for improving customer experiences. The combination of custom development, n-tier architecture, dashboard navigation, physical data modeling, data flow modeling, object-oriented design, testing, documentation, and Scrum planning supports future growth and long-term business value. This revised version also responds to prior feedback by adding more explanation, clearer citations, more detailed models, and stronger project management detail.
Transitioning the project to Scrum provides greater flexibility and responsiveness than the original traditional development methodology. By organizing requirements into prioritized user stories and delivering functionality through multiple Sprints, the project team can continuously incorporate stakeholder feedback while reducing development risk and improving overall product quality.
References
Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional.
Dennis, A., Wixom, B. H., & Tegarden, D. (2021). Systems analysis and design: An object-oriented approach with UML (6th ed.). Wiley.
IBM. (2024). What is software testing? IBM. https://www.ibm.com/topics/software-testing
Nielsen, J. (2024). 10 usability heuristics for user interface design. Nielsen Norman Group. https://www.nngroup.com/articles/ten-usability-heuristics/
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org/scrum-guide.html
Shelly, G. B., & Rosenblatt, H. J. (2012). Systems analysis and design (9th ed.). Cengage Learning.