Requirements Engineering · Specification of Requirements System Models Definition of Requirements The Requirements Engineering Process Feasibility ... each requirement on the rest

UEE020H2 Software Design for Engineers

© M.Randall, 2000 Lecture 3, Page 1

Getting the requirements right first time is perhaps the most important part of theSoftware Lifecycle.

Faculty ofEngineering ME3-SE-1

Requirements Engineering

� Requirements Capture and Analysis� Typical Requirements Problems� The Characteristics of Good Requirements� Stakeholders� Types of Requirements� Requirements Traceability and Database Management




Requirements Capture and Analysis: 1

� Remember, a system is “a set of complementary,interacting parts exhibiting properties, capabilities andbehaviours not exclusively attributable to any of the parts”

� Requirements Capture:� answers the question: What does the client really need?� defines the properties of the system� defines the capabilities of the system� defines the behaviours of the system

� Requirements Analysis:� partitions the system into its interacting components� defines the complementary set without conflicts and in a complete

way

Where do requirements come from?1. The customer

to define what the ‘customer’ requiresthe customer may be internal or externalmay be derived through the ITT process#

2. The vendorwho may want the system to be a common productwho is looking for re-usewho may wish to apply his own standards

3. And later, the design process...

User RequirementsDocument

ProcurementSpecification

Model andReview withCustomer

ProjectRequirements

VendorRequirements

DesignRequirements

May have been matured in

proposal phase





� Requirements Engineering is the “art and science ofunderstanding and defining systems...”

� a SCIENCE:� rigorous approach� hard work� research intensive

� an ART:� client friendly� requires flair� creative and innovative� sometimes a bit of a “black art”--limited

ethnographic knowledge or domain knowledge

During the systems engineering process, the engineer’s understanding of theproblem is constantly changing. This naturally leads to volatile systemrequirements, especially in difficult applications. There are several reasons forthis.

Large systems are usually required to upgrade archaic systems ormanuals. It is hard to predict the effects the “improved” system will haveeven if the old problems were well defined.Large systems have a diverse user community. They tend to havedifferent requirements and priorities which may lead to conflicts andcompromises between them.The people who pay and the end-users are often different and budgetaryor organisational constraints may conflict with end-user requirements.

Sometimes a requirements specification is unrealistic!Requirements can serve three purposes:

• allow engineers to explain their understanding of how the system shouldwork• tell designers what functionality and characteristics the resulting systemis to have• show the test team what to demonstrate to convince the customer thatthe system being delivered is indeed what was ordered.





FeasibilityStudy

RequirementsAnalysis

RequirementsDefinition

RequirementsSpecification

Specification ofRequirements

System Models

Definition ofRequirements

The RequirementsEngineering

Process

FeasibilityReport

RequirementsDocument

� The Requirements Engineering Process is a set of activities thatleads to the production of the requirements specification and thesystems specification.

The four principal stages are:Feasibility Study: What is the problem to be solved? Does the user need anew system developed? Is the proposal cost-effective? What are thealternatives? This stage should be cheap and quick and inform a decisionas to the need for a detailed analysis.Requirements Analysis: Deriving the system requirements by observationof existing systems, discussions with users/procurers, task analysis etc..Development of one or more system models. System prototypes may beused to understand the problem.Requirements Definition: Translates the information gathered into adefining set of requirements, accurately reflecting customer wants.Written to be understood by end-user.Requirements Specification: A detailed and precise description is set outto act as a basis for a contract between client and system developer. Thecreation of this document is usually carried out in parallel with somehigh-level design. The design and requirements activities influence eachother as they develop. During the creation of this document, errors in therequirements document are inevitably discovered. It must be modified tocorrect these problems.

These four stages are iterated, and so the documents will need to be placed undersome kind of management process, called Requirements Management.



Change is inevitableAny changes that come from the customer must be properly considered in termsof their impact on the rest of the system. Any changes that come from the vendormust be approved by the customer. It is sometimes worth flagging uprequirements as belonging to one of two categories:ENDURING: a change in such requirements represents a change of the contractVOLATILE: built-in flexibility.In the requirements database, a field describing the side-effects of a change ofeach requirement on the rest of the system helps to assess whether certainrequirements should be enduring or volatile.





ProjectRequirements

Database

ProjectRequirements

Database

Separationof Reqmts

VendorRequirements

VendorRequirements

DesignRequirements

DesignRequirements

EngineeringManagement

Plans


Plans

e.g. Project Management Plan,Quality Assurance Plan,

Design, Development & Verification Plan

Initial PlansDevelopment

Grouping of Requirements:e.g. Functional, Operational,

Performance, Interface,Design & Construction,

Test etc.

Allocation ofNon-FunctionalRequirements

DuplicateRequirements

Merged


Separationof Reqmts

ProjectRequirements

Database

ChangeRequest

DesignRequirements


Plans

Change mayimpact

Non-FunctionalRequirements

VendorRequirements

Customer ChangedReqmts




Typical Requirements Problems

� Missing Requirements� Ambiguous Requirements� Redundant Requirements� Duplicated Requirements� Conflicting Requirements� Unverifiable Requirements:

� “System shall provide real-time response to queries” �� “System shall respond to queries in not more than two seconds” �

� Amalgamated Requirements� Requirements and Design Detail confused.

Demonstrating a set of requirements meets a user’s needs is difficult if presentedin an abstract way. As a result many systems fall far short of the user’s needs. Toavoid these problems, the requirements should be subject to review:The following components may form part of a review:

Verifiability: is the requirement realistically testable?Comprehensibility: is the requirement properly understood by users andprocurers?Traceability: Is the origin of the requirement clearly stated? If a laterchange is needed, the origin of a requirement is a good place to start inassessing the impact of such a change.Adaptability: Can the requirement be changed without large knock-oneffects in other systems requirements?

