Uploaded byROZLINABINTIMOHAMED
PDF, PPTX9 views

For Chapter_3_ICCGI_2013_Tutorial_Terzakis.pdf

How to write requirements definition

Embed presentation

Download as PDF, PPTX
EARS: The Easy Approach to Requirements Syntax Version 1.0 Requirements Syntax John Terzakis Intel Corporation john.terzakis@intel.com July 21, 2013 ICCGI Conference Nice, France
Legal Disclaimers Intel Trademark Notice: Intel and the Intel Logo are trademarks of Intel Corporation in the U.S. and other countries. Non-Intel Trademark Notice: *Other names and brands may be claimed as the property of others Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 2
Agenda • Requirements overview • Issues with requirements • Overcoming issues with requirements • Identifying ubiquitous requirements • EARS and EARS examples Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 3 • EARS and EARS examples • Using EARS to rewrite requirement examples • EARS at Intel • Wrap up
Requirements Overview Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 4
What is a Requirement? A requirement is a statement of one of the following: 1. What a system must do 2. A known limitation or constraint on resources or design 3. How well the system must do what it does Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 5 The first definition is for Functional Requirements The second and third definitions are for Non-Functional Requirements (NFRs) This session will focus on improving requirements defined by 1 & 2
Examples of Functional and Non-Functional Requirements Video over IP Conference Calling Functional Requirements Non-Functional Requirements Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 6 Functional Requirements •Add Participant •Count Participants •Drop Participant •Lock Call to New Participants •Summon Operator •Mute voice Non-Functional Requirements •Voice and Video Quality •Reliability •Availability •Ease of Use •Cost •Localization
Issues with Requirements Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 7
Issues with Requirements • Authors often lack formal training on writing requirements • Authors write requirements using unconstrained natural language: • Introduces ambiguity, vagueness and subjectivity • Not always clear, concise and coherent • Often not testable Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 8 • Often not testable • Some times missing triggers • Logic is not always complete (“if” but no “else”) • Authors “copy and paste” poor requirements, which multiplies the number of requirements with defects
Examples of Issues with Requirements 1. The software shall support a water level sensor. • What does the word “support” mean? 2. The thesaurus software shall display about five alternatives for the requested word. • How many is “about five”? Three? Four? Six? Ten? More? • Under what conditions are they displayed ? Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 9 3. The software shall blink the LED on the adapter using a 50% on, 50% off duty cycle. • Does the software blink the LED at all times? Or is there a trigger that initiates the blinking? 4. If a boot disk is detected in the system, the software shall boot from it. • What if a boot disk is not present? The logic is incomplete.
Overcoming Issues with Requirements Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 10
Tools to Overcome Requirements Issues • Training • Use a consistent requirements syntax • Check requirements against “goodness” criteria Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 11 • • Use a constrained natural language (e.g., Planguage) • Express requirements using EARS
Training • Develop internal training • Attend external training • Partner requirements authors with requirements subject matter experts • Create “communities of practice” to share best known requirements methods internally Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 12 requirements methods internally
Consistent Requirements Syntax [Trigger] [Precondition] Actor Action [Object] Here is a generic syntax for functional requirements (optional items are in square brackets): Example: When an Order is shipped and Order Terms are not Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 13 “Prepaid”, the system shall create an Invoice. • Trigger: When an Order is shipped • Precondition: Order Terms are not “Prepaid” • Actor: the system • Action: create • Object: an Invoice
Good Requirements Checklist Utilize a checklist that defines the attributes of a well written requirement. For example, a Good Requirement is:  Complete  Correct  Concise  Prioritized  Unambiguous  Verifiable Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 14  Concise  Feasible  Necessary  Verifiable  Consistent  Traceable Most of these attributes apply equally to a single requirement and the entire set of requirements See Backup for details
Planguage: A Constrained Natural Language Many requirements defects can be eliminated by using a constrained natural language. Planguage is an example: • Developed by Tom Gilb in 1988 and explained in detail in his book Competitive Engineering * • Is a combination of the words Planning and Language Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 15 • An informal, but structured, keyword-driven planning language (e.g., Name, Description, Rationale) • Can be used to create all types of requirements * Competitive Engineering, Butterworth-Heinemann, 2005
Planguage Keywords for Any Requirement Name A short, descriptive name Requirement Text that defines the requirement, following EARS* Rationale The reasoning that justifies the requirement Priority Sets the importance of the requirement relative to others in the product Priority Reason A brief justification for the assigned priority level Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 16 Priority Reason A brief justification for the assigned priority level Status The current state of the requirement Contact The person to contact with questions about the requirement Source The original inspiration for the requirement
Planguage Example Name: Create_Invoice Requirement: When an Order is shipped and Order Terms are not “Prepaid”, the system shall create an Invoice. Rationale: Task automation decreases error rate, reduces effort per order. Meets corporate business principle for accounts receivable. Priority: High. Priority Reason: If not implemented, business process reengineering will be necessary and program ROI will drop by $400K per year.  Finance study Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 17 necessary and program ROI will drop by $400K per year.  Finance study Status: Committed Contact: Hugh P. Essen Source: I. Send, Shipping Created by: Julie English Version: 1.1, Modified Date: 20 Oct 11
Express Requirements Using EARS EARS: Easy Approach to Requirements Syntax • Is an effective method of expressing requirements • Was created by Alistair Mavin and others from Rolls- Royce PLC and presented at the 2009 Requirements Engineering (RE 09) conference • Differentiates between five types (or patterns) of Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 18 • Differentiates between five types (or patterns) of requirements: • Ubiquitous (always occurring) • Event-driven • Unwanted behaviors • State-driven • Optional features
EARS Background • Case study involved Rolls-Royce group working on aircraft engine control systems • Software was safety critical, contained thousands of components and involved up to twenty different suppliers • Rolls-Royce identified 8 major problems with existing natural language requirements: • Ambiguity • • Duplication • Wordiness Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 19 • Vagueness • Complexity • Omission • Rewriting requirements using EARS “…demonstrated a significant reduction in all eight problem types…” * (* From: EARS (Easy Approach to Requirements Syntax), Alistair Mavin et al, 17th IEEE International Requirements Engineering Conference (RE 09), page 321) • Wordiness • Inappropriate implementation • Untestability
Identifying Ubiquitous Requirements Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 20
Ubiquitous Requirements Ubiquitous Requirements: • State a fundamental system property • Do not require a stimulus in order to execute • Are universal (exist at all times) Requirements that are not ubiquitous do not occur at all Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 21 Requirements that are not ubiquitous do not occur at all times. They • Require an event or trigger in order to execute, or • Denote a state of the system, or • Denote an optional feature Most requirements are not ubiquitous
About Ubiquitous Requirements Question ubiquitous requirements: Things that may seem universal are often subject to unstated triggers or preconditions Most legitimate ubiquitous requirements state a fundamental property of the software: • The software shall be distributed on CD-ROM and DVD media. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. • The software shall be distributed on CD-ROM and DVD media. • The software shall prevent Unauthorized Access to patient data. Software functions that appear ubiquitous are often not: • The software shall wake the PC from standby • The software shall log the date, time and username of failed logins. 22 The last 2 requirements are missing a trigger
Ubiquitous Requirements or Not? The installer SW shall be available in Greek The SW shall mute the microphone The SW shall phone the Alarm Company The SW shall display a count of the number of participants. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 23 Which requirements are ubiquitous? The SW shall download the book without charge The SW shall warn the user of low battery
Ubiquitous or Not? 1. The installer software shall be available in Greek. • Yes. This is a fundamental property of the installer software 2. The software shall display a count of the number of participants. • No. There is likely an event that causes the count to be displayed. 3. The software shall phone the Alarm Company. • No. We don’t want the software phoning the Alarm Company unless there is a fault or problem. 4. The software shall mute the microphone. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 24 4. The software shall mute the microphone. • No. The muting occurs during some state the system is in 5. The software shall download the book without charge. • No. There is apt to be an optional condition under which books are downloaded for free. 6. The software shall warn the user of low battery • No. There is a state or an event needed for this warning to occur.
EARS and EARS Examples Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 25
EARS Patterns Pattern Name Pattern Ubiquitous The <system name> shall <system response> Event-Driven WHEN <trigger> <optional precondition> the <system name> shall <system response> Unwanted Behavior IF <unwanted condition or event>, THEN the <system name> shall <system response> Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 26 State-Driven WHILE <system state>, the <system name> shall <system response> Optional Feature WHERE <feature is included>, the <system name> shall <system response> Complex (combinations of the above patterns)
Ubiquitous Requirements • Define a fundamental property of the system • Have no preconditions or trigger • Do not require a pattern keyword Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 27 • Do not require a pattern keyword • Have the format: The <system name> shall <system response>
Ubiquitous Examples • The software package shall include an installer. • The software shall be written in Java. • The software shall be available for purchase on the Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 28 • The software shall be available for purchase on the company web site and in retail stores.
Event-Driven Requirements • Are initiated when and only when a trigger occurs or is detected • Use the “When” keyword Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 29 • Have the format: WHEN <trigger> <optional precondition> the <system name> shall <system response>
Event-Driven Examples • When an Unregistered Device is plugged into a USB port, the OS shall attempt to locate and load the driver for the device. • When a DVD is inserted into the DVD player, the OS shall spin up the optical drive. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 30 spin up the optical drive. • When the water level falls below the Low Water Threshold, the software shall open the water valve to fill the tank to the High Water Threshold.
Unwanted Behavior Requirements • Handle unwanted behaviors including error conditions, failures, faults, disturbances and other undesired events • Use the “If” and “then” keywords Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 31 • Have the format: IF <unwanted condition or event>, THEN the <system name> shall <system response>
Unwanted Behavior Examples • If the measured and calculated speeds vary by more than 10%, then the software shall use the measured speed. • If the memory checksum is invalid, then the software shall display an error message. • Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 32 • If the ATM card inserted is reported lost or stolen, then software shall confiscate the card.
State-Driven Requirements • Are triggered while the system is in a specific state • Use the “While” keyword (or optionally the keyword “During”) • Have the format: Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 33 • Have the format: WHILE <system state>, the <system name> shall <system response>
State-Driven Examples • While in Low Power Mode, the software shall keep the display brightness at the Minimum Level. • While the heater is on, the software shall close the water intake valve. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 34 • While the autopilot is engaged, the software shall display a visual indication to the pilot.
Optional Feature Requirements • Are invoked only in systems that include the particular optional feature • Use the “Where” keyword Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 35 • Have the format: WHERE <feature is included>, the <system name> shall <system response>
Optional Feature Examples • Where a thesaurus is part of the software package, the installer shall prompt the user before installing the thesaurus. • Where hardware encryption is installed, the software shall encrypt data using the hardware instead of using a software algorithm. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 36 • Where a HDMI port is present, the software shall allow the user to select HD content for viewing.
Complex Requirements • Describe complex conditional events involving multiple triggers, states and/or optional features • Use a combination of the keywords When, If/Then, While and Where Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 37 • Have the format: • <Multiple Conditions>, the <system name> shall <system response>
Complex Examples • When the landing gear button is depressed once, if the software detects that the landing gear does not lock into position, then the software shall sound an alarm. • Where a second optical drive is installed, when the user selects to copy disks, the software shall display an option to copy directly from one optical drive to the other optical Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 38 to copy directly from one optical drive to the other optical drive. • While in start up mode, when the software detects an external flash card, the software shall use the external flash card to store photos.
Using EARS to Rewrite Requirement Examples Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 39
Example 1 Original: The installer software shall be available in Greek. Rewritten using EARS (no change): The installer software shall be available in Greek. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 40 What type of EARS Pattern? Ubiquitous
Example 2 Original: The software shall display a count of the number of participants. Rewritten using EARS: When the user selects the caller count from the menu, the Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 41 When the user selects the caller count from the menu, the software shall display a count of the number of participants in the audio call in the UI. What type of EARS Pattern? Event Driven
Example 3 Original: The software shall phone the Alarm Company. Rewritten using EARS: If the alarm software detects that a sensor has malfunctioned, then the alarm software shall phone the Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 42 malfunctioned, then the alarm software shall phone the Alarm Company to report the malfunction. What type of EARS Pattern? Unwanted behavior
Example 4 Original: The software shall mute the microphone. Rewritten using EARS: While the mute button is depressed, the software shall mute the microphone. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 43 the microphone. What type of EARS Pattern? State-driven
Example 5 Original: The software shall download the book without charge. Rewritten using EARS: Where the book is available in digital format, the software shall allow the user to download the book without charge for Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 44 shall allow the user to download the book without charge for a trial period of 3 days. What type of EARS Pattern? Optional feature
Example 6 Original: The software shall warn the user of low battery. Rewritten using EARS: While on battery power, if the battery charge falls below 10% remaining, then the system shall display a warning message Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 45 remaining, then the system shall display a warning message to switch to AC power. What type of EARS Pattern? Complex
EARS at Intel Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 46
History of EARS at Intel • EARS was introduced at Intel in 2010 • Although originally developed for the aircraft industry, it was easily adapted to a wide variety of projects at Intel • Integrated into existing Requirements Engineering training materials • Rapidly adopted by requirements authors due to its power Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 47 • Rapidly adopted by requirements authors due to its power and simplicity • Praised by developers & validation teams for providing clarity and removing ambiguity from requirements.
EARS Requirements Examples from Intel • The software shall include an online help file. • Type: Ubiquitous • When the software detects the J7 jumper is shorted, it shall clear all stored user names and passwords. • Type: Event-driven Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 48 • If the software detects an invalid DRAM memory configuration, then it shall abort the test and report the error. • Type: Unwanted behavior Note: Requirements slightly modified from original form
EARS Requirements Examples from Intel • While in Manufacturing Mode, the software shall boot without user intervention. • Type: State-driven • Where both 3G and Wi-Fi radios are available, the software shall prioritize Wi-Fi connections above 3G. • Type: Optional feature Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 49 • Type: Optional feature • While on DC power, if the software detects an error, then the software shall cache the error message instead of writing the error message to disk. • Type: Complex Note: Requirements slightly modified from original form
Wrap up Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 50
Session Summary In this session we have: • Provided a brief overview of requirements • Discussed issues with requirements and listed tools to overcome them • Taught how to identify ubiquitous requirements vs. those that are not Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 51 that are not • Introduced the concept of EARS • Reviewed examples using the EARS template • Rewrote requirements using the EARS template • Observed practical applications of EARS at Intel
Final Thoughts • EARS is a structured aid to writing better requirements Focuses on the different patterns for requirements using keywords (When, If-Then, While, Where and combinations) • EARS helps to identify which requirements are truly ubiquitous Some requirements, written as if they were ubiquitous, are really not Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 52 • EARS is beneficial to both developers and testers in understanding the intent of requirements Removes ambiguity, improves clarity and properly identifies underlying conditions or triggers EARS is Powerful. Start Using it Today!
Contact Information Thank You! For more information, please contact: Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 53 John Terzakis john.terzakis@intel.com
Backup Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 54
Papers on EARS EARS (Easy Approach to Requirements Syntax), Alistair Mavin et al, 17th IEEE International Requirements Engineering Conference (RE 09) Big EARS: The Return of Easy Approach to Requirements Syntax, Alistair Mavin et al, 18th IEEE International Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 55 Syntax, Alistair Mavin et al, 18th IEEE International Requirements Engineering Conference (RE 10)
Complete A requirement is “complete” when it contains sufficient detail for those that use it to guide their work Every gap forces designers and developers to guess –who do you want specifying your product? Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 56 Not Complete: The software must allow a TBD number of incorrect login attempts. Complete: When more than 3 incorrect login attempts occur for a single user ID within a 30 minute period, the software shall lock the account associated with that user ID.
Correct A requirement is correct when it is error-free Requirements can be checked for errors by stakeholders & Subject Matter Experts (SMEs) Requirements can be checked against source materials for errors Correctness is related to other attributes – ambiguity, Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 57 consistency, and verifiability Not Correct: The 802.3 Ethernet frame shall be 2048 bytes or less. Correct: The 802.3 Ethernet frame length shall be between 64 and 1518 bytes inclusive.
Concise A requirement is concise when it contains just the needed information, expressed in as few words as possible Requirements often lack conciseness because of: •Compound statements (multiple requirements in one) •Embedded rationale, examples, or design •Overly-complex grammar Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 58 Not concise: The outstanding software written by the talented development team shall display the current local time when selected by the intelligent and educated user from the well designed menu. Concise: The software shall display the current local time when selected by the user from the menu.
Feasible A requirement is feasible if there is at least one design and implementation for it Requirements may have been proven feasible in previous products Evolutionary or breakthrough requirements can be shown feasible at acceptable risk levels through analysis and prototyping Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 59 Not Feasible: The software shall allow an unlimited number of concurrent users. Feasible: The software shall allow a maximum of twenty concurrent users
Necessary A requirement is necessary when at least one of the following apply: • It is included to be market competitive • It can be traced to a need expressed by a customer, end user, or other stakeholder • It establishes a new product differentiator or usage model • It is dictated by business strategy, roadmaps, or sustainability needs Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 60 needs Not Necessary: The software shall be backwards compatible with all prior versions of Windows® Necessary: The software shall be backwards compatible with Windows® Vista SP2 and SP1, and Windows® XP SP3.
Prioritized A requirement is prioritized when it ranked or ordered according to its importance. All requirements are in competition for limited resources. There are many possible ways to prioritize: • Customer Value, Development Risk, Value to the Company, Competitive Analysis, Cost, Effort, TTM Several scales can be used for prioritization: Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 61 Several scales can be used for prioritization: • Essential, Desirable, Nice to Have • High, Medium, Low • Other ordinal scales based on cost, value, etc. Not Prioritized: All requirements are critical and must be implemented. Prioritized: 80% of requirements High, 15% Medium and 5% Low.
Unambiguous A requirement is unambiguous when it possesses a single interpretation Ambiguity is often dependent on the background of the reader Reduce ambiguity by defining terms, writing concisely, and testing understanding among the target audience Augment natural language with diagrams, tables and algorithms Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 62 Augment natural language with diagrams, tables and algorithms to remove ambiguity and enhance understanding Ambiguous: The software must install quickly. Unambiguous: When using unattended installation with standard options, the software shall install in under 3 minutes 80% of the time and under 4 minutes 100% of the time.
Verifiable A requirement is verifiable if it can be proved that the requirement was correctly implemented Verification may come via demonstration, analysis, inspection, or testing. Requirements are often unverifiable because they are ambiguous, can’t be decided, or are not worth the cost to verify. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 63 can’t be decided, or are not worth the cost to verify. Not Verifiable: The manual shall be easy to find on the CD-ROM. Verifiable: The manual shall be located in a folder named User Manual in the root directory of the CD-ROM.
Consistent A requirement is consistent when it does not conflict with any other requirements at any level Consistency is improved by referring to the original statement where needed instead of repeating statements. Inconsistent: Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 64 Inconsistent: #1: The user shall only be allowed to enter whole numbers. #2: The user shall be allowed to enter the time interval in seconds and tenths of a second. Consistent: #1: The user shall only be allowed to enter whole numbers except if the time interval is selected. #2: The user shall be allowed to enter the time interval in seconds and tenths of a second.
Traceable A requirement is traceable if it is uniquely and persistently identified with a Tag Requirements can be traced to and from designs, tests, usage models, and other project artifacts. Traceability enables improved • Change impact assessment • Schedule and effort estimation Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 65 • Schedule and effort estimation • Coverage analysis (requirements to tests, for example) • Scope management, prioritization, and decision making Not Traceable: The software shall prompt the user for the PIN. Traceable: Prompt_PIN: The software shall prompt the user for the PIN.
For Chapter_3_ICCGI_2013_Tutorial_Terzakis.pdf

