SlideShare una empresa de Scribd logo
1 de 3
Descargar para leer sin conexión
Appendix C:  How to Write a Good Requirement

Use of Correct Terms
Shall = requirement
zz Will = facts or declaration of purpose
zz Should = goal
zz

Editorial Checklist
Personnel Requirement
1.	 The requirement is in the form “responsible party shall perform such and such.” In other words, use the active,
rather than the passive voice. A requirement must state who shall (do, perform, provide, weigh, or other verb) followed by a description of what must be performed.

Product Requirement
1.	 The requirement is in the form “product ABC shall XYZ.” A requirement must state “The product shall” (do, perform, provide, weigh, or other verb) followed by a description of what must be done.
2.	 The requirement uses consistent terminology to refer to the product and its lower level entities.
3.	 Complete with tolerances for qualitative/performance values (e.g., less than, greater than or equal to, plus or minus,
3 sigma root sum squares).
4.	 Is the requirement free of implementation? (Requirements should state WHAT is needed, NOT HOW to provide
it; i.e., state the problem not the solution. Ask, “Why do you need the requirement?” The answer may point to the
real requirement.)
5.	 Free of descriptions of operations? (Is this a need the product must satisfy or an activity involving the product? Sentences like “The operator shall…” are almost always operational statements not requirements.)

Example Product Requirements
The system shall operate at a power level of…
The software shall acquire data from the…
zz The structure shall withstand loads of…
zz The hardware shall have a mass of…
zz
zz

General Goodness Checklist
1.	 The requirement is grammatically correct.
2.	 The requirement is free of typos, misspellings, and punctuation errors.
3.	 The requirement complies with the project’s template and style rules.
4.	 The requirement is stated positively (as opposed to negatively, i.e., “shall not”).
5.	 The use of “To Be Determined” (TBD) values should be minimized. It is better to use a best estimate for a value
and mark it “To Be Resolved” (TBR) with the rationale along with what must be done to eliminate the TBR, who is
responsible for its elimination, and by when it must be eliminated.
6.	 The requirement is accompanied by an intelligible rationale, including any assumptions. Can you validate (concur
with) the assumptions? Assumptions must be confirmed before baselining.
7.	 The requirement is located in the proper section of the document (e.g., not in an appendix).
NASA Systems Engineering Handbook    279
Appendix C:  How to Write a Good Requirement

Requirements Validation Checklist
Clarity
1.	 Are the requirements clear and unambiguous? (Are all aspects of the requirement understandable and not subject
to misinterpretation? Is the requirement free from indefinite pronouns (this, these) and ambiguous terms (e.g., “as
appropriate,” “etc.,” “and/or,” “but not limited to”)?)
2.	 Are the requirements concise and simple?
3.	 Do the requirements express only one thought per requirement statement, a standalone statement as opposed to
multiple requirements in a single statement, or a paragraph that contains both requirements and rationale?
4.	 Does the requirement statement have one subject and one predicate?

Completeness
1.	 Are requirements stated as completely as possible? Have all incomplete requirements been captured as TBDs or
TBRs and a complete listing of them maintained with the requirements?
2.	 Are any requirements missing? For example have any of the following requirements areas been overlooked: functional, performance, interface, environment (development, manufacturing, test, transport, storage, operations),
facility (manufacturing, test, storage, operations), transportation (among areas for manufacturing, assembling, delivery points, within storage facilities, loading), training, personnel, operability, safety, security, appearance and
physical characteristics, and design.
3.	 Have all assumptions been explicitly stated?

Compliance
1.	 Are all requirements at the correct level (e.g., system, segment, element, subsystem)?
2.	 Are requirements free of implementation specifics? (Requirements should state what is needed, not how to provide it.)
3.	 Are requirements free of descriptions of operations? (Don’t mix operation with requirements: update the ConOps
instead.)

Consistency
1.	 Are the requirements stated consistently without contradicting themselves or the requirements of related systems?
2.	 Is the terminology consistent with the user and sponsor’s terminology? With the project glossary?
3.	 Is the terminology consistently used through out the document?
4.	 Are the key terms included in the project’s glossary?