Reviews are used for pointing out errors, omissions etc..Some databases have automated consistency checking which checks for potentialinconsistencies and omissions. Formal descriptions and simulations can also beused.Validation and review of requirements can occur in parallel with the productionof the specification document, involving consultation between client anddevelopers.Prototyping is an important validation technique. For instance, in softwaredevelopment, a demonstration executable can be used that gives user’s hands-onexperience with the system as it is being developed.




Characteristics of Requirements

� It is important that the requirements be validated. Are they:� Correct� Consistent� Complete (internally and externally)� Realistic� Necessary� Verifiable/Testable

“Testable” does not necessarily imply an empirical measure on theoutcome of a requirement, but simply that the existence of the behaviourin the system expected of the requirement is verifiable.

� Traceable

� See paper, “Characteristics of Good Requirements” by Kar andBailey (1996)

Requirements are:SINGLE

TESTABLESTATEMENTS

no slides 16-22

Are the requirements correct? Both we and the customer review them to assure that they are stated withouterror.Are the requirements consistent? That is, are there no conflicting or ambiguous requirements? Forexample, if one requirement states that a maximum of ten users can be using the system at one time, andanother requirement says that in a certain situation there may be twenty simultaneous users, thoserequirements are said to be inconsistent.Are the requirements complete? They are complete if all possible situations are described by somerequirement. Thus, a payroll system should describe what happens when an employee takes a leave withoutpay, when someone gets a raise, or when someone needs an advance. We say that a system description isexternally complete if the description contains all the properties desired by the customer. A description isinternally complete if there are no undefined references among the requirements.Are the requirements realistic? Can what the customer is asking the system to do really be done?Sometimes, when development time is long, the customer can anticipate technological improvements,requesting state-of-the-art requirements. All requirements should be reviewed to insure that all arepossible.Does each requirements describe something that is needed by the customer? Sometimes a requirementrestricts us unnecessarily. For example, the customer may demand that we use an XYZ processor becauseit has a good reputation. However, XYZ may not be the best processor to use for implementing the desiredsystem. Such requirements do not directly address the goals of the system. We should review therequirements to retain only those that work directly to solve the customer’s problem.Are the requirements verifiable? Can tests be written so that we can demonstrate that the requirementshave been met? This is a common place for difficulties to arise. The customer may demand quick responsetime without defining an actual speed and the circumstances under which the response is being measured.For example, “quick response time” may be restated in a more verifiable form as “with the maximumnumber of users on the system (32) using the word processing function, the system can rewrite a user’sscreen with the next page of document in under five seconds”.Are the requirements traceable? Can each system function be traced to a set of requirements that mandatesit? Is it easy to find the set of requirements that deals with a specific aspect of the system? For example, toreview all communications requirements, would all requirements need to be read?



Characteristics of Good RequirementsPradip Kar, Armament Systems Division, United Defense Limited Partnership,

4800 East River Road, MS M239, Minneapolis, Minnesota 55421.Michelle Bailey, Naval Air Warfare Center, China Lake, Mail code 52C000D

China Lake, California 93555.

Abstract. This paper identifies and documents the major characteristics of well defined requirements for bothindividual requirements and aggregates of requirements such as those found in specifications. Characteristicsexhibited by well defined requirements are described. The descriptions are followed by a brief discussion of thecharacteristics. A few examples of well defined requirements are provided. Some supporting characteristics ofrequirements are also described. These supporting characteristics are not properties of the requirementsthemselves but are attributes assigned to individual requirements to assist in managing the requirements throughthe life cycle. The paper was written and reviewed by members of the requirements working group of theINCOSE.

INTRODUCTIONIt is generally recognized that the development of good requirements is essential to quality product design.However, it is well known that requirements for many programs in the past have been poorly written. Thereasons for this shortcoming are many and include a lack of clear definition of user need and insufficient timeand effort dedicated to requirements definition. Also there are few examples of well defined requirements forreference.

One of the fundamental problems associated with writing good requirements is that most engineers are notspecifically trained to write requirements. The basics of well defined requirements are clarity, conciseness andsimplicity. Elegant, entertaining prose is not needed. In the words of Albert Einstein, "When you are out todescribe the truth, leave elegance to the tailor". It is clear that to write good requirements, engineers need todevelop writing skills which are not taught in school. They also need good and readily accessible examples ofboth well and poorly written requirements.

This paper describes the essential characteristics of well defined requirements. Characteristics of both individualrequirements and aggregates of requirements (as embodied in a specification) are provided. Some examples ofwell defined requirements are included in each category. This characterization can be used for

requirements development as well as in requirement reviews and audits for assessing the quality of requirements.It can also be used in Systems Engineering and management process improvements. The paper also describes afew supporting characteristics of requirements. These supporting characteristics, while not essential for writingindividual or aggregate requirements, assist in the process of requirements management, specially where the totalpopulation of requirements is large.

DEFINITIONSThe definitions for the following terms used in this paper, are from IEEE Std 1220-1994.

Constraint. A limitation or implied requirement that constrains the design solution or implementation of thesystems engineering process, is not changeable by the performing activity, and is generally non allocable.Requirement. A statement identifying a capability, physical characteristic, or quality factor that bounds aproduct or process need for which a solution will be pursued.Specification. A document that fully describes a physical element or its interfaces in terms of requirements(functional, performance, constraints and physical characteristics) and the qualification conditions andprocedures for each requirement.System. The top element of the system architecture, specification tree, or system breakdown structure that iscomprised of one or more products and associated life cycle processes and their products and services.

