Requirement Testing

September 2002 http://www.testinginstitute.com Journal of Software Testing Professionals 1

AbstractBy reviewing this paper, the readershould gain additional insight into thefollowing areas:• The differences between functional

and non-functional requirements• The importance of non-functional

requirements during system analysisand testing

• The major categories of non-function-al requirements

• The primary characteristics of eachnon-functional requirement type

• Suggested methods for integratingnon-functional requirements into soft-ware testing practices

IntroductionFrom an early age, we are all taught thebasic questions to ask when gatheringinformation. Whether you are a schoolchild researching a report, a journalistinvestigating a story, or a witnessrecounting a crime scene, you immedi-ately ask yourself the so-called “MagicFive Questions.” These, of course,include “Who,” “What,” “Where,”“When” and “How.” And as every goodjournalist knows instinctively, withoutall of this information the resultingwork seems unfinished and/or raises asmany questions as it answers.

For some reason, however, we IT pro-fessionals seem to forget these basicinvestigative techniques when weattempt to define the requirements for asoftware application. As we interviewcustomers for their needs, we focus ononly one aspect; that is, the “What.”Nearly all of the questions we askaddress what the customer wants to beable to do with the application, and weassume that if we deliver everything thecustomer asked for then our applicationwill be a success.

Unfortunately, this assumption is bla-tantly inaccurate. It is just as importantto ask the remaining four questions as itis to thoroughly document the first. Byfocusing on only the “What” of theapplication, we miss much of the under-lying context and may ignore criticalbusiness constraints that will ultimatelydetermine our effort’s success or fail-ure. And just like a journalist who skipsone or more of his “Magic Five,” weoften end up building software applica-tions that seem unfinished and/or causeas many problems as they solve.

Functional vs. Non-FunctionalRequirementsUnfortunately for IT, software is notlike Kevin Costner’s baseball diamond

in the Hollywood motion picture “Fieldof Dreams.” In the movie, Costner has avision which tells him that “If you buildit (the baseball diamond), they willcome (ghostly players and real-lifefans).” In software, on the other hand,just because we build it (the software),it doesn’t mean they will come (the cus-tomers).

Instead, it is our job to first determineexactly what a customer needs beforewe begin building the solution. We dothis by asking the “What” questions,and the answers to those questions areusually referred to in the IT world as the“functional requirements” for the appli-cation.

Functional requirements describe whatit is that a customer needs to be able todo with our software. They may be doc-umented in the form of rigorously spec-ified process models or use cases, orthey may simply be lists of required fea-tures and functions. Whatever the formused, functional requirements shouldalways identify the minimum function-ality necessary for the software imple-mentation to be considered a success.

However, as mentioned earlier, this isnot enough. Instead, business analysts

How Fast is Fast?Using Non-FunctionalRequirements to TestRequirement Quality.

This paper discusses the difference betweenfunctional and non-functional requirements,defining each as they pertain to applicationsoftware development. Further, it outlines abasic approach for using non-functionalrequirements to improve requirement quality.Suggested testing methods will also be dis-cussed with an eye toward building validationplans using non-functional requirements forquantitative measurement.

by Joseph D. SchulzSenior Product Champion

Starbase Corporation


need to get a complete picture of thecustomer’s needs by asking the addi-tional four questions from our “MagicFive.” These characteristics are usuallyreferred to as “Non-FunctionalRequirements.”

Unfortunately, the name non-functionalrequirements is somewhat misleading.From the name alone, it sounds likenon-functional requirements arerequirements that don’t function (i.e.,things that don’t work). Obviously, thisis just the opposite. Rather thandescribe what the customer wants to do,non-functional requirements describethe additional constraints that affect thecustomer while performing the func-tional requirements. They address theaspects of “Who,” “Where,” “When”and “How.”

Functional Requirements ExampleFor example, a simple functionalrequirement for an Order ProcessingSystem might define the applicationfunctionality necessary to create neworders. The definition of the require-ment, then, would describe what an enduser must be able to do during the ordercreation. A sample functional require-ment definition of this type might looklike the one below.

