Customer Feedback Simulator Company: Amdocs Academic advisor: Ehud Gudes Technical advisor :Gabby Shimony Team: Uzi Lewin Elina Shlangman
Background • Amdocs provides billing services for major communication and cable companies. • Among their customers are major companies such as AT&T, T-mobile & Vodafone, and minor ones such as Cellcom & Orange. • Amdocs is a company who provides services to be integrated in external systems.
The Problem Domain • When Amdocs upgrades its systems it produces new files that should be tested in external systems (companies Amdocs works with). • The external systems are not always available for testing. • The current situation is that new files are tested manually, which makes the testing process really slow.
The Problem Domain Company's Client Amdocs Data gathering Customer Feedback Simulator Company (The customer) Data processing Output file
Proposedsolution • The project’s goal is to create a software to simulate the customers Amdocs works with, and give a feedback on the newly created files. • This simulator must be as generic as possible in order for it to simulate current and future companies. • This will save time and money.
Functional Requirements • Rule configuration definition • File checking • Log file production
Non-FunctionalRequirements • Speed Capacity & Throughput: • File definition & configuration will last less than a second. • processing the file will last less than a minute. • 95% of the time the proper result report will be produced, while in other cases a specific error message will appear. • Only one user may use the system at any given time.
Non-FunctionalRequirements • Reliability: • The simulator is expected to deliver correct valid results at 99% of the time. • Usability: The simulator is simple and easy to learn. A couple of hours are enough to master the simulator. • Platform: • The simulator’s language is English. • Programming language: Java. • OS: Microsoft windows.
UseCases • Rule definition • Rules loading • File testing
Use cases: Rule definition Course of action: 1. User informs that he wants to create a new rule. 2. System presents the GUI tools. 3. User picks a rule. 4. System remembers rule. 5. Go to 2 until user satisfied. 6. System stores the new rule in a file.
Use cases: Rules loading • Course of action: • 1. User informs that he wants to Load a file. • 2. System presents all files saved. • 3. User picks a file & confirms. • 4. System loads file.
Use cases: File testing • Course of action: • 1. User specifies a file to the system. • 2. System checks that the file is consistent with the rule. • 3. System writes a log file.
Risks • Our major risk lies in the definition of the language we are to create. • This language is to be as generic as possible, so we are able to simulate any current or future company Amdocs works with.