CHARACTERISTICS OF REQUIREMENTSThe characteristics of requirements are their principal properties. Characteristics may apply to individualrequirements; or to an aggregate of requirements. A well defined, mature set of requirements should exhibitcertain individual and aggregate characteristics. These characteristics are listed below, with synonyms inparenthesis. The description of each characteristic is followed by a brief discussion of the characteristic and anexample of a requirement displaying the required characteristic.



CHARACTERISTICS OF INDIVIDUAL REQUIREMENTSThe following paragraphs describe and discuss the desired characteristics of good requirements.

Necessary. The stated requirement is an essential capability, physical characteristic, or quality factor of the productor process. If it is removed or deleted, a deficiency will exist, which cannot be fulfilled by other capabilities of theproduct or process.Discussion. This is a primary characteristic. In order to be a well defined requirement, the requirement statementmust exhibit this characteristic. There is no room in a specification for unnecessary or "nice to have" requirementsbecause they add cost to the product. An example of a necessary requirement for a combat vehicle could be "Thevehicle's combat loaded weight shall not exceed 35 Tons". The condition "combat loaded" is defined elsewhere inthe body of the specification. This requirement imposes a major constraint on the design of the vehicle and it isusually based on transportability, utilizing existing resources. If this requirement is deleted from the specification, amajor need (i.e. transportability) will not be met, even if the vehicle is capable of satisfying every other requirement.Accordingly, the requirement is necessary.One good test of necessity is traceability to higher level documentation. In the case of system specifications,traceability may be checked to user documentation such as the Operational Requirements Document (ORD). If thereis no parent requirement, the requirement may not be necessary.

Concise (minimal, understandable). The requirement statement includes only one requirement stating what must bedone and only what must be done, stated simply and clearly. It is easy to read and understand.Discussion. During requirements definition there are often many arguments as to what exactly is meant by 'onerequirement'. The answer in most cases requires engineering judgment. An example of this can be the requirementfor an alarm. Within a military system, both a visual and an audible alarm is often required to warn the crew aboutabnormal or unsafe conditions. Also, the same alarm is used for multiple conditions, such as high temperature, lowoil pressure and low fuel level. The question here is what constitutes a single requirement? Should there be a singlerequirement for the alarm with perhaps a table defining the conditions under which the alarm is activated? Anexample of a requirement following this approach can be "The element shall provide a visual and audible alarmunder all conditions listed in Table 3-10. The alarm shall be activated no longer than 1 second after the conditionexists." Is this one requirement? Or should we write a requirement for each condition? Should the visual and audibleparts be separated into two requirements? On the one hand we do not want to write multiple requirements in oneparagraph; on the other we do not want the number of requirements to proliferate without reason. Each requirementwill have to be managed and verified; and has a cost associated with it.One approach to making a decision on this question is to determine how the requirement will be verified. Obviouslyone would like to verify that both the visual and audible alarms work together. So any test or demonstration to verifythe requirement must include both. Therefore, the visual and audible parts should be combined into a singlerequirement. Further, if the conditions providing inputs to the alarm can be incorporated into the same test ordemonstration, these should also be included in the same requirement. The conclusion is: this is a requirement for asingle alarm, which can be verified using a single test or demonstration. Accordingly, it is a single requirement.To be concise, the requirement statements must not contain any explanations, rationale, definitions or descriptions ofsystem use. The place for these texts are analysis and trade study reports, operational concept documents or usermanuals. A link can be maintained between the requirement text and the supporting analyses and trade studies in arequirements data base so that if desired, the rationale and explanations can be obtained rapidly.

Implementation free. The requirement states what is required, not how the requirement should be met. Arequirement statement should not reflect a design or implementation nor should it describe an operation. However,the treatment of interface requirements is generally an exception.Discussion. This characteristic of a requirement is perhaps the hardest to judge and implement. What exactly ismeant by implementation free? At the system level, requirements can be truly abstract or implementation free. Anexample of a requirement for a shipboard system at the system level is: "The system shall be capable of engagingsea skimming anti ship cruise missile (ASCM) targets." This sentence should be followed by expected performancedata (a quantification of what "engaging" means) against specific ASCM targets. It can be seen from therequirement statement that no specific implementation has been stated, so the system designer is free to pursuealternative, competing system designs, all capable of fulfilling the requirement.The system requirements have to be implemented by a system design solution. After the system designer hasperformed a trade study between alternatives and selected a candidate solution, the system requirement stated in theprevious paragraph, have to be allocated to the elements defined by the system design. This incremental procedureof allocating requirements to the next lower level elements, dependent on system design, has led to the remark: "onelevel of design is the requirement at the next lower level." In the ASCM example above, let us say that the systemdesign solution consists of a radar element to detect and track the targets; a command and control element toperform target recognition, identification, and weapon assignment and control functions; and a missile to engage anddestroy the target. Then there will be three elements below the system level on the system specification tree and thesystem requirement will have to be allocated to these three elements. The element requirements will be for a radar, acommand and control and

Characteristics of Good Requirements: Paper by Kar and Bailey, http://www.incose.org



a missile. The allocated requirement for the radar element can be: "In a clear environment, the radar element shallbe capable of detecting 0.1 (meter)2 ASCM targets at ranges of up to 20 KM with a probability of detection of noless than 0.9 and probability of false alarm of no greater than 10-6." Note that the requirement statement reflects thedesign at the system level (the solution is a radar and associated command and control; and missile) but implies nospecific radar design. This allows the radar designer to pursue alternative radar designs. The conclusion is that arequirement is implementation free at the level that it is being specified, but is a result of the design activity at thelevel above it.Interface requirements are usually an exception to the implementation free rule. Interface requirements are specifiedin interface control drawings or ICDs which describe a specific design of an interface or mating parts. For examplein the case of an electronic interface, the ICD may include part numbers of the interfacing connector(s); pinassignments for various signals; waveform and timing information; and source and sink impedances on each line. Inthis case the requirement must provide complete information so that the two sides of the interface can be designed towork as specified when connected to each other. Interface requirements are usually specified as a result of aninterface control working group (ICWG) activity. The ICWG is usually chaired by the system integrator and hasmembers from contractors representing both sides of a specific interface. The ICWG establishes both the datarequired to go across the interface and the design implementation of the interface.