This example probably looks familiar tomost readers, because this is the format

that the majority of requirement specifi-cation documents use. However, whilethe functional requirement definitionshown in this example is well-formed, itis by no means complete. It accuratelydescribes what the application end usermust be able to do, but it leaves out crit-ical information that will be necessaryto design a complete application solu-tion for the problem.

For example, the functional specifica-tion above does not address any of thequantities involved in the order entryprocess (e.g., number of orders, orderitems, products, unit sizes, etc.).Without knowing this information, thedatabase designer cannot determine themost appropriate storage technologiesand the user interface designer cannotdevelop the optimal screen layout.These are just two of the basicnon-functional issues that are left tointerpretation by the development team.

Requirement OwnershipAnother key difference between thefunctional requirements and thenon-functional requirements rests in theownership of the information.Specifically, there is a major differencebetween who is ultimately responsiblefor managing the functional andnon-functional requirements defini-tions.

Functional requirements are usuallyconsidered to be “owned by” the cus-tomer or end user for the application.Since functional requirements describethe work the customer needs to do, theapplication end user is the most appro-priate source for the data and the mostlikely to be able to define it correctly. Ina perfect world, end users can identifyall of the necessary functional require-ments based on their current or desiredworkflow.

Non-functional requirements, on theother hand, are usually owned andmaintained by the technical staff. This

is primarily due to the fact that thenon-functional requirements describethe context of the work to be done,rather than the work itself. While thecustomer is thinking about and manag-ing the workflow, it is often up to thetechnical staff to ask questions aboutthe non-functional characteristics. Theanswers to those questions, of course,must still come from and be validatedby the customer, but the techniciansmust usually raise many of the relevantissues themselves.

Application VerificationIt is these non-functional requirements,then, that are used to fully “flesh out”the test plan necessary to validate oper-ation of our completed software appli-cation. Without knowing how the appli-cation is going to be used, we cannotconclusively determine whether thesoftware will actually meet the cus-tomers’ needs when it is delivered. Thatis, we need to test not just functionality,but also usability and applicability tothe business problem being solved.

These non-functional characteristicsoften are referred to as “applicationstress points” because they identify theoperational limits the application mustwork within. To adequately define thesestress points, non-functional require-ments must specify both the metric tobe used and the measurement techniqueto be employed. Without both of theseitems, a complete test plan cannot bedeveloped.

For example, in the “Enter Orders”requirement above, it would not beenough to say that the application musthandle 100 products per order. Thiswould still leave open the questionabout how to “count” products. Is eachunique product on the order counted asone or is each product code and unitsize combination? Instead, the formulaor method for counting must also bespecified in the non-functional require-ment definition.

The system must be able to entercustomer orders for products thatare currently in stock. A uniqueorder number must be generated bythe system at the time the order issaved. Each order must be able tospecify different products and unitsizes, with each combination result-ing in a separate order item. Thedesired unit, quantity, and unit pricemust be specified for each orderitem.

Figure A: “Enter Orders” FunctionalRequirement Definition

To this end, the Quality Assurance (QA)staff also should be involved in thedevelopment of the requirement specifi-cations. While QA Analysts do notdefine requirements, they usuallyreview the requirement definitions andpoint out possible deficiencies. Theylook for both omissions (test character-istics not discussed at all) and ambigui-ties (test characteristics that are vagueor incomplete). At this time, a prelimi-nary test plan also can be developed toestablish the basic pattern of testing thatwill be used to verify functional com-pliance.

Non-FunctionalRequirement TypesAs discussed above, non-functionalrequirements address a broad spectrumof issues. They address four of the fivebasic investigative questions, and assuch there are several different kinds ofinformation that we are looking for.Therefore, instead of having one largepool of non-functional requirements, itis often helpful to categorize theserequirements by their major subjectarea.

The easiest way to do this is to groupfacts by the questions they answer.Since we have already addressed the“What” questions, we should definenon-functional categories for the“Who,” “Where,” “When” and “How”aspects. In addition, there are severallayers to the “How” area, and each ofthese merit their own sub-category. At a