More Related Content

PDF
Natural Language Processing (NLP) for Requirements Engineering (RE): an Overview
byalessio_ferrari
 
PPTX
EARS: The Easy Approach to Requirements Syntax
byTechWell
 
PDF
EARS: The Easy Approach to Requirements Syntax
byTechWell
 
PDF
Find Requirements Defects to Build Better Software
byTechWell
 
PDF
Requirements Engineering: focus on Natural Language Processing, Lecture 1
byalessio_ferrari
 
PPT
Man.ppt
byfarouqalfuhidi
 
PPTX
Pressman_Pressman_SoftwareEngineeringPA_9e_Ch007_PPT.pptx
bysangameshk8
 
PPTX
Pressman_Pressman_SoftwareEngineeringPA_9e_Ch007_PPT.pptx
bysangameshk8
 
Natural Language Processing (NLP) for Requirements Engineering (RE): an Overview
byalessio_ferrari
 
EARS: The Easy Approach to Requirements Syntax
byTechWell
 
EARS: The Easy Approach to Requirements Syntax
byTechWell
 
Find Requirements Defects to Build Better Software
byTechWell
 
Requirements Engineering: focus on Natural Language Processing, Lecture 1
byalessio_ferrari
 
Man.ppt
byfarouqalfuhidi
 