Attainable. (achievable or feasible). The stated requirement can be achieved by one or more developed systemconcepts at a definable cost. This implies that at least a high level conceptual design has been completed and costtradeoff studies have been conducted.Discussion. This characteristic is a test of practicality of the numerical value or values set forth in a requirement. Itsignifies that adequate analyses, studies and trades have been done to show that requirement can be met by one ormore concepts and that the technology costs associated with the concept(s) are reasonable within the cost constraintsof the program.For example, consider the following requirement for a radar element: "In a clear environment, the radar elementshall be capable of detecting 0.1 (meter)2 ASCM targets at ranges of up to 20 KM with a probability of detection ofno less than 0.9 and probability of false alarm of no greater than 10-6." It is well known that radars operating in themicrowave frequencies are more or less horizon limited due to straight line propagation of electromagnetic waves atthese frequencies. Under the circumstances, required detection ranges which are much beyond the radar horizon,(the 20 KM range is within the capability of a mast mounted shipboard radar) should be viewed with suspicionunless it is specified under anomalous propagation conditions.

Complete. (standalone) The stated requirement is complete and does not need further amplification. The statedrequirement will provide sufficient capability.Discussion. Requirements should be stated simply, using complete sentences. Each requirement paragraph shouldstate everything that needs to be stated on the topic and the requirement should be capable of standing alone whenseparated from other requirements. Many people seem to have trouble specifying a system parameter called growthcompletely. Let us examine a basic statement: "The vehicle shall permit growth" as an initial idea in trying tospecify growth. The question is how much growth and in which areas? Remember, the requirement should becomplete and not need amplification elsewhere. Growth is usually provided in new design systems for two reasons:• Pre Planned Product Improvements (P3I)• Through life growth.Early P3I analysis may indicate the need to fit new equipment into a vehicle, which will need additional space,power, cabling, cooling and weight margins. Through life growth is system growth due to the addition of newcapabilities in a system to address new requirements which may be imposed during the life cycle of the system butwhich were not known during system development. An example of this type of growth is the addition of a wholenew mission such as tactical ballistic missile defense (TBMD) to the Aegis combat system on U.S. Navy ships.Other types of through life growth are small changes to fix problems and provide minor capability improvements inresponse to user need.

Margins must be provided for both types of growth, although it is easier for P3I growth. A requirement statement,for example, in the area of weight growth, may then be stated as follows: "The vehicle shall permit 12% weightgrowth." This requirement, addresses both how much and in which area, and will permit the vehicle designers todesign the chassis, engine/transmission and the suspension subsystems taking into account the growth margin.




Consistent. The stated requirement does not contradict other requirements. It is not a duplicate of anotherrequirement. The same term is used for the same item in all requirements.Discussion. This characteristic of well defined requirements is usually well understood and does not cause muchdiscussion. However, in a large set of requirements which are not well organized by some clearly defined categories,it may be hard to spot duplications and inconsistencies. It is therefore important to organize the requirements (say inaccordance with MIL STD 490A) so inconsistencies can be spotted during reviews and audits. It is also important tomaintain a glossary of terms being used on the program because the meaning of some words are domain dependent.

Unambiguous. Each requirement must have one and only one interpretation. Language used in the statement mustnot leave a doubt in the reader's mind as to the intended descriptive or numeric value.Discussion. This is an area where a formal requirements language for systems engineering may ultimately help. TheEnglish language can be unstructured and in some cases the same sentence may mean different things to differentpeople. What is needed are some standard constructs and some words to avoid. While the following list isincomplete, it will point the reader in the right direction.

Standard Constructs. One important word that is included in most DOD specification requirements is the word"shall" for all requirements. It is a statement of imperative need and indicates that the requirement must be verified.A standard construct for a requirement is therefore: "The system(or element or equipment) shall ...". Otherrequirements are stated as a goal in specifications. The goal requirements are not imperatives, and sentencescontaining them do not contain the word "shall". An example of a goal requirement is: "The goal is to provide amaximum range capability of 45 Kilometers."The word "will" is not used to signify a requirement. It may be used in a sentence containing a statement of factsuch as "vehicle tests will be conducted at government test facilities". They may also be used to indicate that someevents will take place in the future. "Test instrumentation will be provided by the government in 1998."When a requirement is defined by referencing another standard, use a construct such as "in accordance with" or "asspecified in". An example requirement is "System parts and equipment requiring identification shall be marked inaccordance with MIL STD 130."Do not use "Minimum" and "Maximum" to state limits. Use "No less than" or "No greater than". This standardconstruct avoids the ambiguity associated with the limiting values. The requirement "Gun alignment error inelevation shall be no greater than 1.5 milliradians" is not vague because it is clear that a 1.5 milliradian error ispermissible. On the other hand, if the requirement was stated as "Gun alignment error in elevation shall be 1.5milliradians maximum", there would be some ambiguity as to whether the limiting value i.e. 1.5 milliradians waspermissible. This rule does not mean that the words "minimum" and "maximum" cannot be used at all - just do notuse them to state limits. For example a requirement can be stated as "The gun system's maximum range shall be noless than 25 KM" to convey that the maximum range of the gun system must be equal to or greater than 25 KM.