Traceability
1.	 Are all requirements needed? Is each requirement necessary to meet the parent requirement? Is each requirement
a needed function or characteristic? Distinguish between needs and wants. If it is not necessary, it is not a requirement. Ask, “What is the worst that could happen if the requirement was not included?”
2.	 Are all requirements (functions, structures, and constraints) bidirectionally traceable to higher level requirements
or mission or system-of-interest scope (i.e., need(s), goals, objectives, constraints, or concept of operations)?
3.	 Is each requirement stated in such a manner that it can be uniquely referenced (e.g., each requirement is uniquely
numbered) in subordinate documents?

Correctness
1.	 Is each requirement correct?
2.	 Is each stated assumption correct? Assumptions must be confirmed before the document can be baselined.
3.	 Are the requirements technically feasible?
280    NASA Systems Engineering Handbook
Appendix C:  How to Write a Good Requirement

Functionality
1.	 Are all described functions necessary and together sufficient to meet mission and system goals and objectives?

Performance
1.	 Are all required performance specifications and margins listed (e.g., consider timing, throughput, storage size, latency, accuracy and precision)?
2.	 Is each performance requirement realistic?
3.	 Are the tolerances overly tight? Are the tolerances defendable and cost-effective? Ask, “What is the worst thing that
could happen if the tolerance was doubled or tripled?”

Interfaces
1.	 Are all external interfaces clearly defined?
2.	 Are all internal interfaces clearly defined?
3.	 Are all interfaces necessary, sufficient, and consistent with each other?

Maintainability
1.	 Have the requirements for system maintainability been specified in a measurable, verifiable manner?
2.	 Are requirements written so that ripple effects from changes are minimized (i.e., requirements are as weakly coupled as possible)?

Reliability
1.	 Are clearly defined, measurable, and verifiable reliability requirements specified?
2.	 Are there error detection, reporting, handling, and recovery requirements?
3.	 Are undesired events (e.g., single event upset, data loss or scrambling, operator error) considered and their required responses specified?
4.	 Have assumptions about the intended sequence of functions been stated? Are these sequences required?
5.	 Do these requirements adequately address the survivability after a software or hardware fault of the system from the
point of view of hardware, software, operations, personnel and procedures?

Verifiability/Testability
1.	 Can the system be tested, demonstrated, inspected, or analyzed to show that it satisfies requirements? Can this be
done at the level of the system at which the requirement is stated? Does a means exist to measure the accomplishment of the requirement and verify compliance? Can the criteria for verification be stated?
2.	 Are the requirements stated precisely to facilitate specification of system test success criteria and requirements?
3.	 Are the requirements free of unverifiable terms (e.g., flexible, easy, sufficient, safe, ad hoc, adequate, accommodate,
user-friendly, usable, when required, if required, appropriate, fast, portable, light-weight, small, large, maximize,
minimize, sufficient, robust, quickly, easily, clearly, other “ly” words, other “ize” words)?

Data Usage
1.	 Where applicable, are “don’t care” conditions truly “don’t care”? (“Don’t care” values identify cases when the value
of a condition or flag is irrelevant, even though the value may be important for other cases.) Are “don’t care” conditions values explicitly stated? (Correct identification of “don’t care” values may improve a design’s portability.)

NASA Systems Engineering Handbook    281

Más contenido relacionado

Destacado

Mpeg Advisor Presentation Power Point[1]
Mpeg Advisor Presentation Power Point[1]Mpeg Advisor Presentation Power Point[1]
Mpeg Advisor Presentation Power Point[1]maryannstaff
 
A3 examen et corrige education civique 2012 1 am t2
A3 examen et corrige education civique 2012 1 am t2A3 examen et corrige education civique 2012 1 am t2
A3 examen et corrige education civique 2012 1 am t2Ahmed Mesellem
 
LaunchPad Curriculum Module
LaunchPad Curriculum ModuleLaunchPad Curriculum Module
LaunchPad Curriculum Moduleacastle08
 
Finno-Ugric Capitals of Culture @ UN in Geneva
Finno-Ugric Capitals of Culture @ UN in GenevaFinno-Ugric Capitals of Culture @ UN in Geneva
Finno-Ugric Capitals of Culture @ UN in GenevaOliver Loode
 
Ghế rung- Ghế rung ăn bột cho bé
Ghế rung- Ghế rung ăn bột cho béGhế rung- Ghế rung ăn bột cho bé
Ghế rung- Ghế rung ăn bột cho béShop Trẻ Thơ
 