minimum, this should include “HowMany,” “How Often,” “How Fast,” and“How Easy.”

Non-Functional RequirementCategoriesThe table below identifies the non-func-tional questions that need to beanswered by a requirement specifica-tion document. For each, a typical namefor the corresponding non-functionalrequirement category is listed. Adetailed description of each category,including relevant examples, is includ-ed in the following sections of this doc-ument.The most common method of identify-

ing the non-functional requirements isto ask a series of “qualifying questions”for each of the categories listed above.This is done by inspecting each func-tional requirement and then asking thequalifying questions to the appropriatedecision maker(s). The recommendedqualifying questions for each category

are listed in the appropriate sectionsbelow.

Once the qualifying questions havebeen answered for each requirement,commonalities then are extrapolatedinto global or group-based rules. Eachunique rule is defined as an instance ofa non-functional requirement, and thenthese non-functional requirementsshould be matrixed to the functionalrequirements (refer to the “Require-ments Traceability” section below). Inthis manner, non-functional require-ments are defined as separate, normal-ized objects in the requirements specifi-cation, but the relationships betweenthem and to the functional requirementsare documented.

Security RequirementsThe first non-functional requirementtype addresses the “Who” question.This type is used to specify which endusers are allowed to perform whichfunctions so that the appropriate securi-ty scheme can be designed into thespecifications. In addition, approvals/authorizations need to be considered asa part of the functional workflow.Unfortunately, security requirementsoften are not addressed until the end ofthe design process. This can lead to alarge amount of rework, as the securityissues will very often affect the applica-tion workflow itself. Without a deter-mined, premeditated effort to addressthese constraints early, the workflowoften becomes convoluted when the

14 Journal of Software Testing Professionals http://www.testinginstitute.com September 2002

Non-Functional requirements address a broad spectrum ofissues...and as scuh there are several different kinds of informa-tion that we are looking for...instead of having one large pool of

non-functional requirements, it is often helpful to categorize theserequirements by their major subect area.

Figure B: Non-FunctionalRequirement Categories

Non-Functional Requirement Categories

RequirementWho? SecurityWhere? TopographicalWhen? TimingHow Many? Scalabilty How Often? FrequencyHow Fast? PerformanceHow Easy? Usability

security scheme is “bolted on” at thelast moment.

The most common qualifying questionsused to discover security requirementsinclude:• Who is allowed/denied access to per-

form this function?• Does the function vary by authorized

end user?• Is a separate approval process (third

party) required to complete this func-tion?

• If an additional approval is required,who is authorized to provide it?

• Is the approver allowed to changeinformation entered by the originator?

• Is there any formal notification neces-sary for this function?

In our “Enter Orders” example, addi-tional non-functional requirements toaddress these security issues might bedefined as shown below:

Topographical RequirementsTopographical requirements address the“Where” question. Specifically, thistype of non-functional requirementsdefines any application characteristicsthat are dependent upon geographic

location, hardware profiles, and/or net-work topography. While these require-ments are most helpful during the phys-ical system design, they can just as eas-ily affect the logical transaction designin the functional workflow.

Of course, there is a real danger in try-ing to design the physical aspects of theapplication too early in the process.Therefore, during the functionalrequirement specification, only enoughinformation about the topography needsto be captured to identify any limitingconstraints. That is, topographicalrequirements should only be definedwhen the characteristic is fixed orbeyond the ability of the applicationdesign team to change.

The most common qualifying questionsto discover topographical requirementsinclude:• What type(s) of interface hardware/

software will this function require?• What type(s) of interface hardware/

software will the end user have avail-able?

• Where will the end user(s) for thisfunction be physically located?

• Will this function require data stor-age?

• If data storage is required, where willthe data store/database be located?

• What connectivity to the data locationis available at the end-user location?

• Will this function require a separateapplication component server?

In our “Enter Orders” example, addi-tional non-functional requirements toaddress these topographical issuesmight be defined as shown on the right.

