Please visit the Test Exercise Entry Point first. It is locatedunder This Link.</P>
Kickoff of the Early Attack Testing (EAT) Exercise</P>
I thought I could kick this exercise off with an example. The following demonstrates a method of requirements extraction and serves as a basis for preparation of a Requirements Traceability document.</P></FONT><FONT size=2></FONT><FONT face=Tahoma size=2>
RFP Section 2.2 Last Bullet</P>
"Fast Loading Pages <SUP>Perf-100</SUP> – The Web site must be designed <SUP>Perf-101</SUP> with a balance of text and graphics such that each page loads in 8 seconds <SUP>Perf-102 </SUP>or less<SUP> Perf-103</SUP> on the average computer <SUP>Perf-104</SUP>(using 56K dialup modem)<SUP> Perf-105</SUP>."</P>
Perf-100: Ambiguous except clarification per subsequent requirements. Get page-load time exceptions from customer. Begin to involve capacity planning, and begin performance test plan. Trigger usage projections and begin to factor those in. Ensure capacity planners and system architects are copied on business projections. Get customer to research current usage and factor related metrics in along with usage projections. Trigger research to determine acceptable limits of system resource utilization under both average load and what are deemed to be stress or spike loads beyond average loads (CPU, disk I/O, database activity, etc.). These data will be reconciled against page load times specifications such that we avoid a situation where system resources are over-utilized out of the starting gate to the point where scaling and/or tuning needs to occur. Another thought is that we do not wish for system resources to have little overhead. We may suggest that for example if CPU is shown to be 75% utilized on a daily basis and growth projections show more users – we may need to rethink the system architecture.</P>
Action will be required of the System Analysts, System Architects, and development team with respect to architectural design and development performance awareness and proofing. The development plan and/or standards document should address the same requirements and be traceable.</P></FONT>
The above requirement looked like this originally:
<font color="blue">Fast Loading Pages – The Web site must be designed with a balance of text and graphics such that each
page loads in 8 seconds or less on the average computer (using 56K dialup modem). </font> The transformation represents one method of annotating and mark them for inclusion in a traceability matrix.
Are all the high-level requirements marked, flagged, or otherwise extracted from the above? Is the discussion complete?
Please feel free to address these questions from any perspective as well as <font color="blue">submit your own requirements breakdown for another requirement from the RFP/Spec. </font>
<font color="brown">Please make sure you read all material in this topic as it may affect the material you input.
Ok, is this where we give some input? Let me give this a shot:
- Password-protected content-Sec-0100 contribution and editing-Func-0100 for multiple authors-Sec-0101
-Shared-Sec-0200 calendars with multiple contributors-Func-0300
-On-line dialogue and surveys-Func-0200 to enable us to gather e-mail-Func-0250, Sec-0300 areas of interest-Func-0251 and demographic-Func-0252 information from visitors in a format that permits the City to maintain a single database of users and email-Sec-0300, Perf-0200 each according to their area of interest and profile-Func-0220
Ok, I've handled a couple of bullets here. Let me know if my explanations are any good.
Sec-0100 - Contains tests pertaining to protected access
Sec-0101 - Multiple authors means multiple points of failure. Check for Injection.
Sec-0200 - Contains tests pertaining to data sharing
Sec-0201 - Check that calendars are only shared with appropriate permission levels
Sec-0202 - Check that calendars may not be accessed by regular visitors
Sec-0203 - Check that login for calendars are not subject to injection
Sec-0300 - Pertains to any data collection
Sec-0301 - Can the survey be manipulated to give up email data
Sec-0302 - Can the survey be manipulated to give up areas of interest data
Sec-0303 - Can the survey be manipulated to give up demographic data
Sec-0304 - Attempt to obtain information about the database from errors the survey may raise.
Func-0100 - Functionality pertaining to content management
Func-0101 - content can be created by multiple contributors
Func-0102 - content can be edited by contributors with sufficient permissions
Func-0103 - can content be edited by contributors who are at a lower access level than the original contributor
Func-0104 - are there multiple access levels for contributors
Func-0105 - content can be edited by the original contributor
Func-0200 - Pertains to any visitor-interaction medium
Func-0201 - Are surveys given to the appropriate group
Func-0250 - Can email data be collected and stored via survey
Func-0251 - Can interests be collected and stored via survey
Func-0252 - Can demographic data be collected and stored via survey
Func-0300 - Functionality pertaining to shared content
Func-0301 - Can the calendar content be seen by visitors to the website
Func-0302 - Can calendar content be restricted?
Perf-0200 - related to database performance
Perf-0201 - database can perform under regular stress, within the performance guidelines already outlined.