1. Company: Amdocs Academic advisor: Ehud Gudes Technical advisor :Gabby Shimony Team: Uzi Lewin Elina Shlangman

2. 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.

3. 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.

4. The Problem Domain Company (The customer) Company's Client Customer Feedback Simulator Output file Amdocs Data gathering Data processing

5. Proposed solution  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.

6. System Architecture

7. Functional Requirements  Rule configuration definition  File checking  Log file production

8. Non-Functional Requirements  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.

9. Non-Functional Requirements  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.

10. Use Cases  Rule definition  Rules loading  File testing

11. 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.

12. Use cases: Rule definition

13. 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.

14. Use cases: Rules loading

15. 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.

16. Use cases: File testing

17. 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.

18. The end