Requirements Engineering using Petri Net Tool

Mid Term Paper Requirements Engineering using Petri Net Tool Software Requirements Engineering SEN-570 S.M. Saiful Islam ID # 0712004 Program – M.Sc. in SE April 12, 2008 1. INTRODUCTION............................................................................................................................. 3 1.1 EXAM REQUIREMENT .................................................................................................................... 3 1.2 PROJECT INFO ................................................................................................................................ 3 2. MATERIALS AND METHODS ..................................................................................................... 3 3. PROJECT DESCRIPTION ............................................................................................................. 4 3.1 BUSINESS OVERVIEW .................................................................................................................... 4 3.2 SYSTEM OVERVIEW – WORK PROCESS ......................................................................................... 4 4. ARTICULATED REQUIREMENTS ............................................................................................. 5 5. PETRI NET BASED DES MODEL OF THE REQUIREMENTS DEVELOPED BY HPSIM TOOL ..................................................................................................................................................... 9 6. LIMITATIONS OF THETOOL TO DOCUMENT THE REQUIREMENTS......................... 14 7. SUGGESTIONS TO IMPROVE THE TOOL ............................................................................. 14 8. INTEGRATED DES MODEL....................................................................................................... 15 9. VARYING ATTRIBUTES OF THE MODELS........................................................................... 17 10. BENEFITS OF THE MODEL..................................................................................................... 19 11. USEFULNESS FOR THE PURPOSE OF VERIFICATION, VALIDATION, AND CONSOP PREPARATION................................................................................................................ 19 12. USEFULNESS IN MAINTENANCE STAGE ........................................................................... 19 13. EMPLOYEE TURN OVER IMPACT........................................................................................ 20 14. CONCLUSION ............................................................................................................................. 20 1. Introduction 1.1 Exam Requirement The main objective of this exam is to convert requrements of an existing project into descrete event system and analysis its different aspects. Following are the questions/quidelines to complete this assignment. Questions have been copied bellow from the supplied question paper as it is: ”Take a complete project, very much known to you with access to different itermediate products including code. Apply following suggestions to this project: 1. Articulate requirements as a numbered list in a hierarchical manner, preferably three levels. 2. Attempt to model each requirement as Petri net based discrete event system (DES) using HPSim tool. 3. Document limitations of this tool to model each of this requirements. 4. Provide suggestions to improve the tool to address detected limitations to model requirements. 5. Integrate these discrete models into an integrated one by modeling the whole software. 6. Simulate these model by varying different attributes of the system such as characteristics and execution times of process. With the help of tables and graphs visualize simulation results. 7. What are the benefits could be drawn from this model exercise with respect to the productivity, defects, and requirements change management? 8. How can these models be useful for the purpose of verification, validation, and ConsOps preparation? 9. How can these models be useful at the stage of maintenance? 10. How can these model reduce employee turnover impact in software development and maintenance projects?” 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 ITcare. 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. Key Account $ $ Sales report Offer Offer: Køge 2006 Vejle 2007 Køge 2006, Vejle 2007 Total: 12500,- Order lines Payment plan ----------------------------------------------------------------------01/01: 5000,01/04: 5000,01/07: 2500,Order confirm Payment plan overview 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 Description Key Account List Module 1 1.4.2 1.4.3 1.4.4 1.4.5 Level I Req. No. Level II Req. No. 2.1 Description Key Account Basic Data Req. No 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 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 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 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 Description Key Account Info Module 2 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 Level I Req. No. Level II Req. No. Description Req. No 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 Level III Description 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 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 Description 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 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 5. Payment Plan Module 5.1 Payment Basic Data 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 Level I Req. No. Level II Req. No. 5.2 Description Print Order list Req. No 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 Level III Description 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 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 Description 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 6.5 Archives 6.5.1 6.5.2 6.5.3 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 Level I Req. No. Level II Req. No. 7.9 Description Competetitor Info Import Production Plan Req. No 7.9.1 8.1.1 8.1.2 8.1.3 Level III Description Show Competetor Info Site Update book deadline Update company book deadline Update key Account deadline Description 8. Production Plan Module 8.1 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 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 to Document the Requirements 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. Integrated DES Model All the isolated models have been integrated based on data flow and dependency and shown in the next page. Samas Key Account Apllication (KAA) Figure – 2 : Integrated DES Model - Whole KAA project (Major Entities) 9. Varying Attributes of the Models The DES models have been executed with varying attributes. It would be very complicated to produce the results of all the verying attributes. To do that, the key account search list has been considered. The DES model of the Key Account List Module has been shown in the following figure. Figure 3: Key Account List Module The attributes of the current models give most realistic output The following table shows the current model attributes. Table - 3 : DES model of Key Account List with major attributes Object Type Place Name KAA MDI Key Account List Key Account List2 Key Account Info Transitions Show key accout list Create key account Access key account Delete key account Filter key account Arc KAA MDI -> Show KA List Show KA List -> KA List KA List -> Filter KA Filter KA -> KA List KA List -> Create KA KA List -> Access KA KA List -> Delete KA Initial Tokens 1 0 0 1 Capacity 1 1 1 1 Deterministic Deterministic Deterministic Deterministic Deterministic 1 4 5 6 7 Normal Normal Normal Normal Test Test Test Time Mode Initial Delay Type Object Type Name Delete KA ->KA List Create KA -> KA Info Access KA -> KA Info Initial Tokens Capacity Time Mode Initial Delay Type Test Inhibitor Inhibitor Following table shows the overall execution time on varying execution time mode: Table - 4 : DES model simulation result-Execution Time Steps Transitions Time Mode Initial Delay Total Execution Time (Secs) 1.52 Step 1 Show key accout list Create key account Access key account Delete key account Filter key account Immediate Immediate Immediate Immediate Immediate Deterministic Deterministic Deterministic Deterministic Deterministic Exponential Exponential Exponential Exponential Exponential Uniform Distribution Uniform Distribution Uniform Distribution Uniform Distribution Uniform Distribution Immediate Deterministic 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 4 Step 2 Show key accout list Create key account Access key account Delete key account Filter key account 2.56 Step 3 Show key accout list Create key account Access key account Delete key account Filter key account 1.55 Step 4 Show key accout list Create key account Access key account Delete key account Filter key account 2.12 Final Step Show key accout list Create key account 5.10 Steps Transitions Time Mode Initial Delay Total Execution Time (Secs) Access key account Delete key account Filter key account Deterministic Deterministic Deterministic 5 6 7 10. Benefits of the Model Using the DES model will have significant benefits in productivity, defects and requirements change management. These could be described in the following points: 1. The DES model will increase the productivity. The requirements understanding time will be significantly reduced. The requirements can be efficiently and correctly communicated among stake holders. This will significantly speed up the process which in turn will increase the productivity. 2. The DES model will be more efficient in defect prevention. As the understandability and communciation will be more transperent and accurate among stakeholders, it will prevent significant defects. It will also helps in defect detection. 3. The DES model will also help in requirement change management. It will be very easy to visualize the changes from the previous versions. That will speed up the process and would be great help to the stake holders. 11. Usefulness for the purpose of verification, validation, and ConsOp preparation The DES model will play a vital role in verification, validation and ConsOp prepration. The usefulness can be listed as follows: 1. The DES model will be able to simulate requirements in detail and dynmic manner. Changing the different behavior it will be easy to test the requirements. So, it will be a useful tool to verify the requirements. 2. The DES model will be also helpful to validate the requirements. As this could be communicated to the stakeholders in more lively way, they will be able to give their feedback more accurately. So, whether the requirement is valid or not will be identified easily. So, DES model can play a vital role in validating requirements. 3. The DES model will be very helpful in preparing the concept of operations. If the DES modeling is done taking the user perspective, in detail way, it will be a very good input for the preparation of ConsOp. Due to its visual appeal and livelyness, user will give more close feed back and comments. Incorporating those, it will be very easy to translate DES models to ConsOp. 12. Usefulness in Maintenance Stage The DES model will be very useful in maintenance stage. As usually, there is not many people involved in maintenance stage, few people are responsible for providing support, it is not usually possible for them to memorize everything. In case of any urgeant support, the DES model will help a lot to understand the problem and to provide quick support accordingly. 13. Employee turn over impact The DES model can significantly reduce employee turn over impact in software development and maintenance project. The DES model represent requirements in well articulated manner. Due its visual appeal and liveliness and well articulated behavior, the requirements become very clear and understandable to the new entrant. He will take significantly less time to reach up to the level so that he can be useful resource soon. 14. 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.