Words to avoid. Specific words that should be avoided because they are vague and general are "flexible", "faulttolerant", "high fidelity", "adaptable", "rapid or fast", "adequate", "user friendly", "support", "maximize" and"minimize" ("The system design shall be flexible and fault tolerant" is an example). Other words that should beavoided are "and/or", "etc." and "may".

Verifiable. The stated requirement is not vague or general but is quantified in a manner that can be verified by oneof these 4 alternative methods: inspection, analysis, demonstration or test.Discussion. Verifiability is an important characteristic of a requirement. The verifiability of a requirement should beconsidered at the same time that a requirement is being defined. A requirement which is not verifiable is a problem,both for the customer and the contractor because it involves the acceptability of a system. In order to be verifiable,the requirement should be stated in measurable terms such as: "The overall length of the system shall be 105+/-0.5inches" (verifiable by inspection) or "Gun alignment error in elevation shall be no greater than 1.5milliradians"(verifiable by test).

Questions are often asked as to what exactly is the difference between a demonstration and a test; and how to decidebetween a demonstration and a test, when planning a verification strategy. The answer to the first question is extentof instrumentation. A test is fully instrumented while a demonstration involves observation and simple recording ofinformation such as time. A well known demonstration which is required on many programs is a maintainabilitydemonstration. The objective of a maintainability demonstration is to verify the maintainability of a system, usuallyspecified as the mean time to repair (MTTR).




During the demo a trained soldier or sailor (made available by the user community) attempts to repair a series ofartificially induced faults on the system, using the technical documentation and available spare parts. For each fault,the only measurements are time taken to diagnose the problem, correct the problem and re- test the system forcorrect operation. The achieved MTTR is computed from the measured times.A test, on the other hand, utilizes a large number of instruments. A shipborne missile firing test to determine missileperformance against a target utilizes both shipboard instrumentation and missile borne telemetry to determine notonly the end results but intermediate results as well to determine whether the missile performed to requirementsthroughout the flight.

As can be expected, testing is the most expensive and also the most reliable method of verification. Verifying everyrequirement by test can be expensive. When determining a verification strategy, trade studies may have to beperformed to decide the optimum strategy. This is where analysis comes in. Analysis is often much cheaper than testand can be used effectively in a supporting role. For example, computer models of the system can be used to verifysystem performance under certain (hard to achieve in real life) conditions, especially after the model has beenvalidated against test results.

CHARACTERISTICS OF AGGREGATE REQUIREMENTSAggregate requirements are a set of requirements for a system or element that specify its characteristics in totality.Usually these aggregates are found in specifications. Characteristics of individual requirements are applicable toaggregates also. The following characteristics are applicable to aggregates.

Complete. The set of requirements is complete and does not need further amplification. The set of requirements hasaddressed all categories (see supporting characteristics), and covers all allocations from higher levels.Discussion. This characteristic addresses the difficult problem of identifying requirements which are necessary butare missing from the set. There are several approaches to identifying missing requirements. One is to develop thesystem operations concept and an associated set of scenarios. Walking through these from cradle to grave: how willthe system be delivered? how will it be deployed? how will it be used, upgraded and disposed of, help to identifymissing requirements. The next step is to walk through the same set of scenarios and play the "what if" game. Whatif something goes wrong? This step usually uncovers a whole new set of requirements. Another approach is todevelop a checklist of topics or areas such as a specification outline as given in MIL STD 490A or DOD STD2167A and verify that requirements exist in each topic area or if they do not, there are good reasons for it. Yetanother is to check the aggregate against a higher level specification (if one exists) to verify that all allocatedrequirements have been included in the set. Often we leave out the obvious such as "The ship shall float."

Consistent. The set of requirements does not have individual requirements which are contradictory. Requirementsare not duplicated. The same term is used for the same item in all requirements.Discussion. This characteristic addresses the problem of identifying unnecessary or conflicting requirements whichare inadvertently included in the set. Assignment of a project unique identification to each requirement, andthorough reviews should eliminate these requirements.

SUPPORTING CHARACTERISTICSThese are secondary properties or attributes of individual requirements which provide supplementary informationabout the requirement, its relationship to other requirements and source documents; and assist in requirementsmanagement. These supporting characteristics are not essential in all cases and if an automated requirementmanagement tool is used, the tool may generate some or all of these attributes automatically.

Project unique identification. (PUID). The PUID is a unique identifier assigned to a single requirement foridentification and tracking. It may be either numeric or alpha numeric. The PUID assists in identification,maintaining change history, and provides traceability.Assigning a PUID is probably a better method to track and maintain requirements on an individual basis than a titleor some such textual description. PUIDs can be purely numeric or alphanumeric. An alphanumeric PUID, inaddition to being a unique identifier, can provide information about the requirement. For example, the PUIDSYS0001 clearly shows that the requirement is a system requirement. On the other hand, the numeric PUID can beautomatically assigned to newly formed requirements by many requirement management tools.




Level. This attribute indicates the level at which the specific requirement is applicable in the System Hierarchy. Forexample, level I may indicate a top or system level requirement. Level II may be the segment level requirement.Requirements written at the right level will provide adequate information without constraining the designer'sfreedom. While not an essential characteristic, levels can be used to provide statistics on requirements fan out andverification levels.