Pressman_Pressman_SoftwareEngineeringPA_9e_Ch007_PPT.pptx
bysangameshk8
 
Pressman_Pressman_SoftwareEngineeringPA_9e_Ch007_PPT.pptx
bysangameshk8
 

Similar to For Chapter_3_ICCGI_2013_Tutorial_Terzakis.pdf

PPT
sxdcdcfdffvfvfvfvfvfvfvvgvgvgvgvgvgggggg
byCharuNangia
 
PPT
Reviewwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.ppt
byshravanichanikya
 
PPT
Business requirement analysis session 5
bysampad_senapati
 
PPT
Requirements management
byAdelina Maxim
 
PDF
[2].the requirement engineering handbook
byNgan Do
 
PDF
SE UNIT-2.pdf
byDr. Radhey Shyam
 
PPTX
Andromeda Interim Phase1.pptx
byTriGoEV
 
PDF
Software Requirements and Specifications
byvustudent1
 
PPTX
03_IT4557.pptx
byjohnmichael314688
 
PPT
11 req specs
byNajam Uddin
 
PPTX
SE-Lecture 2A-Requirements.pptx
byTangZhiSiang
 
PDF
Precise and Complete Requirements? An Elusive Goal
byLionel Briand
 
PDF
Session03-Requirement (1).pdf
byPeterTran514407
 