Pensamiento logico 1 escaner
Pensamiento logico 1 escanerPensamiento logico 1 escaner
Pensamiento logico 1 escaneraamayac01
 
A4 examen et corrige edu isl 2013 1-am t2
A4 examen et corrige edu isl 2013 1-am t2A4 examen et corrige edu isl 2013 1-am t2
A4 examen et corrige edu isl 2013 1-am t2Ahmed Mesellem
 
Dasar dasar teori kuantum klasik
Dasar dasar teori kuantum klasikDasar dasar teori kuantum klasik
Dasar dasar teori kuantum klasikMuhammad Syahida
 
Fashion Website Research
Fashion Website ResearchFashion Website Research
Fashion Website Researchjoelyp
 
Ip and-software-patents-august-2014
Ip and-software-patents-august-2014Ip and-software-patents-august-2014
Ip and-software-patents-august-2014nghia le trung
 
Foss in-e gov-august-2014
Foss in-e gov-august-2014Foss in-e gov-august-2014
Foss in-e gov-august-2014nghia le trung
 
Cute cats and dogs
Cute cats and dogsCute cats and dogs
Cute cats and dogsgmyachtsman
 
Как провалить выступление
Как провалить выступлениеКак провалить выступление
Как провалить выступлениеТатьяна Кущук
 
Ehr034 instalações prediais hidráulico -sanitário
Ehr034   instalações prediais hidráulico -sanitárioEhr034   instalações prediais hidráulico -sanitário
Ehr034 instalações prediais hidráulico -sanitárioEulalia Cristina
 

Destacado (19)

Podstawy projektowania do Internetu - zdjęcia
Podstawy projektowania do Internetu - zdjęciaPodstawy projektowania do Internetu - zdjęcia
Podstawy projektowania do Internetu - zdjęcia
 
Mpeg Advisor Presentation Power Point[1]
Mpeg Advisor Presentation Power Point[1]Mpeg Advisor Presentation Power Point[1]
Mpeg Advisor Presentation Power Point[1]
 
A3 examen et corrige education civique 2012 1 am t2
A3 examen et corrige education civique 2012 1 am t2A3 examen et corrige education civique 2012 1 am t2
A3 examen et corrige education civique 2012 1 am t2
 
LaunchPad Curriculum Module
LaunchPad Curriculum ModuleLaunchPad Curriculum Module
LaunchPad Curriculum Module
 
15 compo
15 compo15 compo
15 compo
 
Finno-Ugric Capitals of Culture @ UN in Geneva
Finno-Ugric Capitals of Culture @ UN in GenevaFinno-Ugric Capitals of Culture @ UN in Geneva
Finno-Ugric Capitals of Culture @ UN in Geneva
 
Ghế rung- Ghế rung ăn bột cho bé
Ghế rung- Ghế rung ăn bột cho béGhế rung- Ghế rung ăn bột cho bé
Ghế rung- Ghế rung ăn bột cho bé
 
Pensamiento logico 1 escaner
Pensamiento logico 1 escanerPensamiento logico 1 escaner
Pensamiento logico 1 escaner
 
Al
AlAl
Al
 
A4 examen et corrige edu isl 2013 1-am t2
A4 examen et corrige edu isl 2013 1-am t2A4 examen et corrige edu isl 2013 1-am t2
A4 examen et corrige edu isl 2013 1-am t2
 
Dasar dasar teori kuantum klasik
Dasar dasar teori kuantum klasikDasar dasar teori kuantum klasik
Dasar dasar teori kuantum klasik
 
How are you
How are youHow are you
How are you
 
Fashion Website Research
Fashion Website ResearchFashion Website Research
Fashion Website Research
 
Ip and-software-patents-august-2014
Ip and-software-patents-august-2014Ip and-software-patents-august-2014
Ip and-software-patents-august-2014
 
Foss in-e gov-august-2014
Foss in-e gov-august-2014Foss in-e gov-august-2014
Foss in-e gov-august-2014
 
Cute cats and dogs
Cute cats and dogsCute cats and dogs
Cute cats and dogs
 
Render terreno
Render terrenoRender terreno
Render terreno
 
Как провалить выступление
Как провалить выступлениеКак провалить выступление
Как провалить выступление
 