Timing RequirementsAnother non-functional aspect thatneeds to be addressed involves answer-ing the “When” question. Theserequirements, usually referred to as tim-ing requirements, describe how timeaffects the functional requirements anddetermine parameters for starting and

stopping functional workflow. In addi-tion, dependencies between the require-ments are examined, as well as paralleland mutually-exclusive activities.These factors are then used to modifyprocessing patterns as needed to sup-port alternative paths.

Timing requirements are sometimesdifficult for end users to identify, asthey often involve compounding condi-tions outside normal boundaries. Forexample, to the casual observer, a traf-fic signal has very simple functionalrequirements (e.g., change from red togreen, green to yellow, and back to red).However, few people realize that thedynamics of this interaction are highlydependent on time. For instance, theinterval between red and green periodsis very different in the evening than it isduring the morning commute time. Thesignal may additionally be programmedto blink red or yellow continuously dur-ing the early morning hours or on busi-ness holidays. All of these variationsare examples of timing requirements.


• All members of the Order Entrydepartment are allowed to enternew orders.

• New product orders are in a statusof “Pending” until approved.

• All members of the Order Entrydepartment may approve orderswith a total value of less than orequal to $50,000 USD.

• Only Order Entry departmentsupervisors may approve orderswith a total value of greater than$50,000 USD.

• An order acceptance letter must begenerated and sent to the orderingcustomer at the time the order isapproved.

Figure C: Sample SecurityRequirements

• All Order Entry functions mustexecute on the Windows 2000Professional operating system.

• The Order Processing system mustrequire no more than 128MB ofsystem RAM on the end-usermachine.

• The “Enter Orders” function mustbe available to all members of theOrder Entry staff located inAtlanta (USA), San Francisco(USA), London (England), andSidney (Australia).

• Order data must be stored in asecure facility that provides accessby all members of the Order Entry,Accounts Payable, and Shipping/Receiving departments.

Figure D: Sample TopographicalRequirements

The most common qualifying questionsused to discover timing requirementsinclude:

• Does the time of day, day of week, ordate (day, month or year) impact theworkflow for this function?

• Does the behavior of this workflowchange at slack or peak times?

• What other event or function does thisfunction depend on?

• What other event or function dependson this function?

• Are there other functions thatcan/cannot occur at the same time asthis function?

In our “Enter Orders” example, addi-tional non-functional requirements toaddress these timing issues might bedefined as shown below:

Frequency RequirementsFrequency requirements are the firstsubcategory in the “How” category, andthey address the question “How Often.”Part of a triad of questions oftenreferred to as “volumetrics,” frequencyrequirements identify the number offunctional transactions that can beexpected within a specified timeframe.These statistics are essential when

designing the user interface, and alsoplay a very important role when select-ing communication, data storage, andother infrastructure components.

A simple example might be the func-tional specifications for a householdappliance like an automatic-drip coffeemaker. It must be able to heat water,drip the water through a filter of groundcoffee, and maintain heat on the brewedcoffee. By using these functionalrequirements as the only measure, anycoffee maker is a candidate to satisfythe need.

However, once the frequency character-istics are factored in, the choice of pos-sible coffee machines may be radicallydifferent. For instance, if the coffeemaker is to be used to make 1,000 cupsof coffee per day (as in the case of arestaurant), then most “home use” cof-fee machines are not viable. On theother hand, if the coffee maker is to beused only once per year, it may actuallybe more cost-effective to rent a machinewhen necessary and/or to purchase cof-fee from a third-party provider.

The most common qualifying questionsto discover frequency requirementsinclude:• What is the period frequencies are

measured in (e.g., items per minute,etc.)?

• What is the average frequency for thisfunction within the stated period?

• What is the minimum and maximumfrequency at slack/peak times?

• Does the frequency for this functionvary by time, day or date?

• How many end users will be perform-ing this function?

• Does the frequency for this functionvary by end user or end-user group?

• Does the workflow for this functionchange at volume thresholds?

In our “Enter Orders” example, addi-tional non-functional requirements toaddress these frequency issues might be

defined as shown below:

Performance RequirementsThe second part of the “volumetrics”triad, performance requirementsaddress the question “How Fast.” Theydefine the absolute and relative per-formance constraints that are to beplaced on the application. As with fre-quency requirements, performancerequirements are essential to develop-ing an adequate functional workflowand user interface for the application.They will also greatly influence theselection of communication and datastorage technologies.

Performance requirements are extreme-ly pervasive in both application designand popular culture. Software develop-ers spend a significant amount of effortdesigning and redesigning program-


• All customer orders with a statusof “Pending” must be approved ordeleted by 11:59 PM EasternStandard Time.

• The approval limit for all membersof the Order Entry department isdoubled on the last business day ofeach monthly period.

• Customer orders for a specificproduct cannot be entered untilthat product’s inventory level isverified by the Shipping depart-ment.

• Only one new order may update aproduct’s in-stock quantity at atime.

Figure E: Sample TimingRequirements

• The standard workday is from8:00 AM EST to 5:00 PM EST,Monday through Friday.

• During the standard workday, thesystem must be able to record anaverage of 50 new customer ordersper hour per employee, with anexpected minimum and maximumof 10 and 80, respectively.

• During the standard workday, thesystem must be able to support anaverage of 12 employees workingsimultaneously, with an expectedminimum and maximum of 4 and20, respectively.

• From Nov. 15th to Dec. 31st, thesystem must be able to supporttriple the number of orders andemployees as a standard workday.

• When more than thirty (30)employees are logged into the sys-tem at one time, order acceptanceletters will only be generated fororders with a total value exceeding$25,000 USD.

Figure F: Sample FrequencyRequirements

ming logic to improve execution per-formance, and often add extraneousfunctionality (e.g., progress displays)just to provide visual stimulation duringtedious processing. Even auto manufac-turers cater to our seemingly instinctiveperformance desires, prominentlyadvertising a model’s “0-to-60” ratingin an attempt to entice customers.

Unfortunately, while performancerequirements often are discussed andeven frequently written down, they arerarely expressed in concrete, testableterms. All too often, incomplete orambiguous requirement definitionsleave so much open to interpretationthat end users are disappointed whilethe development staff is convinced theymet the terms of the agreement. As dis-cussed in the Application Verificationsection above, both the metric and themeasurement technique must be speci-fied in the performance requirements.

The most common qualifying questionsto discover performance requirementsinclude:• What is the period that performance

metrics are measured in?• How is the performance data to be

captured (e.g., duration or responsetime)?

• What is the absolute minimum stan-dard for functional performance?

• What is the absolute maximum stan-dard for functional performance?

• Does the performance requirementvary by time, day or date?

• Does the performance requirementvary by end user or end-user group?

In our “Enter Orders” example, addi-tional non-functional requirements toaddress these performance issues mightbe defined as shown above.

Scalability RequirementsThe third and final part of the “volu-metrics” triad is the scalability require-ments, which define the characteristicsto resolve the question “How Many.”

Scalability requirements are similar tothe frequency requirements describedabove, except that scalability require-ments focus on the expected future stateof the application rather than the currentstate. Scalability requirements are usedto defer “operational obsolescence” bydesigning for future capacities.

An everyday example of this type ofthinking might be when young couplesbegin to look for a home. They not onlyconsider what they need immediately(e.g., a kitchen, one bedroom, one bath,etc.), but also what they will need in thefuture (e.g., extra bedrooms, baths,etc.). They then balance the cost of pur-chasing these upgrades immediatelyagainst the cost of having to move againwhen they become a necessity. Thisprocess of “planning for the future” isan example of using scalability require-ments to influence the decision-makingand design process.

In application systems, scalabilityrequirements most often specify expect-ed future volumes and performance cri-teria. In addition, scalability require-ments also are used to record archival

and record retention policies so that the“volumetrics” can be adjusted for ananticipated year-on-year growth.

The most common qualifying questionsto discover scalability requirementsinclude:• How long is the application’s expect-

ed lifecycle?• How will the average transaction vol-

ume change throughout this lifecycle?• How will the average end-user popu-