PDF
notes_Software Requirement Engg Lec_11.pdf
byAqsa162589
 
DOC
Writing good requirements
byManish Chaurasia
 
PPTX
What BABoK Does not teach you content.pptx
byLN Mishra CBAP
 
PDF
The Requirements Engineering Handbook Ralph R Young
byuahpirsahrin
 
PPT
requirements analysis and design
byPreeti Mishra
 
PPTX
Requirements Engineering in Software Engineering.pptx
bybeulj98
 
PPTX
How to build a requirement
byPerry McLeod
 
sxdcdcfdffvfvfvfvfvfvfvvgvgvgvgvgvgggggg
byCharuNangia
 
Reviewwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.ppt
byshravanichanikya
 
Business requirement analysis session 5
bysampad_senapati
 
Requirements management
byAdelina Maxim
 
[2].the requirement engineering handbook
byNgan Do
 
SE UNIT-2.pdf
byDr. Radhey Shyam
 
Andromeda Interim Phase1.pptx
byTriGoEV
 
Software Requirements and Specifications
byvustudent1
 
03_IT4557.pptx
byjohnmichael314688
 
11 req specs
byNajam Uddin
 
SE-Lecture 2A-Requirements.pptx
byTangZhiSiang
 
Precise and Complete Requirements? An Elusive Goal
byLionel Briand
 
Session03-Requirement (1).pdf
byPeterTran514407
 
notes_Software Requirement Engg Lec_11.pdf
byAqsa162589
 
Writing good requirements
byManish Chaurasia
 
What BABoK Does not teach you content.pptx
byLN Mishra CBAP
 
The Requirements Engineering Handbook Ralph R Young
byuahpirsahrin
 
requirements analysis and design
byPreeti Mishra
 
Requirements Engineering in Software Engineering.pptx
bybeulj98
 
How to build a requirement
byPerry McLeod
 

Recently uploaded

PDF
Doctor On Call App Development for Digital Healthcare.
byV3CUBE TECHNOLABS
 
PDF
The Ultimate Guide to Real Estate Tokenization Platforms
byDaniel Smith
 
PDF
Building Smarter AI: 16 RAG Approaches for Accuracy, Memory, and Reasoning Vi...
byVineet Sharma
 
PDF
Ecommerce Website Development Services - Web Panel Solutions.pdf
byWEB PANEL SOLUTIONS
 