Ehr034 instalações prediais hidráulico -sanitário
Ehr034   instalações prediais hidráulico -sanitárioEhr034   instalações prediais hidráulico -sanitário
Ehr034 instalações prediais hidráulico -sanitário
 

Similar a App c howtowritea_goodrequirement

CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docxCMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docxmary772
 
AJRA Test Strategy Discussion
AJRA Test Strategy DiscussionAJRA Test Strategy Discussion
AJRA Test Strategy Discussionajrhem
 
Requirement Engineering for Dependable Systems
Requirement Engineering for Dependable SystemsRequirement Engineering for Dependable Systems
Requirement Engineering for Dependable SystemsKamalika Guha Roy
 
Test analysis identifying test conditions
Test analysis identifying test conditionsTest analysis identifying test conditions
Test analysis identifying test conditionsromi wisarta
 
Guidelines to Understanding Design of Experiment and Reliability Prediction
Guidelines to Understanding Design of Experiment and Reliability PredictionGuidelines to Understanding Design of Experiment and Reliability Prediction
Guidelines to Understanding Design of Experiment and Reliability Predictionijsrd.com
 
201008 Software Testing Notes (part 1/2)
201008 Software Testing Notes (part 1/2)201008 Software Testing Notes (part 1/2)
201008 Software Testing Notes (part 1/2)Javier Gonzalez-Sanchez
 
Manual testing real time questions by subbu
Manual testing real time questions by subbuManual testing real time questions by subbu
Manual testing real time questions by subbupalla subrahmanyam
 
Tool support for testing
Tool support for testingTool support for testing
Tool support for testingelvira munanda
 
Requirements Engineering
Requirements EngineeringRequirements Engineering
Requirements EngineeringEhsan Elahi
 
Ôn tập kiến thức ISTQB
Ôn tập kiến thức ISTQBÔn tập kiến thức ISTQB
Ôn tập kiến thức ISTQBJenny Nguyen
 
Question ISTQB foundation 3
Question ISTQB foundation 3Question ISTQB foundation 3
Question ISTQB foundation 3Jenny Nguyen
 
Testing 3 test design techniques
Testing 3 test design techniquesTesting 3 test design techniques
Testing 3 test design techniquesMini Marsiah
 
52892006 manual-testing-real-time
52892006 manual-testing-real-time52892006 manual-testing-real-time
52892006 manual-testing-real-timeSunil Pandey
 
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...Dhivyaa C.R
 
Testing throughout the software life cycle (test types)
Testing throughout the software life cycle (test types)Testing throughout the software life cycle (test types)
Testing throughout the software life cycle (test types)tyas setyo
 
Software requirement specification
Software requirement specificationSoftware requirement specification
Software requirement specificationshiprashakya2
 
Test analysis: indentifying test conditions
Test analysis: indentifying test conditionsTest analysis: indentifying test conditions
Test analysis: indentifying test conditionsJeri Handika
 

Similar a App c howtowritea_goodrequirement (20)

CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docxCMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
CMGT410 v19Business Requirements TemplateCMGT410 v19Page 2.docx
 
AJRA Test Strategy Discussion
AJRA Test Strategy DiscussionAJRA Test Strategy Discussion
AJRA Test Strategy Discussion
 
Requirement Engineering for Dependable Systems
Requirement Engineering for Dependable SystemsRequirement Engineering for Dependable Systems
Requirement Engineering for Dependable Systems
 
Test analysis identifying test conditions
Test analysis identifying test conditionsTest analysis identifying test conditions
Test analysis identifying test conditions
 
Guidelines to Understanding Design of Experiment and Reliability Prediction
Guidelines to Understanding Design of Experiment and Reliability PredictionGuidelines to Understanding Design of Experiment and Reliability Prediction
Guidelines to Understanding Design of Experiment and Reliability Prediction
 
201008 Software Testing Notes (part 1/2)
201008 Software Testing Notes (part 1/2)201008 Software Testing Notes (part 1/2)
201008 Software Testing Notes (part 1/2)
 
Manual testing real time questions by subbu
Manual testing real time questions by subbuManual testing real time questions by subbu
Manual testing real time questions by subbu
 
Tool support for testing
Tool support for testingTool support for testing
Tool support for testing
 
