472:
probably constraints, and should be clearly articulated in the
Constraints section of the Requirements document. The contrasting view is that this perspective fails on two points. First, the perspective does not recognize that the user experience may be supported by requirements not perceivable by the user. For example, a requirement to present
435:(unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are avoided.
175:
development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement that the product be maintainable (a product requirement) often is addressed by imposing requirements to follow particular development styles (e.g.,
501:
Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent. However, they may be traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from
718:
Showing up late - e.g., Doing little or no effort in requirements elicitation prior to development. This may be due to thinking they will get the same benefit regardless of individual participation, or that there is no point if they can just insert demands at the testing stage and next spin, or the
692:
There are multiple taxonomies for requirements depending on which framework one is operating under. (For example, the stated standards of IEEE, vice IIBA or U.S. DoD approaches). Differing language and processes in different venues or casual speech can cause confusion and deviation from desired
679:
the alteration of requirements is allowed but if not adequately tracked or preceding steps (business goals then user requirements) are not throttled by additional oversight or handled as a cost and potential program failure, then requirements changes are easy and likely to happen. It is easy for
710:
New players wanting a do-over - e.g., The natural tendency of new people to want to change their predecessor's work to demonstrate their power or claims of value, such as a new CEO wanting to change the previous CEO's planning, including business goals, of something (such as a software solution)
552:
have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis
476:
information to the user may be supported by a requirement for an interface with an external third party business partner. The interface will be imperceptible to the user, though the presentation of information obtained through the interface certainly would not. Second, a constraint limits design
714:
Coloring outside the lines - e.g., Users wanting more control do not just input things that meet the requirements management definition of "user requirement" or priority level, but insert design details or favored vendor characteristic as user requirements or everything their office says as the
312:
Usually, detailed statements of capabilities or behavior required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include recruitment, role changes, education, migration of data from one
741:
enthusiasm ca. 1998 for 'Net-Ready' led to its mandate as Key
Performance Parameter from the Net-Ready office, outside the office defining requirements process and not consistent to that office's previously defined process, their definition of what a KPP was, or that some efforts might not be
471:
To the above some add
Externally Observable, that is, the requirement specifies a characteristic of the product that is externally observable or experienced by the user. Such advocates argue that requirements that specify internal architecture, design, implementation, or testing decisions are
589:
Requirements are usually written as a means for communication between the different stakeholders. This means that the requirements should be easy to understand both for normal users and for developers. One common way to document a requirement is stating what the system must do. Example: 'The
342:
The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally
174:
Product and process requirements are closely linked; a product requirement could be said to specify the automation required to support a process requirement while a process requirement could be said to specify the activities required to support a product requirement. For example, a maximum
287:
Usually detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. Examples include: reliability, testability, maintainability, availability. They are also known as
261:
Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the high-level business requirements and more detailed solution
701:
A process being run by humans is subject to human flaws in governance, where convenience or desires or politics may lead to exceptions or outright subversion of the process and deviations from the textbook way the process is supposed to proceed. Examples include:
443:
Many requirements represent a stakeholder-defined characteristic the absence of which will result in a major or even fatal deficiency. Others represent features that may be implemented if time and budget permits. The requirement must specify a level of importance.
477:
alternatives, whereas a requirement specifies design characteristics. To continue the example, a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture.
660:(short summaries fitting on an index card explaining one aspect of what the system should do), and considers it the developer's duty to directly ask the customer for clarification. Agile methodologies attempt to capture requirements in a series of automated
610:. For many projects, requirements are altered before the system is complete. This is partly due to the complexity of computer software and the fact that users don't know what they want before they see it. This characteristic of requirements has led to
627:
There are several competing views of what requirements are and how they should be managed and used. Two leading bodies in the industry are the IEEE and the IIBA. Both of these groups have different but similar definitions of what a requirement is.
114:
Requirement is a relatively broad concept that can describe any necessary or desired function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, user, or other stakeholder.
706:
Process with no rigor gets no respect - If exceptions or changes are common, such as the organization running it having little independence or power or not being reliable and transparent in records, it may lead to the overall process being
57:
is a condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear and often quantitative description of a condition to be satisfied by a material, design, product, or service.
711:
already in development, or a newly created office objects to current development of a project because they did not exist when user requirements were crafted, so they begin an effort to backtrack and re-baseline the project.
187:
Requirements are typically classified into types produced at different stages in a development progression, with the taxonomy depending on the overall model being used. For example, the following scheme was devised by the
497:
exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable.
485:
All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration, inspection, or review of design).
640:
and design performance
Requirements hinder creativity and design because designers become overly preoccupied with provided information. More generally, some research suggests that software requirements are an
272:
Usually detailed statements of capabilities, behavior, and information that the solution will need. Examples include formatting text, calculating a number, modulating a signal. They are also sometimes known as
189:
246:
High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities that an organization wants to realise or problems that they want to solve. Often stated in a
398:
Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate
American postal codes" and (2) "The postal code field must validate Canadian postal codes".
169:
prescribe activities to be performed by the developing organization. For instance, process requirements could specify the methodologies that must be followed, and constraints that the organization must
454:
The implementation of the requirement can be determined through basic possible methods: inspection, demonstration, test (instrumented) or analysis (to include validated modeling & simulation).
510:. Other non-functional requirements will trace to other system components and be verified at that level. For example, system reliability is often verified by analysis at the system level.
141:
A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
738:, attributed to F-15 program attempting to sabotage competition or individual offices putting in local desires eroding the concept of being lightweight and low cost.
545:(checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct).
873:. University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA. pp. 12–29.
636:
Many projects have succeeded with little or no agreement on requirements. Some evidence furthermore indicates that specifying requirements can decrease
901:
925:
652:
methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead,
460:
There are many more attributes to consider that contribute to the quality of requirements. If requirements are subject to rules of
229:
556:
There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they
378:
The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
1167:
1140:
1111:
1084:
1059:
954:
73:
990:
Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing
Architecturally Significant Requirements".
1038:, and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136
792:
573:
evolved as a way of overcoming these problems, by baselining requirements at a high-level, and elaborating detail on a
489:
Certain requirements, by their very structure, are not verifiable. These include requirements that say the system must
521:
Activities that lead to the derivation of the system or software requirements. Requirements engineering may involve a
1034:
Ralph, P., and Wand, Y. A Proposal for a Formal
Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P.,
878:
197:
1101:
645:
created by misrepresenting design decisions as requirements in situations where no real requirements are evident.
1355:
548:
Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous
409:
The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.
384:
148:
This definition is based on IEEE 610.12-1990: IEEE Standard
Glossary of Software Engineering Terminology.
17:
209:
Architectural requirements explain what has to be done by identifying the necessary integration of system
449:
282:
176:
43:
797:
782:
649:
570:
256:
77:
787:
1338:
468:
confirms that the requirement set satisfies the need (no more - and no less than what is required).
772:
762:
723:
Within the U.S. Department of
Defense process, some historical examples of requirements issues are
680:
requirement changes to occur faster than developers are able to produce work, and the effort to go
606:
Requirements generally change with time. Once defined and approved, requirements should fall under
530:
39:
777:
676:
611:
574:
534:
267:
104:
66:
1204:
Proceedings of the 5th
International Workshop on the Twin Peaks of Requirements and Architecture
464:(for example) then accuracy/correctness and validity/authorization are also worthy attributes.
929:
232:, which is defined as those requirements that have a measurable impact on a software system’s
100:
976:
394:, i.e., it does not contain conjunctions. E.g., "The postal code field must validate American
767:
757:
752:
542:
538:
241:
233:
138:
A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
65:
or spec is a set of requirements that is typically used by developers in the design stage of
30:
This article is about product and process development. For other kinds of requirements, see
503:
225:
108:
96:
8:
653:
549:
218:
204:
631:
1317:
1299:
1049:
1017:
964:
843:
92:
88:
1257:
1272:
1230:
1199:
1163:
1136:
1107:
1080:
1055:
950:
874:
560:
take a long time to produce - sometimes to the point of being obsolete once completed
522:
511:
1321:
1021:
926:"IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology"
1309:
1253:
1226:
1007:
999:
590:
contractor must deliver the product no later than xyz date.' Other methods include
507:
428:
80:, requirements are developed in parallel with design and implementation. With the
1157:
1035:
871:
ICSE '06 Proceedings of the 28th international conference on Software engineering
661:
81:
127:
has been in use in the software engineering community since at least the 1960s.
607:
461:
307:
1313:
946:
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0
1349:
803:
735:
728:
248:
62:
1290:
Ralph, Paul (2012). "The Illusion of Requirements in Software Development".
866:
834:
595:
465:
404:
368:
The requirement is fully stated in one place with no missing information.
144:
A documented representation of a condition or capability as in (1) or (2).
672:
422:
373:
50:
1003:
902:"1.3 Key Concepts - IIBA | International Institute of Business Analysis"
533:(gathering, understanding, reviewing, and articulating the needs of the
179:), style-guides, or a review/inspection process (process requirements).
27:
Condition that must be satisfied for an engineered work to be acceptable
1117:
809:
657:
637:
316:
35:
1012:
1051:
Software Requirements: Objects, Functions, and States, Second Edition
632:
Disputes regarding the necessity and effects of software requirements
591:
473:
210:
1244:
Purcell, A.; Gero, J. (1996). "Design and other types of fixation".
727:
the M-2 Bradley issues of casual requirements movement portrayed in
84:, requirements are completed before design or implementation start.
1277:
Proceedings of the International Conference on Software Engineering
814:
642:
506:
may be satisfied by replacing it with a process requirement to use
417:
The requirement has not been made obsolete by the passage of time.
326:
214:
1304:
1077:
IEEE Recommended Practice for Software Requirements Specifications
515:
432:
298:
719:
preference to be always right by waiting for post-work critique.
330:
193:
943:
Iiba; Analysis, International Institute of Business (2009).
1200:"Is Requirements Engineering Inherently Counterproductive?"
742:
appropriate or able to define what constituted 'Net-Ready'.
87:
Requirements are used in many engineering fields including
31:
1079:. Institute of Electrical and Electronics Engineers, Inc.
514:
with its complicated safety requirements must follow the
322:
734:
the F-16 growth from lightweight fighter concept of the
427:
The requirement is concisely stated without recourse to
1271:
Mohanani, Rahul; Ralph, Paul; Shreeve, Ben (May 2014).
337:
192:
in their Business Analysis Body of Knowledge (see also
867:"A view of 20th and 21st century software engineering"
151:
1074:
1068:
989:
1270:
656:
for example describes requirements informally using
687:
1217:Jansson, D.; Smith, S. (1991). "Design fixation".
944:
675:may occur from requirements moving over time. In
360:The requirement addresses one and only one thing.
156:Requirements can be said to relate to two fields:
132:Guide to the Business Analysis Body of Knowledge®
1347:
283:Quality-of-service (non-functional) requirements
134:version 2 from IIBA (BABOK), a requirement is:
69:and by testers in their verification process.
1099:
1197:
1216:
942:
190:International Institute of Business Analysis
163:prescribe properties of a system or product.
1279:. Hyderabad, India: IEEE. pp. 895–906.
1243:
1100:Stellman, Andrew; Greene, Jennifer (2005).
836:Form and Style of Standards, ASTM Blue Book
584:
601:
563:limit the implementation options available
333:(company, departmental, or project-level).
325:(Federal, State, Municipal, or Regional),
1303:
1198:Ralph, Paul; Mohanani, Rahul (May 2015).
1182:
1124:
1011:
1206:. Florence, Italy: IEEE. pp. 20–23.
308:Implementation (transition) requirements
230:architecturally significant requirements
182:
1149:
1130:
983:
14:
1348:
1041:
696:
622:
1289:
1155:
1133:Software Requirements, Second Edition
1047:
864:
667:
74:iterative and incremental development
338:Characteristics of good requirements
1103:Applied Software Project Management
152:Product versus process requirements
24:
793:Specification (technical standard)
268:Functional (solution) requirements
118:
25:
1367:
1332:
553:strives to address these issues.
1185:System Thinking, System Practice
1159:Effective Requirements Practices
688:Multiple requirements taxonomies
1340:Discovering System Requirements
1283:
1264:
1237:
1210:
1191:
1176:
1093:
480:
257:User (stakeholder) requirements
1106:. O'Reilly Media. p. 98.
1075:IEEE Computer Society (1998).
1028:
936:
918:
894:
858:
827:
13:
1:
1258:10.1016/S0142-694X(96)00023-3
820:
1231:10.1016/0142-694X(91)90003-F
42:. For historical usage, see
7:
746:
329:(terms and conditions), or
177:object-oriented programming
44:Spanish Requirement of 1513
10:
1372:
806:- prioritisation technique
783:Requirement prioritization
715:highest possible priority.
650:agile software development
205:Architectural requirements
78:agile software development
29:
1314:10.1007/s00766-012-0161-4
1183:Checkland, Peter (1999).
1131:Wiegers, Karl E. (2003).
788:Requirements traceability
617:
527:conceptual analysis phase
1292:Requirements Engineering
1156:Young, Ralph R. (2001).
773:Requirements elicitation
763:Requirements engineering
585:Documenting requirements
531:requirements elicitation
321:Requirements defined by
40:Intelligence requirement
1273:"Requirements Fixation"
1048:Davis, Alan M. (1993).
778:Requirements management
677:Requirements management
614:studies and practices.
612:requirements management
602:Changes in requirements
579:last responsible moment
317:Regulatory requirements
101:enterprise engineering
1356:Software requirements
865:Boehm, Barry (2006).
768:Requirements analysis
758:Software requirements
753:Business requirements
566:are costly to produce
539:requirements analysis
518:development process.
242:Business requirements
198:Types of requirements
183:Types of requirements
1187:. Chichester: Wiley.
932:on January 10, 2011.
226:software engineering
167:Process requirements
161:Product requirements
109:process optimization
97:software engineering
1135:. Microsoft Press.
1004:10.1109/MS.2012.174
697:Process corruptions
654:extreme programming
623:Competing standards
529:of the project and
440:Specify Importance
390:The requirement is
357:Unitary (Cohesive)
219:system architecture
105:product development
67:product development
1162:. Addison-Wesley.
975:has generic name (
844:ASTM International
668:Requirements creep
313:system to another.
228:, they are called
93:system engineering
89:engineering design
1169:978-0-201-70912-4
1142:978-0-7356-1879-4
1113:978-0-596-00948-9
1086:978-0-7381-0332-7
1061:978-0-13-805763-3
1054:. Prentice Hall.
956:978-0-9811292-1-1
523:feasibility study
512:Avionics software
458:
457:
130:According to the
16:(Redirected from
1363:
1326:
1325:
1307:
1287:
1281:
1280:
1268:
1262:
1261:
1241:
1235:
1234:
1214:
1208:
1207:
1195:
1189:
1188:
1180:
1174:
1173:
1153:
1147:
1146:
1128:
1122:
1121:
1116:. Archived from
1097:
1091:
1090:
1072:
1066:
1065:
1045:
1039:
1032:
1026:
1025:
1015:
987:
981:
980:
974:
970:
968:
960:
940:
934:
933:
928:. Archived from
922:
916:
915:
913:
912:
898:
892:
891:
889:
887:
862:
856:
855:
853:
851:
841:
831:
662:acceptance tests
648:Meanwhile, most
571:Agile approaches
508:pair programming
429:technical jargon
383:Non-Conjugated (
346:
345:
21:
1371:
1370:
1366:
1365:
1364:
1362:
1361:
1360:
1346:
1345:
1335:
1330:
1329:
1288:
1284:
1269:
1265:
1242:
1238:
1215:
1211:
1196:
1192:
1181:
1177:
1170:
1154:
1150:
1143:
1129:
1125:
1114:
1098:
1094:
1087:
1073:
1069:
1062:
1046:
1042:
1033:
1029:
988:
984:
972:
971:
962:
961:
957:
941:
937:
924:
923:
919:
910:
908:
900:
899:
895:
885:
883:
881:
863:
859:
849:
847:
839:
833:
832:
828:
823:
749:
699:
690:
670:
634:
625:
620:
604:
587:
483:
349:Characteristic
340:
290:characteristics
185:
154:
121:
119:Origins of term
82:waterfall model
47:
28:
23:
22:
15:
12:
11:
5:
1369:
1359:
1358:
1344:
1343:
1334:
1333:External links
1331:
1328:
1327:
1298:(3): 293–296.
1282:
1263:
1252:(4): 363–383.
1246:Design Studies
1236:
1219:Design Studies
1209:
1190:
1175:
1168:
1148:
1141:
1123:
1120:on 2015-02-09.
1112:
1092:
1085:
1067:
1060:
1040:
1036:Mylopoulos, J.
1027:
982:
955:
935:
917:
893:
879:
857:
825:
824:
822:
819:
818:
817:
812:
807:
801:
798:Shall and will
795:
790:
785:
780:
775:
770:
765:
760:
755:
748:
745:
744:
743:
739:
732:
721:
720:
716:
712:
708:
698:
695:
689:
686:
669:
666:
633:
630:
624:
621:
619:
616:
608:change control
603:
600:
586:
583:
568:
567:
564:
561:
482:
479:
462:data integrity
456:
455:
452:
446:
445:
441:
437:
436:
425:
419:
418:
415:
411:
410:
407:
401:
400:
388:
380:
379:
376:
370:
369:
366:
362:
361:
358:
354:
353:
350:
343:acknowledged.
339:
336:
335:
334:
319:
314:
310:
304:
303:
285:
279:
278:
270:
264:
263:
259:
253:
252:
244:
238:
237:
222:
207:
184:
181:
172:
171:
164:
153:
150:
146:
145:
142:
139:
120:
117:
26:
9:
6:
4:
3:
2:
1368:
1357:
1354:
1353:
1351:
1342:
1341:
1337:
1336:
1323:
1319:
1315:
1311:
1306:
1301:
1297:
1293:
1286:
1278:
1274:
1267:
1259:
1255:
1251:
1247:
1240:
1232:
1228:
1224:
1220:
1213:
1205:
1201:
1194:
1186:
1179:
1171:
1165:
1161:
1160:
1152:
1144:
1138:
1134:
1127:
1119:
1115:
1109:
1105:
1104:
1096:
1088:
1082:
1078:
1071:
1063:
1057:
1053:
1052:
1044:
1037:
1031:
1023:
1019:
1014:
1009:
1005:
1001:
997:
993:
992:IEEE Software
986:
978:
973:|first2=
966:
958:
952:
948:
947:
939:
931:
927:
921:
907:
903:
897:
882:
880:1-59593-375-1
876:
872:
868:
861:
845:
838:
837:
830:
826:
816:
813:
811:
808:
805:
804:MoSCoW Method
802:
799:
796:
794:
791:
789:
786:
784:
781:
779:
776:
774:
771:
769:
766:
764:
761:
759:
756:
754:
751:
750:
740:
737:
736:Fighter mafia
733:
730:
729:Pentagon Wars
726:
725:
724:
717:
713:
709:
705:
704:
703:
694:
685:
684:as a result.
683:
678:
674:
665:
663:
659:
655:
651:
646:
644:
639:
629:
615:
613:
609:
599:
597:
593:
582:
580:
576:
572:
565:
562:
559:
558:
557:
554:
551:
546:
544:
540:
536:
532:
528:
524:
519:
517:
513:
509:
505:
499:
496:
492:
487:
478:
475:
469:
467:
463:
453:
451:
448:
447:
442:
439:
438:
434:
430:
426:
424:
421:
420:
416:
413:
412:
408:
406:
403:
402:
397:
393:
389:
386:
382:
381:
377:
375:
372:
371:
367:
364:
363:
359:
356:
355:
351:
348:
347:
344:
332:
328:
324:
320:
318:
315:
311:
309:
306:
305:
302:
300:
295:
291:
286:
284:
281:
280:
276:
271:
269:
266:
265:
262:requirements.
260:
258:
255:
254:
250:
249:business case
245:
243:
240:
239:
235:
231:
227:
223:
220:
216:
212:
208:
206:
203:
202:
201:
199:
195:
191:
180:
178:
168:
165:
162:
159:
158:
157:
149:
143:
140:
137:
136:
135:
133:
128:
126:
116:
112:
110:
106:
102:
98:
94:
90:
85:
83:
79:
75:
70:
68:
64:
63:specification
59:
56:
52:
45:
41:
37:
33:
19:
1339:
1295:
1291:
1285:
1276:
1266:
1249:
1245:
1239:
1222:
1218:
1212:
1203:
1193:
1184:
1178:
1158:
1151:
1132:
1126:
1118:the original
1102:
1095:
1076:
1070:
1050:
1043:
1030:
998:(2): 38–45.
995:
991:
985:
945:
938:
930:the original
920:
909:. Retrieved
906:www.iiba.org
905:
896:
884:. Retrieved
870:
860:
848:. Retrieved
835:
829:
722:
700:
691:
681:
671:
658:user stories
647:
635:
626:
605:
596:user stories
588:
578:
575:just-in-time
569:
555:
547:
535:stakeholders
526:
520:
500:
494:
490:
488:
484:
481:Verification
470:
466:Traceability
459:
395:
391:
352:Explanation
341:
297:
293:
289:
275:capabilities
274:
234:architecture
221:of a system.
186:
173:
166:
160:
155:
147:
131:
129:
124:
122:
113:
86:
71:
60:
54:
48:
18:Requirements
1225:(1): 3–11.
673:Scope creep
423:Unambiguous
294:constraints
213:and system
125:requirement
55:requirement
51:engineering
1013:10344/3061
911:2016-09-25
886:January 2,
821:References
810:User Story
800:- phrasing
638:creativity
550:inspection
450:Verifiable
374:Consistent
36:Obligation
1305:1304.0116
965:cite book
850:5 January
693:process.
682:backwards
592:use cases
504:backdoors
405:Traceable
365:Complete
327:contracts
211:structure
123:The term
1350:Category
1322:11499083
1022:17399565
815:Use Case
747:See also
707:ignored.
643:illusion
543:analysis
474:geocoded
433:acronyms
414:Current
331:policies
217:, i.e.,
215:behavior
76:such as
581:basis.
516:DO-178B
299:ilities
296:or the
1320:
1166:
1139:
1110:
1083:
1058:
1020:
953:
877:
846:. 2012
618:Issues
537:) and
495:always
392:atomic
385:Atomic
107:, and
38:, and
1318:S2CID
1300:arXiv
1018:S2CID
840:(PDF)
525:or a
491:never
194:FURPS
170:obey.
72:With
1164:ISBN
1137:ISBN
1108:ISBN
1081:ISBN
1056:ISBN
977:help
951:ISBN
888:2013
875:ISBN
852:2013
594:and
323:laws
196:and
53:, a
32:Need
1310:doi
1254:doi
1227:doi
1008:hdl
1000:doi
577:or
493:or
396:and
224:In
200:).
111:.
49:In
1352::
1316:.
1308:.
1296:18
1294:.
1275:.
1250:17
1248:.
1223:12
1221:.
1202:.
1016:.
1006:.
996:30
994:.
969::
967:}}
963:{{
949:.
904:.
869:.
842:.
664:.
598:.
541:,
431:,
387:)
292:,
103:,
99:,
95:,
91:,
61:A
34:,
1324:.
1312::
1302::
1260:.
1256::
1233:.
1229::
1172:.
1145:.
1089:.
1064:.
1024:.
1010::
1002::
979:)
959:.
914:.
890:.
854:.
731:;
301:.
277:.
251:.
236:.
46:.
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.