PDF
Mastering Zero-Allocation Parsers: A Deep Dive into High-Performance C#
byVineet Sharma
 
PPTX
40m_wAIred_DigitalPlatformRabobank_10022026.pptx
bySimonedeGijt
 
PDF
ACE Aarhus February 2026: Atlassian news
byDanielEriksen5
 
PDF
Metrics, Logs, Traces, and Mayhem_ Introducing an observability adventure gam...
byImma Valls Bernaus
 
PPTX
Pitch Deck for MEVIA OS - No Apps, Infinite, Decentralized Operating System
byDr. Edwin Hernandez
 
PDF
MySQL Routing Guidelines: Designing Smarter Query Routing Together
byMiguel Araújo
 
PPTX
How CFD Simulations Support Sustainable Data Center Design Optimization
byWeb Synergies
 
PPTX
Chapter Two Logic and Language - Copy.pptx
byGediyonBelay
 
PDF
Ontwikkel sneller en veiliger met GitHub Copilot
byDelta-N
 
PPTX
Prime Teams – Real-Time Employee Monitoring & Project Management Software
byPrime Teams
 
PDF
Clean Architecture with Vertical Slice Architecture in .NET 8
byVineet Sharma
 
PDF
Lost Android Phone Recovery_ Steps That Work Fast.pdf
byIsabella Reed
 
PPTX
40m_wAIred_DigitalPlatformRabobank_10022026.pptx
bySimonedeGijt
 
PDF
Ready, Set, REST! Introducing MySQL's Built-In REST Service
byMiguel Araújo
 
PDF
Langchain4J – An Introduction for Impatient Developers
byJuarez Junior
 
PPTX
Installing Python in Visual Studio Code
bydabydcatahanibmcom
 
Doctor On Call App Development for Digital Healthcare.
byV3CUBE TECHNOLABS
 
The Ultimate Guide to Real Estate Tokenization Platforms
byDaniel Smith
 
Building Smarter AI: 16 RAG Approaches for Accuracy, Memory, and Reasoning Vi...
byVineet Sharma
 
Ecommerce Website Development Services - Web Panel Solutions.pdf
byWEB PANEL SOLUTIONS
 
Mastering Zero-Allocation Parsers: A Deep Dive into High-Performance C#
byVineet Sharma
 
40m_wAIred_DigitalPlatformRabobank_10022026.pptx
bySimonedeGijt
 
ACE Aarhus February 2026: Atlassian news
byDanielEriksen5
 
Metrics, Logs, Traces, and Mayhem_ Introducing an observability adventure gam...
byImma Valls Bernaus
 
Pitch Deck for MEVIA OS - No Apps, Infinite, Decentralized Operating System
byDr. Edwin Hernandez
 
MySQL Routing Guidelines: Designing Smarter Query Routing Together
byMiguel Araújo
 
How CFD Simulations Support Sustainable Data Center Design Optimization
byWeb Synergies
 
Chapter Two Logic and Language - Copy.pptx
byGediyonBelay
 
Ontwikkel sneller en veiliger met GitHub Copilot
byDelta-N
 
Prime Teams – Real-Time Employee Monitoring & Project Management Software
byPrime Teams
 
Clean Architecture with Vertical Slice Architecture in .NET 8
byVineet Sharma
 
Lost Android Phone Recovery_ Steps That Work Fast.pdf
byIsabella Reed
 
40m_wAIred_DigitalPlatformRabobank_10022026.pptx
bySimonedeGijt
 
Ready, Set, REST! Introducing MySQL's Built-In REST Service
byMiguel Araújo
 
Langchain4J – An Introduction for Impatient Developers
byJuarez Junior
 
Installing Python in Visual Studio Code
bydabydcatahanibmcom
 