Requirements Engineering
Requirements EngineeringRequirements Engineering
Requirements Engineering
 
Ôn tập kiến thức ISTQB
Ôn tập kiến thức ISTQBÔn tập kiến thức ISTQB
Ôn tập kiến thức ISTQB
 
Question ISTQB foundation 3
Question ISTQB foundation 3Question ISTQB foundation 3
Question ISTQB foundation 3
 
SRS.pdf
SRS.pdfSRS.pdf
SRS.pdf
 
Testing 3 test design techniques
Testing 3 test design techniquesTesting 3 test design techniques
Testing 3 test design techniques
 
52892006 manual-testing-real-time
52892006 manual-testing-real-time52892006 manual-testing-real-time
52892006 manual-testing-real-time
 
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
Quality attributes in software architecture by Dr.C.R.Dhivyaa, Assistant prof...
 
Test analysis
Test analysisTest analysis
Test analysis
 
Testing overview
Testing overviewTesting overview
Testing overview
 
Testing throughout the software life cycle (test types)
Testing throughout the software life cycle (test types)Testing throughout the software life cycle (test types)
Testing throughout the software life cycle (test types)
 
Software requirement specification
Software requirement specificationSoftware requirement specification
Software requirement specification
 
Test analysis: indentifying test conditions
Test analysis: indentifying test conditionsTest analysis: indentifying test conditions
Test analysis: indentifying test conditions
 

Último

The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 

Último (20)

The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
20230104 - machine vision
20230104 - machine vision20230104 - machine vision
20230104 - machine vision
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 