lation change throughout this lifecy-cle?

• What type and how many transactionswill be stored?

• How long (in duration) must thesetransactions be stored?

In our “Enter Orders” example, addi-tional non-functional requirements toaddress these scalability issues might bedefined as shown below:

Usability RequirementsThe final subcategory within the “How”requirements categories involves identi-fying the usability requirements. Theserequirements address the end-useraspects of the application and answerthe question “How Easy.” Many times,these requirements are a mix of corpo-rate and/or industry standards and


• All performance measurementsshall be based on the responsetime experienced at the end-usermachine.

• When the end user presses the“New” button, the order numbermust be generated and displayedwithin a maximum of 4 seconds.

• From Nov. 15th to Dec. 31st,allowable response times must be25% less than standard (e.g., 3seconds instead of 4).

• When employees outside of theOrder Entry department use thesystem, allowable response timescan be up to 50% longer (e.g., 6sec. instead of 4).

Figure G: Sample PerformanceRequirements

• The system must be able to oper-ate for a minimum of ten years.

• The number of new customerorders entered is expected toincrease at an average of 10% peryear from the current statistics.

• The number of Order Entryemployees is expected to remainflat for two years and then toincrease an average of 5% per yearthereafter.

• Approved orders will be retainedin active storage for a minimum ofone calendar year after they areapproved

Figure H: Sample ScalabilityRequirements

application-specific needs. Most often, usability requirements iden-tify necessary traits for the user inter-face design. This might include stan-dardized look-and-feel characteristicswhich are specific to the operating plat-form on which the application will beexecuted. In addition, the usabilityrequirements may also include specifi-cations about required skill levelsand/or training needs. All of these qual-ities are critical when designing theso-called “man-machine boundary.”

The most common example of the needfor usability requirements is the modernVideo Cassette Recorder (VCR). Whilethe basic functionality of a VCR has notchanged in over a decade, when thesedevices were first introduced they wereso difficult to use that the majority ofthe population avoided them. In fact, itwas considered a “badge of honor” ifsomeone was able to successfully pro-gram their VCR to record a favorite tel-evision show.

More recently, however, the VCR man-ufacturers have learned from their mis-takes and have added a wide variety ofusability enhancements that make theirdevices easy and sometimes fun to use.In fact, they have been able to dramati-cally widen their customer base simplyby focusing on usability characteristicsrather than functionality.

The most common qualifying questionsto discover usability requirementsinclude:• What type(s) of interface hardware/

software will the end user have avail-able?

• Are there any company/industry inter-face standards that apply to this func-tion?

• What is the average level of skill forthis function?

• What is the minimum/maximumamount of end-user training expectedto be available for this function?

•What type(s) of online help is

required for this function?• Are there any unique accessibility

requirements for this function?• How is this function performed in the

current environment?

In our “Enter Orders” example, addi-tional non-functional requirements toaddress these usability issues might bedefined as shown below:

Requirements TraceabilityThe final step in completing therequirement specification is to establishcausality relationships, named “traces,”between the various requirementinstances. Specifically, traces must bedefined between any related non-func-tional requirements and betweennon-functional requirements and theaffected functional requirements.

Unlike requirements definitions, tracesare hard to manage in a textual or docu-ment-based format. Because of this,functional specifications that includerequirements traceability usually neces-sitate the use of a commercial

Requirements Management (RM) prod-uct that stores the requirements defini-tion in a database format.

Non-Functional DependenciesThe first type of trace, between twonon-functional requirements, is usuallyreferred to as a “dependency.”Dependencies denote that onenon-functional requirement has a directand immediate impact on another. Theyare used to identify the effect that onerequirement will have on another. Veryoften, dependencies between non-func-tional requirements are used to modelcalculation or multi-step logic whereone fact is based on the definition ofanother.

One obvious example of a dependencyis contained in the frequency require-ments above where one requirementlists the standard workday transactionvolume as “50 new customer orders perhour per employee” and another liststhe holiday volume as “triple the num-ber of orders and employees as a stan-dard workday”. Maintaining a depend-ency between these two requirements isimportant since the holiday volumemust be re-evaluated if the standardworkday requirement is modified.

