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