Category. Categories are used to classify requirements. There are two major categories:Program requirements. These are customer or user requirements imposed on contractors through contractualvehicles other than specifications. Examples of documents in which program requirements are listed are the contractitself and the contract statement of work (SOW). Program requirements include: compliance with federal, state orlocal laws including environmental laws; administrative requirements such as security; customer/contractorrelationship requirements such as directives to use government facilities for specific types of work such as test; andspecific work directives (such as those included in Statements of Work and Contract Data Requirements Lists).Program requirements may also be imposed on a program by Corporate policy or practice.Program requirements are different from the requirements that have been discussed so far. These are notrequirements imposed on the system or product to be delivered, but on the process to be followed by the contractor.Program requirements should be necessary, concise, attainable, complete, consistent and unambiguous. Programrequirements are managed in the same manner as product requirements.Technical (product) requirements. These are requirements applicable to the product or service to be delivered.Product requirements are usually listed in specifications or interface control drawings. These are further classifiedby these requirement types:a) Functional. Qualitative requirements describing what the system needs to do without describing them inquantitative terms. These requirements are usually descriptive and are verified by the summation of the associatedperformance requirements. An example of a functional requirement for a radar element is: "The radar element shallbe capable of detecting targets."b) Performance. These are quantitative requirements of system performance, and are verifiable individually. Oneperformance requirement associated with the functional requirement example in the previous paragraph can be "In aclear environment, the radar element shall be capable of detecting 0.1 (meter)2 ASCM targets at ranges of up to 20KM with a probability of detection of no less than 0.9 and probability of false alarm of no greater than 10-6." In factan appropriate paragraph heading for this requirement would be "Target Detection", the function with which it isassociated. There are usually several performance requirements associated with a single functional requirement.c) Design constraints. These requirements identify the constraints under which the system is required to operate orexist. Size and weight limitations are included in this category, as are environmental requirements. An example of adesign constraint in the area of weight is "The vehicle's combat loaded weight shall not exceed 35 Tons".d) Interface. Interface requirements are the definition of how the system is required to interact with externalsystems (external interface), or how subsystems within the system interact with each other (internal interface).Interface requirements are often an exception to the 'implementation free' rule of requirements.e) Non requirement. In a strict sense this is not a requirement type. Very often some explanatory text is provided insource documents which are not requirements, but which is maintained in the requirements data base forcompleteness and to re- create the original source document, if needed.Compliance level. There are two levels of compliance:

Mandatory. This attribute is applicable to all requirements defined in sentences containing the word "shall". Theserequirements must be verified.Goal or objective. These indicate that this level of performance is desired by the customer. They are not mandatorybut need rationale and documentation if they are not met.Allocated to. Each requirement must be allocated to one or more lower level components. This can be done byallocating the requirement to a component name or to the name of the specification that will define the componentrequirements. Allocation provides insurance that all requirements are flowed down to the next level. It is a basis forchecking that lower level requirements are responsive to the higher level requirement.Parent PUID. This attribute provides a link to the immediate parent of a derived or lower level requirement. For alower level requirement, this PUID will represent the next higher level requirement. This attribute is required toprovide vertical traceability through the specification tree of the system.Source. The top level document, supplied by the user, that is the sources for all program requirements. Eachrequirement is traced to this document and to a unique paragraph number. The document can be a specification,operational requirements document or statement of work. This attribute is required to provide direct traceability forindividual requirements to user documents.




Specification number, specification title, paragraph number and paragraph title. These attributes are importantwhen searching and printing requirements. They are used to associate requirements with the appropriate document.Rationale. This attribute provides a link to the data or tradeoff analyses which support the requirement. Thesupporting data may include the reason or reasons a requirement is needed; any assumptions made at the time therequirement was formulated; numbers and locations of analysis or trade study reports which support formulation ofthe requirement and its current value or values. In a large system the rationale for every requirement is not readilyavailable. This attribute provides an index to the rationale for every requirement.Verification method. This attribute describes and tracks the selected verification method for the requirement. Thealternatives are: inspection, analysis, demonstration and test.Verification documents. This attribute provides a link to the number, title and paragraph number of the verificationPlan and Procedure (such as a test plan) used to verify the requirement.Change notices. This attribute records the number and date of specification change notices affecting the statedrequirement. It assists in maintaining the change history associated with this requirement.Risk. This attribute provides a record of the risk associated with a requirement, if any. A quantitative assessment ofthe risk and the date of the assessment is provided.TPM Parameter. This attribute provides a record of the Technical Performance Measure Parameter in which therequirement is included (The requirement itself may be a TPM parameter) and the current value of the parameter.Current status. This attribute provides a record of the current status of the requirement. The alternatives are:TBD (to be defined) - this indicates that the value of the requirement has not been defined yet. It is good practice touse TBDs for requirements which do not have defined values. It can be used to provide metrics such as the numberof requirements which are not yet defined.TBR (to be reviewed)- this indicates that a preliminary value is available but needs further review.Defined. - This indicates that a final value for the requirement has been obtained through analysis and trades.Approved. - The requirement has been reviewed and approved by the appropriate authorities.Verified. - The requirement has been verified in accordance with the verification plan.Deleted. - The requirement is no longer applicable to the program.Standards. The standards or conditions under which a requirement must be met.

