"Requirements Review Checklist - DOC"
1 Review Checklist This checklist has been created to assist you in the requirements review process. It is divided in the several categories that all have an effect on performance. The list can be extended as needed, but it contains all the essential questions. The checklist also indicates the document(s) where the answer on the question should be found. A requirement is only correct if it is unambiguous. If for instance a requirement defines a certain response time, it must be clear under which conditions this response time should occur. Question Why do we ask this? User Base Total amount of users? Defines the size of the user information database. (logins that need to be created for the simulation) How many concurrent users? Defines the load that the system should be able to handle. Concurrent means: How many users are busy with the system. How many peak users? Defines the maximum load that the system should be able to handle. How often are the peaks and when are Defines how often the maximum amount of users occurs and they occurring? when the peaks are occurring Roles of the users? Defines the break down of the users in roles that could have different impact on the system resources. For instance: ESR, data entry, management, supervisor etc. Which roles support which business Defines the break down of the users in roles/activities that functions/user scenarios? could have a different impact on the system resources. Location of the users? Defines potential remote connections and therefore specific test requirements. Network connection methods of the Defines if the users need to connect through alternative users? mechanisms (instead of the LAN). This could result in specific test requirements. Activities Supported business functions? Defines the different unique business functions and enables the test group to assess the resource usage per business function. Business functions ranked by Defines how often certain business functions are used in order frequency to assess the overall resource usage. User scenarios Defines how the system will be used by the users. It is necessary to simulate this in a performance test. User scenarios ranked by frequency Defines how often certain scenarios are executed so that you are able to define a correct simulation. This will result in information about the throughput of the system. Batch run times Defines how much time is set aside for batch programs to run and therefore how much time in a day is available for the online system. This is needed to estimate the daily throughput. User scenarios ranked by response Defines the scenarios that belong to front office and to back sensitivity (talking on the phone with a office. In the simulation, special attention can be given to the client) front office activities. Environmental Constraints Operating hours? Defines the requirements related to stability of the application. If the application is supposed to be 24/24, then tests related to this requirement should be executes to assess the stability of the system components. Dependencies on other systems? Defines how other systems could potentially influence the Question Why do we ask this? performance results of the system under test. If a significant influence is expected then this influence should be simulated in the tests. Dependencies on system resources? Defines how specific system resources could potentially influence the performance results of the system under test. If a significant influence is expected then this influence should be simulated in the tests. System resources are shared with? Defines how specific shared system resources could potentially influence the performance results of the system under test. If a significant influence is expected then this influence should be simulated in the tests. Security requirements that might Defines how specific security requirements could potentially impact performance (SSL, firewalls, influence the performance results of the system under test. If a SSO) significant influence is expected then this influence should be quantified in the tests. Response times Information request Defines the general performance expectation for this activity. Information request is the retrieval on information based on a user-supplied key. Value lookup Defines the general performance expectation for this activity. Value lookup is the retrieval of a code value description. Save/Submit entered information Defines the general performance expectation for this activity. Save/Submit is storing the new or changed information in the database. Search information Defines the general performance expectation for this activity. Search information is using a search facility in the application that does not necessarily use key values. Start to print Defines the general performance expectation for this activity. Start to print is defined as the time between giving the print command to the time that the printer starts to print. Time to print Defines the general performance expectation for this activity. Time to print is the time that it takes for the print action to be finished measured from the time that the printer starts. Window/Page appearance Window/Page appearance refers to the time that it takes for a new window/page to show up and be able to be used. Window/Page operational Window/Page operational refers to the time that it takes to operate features in the window like pushbuttons, list boxes etc. Front office/Back office values for all Defines the difference between the expected response times of of the above a front office function and a back office function. Risks What are the risks to the scenarios, the Defines the risk that will drive the plan for Performance system, the Company if performance Testing. criteria are not met? Common risks factors: These are the most common risk factors related to Large user base performance. New technology Unproven technology New use of existing technology Inexperienced team High peak usage Large portion of front office activities Question Why do we ask this? External exposure Stringent security measures Resource intensive scenarios