Non-Functional ConstraintsThe second type of trace, between func-tional and non-functional requirements,is usually referred to as a “constraint.”That is, the non-functional requirementconstrains, or limits, the functionalitydescribed in the functional requirement.Constraints usually include operationaland/or performance criteria which cir-cumscribe the conditions under whichthe function is performed.

For example, one performance require-ment example listed above stated that“the order number must be generatedwithin a maximum of 4 seconds.” Thisconstraint should be traced back to thefunctional requirement that describedgenerating the order number. In this


• All Order Entry functions mustutilize a graphical user interfacecompliant with the Microsoft stan-dard #99.9999 published on6/1/2001.

• End-users must have completedthe approved corporate trainingclass for Microsoft Windows 2000prior to the installation of the newsystem.

• The “Enter Orders” function mustrequire an average of less than 8hours of formal classroom trainingto achieve proficiency.

• Customer orders must be able tobe entered by end-users that usethe Microsoft Windows 2000“StickyKeys” accessibility option.

• End-user “drag-and-drop” func-tionality must not be required.

Figure I: Sample UsabilityRequirements

manner, when the application designersare developing the system for generat-ing order numbers, they will immedi-ately know: 1) what has to be done; and2) the constraints within which it has tobe done.

These constraint relationships are theninvaluable for subsequent impact analy-sis. If the functional requirementchanges (e.g., more functionality isadded), the designer will immediatelyknow which constraints still apply tothe new design. Conversely, if thenon-functional requirement changes(e.g., a restriction is eased), the design-er can immediately see which function-al requirements are affected and may beable to alter the design specifications totake advantage of a new opportunity.

Using Traces for Quality AssuranceTraces, both dependencies and con-straints, also are important during thedevelopment of the Quality Assuranceplan. When the functional tests aredefined, it is usually the non-functionalrequirements that provide the measure-ments necessary to properly determinesuccess or failure of the testing process.As described earlier, it is not enoughjust for the application system to workas designed; rather, it must also work

with the customer’s environment andwithin the environmental pressures thatexist.

SummaryA well-formed system requirementsspecification must include not only def-initions of the functional requirements(the “What”), but also of the non-func-tional requirements (the “Who,”“Where,” “When” and “How”). Thesenon-functional requirements thenshould be organized into appropriatecategories and should detail the envi-ronmental characteristics that constrainor bound the application. The non-func-tional requirements then should berelated to one another and to the rele-vant functional requirements.

Without both of these components inthe requirements specification, theapplication development team risksdelivering an incomplete or unusableapplication. By defining both compo-nents and relating them to each other,the development team is much morelikely to deliver an application that notonly works as designed but also canoperate within the end-user’s dynamicenvironment.

About the AuthorJoseph D. Schulz is a seasoned devel-oper with more than 19 years of profes-sional Information Systems experiencespanning a wide range of vertical indus-tries. Currently, Joe is the SeniorProduct Champion at StarbaseCorporation. In this position, he helpsorganizations around the globe improvetheir development processes by deliver-ing methods/tool training and providingonsite mentoring. He also supportsStarbase’s international distributors,ensuring their ability to support theStarbase family of products.

References1. Weigers, KE: “Software require-

ments,” Microsoft Press, RedmondWA USA, 1999.

2. Young, RR: “EffectiveRequirements Practices,” Addison,Reading MA USA, 2001.

3. Allen, P, and Frost, S:“Component-Based Developmentfor Enterprise Systems: Applyingthe SELECT Perspective,”Cambridge Univ. Press, CambridgeUK, 1998.

4. Schneider, G, and Winters, JP:“Applying Use Cases: A PracticalGuide,” Addison, Reading MAUSA, 1998.


A well-formed system requirements specification must include not

only definitions of the functional requirements (the “What”),

but also of the non-functional requirements

(the “Who,” “Where,” “When” and “How”).

Requirement Testing

Documents

Transcript of Requirement Testing