For Chapter_3_ICCGI_2013_Tutorial_Terzakis.pdf

  • 1.
    EARS: The EasyApproach to Requirements Syntax Version 1.0 Requirements Syntax John Terzakis Intel Corporation john.terzakis@intel.com July 21, 2013 ICCGI Conference Nice, France
  • 2.
    Legal Disclaimers Intel TrademarkNotice: Intel and the Intel Logo are trademarks of Intel Corporation in the U.S. and other countries. Non-Intel Trademark Notice: *Other names and brands may be claimed as the property of others Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 2
  • 3.
    Agenda • Requirements overview •Issues with requirements • Overcoming issues with requirements • Identifying ubiquitous requirements • EARS and EARS examples Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 3 • EARS and EARS examples • Using EARS to rewrite requirement examples • EARS at Intel • Wrap up
  • 4.
    Requirements Overview Copyright ©2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 4
  • 5.
    What is aRequirement? A requirement is a statement of one of the following: 1. What a system must do 2. A known limitation or constraint on resources or design 3. How well the system must do what it does Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 5 The first definition is for Functional Requirements The second and third definitions are for Non-Functional Requirements (NFRs) This session will focus on improving requirements defined by 1 & 2
  • 6.
    Examples of Functionaland Non-Functional Requirements Video over IP Conference Calling Functional Requirements Non-Functional Requirements Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 6 Functional Requirements •Add Participant •Count Participants •Drop Participant •Lock Call to New Participants •Summon Operator •Mute voice Non-Functional Requirements •Voice and Video Quality •Reliability •Availability •Ease of Use •Cost •Localization
  • 7.
    Issues with Requirements Copyright© 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 7
  • 8.
    Issues with Requirements •Authors often lack formal training on writing requirements • Authors write requirements using unconstrained natural language: • Introduces ambiguity, vagueness and subjectivity • Not always clear, concise and coherent • Often not testable Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 8 • Often not testable • Some times missing triggers • Logic is not always complete (“if” but no “else”) • Authors “copy and paste” poor requirements, which multiplies the number of requirements with defects
  • 9.
    Examples of Issueswith Requirements 1. The software shall support a water level sensor. • What does the word “support” mean? 2. The thesaurus software shall display about five alternatives for the requested word. • How many is “about five”? Three? Four? Six? Ten? More? • Under what conditions are they displayed ? Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 9 3. The software shall blink the LED on the adapter using a 50% on, 50% off duty cycle. • Does the software blink the LED at all times? Or is there a trigger that initiates the blinking? 4. If a boot disk is detected in the system, the software shall boot from it. • What if a boot disk is not present? The logic is incomplete.
  • 10.
    Overcoming Issues withRequirements Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 10
  • 11.
    Tools to OvercomeRequirements Issues • Training • Use a consistent requirements syntax • Check requirements against “goodness” criteria Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 11 • • Use a constrained natural language (e.g., Planguage) • Express requirements using EARS
  • 12.
    Training • Develop internaltraining • Attend external training • Partner requirements authors with requirements subject matter experts • Create “communities of practice” to share best known requirements methods internally Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 12 requirements methods internally
  • 13.
    Consistent Requirements Syntax [Trigger][Precondition] Actor Action [Object] Here is a generic syntax for functional requirements (optional items are in square brackets): Example: When an Order is shipped and Order Terms are not Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 13 “Prepaid”, the system shall create an Invoice. • Trigger: When an Order is shipped • Precondition: Order Terms are not “Prepaid” • Actor: the system • Action: create • Object: an Invoice
  • 14.
    Good Requirements Checklist Utilizea checklist that defines the attributes of a well written requirement. For example, a Good Requirement is:  Complete  Correct  Concise  Prioritized  Unambiguous  Verifiable Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 14  Concise  Feasible  Necessary  Verifiable  Consistent  Traceable Most of these attributes apply equally to a single requirement and the entire set of requirements See Backup for details
  • 15.
    Planguage: A ConstrainedNatural Language Many requirements defects can be eliminated by using a constrained natural language. Planguage is an example: • Developed by Tom Gilb in 1988 and explained in detail in his book Competitive Engineering * • Is a combination of the words Planning and Language Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 15 • An informal, but structured, keyword-driven planning language (e.g., Name, Description, Rationale) • Can be used to create all types of requirements * Competitive Engineering, Butterworth-Heinemann, 2005
  • 16.
    Planguage Keywords forAny Requirement Name A short, descriptive name Requirement Text that defines the requirement, following EARS* Rationale The reasoning that justifies the requirement Priority Sets the importance of the requirement relative to others in the product Priority Reason A brief justification for the assigned priority level Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 16 Priority Reason A brief justification for the assigned priority level Status The current state of the requirement Contact The person to contact with questions about the requirement Source The original inspiration for the requirement
  • 17.
    Planguage Example Name: Create_Invoice Requirement:When an Order is shipped and Order Terms are not “Prepaid”, the system shall create an Invoice. Rationale: Task automation decreases error rate, reduces effort per order. Meets corporate business principle for accounts receivable. Priority: High. Priority Reason: If not implemented, business process reengineering will be necessary and program ROI will drop by $400K per year.  Finance study Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 17 necessary and program ROI will drop by $400K per year.  Finance study Status: Committed Contact: Hugh P. Essen Source: I. Send, Shipping Created by: Julie English Version: 1.1, Modified Date: 20 Oct 11
  • 18.
    Express Requirements UsingEARS EARS: Easy Approach to Requirements Syntax • Is an effective method of expressing requirements • Was created by Alistair Mavin and others from Rolls- Royce PLC and presented at the 2009 Requirements Engineering (RE 09) conference • Differentiates between five types (or patterns) of Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 18 • Differentiates between five types (or patterns) of requirements: • Ubiquitous (always occurring) • Event-driven • Unwanted behaviors • State-driven • Optional features
  • 19.
    EARS Background • Casestudy involved Rolls-Royce group working on aircraft engine control systems • Software was safety critical, contained thousands of components and involved up to twenty different suppliers • Rolls-Royce identified 8 major problems with existing natural language requirements: • Ambiguity • • Duplication • Wordiness Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 19 • Vagueness • Complexity • Omission • Rewriting requirements using EARS “…demonstrated a significant reduction in all eight problem types…” * (* From: EARS (Easy Approach to Requirements Syntax), Alistair Mavin et al, 17th IEEE International Requirements Engineering Conference (RE 09), page 321) • Wordiness • Inappropriate implementation • Untestability
  • 20.
    Identifying Ubiquitous Requirements Copyright© 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 20
  • 21.
    Ubiquitous Requirements Ubiquitous Requirements: •State a fundamental system property • Do not require a stimulus in order to execute • Are universal (exist at all times) Requirements that are not ubiquitous do not occur at all Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 21 Requirements that are not ubiquitous do not occur at all times. They • Require an event or trigger in order to execute, or • Denote a state of the system, or • Denote an optional feature Most requirements are not ubiquitous
  • 22.
    About Ubiquitous Requirements Questionubiquitous requirements: Things that may seem universal are often subject to unstated triggers or preconditions Most legitimate ubiquitous requirements state a fundamental property of the software: • The software shall be distributed on CD-ROM and DVD media. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. • The software shall be distributed on CD-ROM and DVD media. • The software shall prevent Unauthorized Access to patient data. Software functions that appear ubiquitous are often not: • The software shall wake the PC from standby • The software shall log the date, time and username of failed logins. 22 The last 2 requirements are missing a trigger
  • 23.
    Ubiquitous Requirements orNot? The installer SW shall be available in Greek The SW shall mute the microphone The SW shall phone the Alarm Company The SW shall display a count of the number of participants. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 23 Which requirements are ubiquitous? The SW shall download the book without charge The SW shall warn the user of low battery
  • 24.
    Ubiquitous or Not? 1.The installer software shall be available in Greek. • Yes. This is a fundamental property of the installer software 2. The software shall display a count of the number of participants. • No. There is likely an event that causes the count to be displayed. 3. The software shall phone the Alarm Company. • No. We don’t want the software phoning the Alarm Company unless there is a fault or problem. 4. The software shall mute the microphone. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 24 4. The software shall mute the microphone. • No. The muting occurs during some state the system is in 5. The software shall download the book without charge. • No. There is apt to be an optional condition under which books are downloaded for free. 6. The software shall warn the user of low battery • No. There is a state or an event needed for this warning to occur.
  • 25.
    EARS and EARSExamples Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 25
  • 26.
    EARS Patterns Pattern NamePattern Ubiquitous The <system name> shall <system response> Event-Driven WHEN <trigger> <optional precondition> the <system name> shall <system response> Unwanted Behavior IF <unwanted condition or event>, THEN the <system name> shall <system response> Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 26 State-Driven WHILE <system state>, the <system name> shall <system response> Optional Feature WHERE <feature is included>, the <system name> shall <system response> Complex (combinations of the above patterns)
  • 27.
    Ubiquitous Requirements • Definea fundamental property of the system • Have no preconditions or trigger • Do not require a pattern keyword Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 27 • Do not require a pattern keyword • Have the format: The <system name> shall <system response>
  • 28.
    Ubiquitous Examples • Thesoftware package shall include an installer. • The software shall be written in Java. • The software shall be available for purchase on the Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 28 • The software shall be available for purchase on the company web site and in retail stores.
  • 29.
    Event-Driven Requirements • Areinitiated when and only when a trigger occurs or is detected • Use the “When” keyword Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 29 • Have the format: WHEN <trigger> <optional precondition> the <system name> shall <system response>
  • 30.
    Event-Driven Examples • Whenan Unregistered Device is plugged into a USB port, the OS shall attempt to locate and load the driver for the device. • When a DVD is inserted into the DVD player, the OS shall spin up the optical drive. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 30 spin up the optical drive. • When the water level falls below the Low Water Threshold, the software shall open the water valve to fill the tank to the High Water Threshold.
  • 31.
    Unwanted Behavior Requirements •Handle unwanted behaviors including error conditions, failures, faults, disturbances and other undesired events • Use the “If” and “then” keywords Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 31 • Have the format: IF <unwanted condition or event>, THEN the <system name> shall <system response>
  • 32.
    Unwanted Behavior Examples •If the measured and calculated speeds vary by more than 10%, then the software shall use the measured speed. • If the memory checksum is invalid, then the software shall display an error message. • Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 32 • If the ATM card inserted is reported lost or stolen, then software shall confiscate the card.
  • 33.
    State-Driven Requirements • Aretriggered while the system is in a specific state • Use the “While” keyword (or optionally the keyword “During”) • Have the format: Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 33 • Have the format: WHILE <system state>, the <system name> shall <system response>
  • 34.
    State-Driven Examples • Whilein Low Power Mode, the software shall keep the display brightness at the Minimum Level. • While the heater is on, the software shall close the water intake valve. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 34 • While the autopilot is engaged, the software shall display a visual indication to the pilot.
  • 35.
    Optional Feature Requirements •Are invoked only in systems that include the particular optional feature • Use the “Where” keyword Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 35 • Have the format: WHERE <feature is included>, the <system name> shall <system response>
  • 36.
    Optional Feature Examples •Where a thesaurus is part of the software package, the installer shall prompt the user before installing the thesaurus. • Where hardware encryption is installed, the software shall encrypt data using the hardware instead of using a software algorithm. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 36 • Where a HDMI port is present, the software shall allow the user to select HD content for viewing.
  • 37.
    Complex Requirements • Describecomplex conditional events involving multiple triggers, states and/or optional features • Use a combination of the keywords When, If/Then, While and Where Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 37 • Have the format: • <Multiple Conditions>, the <system name> shall <system response>
  • 38.
    Complex Examples • Whenthe landing gear button is depressed once, if the software detects that the landing gear does not lock into position, then the software shall sound an alarm. • Where a second optical drive is installed, when the user selects to copy disks, the software shall display an option to copy directly from one optical drive to the other optical Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 38 to copy directly from one optical drive to the other optical drive. • While in start up mode, when the software detects an external flash card, the software shall use the external flash card to store photos.
  • 39.
    Using EARS toRewrite Requirement Examples Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 39
  • 40.
    Example 1 Original: The installersoftware shall be available in Greek. Rewritten using EARS (no change): The installer software shall be available in Greek. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 40 What type of EARS Pattern? Ubiquitous
  • 41.
    Example 2 Original: The softwareshall display a count of the number of participants. Rewritten using EARS: When the user selects the caller count from the menu, the Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 41 When the user selects the caller count from the menu, the software shall display a count of the number of participants in the audio call in the UI. What type of EARS Pattern? Event Driven
  • 42.
    Example 3 Original: The softwareshall phone the Alarm Company. Rewritten using EARS: If the alarm software detects that a sensor has malfunctioned, then the alarm software shall phone the Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 42 malfunctioned, then the alarm software shall phone the Alarm Company to report the malfunction. What type of EARS Pattern? Unwanted behavior
  • 43.
    Example 4 Original: The softwareshall mute the microphone. Rewritten using EARS: While the mute button is depressed, the software shall mute the microphone. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 43 the microphone. What type of EARS Pattern? State-driven
  • 44.
    Example 5 Original: The softwareshall download the book without charge. Rewritten using EARS: Where the book is available in digital format, the software shall allow the user to download the book without charge for Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 44 shall allow the user to download the book without charge for a trial period of 3 days. What type of EARS Pattern? Optional feature
  • 45.
    Example 6 Original: The softwareshall warn the user of low battery. Rewritten using EARS: While on battery power, if the battery charge falls below 10% remaining, then the system shall display a warning message Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 45 remaining, then the system shall display a warning message to switch to AC power. What type of EARS Pattern? Complex
  • 46.
    EARS at Intel Copyright© 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 46
  • 47.
    History of EARSat Intel • EARS was introduced at Intel in 2010 • Although originally developed for the aircraft industry, it was easily adapted to a wide variety of projects at Intel • Integrated into existing Requirements Engineering training materials • Rapidly adopted by requirements authors due to its power Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 47 • Rapidly adopted by requirements authors due to its power and simplicity • Praised by developers & validation teams for providing clarity and removing ambiguity from requirements.
  • 48.
    EARS Requirements Examplesfrom Intel • The software shall include an online help file. • Type: Ubiquitous • When the software detects the J7 jumper is shorted, it shall clear all stored user names and passwords. • Type: Event-driven Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 48 • If the software detects an invalid DRAM memory configuration, then it shall abort the test and report the error. • Type: Unwanted behavior Note: Requirements slightly modified from original form
  • 49.
    EARS Requirements Examplesfrom Intel • While in Manufacturing Mode, the software shall boot without user intervention. • Type: State-driven • Where both 3G and Wi-Fi radios are available, the software shall prioritize Wi-Fi connections above 3G. • Type: Optional feature Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 49 • Type: Optional feature • While on DC power, if the software detects an error, then the software shall cache the error message instead of writing the error message to disk. • Type: Complex Note: Requirements slightly modified from original form
  • 50.
    Wrap up Copyright ©2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 50
  • 51.
    Session Summary In thissession we have: • Provided a brief overview of requirements • Discussed issues with requirements and listed tools to overcome them • Taught how to identify ubiquitous requirements vs. those that are not Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 51 that are not • Introduced the concept of EARS • Reviewed examples using the EARS template • Rewrote requirements using the EARS template • Observed practical applications of EARS at Intel
  • 52.
    Final Thoughts • EARSis a structured aid to writing better requirements Focuses on the different patterns for requirements using keywords (When, If-Then, While, Where and combinations) • EARS helps to identify which requirements are truly ubiquitous Some requirements, written as if they were ubiquitous, are really not Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 52 • EARS is beneficial to both developers and testers in understanding the intent of requirements Removes ambiguity, improves clarity and properly identifies underlying conditions or triggers EARS is Powerful. Start Using it Today!
  • 53.
    Contact Information Thank You! Formore information, please contact: Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 53 John Terzakis john.terzakis@intel.com
  • 54.
    Backup Copyright © 2013Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 54
  • 55.
    Papers on EARS EARS(Easy Approach to Requirements Syntax), Alistair Mavin et al, 17th IEEE International Requirements Engineering Conference (RE 09) Big EARS: The Return of Easy Approach to Requirements Syntax, Alistair Mavin et al, 18th IEEE International Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 55 Syntax, Alistair Mavin et al, 18th IEEE International Requirements Engineering Conference (RE 10)
  • 56.
    Complete A requirement is“complete” when it contains sufficient detail for those that use it to guide their work Every gap forces designers and developers to guess –who do you want specifying your product? Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 56 Not Complete: The software must allow a TBD number of incorrect login attempts. Complete: When more than 3 incorrect login attempts occur for a single user ID within a 30 minute period, the software shall lock the account associated with that user ID.
  • 57.
    Correct A requirement iscorrect when it is error-free Requirements can be checked for errors by stakeholders & Subject Matter Experts (SMEs) Requirements can be checked against source materials for errors Correctness is related to other attributes – ambiguity, Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 57 consistency, and verifiability Not Correct: The 802.3 Ethernet frame shall be 2048 bytes or less. Correct: The 802.3 Ethernet frame length shall be between 64 and 1518 bytes inclusive.
  • 58.
    Concise A requirement isconcise when it contains just the needed information, expressed in as few words as possible Requirements often lack conciseness because of: •Compound statements (multiple requirements in one) •Embedded rationale, examples, or design •Overly-complex grammar Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 58 Not concise: The outstanding software written by the talented development team shall display the current local time when selected by the intelligent and educated user from the well designed menu. Concise: The software shall display the current local time when selected by the user from the menu.
  • 59.
    Feasible A requirement isfeasible if there is at least one design and implementation for it Requirements may have been proven feasible in previous products Evolutionary or breakthrough requirements can be shown feasible at acceptable risk levels through analysis and prototyping Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 59 Not Feasible: The software shall allow an unlimited number of concurrent users. Feasible: The software shall allow a maximum of twenty concurrent users
  • 60.
    Necessary A requirement isnecessary when at least one of the following apply: • It is included to be market competitive • It can be traced to a need expressed by a customer, end user, or other stakeholder • It establishes a new product differentiator or usage model • It is dictated by business strategy, roadmaps, or sustainability needs Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 60 needs Not Necessary: The software shall be backwards compatible with all prior versions of Windows® Necessary: The software shall be backwards compatible with Windows® Vista SP2 and SP1, and Windows® XP SP3.
  • 61.
    Prioritized A requirement isprioritized when it ranked or ordered according to its importance. All requirements are in competition for limited resources. There are many possible ways to prioritize: • Customer Value, Development Risk, Value to the Company, Competitive Analysis, Cost, Effort, TTM Several scales can be used for prioritization: Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 61 Several scales can be used for prioritization: • Essential, Desirable, Nice to Have • High, Medium, Low • Other ordinal scales based on cost, value, etc. Not Prioritized: All requirements are critical and must be implemented. Prioritized: 80% of requirements High, 15% Medium and 5% Low.
  • 62.
    Unambiguous A requirement isunambiguous when it possesses a single interpretation Ambiguity is often dependent on the background of the reader Reduce ambiguity by defining terms, writing concisely, and testing understanding among the target audience Augment natural language with diagrams, tables and algorithms Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 62 Augment natural language with diagrams, tables and algorithms to remove ambiguity and enhance understanding Ambiguous: The software must install quickly. Unambiguous: When using unattended installation with standard options, the software shall install in under 3 minutes 80% of the time and under 4 minutes 100% of the time.
  • 63.
    Verifiable A requirement isverifiable if it can be proved that the requirement was correctly implemented Verification may come via demonstration, analysis, inspection, or testing. Requirements are often unverifiable because they are ambiguous, can’t be decided, or are not worth the cost to verify. Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 63 can’t be decided, or are not worth the cost to verify. Not Verifiable: The manual shall be easy to find on the CD-ROM. Verifiable: The manual shall be located in a folder named User Manual in the root directory of the CD-ROM.
  • 64.
    Consistent A requirement isconsistent when it does not conflict with any other requirements at any level Consistency is improved by referring to the original statement where needed instead of repeating statements. Inconsistent: Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 64 Inconsistent: #1: The user shall only be allowed to enter whole numbers. #2: The user shall be allowed to enter the time interval in seconds and tenths of a second. Consistent: #1: The user shall only be allowed to enter whole numbers except if the time interval is selected. #2: The user shall be allowed to enter the time interval in seconds and tenths of a second.
  • 65.
    Traceable A requirement istraceable if it is uniquely and persistently identified with a Tag Requirements can be traced to and from designs, tests, usage models, and other project artifacts. Traceability enables improved • Change impact assessment • Schedule and effort estimation Copyright © 2013 Intel Corporation. All Rights Reserved. No part of this presentation may be copied without the written permission of Intel Corporation. 65 • Schedule and effort estimation • Coverage analysis (requirements to tests, for example) • Scope management, prioritization, and decision making Not Traceable: The software shall prompt the user for the PIN. Traceable: Prompt_PIN: The software shall prompt the user for the PIN.