SUMMARYWriting good requirements is difficult, requires careful thinking and analysis, but is not magical. Requirementswhich have the characteristics described in this paper will be easier to meet and help insure that the customer getswhat he wants. Time spent up front, carefully defining and articulating the requirements is the first step towardsinsuring a high quality product.ACKNOWLEDGEMENTSThe authors wish to thank Ivy Hooks (Compliance Automation/Vital Link), Beth Simon (McDonnell Douglas Aerospace), Dave Jones (Texas Instruments); and Allan Ray, John Bangs andSaumya Sanyal (United Defense) for reviewing the paper and providing useful suggestions and comments.BIBLIOGRAPHY1.Writing Good Requirements, Ivy Hooks: Proceedings of the Fourth Annual Symposium, NCOSE working Group Papers Volume II.2.An Introduction to Systems Engineering, J. Douglas Sailor.3.Current System Development Practices using the Hatley/Pirbhai Methods, Derek Hatley, The journal of NCOSE Volume 1 Number 1 July-September 1994.4.Application of the System Engineering process to define requirements for Computer Based design tools, Benjamin Blanchard, Wolter Fabrycky and Dinesh Verma March 1994.5.Requirements Management/Traceability: A case Study - NASA's National Launch System, Mary Beth Pinkerton & Frank R. Fogle, Proceedings of the Second Annual Symposium, NCOSE6.Development & implementation of an integrated Systems Engineering environment, R.M. Harwell, Proceedings of the Second Annual Symposium, NCOSE.7.Requirements for Development of Software Requirements, Brian W. Mar, Proceedings of the Fourth Annual Symposium, NCOSE.8.What Is A Requirement? Richard Harwell, Erik Aslaksen, Ivy Hooks, Roy Mengot, Ken Ptack, Proceedings of the Third Annual International Symposium, NCOSE.9.IEEE Std 1220-1994 (Issued February 1995 for trial use).ABOUT THE AUTHORSPradip Kar is the Systems Engineering Manager for the Armament Systems Division of United Defense Limited Partnership, a partnership of FMC and Harsco corporations. Over the past 14years he has worked on a number of engineering development programs such as the Army's Crusader and Bradley Fighting Vehicles, and the Navy's Aegis and Mk 41 Vertical Launching Systemprograms. Prior to working at United Defense, he was an officer in the Indian Navy and spent time developing a command and control system. He has been a member of INCOSE since 1992. Hehas a B.S degree in Electrical Engineering from London University and has done graduate work in Computer science at the University of Minnesota.Michelle Bailey is currently a member of the Range Architecture Office, Naval Air Warfare Center Weapons Division, China Lake, Ca. which has responsibility for major investments within theNavy's West Coast test ranges. Previous experience includes leading the software development effort on the AIM-9R air to air missile and subsequently serving as the systems engineer for thateffort. Other experience includes working on advanced signal processing systems and a one year tour in the Pentagon where she wrote the Naval Science and Technology Requirements. Otherpublications include the China Lake design process handbook, the China Lake System Engineer Handbook, "System Engineering for all Engineers" NCOSE 1994 Symposium, and "HWILContributions to Navy Test and Evaluations" SPIE 1996 Symposium.Requirements Working Group Information PaperPresented at the 1996 INCOSE Symposium. Prepared by the Requirements Working Group of the International Council on Systems Engineering, for information purposes only. Not approved byINCOSE Technical Board. Not an official position of INCOSE. http://www.incose.org




New stakeholders may produce new requirements as the business and economicenvironment changes dynamically.Requirements capture involves:

Domain Understanding: research about companyRequirements Collection: interacting with stakeholders to find out whatthey want.Classification: organising unstructured requirements coherentlyConflict Resolution: where stakeholders’ requirements clashPrioritisation: discovering the order of importance of requirementsRequirements Validation: are requirements complete, consistent and inaccordance to stakeholder needs?

For any medium-sized or large system, there are usually different types of enduser. Different people in an organisation all have some kind of interest in thesystem requirements.


Stakeholders

� System developers will meet with a number of different peoplein the client company (end-users, their managers etc.), calledstakeholders.

� Stakeholders...� often don’t know what they want except in the most general terms, or

cannot articulate what they want, or make unrealistic demands.� naturally express requirements in their own terms, and with implicit

knowledge of their work. Engineers need to understand the client’sdomain and translate terms into an agreed form.

� have different requirements and may express these in different ways.Engineers need to source as many requirements as they can.

� may be influenced by political factors in/outside of their company

� May need to sift and prioritise!




Stakeholders provide “Viewpoints”

� For example, an ATM system for a bank would have thefollowing stakeholders:� current bank customers, representatives from co-operating banks, branch

managers, counter staff, database administrators, bank security managers,communications engineers, the bank’s marketing dept., hardware andsoftware engineers, personnel dept., etc..

� Not all these people will need to be consulted but, it shows that there aremany...

� Viewpoints� The perspectives of different viewpoints are not completely independent.� A key point of this approach is to recognise these overlaps, and

identifying conflicts.

The idea of a top-down analysis with a single system is too simplistic. Thisapproach recognises there are many “tops”.A viewpoint may be considered as:

A data source or sink: viewpoints are responsible for producing orconsuming data. Analysis identifies all such viewpoints, the data involvedand investigates whether all data produced is consumed and vice versa.(The CORE method)A representation framework: each viewpoint is a particular type of systemmodel. Comparison of requirements for each model reveals any omissionetc. (The VOSE method)A receiver of services: viewpoints are external to the system and receiveservices from it. Analysis of the services received and the conflicts thatmay exist (The VORD method)




Types of Requirement

The requirements definition describeseverything about how the systemis to interact with its environment e.g

� Physical Environment� Interfaces� Users and Human Factors� Functionality� Documentation� “Data”� Resources� Security� Quality Assurance

SYSTEM

USER TYPE

PERFORMANCEREQUIREMENTS

DATA TYPE

LEGISLATION

A Requirements Tree:One way to organise requirements

Physical Environment:Where is the equipment to function?Is there any environmental restrictions, such as temperature,humidity, or magnetic interference?

Interfaces:Is the input coming from one or more other systems?Is the output going to one or many other systems?Is there a prescribed way in which the data must beformatted?Is there a prescribed medium that the data must use?

Users and Human Factors:Who will use the system?Will there be several types of users?What is the skill level of each type of user?What training will be required for each type of user?How easy will it be to understand/use the system?How difficult will it be for a user to misuse the system?

Functionality:What will the system do?When will the system do it?How and when can the system be changed or enhanced?Are there constraints on execution speed, response time orthroughput?

Documentation:How much documentation is required?To what audience is the documentation addressed?

DataFor both input and output, what should the format of the databe?How often will it be received or sent?How accurate must it be?

