IBM BS029ML Self Help Guide - Page 29

The following non-functional requirements are documented to articulate the critical elements of a successful implementation: Availability Backup and Recovery Capacity Estimates and Planning Disaster Recovery Extensibility/Flexibility Failure Management Performance Scalability Security Service Level Agreements Standards System Management Usability Tip: A non-functional requirement is not well specified if it is not specific or measurable. Attainability and measurability are checks that should be performed against each requirement. A requirement should only be included if it is attainable and realizable. 2.1.6 Frequently asked questions about sizing The most frequently asked questions in terms of non-functional requirements are typically those regarding sizing or capacity planning. For example, given a specific Portal deployment and an anticipated traffic load, what kind of configuration will satisfy the sizing requirements? For example, Customer X has an initial registered user base of 20,000 potential users. This figure is however envisaged to rise to 40,000 users in two years time and potentially to an upper bound of around 60,000 registered users after that. Therefore, the need to architect a platform that can scale to accommodate the growth forecasted for the next two to five years exists. It is important to understand that the definition of the registered user base does not actually impact the number of users or clients concurrently accessing the solution. Rather, the registered user base is just the user population that may access the solution at any given point in time. Internally, WebSphere Portal Server maintains a database entry for all registered users after their initial login. No constraint, other than the size of the database table and the size of the selected LDAP user repository, should impede the growth of the registered user base. A more meaningful metric when sizing any WebSphere Portal Server solution is the anticipated number of concurrent users or clients. Typically, such values for the number of concurrent clients are calculated as a percentage of the registered user base. For example, based on the current metrics supplied by Customer X for their existing Web deployment, this figure averages at about 2,500 unique user sessions per hour. This would imply that only 12.5% of the current registered user base actually interacts with the current solution. By the same calculation, the number of concurrent clients would increase to 5,000 for the projected growth in the registered user base to 40,000. This assumes that the percentage of clients using the Portal remains stable at 12.5%. However, careful consideration needs to be taken into account, as this figure may increase once more applications and functions are brought online within the Portal solution. As such, for Customer Chapter 2. Architecture and planning 15