Usability of Petri net Tool in Requirements Engineering

Assignment - 2 Usability of Petri net Tool in Requirements Engineering Software Requirements Engineering SEN-570 S.M. Saiful Islam ID # 0712004 Program – M.Sc. in SE March 22, 2008 1. INTRODUCTION............................................................................................................................. 3 1.1 ASSIGNMENT REQUIREMENT ........................................................................................................ 3 1.2 PROJECT INFO ................................................................................................................................ 3 2. MATERIALS AND METHODS ..................................................................................................... 3 3. PROJECT DESCRIPTION ............................................................................................................. 3 3.1 BUSINESS OVERVIEW .................................................................................................................... 3 3.2 SYSTEM OVERVIEW – WORK PROCESS ......................................................................................... 4 4. ARTICULATED REQUIREMENTS ............................................................................................. 4 5. PETRI NET BASED DES MODEL OF THE REQUIREMENTS DEVELOPED BY HPSIM TOOL ..................................................................................................................................................... 8 6. LIMITATIONS OF THETOOL.................................................................................................... 14 7. SUGGESTIONS TO IMPROVE THE TOOL ............................................................................. 14 8. CONCLUSION ............................................................................................................................... 15 1. Introduction 1.1 Assignment Requirement The main objective of this assignment is to convert requrements of an existing project into descrete event system and analysis its different aspects and limitatitions. To reach a common template to document the answer a discussion was held in the class room. The subsequent sections will follow that template. 1.2 Project Info A completed project named KAA (Key Account Application) developed by the ITNet Ltd (www.ITNet.com) for a Danish company named Enren Denmark A/S (www.Enren.dk) has been taken into account to complete this assignment. This project at present is running in production environment at Enren and passing through the maintenance phase. A brief over view of the project has been described later on. 2. Materials and Methods For preparing this document, I have taken the most recent project in which I played the key role and I have full access to all resources. Most of the requirements were specified by the Enren Business Development Consultant and documented by IT Consultant from Groupcare. Many documents have been produced in this project which includes Requirements Specification document also. I have mainly used that document to articulate the requirements in hierarchical manner. Then these requirements have been modeled as discrete event system using Petri net tool HPSim. Then analyzed difficulties of modeling the requirements and tried to come up with some suggestions to overcome those difficulties. At the same time, the strength of Petri net tools have discovered and this could improve productivity and other concern areas have been figured out. 3. Project Description 3.1 Business Overview One of the major business area of Enren is to publish different directory like Yellow Pages. Enren publishes more than 700 directories in the Nordic countries. Enren Denmark alone publishes more than 300 directories in Denmark. These directories (relevant ones) are available wholeover the country - all offices, public places, shops, houses for free. But, these books contain huge number of advertisements. Advertising in these books are highly costly. These advertisements generates huge revenue for Enren per year. There is millions of customers who give advertisement in these books. So, selling these advertisement is a huge task. There is two type of customer - Core Customer and Key Account Customer. If any customer meets one of the following criteria can be treated as Key Account: • Yearly sales above DKK 150,000 (US$ 30,000) and/or • A chain with more than 10 departments (also referred to as companies or branches) • One of the 100 largest business-to-consumer enterprises in Denmark • High order complexity (ordering more than 10 books per year) This project - KAA only focuses on supporting the sales and registration procedures for Key Accounts. 3.2 System Overview – Work Process An overall view of the major entities in KAA is shown below. Figure 1 – Major System Entities All items in the figure 1 shaped as a document illustrates a report/letter printed from the application. The customer is the main entity in the application and all actions is based on these. A normal work process would be: 1. A Key Account is selected 2. Offer is created (and printed) by the salesperson/supporter when the Key Account is prepared. Preparing simply means that all information such as phonebook ads, Key Account overview and Key Account Offer is printed and collected to prepare the sales person for a customer visit. 3. When the order is received from the customer (by fax or letter) an order confirmation is sent to the customer. 4. The order lines are added to a payment plan and registered in Daisy. 5. Payments are then added to the payment plan and an order confirmation and payment plan overview is printed by the sales supporter and sent to the Key Account. 6. Sales reports can be printed to follow-up on the sales effort. 4. Articulated Requirements The major functional Requirements of KAA has been articulated and described in the hierachical manner upto three levels in the follwoing table: $ $ Table – 1 : Well articulated requirments in hierachical mamer Level I Req. No. Level II Req. No. 1.1 Description Show Key Account List Req. No 1.1.1 1.1.2 1.2 Filter Key Account List 1.2.1 1.2.2 1.3 1.4 Create Key Account Delete Key Account 1.3.1 1.4.1 Level III Description Show only active key account list Show list by pages (200 per page) Filter list by Key account name Filter list by Department (name or number) Open new Key Account Info Check whether selectected Key Account has multiple department associated. If it has multiple departments then abort other wise proceed for deletion. Delete Key Account Delete Main Office Delete Related Offers Delete Related Payment Plans Provide Key account general Information Select Main Office Select Status Select Sales Persons Select Book Deadline Validate and Save Key Account Info Show associated department list Show Search and Associate UI Add departments Remove departments Show key account offer list Filter Key Account Offer list Create new Key Account Offier Description Key Account List Module 1 1.4.2 1.4.3 1.4.4 1.4.5 2 Key Account Info Module 2.1 Key Account Basic Data 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.2 Key Account Departments 2.2.1 2.2.2 2.2.3 2.2.3 2.3 Key Account Offers 2.3.1 2.3.2 2.3.3 Level I Req. No. Level II Req. No. Description Req. No 2.3.4 2.3.5 2.4 Print Orders 2.4.1 2.4.2 2.4.3 2.5 Payment Plans 2.5.1 2.5.2 2.6 Key Account Ads 2.6.1 2.6.2 2.6.3 Level III Description Remove key Account Offer Delete key Account offer Show Print Order list Filter order lines Show select order information Show payemnt plan list Filter payment plan list Show Key Account Ads Fliter Ads Print Proof Provide general Information Select Customer Select Payer Provide Text for Customer Validate and Save Key Account Offer Create Payment Plan Add to Payment Plan Send Customer Letter Show Offline Orderline list Create Offerline Copy Offerlines Remove Offerlines Delete Offerlines Replace Orderlines Recalculate Select Book Select Section Select Heading Select Product Calculate Product Price Select Ad Description 3. Key Account Offer Module 3.1 Key Account Offer basic data 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 3.2 Print Order list 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 4. Offline Offerline Module 4.1 Offline Offerline Basic Data 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 Level I Req. No. Level II Req. No. Description Req. No 4.1.7 4.1.8 4.1.9 4.2 Alternative Address 4.2.1 4.2.2 4.2.3 4.3 ATX/RTX 4.3.1 4.3.2 4.3.3 4.4 Ad 4.4.1 4.4.2 Level III Description Select Extra Product Calculate Extra Product price Validate and Save Offerline Show Main Address Show Alternative Address Change Alternative Address Provide ATX Provide RTX Provide Logo no Show Ad no. Show Ad Select Payer Show offer Value Distribute Payments Makeup Payments Validate and Save Payment Plan Show Offline Orderline list Create Offerline Copy Offerlines Remove Offerlines Delete Offerlines Replace Orderlines Key Account Offer Letter Detail Offer Letter Key Account Order Confirmation Detail Order Confirmation Payment Plan Overview Letter Proof Print Show letter list Archive letter Email letter Description 5. Payment Plan Module 5.1 Payment Basic Data 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2 Print Order list 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 6. XLetter Module 6.1 Send Customer Letter 6.1.1 6.1.2 6.1.3 6.1.4 6.2 6.3 6.4 Payment Plan Ad Letters 6.2.1 6.3.1 6.4.1 6.4.2 6.4.3 Level I Req. No. Level II Req. No. 6.5 Description Archives Req. No 6.5.1 6.5.2 6.5.3 Level III Description Show archived letters Delete letter Show deleted letters Show Company Basic Info Show Company Info Site Show Company related Information Show Parent Company List Show Chilt Company List Show Complaints against Sales person Show Complaints against Company Show activitiy list related with this company Show activity detail Show print order list Show order information Show Competetor Info Site Update book deadline Update company book deadline Update key Account deadline Description 7. Company Module 7.1 7.2 7.3 7.4 Company Basic Data Info Site Information Relations 7.1.1 7.2.1 7.3.1 7.4.1 7.4.2 7.5 Complaints 7.5.1 7.5.2 7.6 Activities 7.6.1 7.6.2 7.8 Print Orders 7.8.1 7.8.2 7.9 8. Production Plan Module 8.1 Competetitor Info Import Production Plan 7.9.1 8.1.1 8.1.2 8.1.3 5. Petri net based DES model of the requirements developed by HPSim tool Following table shows the DES model of the major requirements developed by HPSim: Table - 2 : DES model of the major requirements Req. No. Description DES Model Req. No. Description Key Account List Module DES Model 1 2 Key Account Info Module Req. No. Description DES Model 3. Key Account Offer Module Req. No. Description Offline Offerline Module DES Model 4. Req. No. Description Payment Plan Module DES Model 5. 6. XLetter Module Req. No. Description Company Module DES Model 7. Req. No. Description Production Plan Module DES Model 8. 6. Limitations of theTool For documenting the requirements I faced the following difficulties: 1. I needed to place several transitions between two places those will be executed one after another sequenciatially. That was very complicated to do. There I found some way to solve that problem using time effect. That is not feasible if the number of transitions is high. 2. It is very difficult to simulate a looping action controlling the initial and final tokens. 3. It is very complicated to simulate a whole process that require several sequential and parallel process. 4. Controlling the token flow providing different time effect on transitions and changing the behavior of the arch is complicated. 5. It is very difficult to denote different entities and actions, as there is only one type of tokes, places and transitions. 7. Suggestions to Improve the Tool Follwoing suggestions could help to improve the tool that would be better suited for modelling the requirements, design or something like that: 1. How many times a transition will be executed i.e will pass token, if can be pre set, then it will solve many problems. 2. If the number tokens can be controlled in a place without depending on token flow, will be a big help to similuate many practical requirements. 3. Improvement need in fake token flow. Now, using test and inhibitor token flow can be controlled up to some point. But, improvement needed here. 4. Need improvement in inter dependency management and process synchronization. If there is any option to define some execution area as process and making it related or dependent on other process, that would be a great improvement. 5. There should have some visual options to differentiate tokens, places and transitions for different entities and actions. 6. It would be very nice, if there is some options to control token flow, tokens count, time, etc. using some formula for advance user. That would help to model some complicated requirements. 8. Conclusion From the above study, it is eveident that, Petri net based HPSim tool can be used to model the whole software, though, there is still some limitations. If do model the system considering all the limitations, still it will worth a lot. Uses of the DES model, will increase the stakeholders understandability significantly. It will increase transperancy of the requirements, i.e. stakeholders will the more clear picture. This will in turn increase the productivity, mantainablity and reduce the employee turn over impact. So, DES model could be widely used in the defferent areas like verification, validation, ConsOp preparation, etc.