Data continued...To what degree of precision must the calculations be made?How much data flows through the system?Must any data be retained for any period of time?

ResourcesWhat materials, personnel, or other resources are required tobuild, use, and maintain the system?What skills must the engineers/developers have?How much physical space will be taken up by the system?What are the requirements for power, heating, or airconditioning?Is there a prescribed timetable for development?Is there a limit on the amount of money to be spent ondevelopment or on hardware and software?

SecurityMust access to the system or information be controlledHow will one user’s data be isolated from others’?Should precautions be taken against fire and theft?

Quality AssuranceWhat are the requirements for reliability?How must the characteristics of the system be demonstratedto others?Must the system detect and isolate faults?What is the prescribed mean time between failures?Is there a maximum time allowed for restarting the systemafter a failure?How the system incorporate changes to the design?Will maintenance merely correct errors, or will it alsoinclude improving the system?How easy should it be to move the system from location toanother?




Non-functional Requirements: 1

� Non-functional requirements define system properties (e.g.reliability, response time, store occupancy) and constraints (e.g.i/o capabilities, data representations used by other systems).

� They are as important as functional requirements (e.g. aviationstandards).

� Some may constrain the process rather than the product, e.g. theuse of a specific language or CASE tool. These impositions maybe to achieve:� system quality� system maintainability

A very common error in requirements spec. is to confuse non-functionalrequirements with general goals of the system. The requirement for “user-friendliness” is not verifiable because of its subjectivity. However, therequirement for a menu-driven system is.The best way to ensure than non-functional requirements are verifiable is toexpress them quantitatively. Traditionally such requirements are known asmetrics but this is an ambiguous term in Systems Engineering, so use the termmeasures instead. Examples follow.

Property MeasureSpeed Processed transactions/second

User/event response timeSize Physical dimensions of system

Number of RAM chips etc.Ease of use Training time

Number of help framesReliability Mean time to failure

Probability of unavailability/availabilityRate of failure occurrence

Robustness Time to restart after failurePercentage of events causing failurePercentage of data corruption on failure

Portability Percentage of target-dependent statementsNumber of target systems




Non-functional Requirements: 2

Non-functionalRequirements

ProductRequirements

ProcessRequirements

ExternalRequirements

Delivery Implementation Standards

Inter-operability EthicalPortabilityReliabilityEfficiency

Usability

Performance Space

Legal

Privacy Safety

In principle, functional and non-functional requirements should be differentiatedin a requirements specification.This may be difficult because the often non-functional requirements are at asystems level (e.g. time to learn system operation)If non-functional specifications are stated separately from the functionalrequirements, it is sometimes difficult to see the relationships between them. Ifstated with the functional requirements, it can be difficult to separate functionaland non-functional considerations and to identify the system requirements.Non-functional requirements can be further categorised

Operational Requirements: constraints on the systems engineeringprocess during the development phase, and constraints on the operationalprocess of the system within its final contextPerformance Requirements: well-specified constraints on how thesystem should perform within its final context giving measures ofperformance which can be test, e.g. speed, reliability etc..Interface Requirements: constraints on how the user should interfacewith the system, or on the interface software, or on the data protocols,hardware protocols between subsystems.




Requirements Database

� Once the requirements have been captured they need to beorganised into a database.

� It is important to note for each requirement:� its reference� its origin� side-effects� dependencies� version number

� Big projects should have dedicated Database Programmers� a strict set of rules should be set up as to how the database is to be

updated and how these updates are recorded in the requirements.� “baselining”

Requirements capture is a long and difficult process and requires a lot of earlycustomer contact.Each requirement will have a number that will be cross-referenced whenever it isreferred to.In principle the requirements ought to be complete and consistent. All systemfunctions should be specified and requirements should not conflict. This isdifficult and so the document should be structured so that it is easy to changewith as little cross-referencing as possible.The database can then be used for automated consistency checking, conflictidentification, and keeping account of changes.It is a mistake to assume that a purpose-built database is required.This is not the case. E.g. Microsoft Access is very powerful and ismuch cheaper than many other special purpose tools. Unfortunately,it is not that good for large projects.




Traceability

� The requirements should be stated so that there is traceabilitybetween the requirements and the final design.

� Traceability is closely linked to managing a requirementsdatabase as the system is being developed through the design,building, integration and testing phases.� Later on in the life-cycle traceability between the all sources of

requirements and the system components is essential� need to be able to demonstrate compliance� need to be able to perform impact analysis in both directions� Granularity of the traceability needs careful assessment� When to initiate traceability also needs assessment

� Links should allow for forward and backward analysis.

A requirements database is not necessarily a “nice” linear catalogue of therequirements. The requirements should be organised into modules, e.g.performance criteria, interface specifications, subsystem abstractions etc.)As a result, the modules have to be organised so that the life of each requirementis traceable through the design, building, integration and testing phases. It is theneasier to test each requirement at the validation and delivery stage of the system.There needs to be a traceable path for every requirement through each phase ofthe system lifecycle. Thus, for every requirement, there will be a cross-referenceto a design paper, a construction report, and ultimately the test. Modularisation istherefore important because some of the requirements may need to be testedtogether because of side effects.Links must be obvious between each of the phases of the life-cycle so that animpact analysis can be achieved:

• in the event of a change of contract (forwards analysis)• in the event of a module/system failure at test time (backwards analysis)

Later on in the development process, it may be necessary to rework therequirements to take into account additions from the design and implementationphases. Reworking requirements can lead to a management nightmare!The traceability of reworked requirements is very difficult to control and soproper database management and referencing is essential through the system life-cycle and development process.

Documents

Requirements Engineering · Specification of Requirements System Models Definition of Requirements The Requirements Engineering Process Feasibility ... each requirement on the rest