App c howtowritea_goodrequirement

  • 1. Appendix C:  How to Write a Good Requirement Use of Correct Terms Shall = requirement zz Will = facts or declaration of purpose zz Should = goal zz Editorial Checklist Personnel Requirement 1. The requirement is in the form “responsible party shall perform such and such.” In other words, use the active, rather than the passive voice. A requirement must state who shall (do, perform, provide, weigh, or other verb) followed by a description of what must be performed. Product Requirement 1. The requirement is in the form “product ABC shall XYZ.” A requirement must state “The product shall” (do, perform, provide, weigh, or other verb) followed by a description of what must be done. 2. The requirement uses consistent terminology to refer to the product and its lower level entities. 3. Complete with tolerances for qualitative/performance values (e.g., less than, greater than or equal to, plus or minus, 3 sigma root sum squares). 4. Is the requirement free of implementation? (Requirements should state WHAT is needed, NOT HOW to provide it; i.e., state the problem not the solution. Ask, “Why do you need the requirement?” The answer may point to the real requirement.) 5. Free of descriptions of operations? (Is this a need the product must satisfy or an activity involving the product? Sentences like “The operator shall…” are almost always operational statements not requirements.) Example Product Requirements The system shall operate at a power level of… The software shall acquire data from the… zz The structure shall withstand loads of… zz The hardware shall have a mass of… zz zz General Goodness Checklist 1. The requirement is grammatically correct. 2. The requirement is free of typos, misspellings, and punctuation errors. 3. The requirement complies with the project’s template and style rules. 4. The requirement is stated positively (as opposed to negatively, i.e., “shall not”). 5. The use of “To Be Determined” (TBD) values should be minimized. It is better to use a best estimate for a value and mark it “To Be Resolved” (TBR) with the rationale along with what must be done to eliminate the TBR, who is responsible for its elimination, and by when it must be eliminated. 6. The requirement is accompanied by an intelligible rationale, including any assumptions. Can you validate (concur with) the assumptions? Assumptions must be confirmed before baselining. 7. The requirement is located in the proper section of the document (e.g., not in an appendix). NASA Systems Engineering Handbook    279
  • 2. Appendix C:  How to Write a Good Requirement Requirements Validation Checklist Clarity 1. Are the requirements clear and unambiguous? (Are all aspects of the requirement understandable and not subject to misinterpretation? Is the requirement free from indefinite pronouns (this, these) and ambiguous terms (e.g., “as appropriate,” “etc.,” “and/or,” “but not limited to”)?) 2. Are the requirements concise and simple? 3. Do the requirements express only one thought per requirement statement, a standalone statement as opposed to multiple requirements in a single statement, or a paragraph that contains both requirements and rationale? 4. Does the requirement statement have one subject and one predicate? Completeness 1. Are requirements stated as completely as possible? Have all incomplete requirements been captured as TBDs or TBRs and a complete listing of them maintained with the requirements? 2. Are any requirements missing? For example have any of the following requirements areas been overlooked: functional, performance, interface, environment (development, manufacturing, test, transport, storage, operations), facility (manufacturing, test, storage, operations), transportation (among areas for manufacturing, assembling, delivery points, within storage facilities, loading), training, personnel, operability, safety, security, appearance and physical characteristics, and design. 3. Have all assumptions been explicitly stated? Compliance 1. Are all requirements at the correct level (e.g., system, segment, element, subsystem)? 2. Are requirements free of implementation specifics? (Requirements should state what is needed, not how to provide it.) 3. Are requirements free of descriptions of operations? (Don’t mix operation with requirements: update the ConOps instead.) Consistency 1. Are the requirements stated consistently without contradicting themselves or the requirements of related systems? 2. Is the terminology consistent with the user and sponsor’s terminology? With the project glossary? 3. Is the terminology consistently used through out the document? 4. Are the key terms included in the project’s glossary? Traceability 1. Are all requirements needed? Is each requirement necessary to meet the parent requirement? Is each requirement a needed function or characteristic? Distinguish between needs and wants. If it is not necessary, it is not a requirement. Ask, “What is the worst that could happen if the requirement was not included?” 2. Are all requirements (functions, structures, and constraints) bidirectionally traceable to higher level requirements or mission or system-of-interest scope (i.e., need(s), goals, objectives, constraints, or concept of operations)? 3. Is each requirement stated in such a manner that it can be uniquely referenced (e.g., each requirement is uniquely numbered) in subordinate documents? Correctness 1. Is each requirement correct? 2. Is each stated assumption correct? Assumptions must be confirmed before the document can be baselined. 3. Are the requirements technically feasible? 280    NASA Systems Engineering Handbook
  • 3. Appendix C:  How to Write a Good Requirement Functionality 1. Are all described functions necessary and together sufficient to meet mission and system goals and objectives? Performance 1. Are all required performance specifications and margins listed (e.g., consider timing, throughput, storage size, latency, accuracy and precision)? 2. Is each performance requirement realistic? 3. Are the tolerances overly tight? Are the tolerances defendable and cost-effective? Ask, “What is the worst thing that could happen if the tolerance was doubled or tripled?” Interfaces 1. Are all external interfaces clearly defined? 2. Are all internal interfaces clearly defined? 3. Are all interfaces necessary, sufficient, and consistent with each other? Maintainability 1. Have the requirements for system maintainability been specified in a measurable, verifiable manner? 2. Are requirements written so that ripple effects from changes are minimized (i.e., requirements are as weakly coupled as possible)? Reliability 1. Are clearly defined, measurable, and verifiable reliability requirements specified? 2. Are there error detection, reporting, handling, and recovery requirements? 3. Are undesired events (e.g., single event upset, data loss or scrambling, operator error) considered and their required responses specified? 4. Have assumptions about the intended sequence of functions been stated? Are these sequences required? 5. Do these requirements adequately address the survivability after a software or hardware fault of the system from the point of view of hardware, software, operations, personnel and procedures? Verifiability/Testability 1. Can the system be tested, demonstrated, inspected, or analyzed to show that it satisfies requirements? Can this be done at the level of the system at which the requirement is stated? Does a means exist to measure the accomplishment of the requirement and verify compliance? Can the criteria for verification be stated? 2. Are the requirements stated precisely to facilitate specification of system test success criteria and requirements? 3. Are the requirements free of unverifiable terms (e.g., flexible, easy, sufficient, safe, ad hoc, adequate, accommodate, user-friendly, usable, when required, if required, appropriate, fast, portable, light-weight, small, large, maximize, minimize, sufficient, robust, quickly, easily, clearly, other “ly” words, other “ize” words)? Data Usage 1. Where applicable, are “don’t care” conditions truly “don’t care”? (“Don’t care” values identify cases when the value of a condition or flag is irrelevant, even though the value may be important for other cases.) Are “don’t care” conditions values explicitly stated? (Correct identification of “don’t care” values may improve a design’s portability.) NASA Systems Engineering Handbook    281