968:. This documentation may be used by developers, testers, and also end-users. Today, a lot of high-end applications are seen in the fields of power, energy, transportation, networks, aerospace, safety, security, industry automation, and a variety of other domains. Technical documentation has become important within such organizations as the basic and advanced level of information may change over a period of time with architecture changes. There is evidence that the existence of good code documentation actually reduces maintenance costs for software.
804:
mechanical equipment), more formal requirements documentation is often required. If the software is expected to live for only a month or two (e.g., very small mobile phone applications developed specifically for a certain campaign) very little requirements documentation may be needed. If the software is a first release that is later built upon, requirements documentation is very helpful when managing the change of the software and verifying that nothing has been broken in the software when it is modified.
2172:
25:
2162:
792:
difficult to know how to document requirements considering the variety of people who shall read and use the documentation. Thus, requirements documentation is often incomplete (or non-existent). Without proper requirements documentation, software changes become more difficult — and therefore more error prone (decreased
838:
being second derivative, and code documents being first). Very little in the architecture documents is specific to the code itself. These documents do not describe how to program a particular routine, or even why that particular routine exists in the form that it does, but instead merely lays out the
1093:
are usually part of several software development activities, such as code walks and porting, where third-party source code is analysed in a functional way. Annotations can therefore help the developer during any stage of software development where a formal documentation system would hinder progress.
860:
A very important part of the design document in enterprise software development is the
Database Design Document (DDD). It contains Conceptual, Logical, and Physical Design Elements. The DDD includes the formal information that the people who interact with the database need. The purpose of preparing
1156:
approach, where chapters or sections concentrate on one particular area of interest, is of more general use to an intermediate user. Some authors prefer to convey their ideas through a knowledge based article to facilitate the user needs. This approach is usually practiced by a dynamic industry,
791:
The variation and complexity of requirement documentation make it a proven challenge. Requirements may be implicit and hard to uncover. It is difficult to know exactly how much and what kind of documentation is needed and how much can be left to the architecture and design documentation, and it is
1119:
Typically, the user documentation describes each feature of the program, and assists the user in realizing these features. It is very important for user documents to not be confusing, and for them to be up to date. User documents do not need to be organized in any particular way, but it is very
856:
to dazzle the reader), and most importantly is impartial. It should honestly and clearly explain the costs of whatever solution it offers as best. The objective of a trade study is to devise the best solution, rather than to push a particular point of view. It is perfectly acceptable to state no
807:
Traditionally, requirements are specified in requirements documents (e.g. using word processing applications and spreadsheet applications). To manage the increased complexity and changing nature of requirements documentation (and software documentation in general), database-centric systems and
803:
of the software. If the software is very complex or developed by many people (e.g., mobile phone software), requirements can help better communicate what to achieve. If the software is safety-critical and can have a negative impact on human life (e.g., nuclear power systems, medical equipment,
1256:
A survey among software engineering experts revealed, however, that documentation is by no means considered unnecessary in agile development. Yet it is acknowledged that there are motivational problems in development, and that documentation methods tailored to agile development (e.g. through
1167:
The final type of organizing principle is one in which commands or tasks are simply listed alphabetically or logically grouped, often via cross-referenced indexes. This latter approach is of greater use to advanced users who know exactly what sort of information they are looking
728:
to communicate how the software functions or how it is intended to operate. It is also used as an agreement or as the foundation for agreement on what the software will do. Requirements are produced and consumed by everyone involved in the production of software, including:
852:, code, design, or even architectural level. It will outline what the situation is, describe one or more alternatives, and enumerate the pros and cons of each. A good trade study document is heavy on research, expresses its idea clearly (without relying heavily on obtuse
1320:: Encourages contributions from various team members, including developers, testers, and product managers.Combining Docs as Code with Agile methodologies creates a robust framework for maintaining high-quality, up-to-date documentation. Here's how to integrate the two:
839:
general requirements that would motivate the existence of such a routine. A good architecture document is short on details but thick on explanation. It may suggest approaches for lower level design, but leave the actual exploration trade studies to other documents.
963:
documentation) to be thorough, but not so verbose that it becomes overly time-consuming or difficult to maintain them. Various how-to and overview documentation guides are commonly found specific to the software application or software product being documented by
1181:
that gives only reference information on commands or menu items. The job of tutoring new users or helping more experienced users get the most out of a program is left to private publishers, who are often given significant assistance by the software developer.
821:
with accompanying acceptance criteria. User stories are typically part of a feature, or an epic, which is a broader functionality or set of related functionalities that deliver a specific value to the user based on the business requirements.
1190:
Like other forms of technical documentation, good user documentation benefits from an organized process of development. In the case of user documentation, the process as it commonly occurs in industry consists of five steps:
1172:
A common complaint among users regarding software documentation is that only one of these three approaches was taken to the near-exclusion of the other two. It is common to limit provided software documentation for
1085:
Elucidative
Programming is the result of practical applications of Literate Programming in real programming contexts. The Elucidative paradigm proposes that source code and documentation be stored separately.
1042:), the programmer can write it while referring to the code, and use the same tools used to create the source code to make the documentation. This makes it much easier to keep the documentation up-to-date.
1252:
advocates valuing "working software over comprehensive documentation", which could be interpreted cynically as "We want to spend all our time coding. Remember, real programmers don't write documentation."
857:
conclusion, or to conclude that none of the alternatives are sufficiently better than the baseline to warrant a change. It should be approached as a scientific endeavor, not as a marketing technique.
1225:
For many applications it is necessary to have some promotional materials to encourage casual observers to spend more time learning about the product. This form of documentation has three purposes:
1437:"RH Earle, MA Rosso, KE Alexander (2015) User preferences of software documentation genres. Proceedings of the 33rd Annual International Conference on the Design of Communication (ACM SIGDOC)"
941:
It is very important to include all information that is to be used by all actors in the scene. It is also very important to update the documents as any change occurs in the database as well.
1038:
The idea of auto-generating documentation is attractive to programmers for various reasons. For example, because it is extracted from the source code itself (for example, through
675:
or is embedded in the source code. The documentation either explains how the software operates or how to use it, and may mean different things to people in different roles.
1128:
are very well accomplished towards writing good user documents as they would be well aware of the software architecture and programming techniques used. See also
1116:, the code documents and user documents could in some cases be effectively equivalent and worth conjoining, but for a general application this is not often true.
688:– Statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what will be or has been implemented.
1135:
User documentation can be produced in a variety of online and print formats. However, there are three broad ways in which user documentation can be organized.
655:
1045:
A possible downside is that only programmers can edit this kind of documentation, and it depends on them to refresh the output (for example, by running a
691:
Architecture/Design – Overview of software. Includes relations to an environment and construction principles to be used in design of software components.
609:
1124:. Consistency and simplicity are also very valuable. User documentation is considered to constitute a contract specifying what the software will do.
1648:
576:
1340:: Assign roles and responsibilities for documentation within the Agile team. Ensure everyone understands the importance of documentation.
1089:
Often, software developers need to be able to create and access information that is not going to be part of the source file itself. Such
648:
428:
1244:"The resistance to documentation among developers is well known and needs no emphasis." This situation is particularly prevalent in
89:
1146:
approach is considered the most useful for a new user, in which they are guided through each step of accomplishing particular tasks.
1526:
61:
799:
The need for requirements documentation is typically related to the complexity of the product, the impact of the product, and the
42:
1361:
566:
418:
68:
2165:
2031:
1960:
641:
541:
297:
282:
1232:
To inform them about what exactly the product does, so that their expectations are in line with what they will be receiving.
1854:
1757:
561:
599:
1248:
because these methodologies try to avoid any unnecessary activities that do not directly bring value. Specifically, the
75:
1641:
897:
508:
272:
1834:
1701:
1686:
831:
375:
108:
2201:
1027:, or Universal Report can be used to auto-generate the code documents—that is, they extract the comments and
498:
493:
249:
57:
1276:
is an approach to documentation that treats it with the same rigor and processes as software code. This includes:
1216:, is the final step in which the information collected in steps three and four is used to produce the final draft.
2196:
1603:
Prause, Christian R., and Zoya Durdik. "Architectural design and documentation: Waste in agile development?" In:
627:
842:
Another type of design document is the comparison document, or trade study. This would often take the form of a
1990:
1917:
1907:
1752:
1681:
1523:
1511:
1070:
1039:
518:
231:
211:
46:
1204:
Draft review, is a self-explanatory phase where feedback is sought on the draft composed in the previous step.
380:
2175:
2041:
1970:
1912:
1634:
893:
834:) is a special type of design document. In a way, architecture documents are third derivative from the code (
317:
307:
257:
1229:
To excite the potential user about the product and instill in them a desire to become more involved with it.
1980:
1839:
1706:
1328:: Start by placing your documentation in a version control system. Structure it similarly to your codebase.
604:
332:
148:
1902:
1897:
1711:
423:
395:
848:. It focuses on one specific aspect of the system and suggests alternate approaches. It could be at the
772:
Requirements come in a variety of styles, notations and formality. Requirements can be goal-like (e.g.,
724:
documentation is the description of what a particular software does or should do. It is used throughout
2097:
1945:
1940:
1892:
1869:
1849:
1245:
546:
390:
277:
267:
206:
1295:: Enabling multiple contributors to work on documentation simultaneously, similar to code development.
1077:
have built-in support for a simple form of literate programming, but this support is not widely used.
2102:
2092:
1401:
861:
it is to create a common source to be used by all players within the scene. The potential users are:
312:
292:
82:
2005:
1804:
1787:
1696:
453:
322:
302:
1955:
1799:
1020:
984:
950:
809:
581:
463:
342:
216:
35:
2010:
1767:
1762:
1158:
1103:
871:
778:
builds can be started by right-clicking a configuration file and selecting the 'build' function
523:
433:
327:
1031:, where available, from the source code and create reference manuals in such forms as text or
1829:
1782:
1012:
754:
347:
163:
153:
1061:
has noted that documentation can be a very difficult afterthought process and has advocated
2127:
1965:
1824:
1814:
1726:
1671:
1657:
1386:
1062:
1049:
to update the documents nightly). Some would characterize this as a pro rather than a con.
785:
725:
443:
287:
221:
188:
168:
129:
1476:
1102:
This section is about consumable guides for software usage. For more general systems, see
955:
It is important for the code documents associated with the source code (which may include
8:
2147:
2132:
2000:
1864:
1772:
1716:
1113:
886:
438:
357:
183:
1503:
2137:
1777:
1366:
1153:
1121:
1028:
762:
758:
750:
556:
2051:
1809:
1519:
1515:
1258:
1207:
1174:
1129:
695:
2122:
2066:
1844:
1736:
1731:
1507:
1334:: Implement CI/CD tools to automate the generation and deployment of documentation.
793:
781:
766:
513:
476:
458:
448:
173:
1591:
2142:
1995:
1975:
1859:
1721:
1530:
1451:
1396:
1371:
1314:: Automated tools can handle repetitive tasks, such as formatting and deployment.
1249:
835:
738:
400:
352:
236:
158:
975:
style, allowing a programmer to quickly look up an arbitrary function or class.
2046:
1950:
1691:
1422:
849:
1346:: Schedule regular documentation reviews as part of the sprint retrospectives.
681:
is an important part of software engineering. Types of documentation include:
2190:
2026:
1794:
1381:
1195:
1109:
Unlike code documents, user documents simply describe how a program is used.
996:
678:
143:
1436:
2061:
2056:
1985:
1262:
1235:
To explain the position of this product with respect to other alternatives.
1074:
1058:
1008:
800:
226:
1308:: Documentation can be kept in sync with the codebase, ensuring accuracy.
1178:
1066:
721:
685:
707:
Marketing – How to market the product and analysis of the market demand.
2071:
2036:
1626:
1356:
1125:
1090:
965:
879:
844:
816:
900:
or not), including following information and their clear definitions:
1481:
1472:
1376:
746:
178:
704:– Manuals for the end-user, system administrators and support staff.
24:
1819:
1143:
1046:
1024:
815:
In Agile software development, requirements are often expressed as
780:), and anything in between. They can be specified as statements in
734:
730:
701:
672:
551:
503:
488:
483:
1239:
978:
1289:: Automating the process of documentation generation and updates.
1213:
1016:
1000:
988:
1676:
1391:
956:
853:
694:
Technical – Documentation of code, algorithms, interfaces, and
262:
1283:: Using systems like Git to track changes and manage versions.
1210:, whereby the usability of the document is tested empirically.
1876:
1004:
742:
337:
1069:
and extracted by automatic means. The programming languages
2087:
1032:
992:
571:
671:
is written text or illustration that accompanies computer
960:
1605:
International
Conference on Software and System Process
889:
Systems, the document should include following parts:
917:
Relational Schema, including following information:
825:
49:. Unsourced material may be challenged and removed.
2188:
1616:Selic, Bran. "Agile documentation, anyone?" In:
1477:"Knowledge Base Articles for Driver Development"
1240:Documentation and agile development controversy
1185:
1065:, written at the same time and location as the
979:Technical documentation embedded in source code
926:Constraints such as primary keys, foreign keys,
1642:
1577:Herbsleb, James D. and Moitra, Dependra. In:
716:
649:
1423:"How to get a budget for code documentation"
1201:Planning, or the actual documentation phase.
932:Cascading Policy for referential constraints
1510:Series in Technical Communication, 2nd ed.
1299:
1649:
1635:
1594:IEEE Computer, vol. 34, no. 12, p. 4, 2001
1581:, vol. 18, no. 2, pp. 16-20, Mar/Apr 2001
1220:
1198:, the basic research phase of the process.
1080:
971:Code documents are often organized into a
944:
830:Architecture documentation (also known as
656:
642:
109:Learn how and when to remove this message
1840:Software development process/methodology
1656:
920:Tables, Attributes, and their properties
1052:
2189:
1362:Comparison of documentation generators
1120:important for them to have a thorough
929:Cardinality of referential constraints
610:Electrical and electronics engineering
16:Explains the functionality of software
1630:
1471:
1097:
912:Attribute and Tuple based constraints
2161:
1855:Software verification and validation
1758:Component-based software engineering
47:adding citations to reliable sources
18:
1465:
788:, or as a combination of them all.
13:
1443:
909:Candidate keys for each entity set
906:Relationships and their attributes
796:) and time-consuming (expensive).
14:
2213:
1835:Software configuration management
1702:Search-based software engineering
1687:Experimental software engineering
1620:, vol. 26, no. 6, pp. 11-12, 2009
1449:
832:software architecture description
826:Architecture design documentation
536:Standards and bodies of knowledge
2171:
2170:
2160:
903:Entity Sets and their attributes
784:, as drawn figures, as detailed
23:
1610:
1597:
1584:
1571:
1268:
628:Outline of software development
34:needs additional citations for
1682:Empirical software engineering
1562:
1553:
1544:
1535:
1504:Writing Software Documentation
1496:
1452:"The KDE Documentation Primer"
1429:
1415:
1:
1592:"Manifesto elicits cynicism."
1506:, Preface, xxiv. Part of the
1057:Respected computer scientist
1707:Site reliability engineering
1186:Composing user documentation
894:Entity - Relationship Schema
774:distributed work environment
7:
1712:Social software engineering
1350:
10:
2218:
1850:Software quality assurance
1246:agile software development
1101:
948:
776:), close to design (e.g.,
717:Requirements documentation
391:Software quality assurance
2156:
2115:
2080:
2019:
1933:
1926:
1885:
1745:
1664:
1402:Unified Modeling Language
2006:Model-driven engineering
1805:Functional specification
1788:Software incompatibility
1697:Requirements engineering
1408:
1300:Benefits of Docs as Code
711:
376:Configuration management
58:"Software documentation"
2202:Technical communication
1800:Enterprise architecture
1221:Marketing documentation
1081:Elucidative programming
951:Technical documentation
945:Technical documentation
810:requirements management
600:Artificial intelligence
2197:Software documentation
2011:Round-trip engineering
1768:Backward compatibility
1763:Software compatibility
1287:Continuous Integration
1159:Information technology
1104:End user documentation
872:Database administrator
669:Software documentation
524:Infrastructure as code
370:Supporting disciplines
1830:Software architecture
1783:Forward compatibility
1529:May 13, 2013, at the
1326:Setup Version Control
880:Application developer
812:tools are advocated.
786:mathematical formulas
759:interaction designers
381:Deployment management
2128:Computer engineering
1825:Software archaeology
1815:Programming paradigm
1727:Software maintenance
1672:Computer programming
1658:Software engineering
1607:(ICSSP), IEEE, 2012.
1387:Literate programming
1063:literate programming
1053:Literate programming
876:Application designer
201:Paradigms and models
130:Software development
43:improve this article
2148:Systems engineering
2133:Information science
1913:Service orientation
1865:Structured analysis
1773:Compatibility layer
1717:Software deployment
1590:Rakitin, Steven. ,
887:Relational Database
885:When talking about
755:usability engineers
751:software architects
124:Part of a series on
2138:Project management
1903:Object orientation
1870:Essential analysis
1778:Compatibility mode
1512:Upper Saddle River
1502:Thomas T. Barker,
1367:Design by contract
1332:Automate Processes
1259:Reputation systems
1175:personal computers
1165:List or Reference:
1098:User documentation
1029:software contracts
868:Database developer
519:Release automation
396:Project management
2184:
2183:
2111:
2110:
2052:Information model
1956:Incremental model
1810:Modeling language
1516:Pearson Education
1508:Allyn & Bacon
1265:) may be needed.
1208:Usability testing
1130:technical writing
1112:In the case of a
865:Database designer
666:
665:
557:ISO/IEC standards
119:
118:
111:
93:
2209:
2174:
2173:
2164:
2163:
2123:Computer science
1931:
1930:
1845:Software quality
1737:Systems analysis
1732:Software testing
1651:
1644:
1637:
1628:
1627:
1621:
1614:
1608:
1601:
1595:
1588:
1582:
1575:
1569:
1568:Barker, pg. 240.
1566:
1560:
1559:Barker, pg. 217.
1557:
1551:
1550:Barker, pg. 173.
1548:
1542:
1541:Barker, pg. 118.
1539:
1533:
1500:
1494:
1493:
1491:
1489:
1469:
1463:
1462:
1460:
1458:
1447:
1441:
1440:
1433:
1427:
1426:
1419:
1114:software library
808:special-purpose
794:software quality
782:natural language
739:project managers
658:
651:
644:
605:Computer science
514:Build automation
121:
120:
114:
107:
103:
100:
94:
92:
51:
27:
19:
2217:
2216:
2212:
2211:
2210:
2208:
2207:
2206:
2187:
2186:
2185:
2180:
2152:
2143:Risk management
2107:
2076:
2015:
1996:Waterfall model
1966:Prototype model
1961:Iterative model
1922:
1898:Aspect-oriented
1881:
1860:Software system
1741:
1722:Software design
1660:
1655:
1625:
1624:
1615:
1611:
1602:
1598:
1589:
1585:
1576:
1572:
1567:
1563:
1558:
1554:
1549:
1545:
1540:
1536:
1531:Wayback Machine
1501:
1497:
1487:
1485:
1470:
1466:
1456:
1454:
1450:Woelz, Carlos.
1448:
1444:
1435:
1434:
1430:
1421:
1420:
1416:
1411:
1397:User Assistance
1372:Design document
1353:
1344:Regular Reviews
1302:
1281:Version Control
1271:
1250:Agile Manifesto
1242:
1223:
1188:
1107:
1100:
1083:
1055:
981:
973:reference guide
953:
947:
836:design document
828:
801:life expectancy
719:
714:
662:
633:
632:
623:
615:
614:
595:
587:
586:
537:
529:
528:
479:
469:
468:
414:
406:
405:
401:User experience
371:
363:
362:
253:
242:
241:
202:
194:
193:
139:
138:Core activities
115:
104:
98:
95:
52:
50:
40:
28:
17:
12:
11:
5:
2215:
2205:
2204:
2199:
2182:
2181:
2179:
2178:
2168:
2157:
2154:
2153:
2151:
2150:
2145:
2140:
2135:
2130:
2125:
2119:
2117:
2116:Related fields
2113:
2112:
2109:
2108:
2106:
2105:
2100:
2095:
2090:
2084:
2082:
2078:
2077:
2075:
2074:
2069:
2064:
2059:
2054:
2049:
2047:Function model
2044:
2039:
2034:
2029:
2023:
2021:
2017:
2016:
2014:
2013:
2008:
2003:
1998:
1993:
1988:
1983:
1978:
1973:
1968:
1963:
1958:
1953:
1951:Executable UML
1948:
1943:
1937:
1935:
1928:
1924:
1923:
1921:
1920:
1915:
1910:
1905:
1900:
1895:
1889:
1887:
1883:
1882:
1880:
1879:
1874:
1873:
1872:
1862:
1857:
1852:
1847:
1842:
1837:
1832:
1827:
1822:
1817:
1812:
1807:
1802:
1797:
1792:
1791:
1790:
1785:
1780:
1775:
1770:
1760:
1755:
1749:
1747:
1743:
1742:
1740:
1739:
1734:
1729:
1724:
1719:
1714:
1709:
1704:
1699:
1694:
1692:Formal methods
1689:
1684:
1679:
1674:
1668:
1666:
1662:
1661:
1654:
1653:
1646:
1639:
1631:
1623:
1622:
1609:
1596:
1583:
1570:
1561:
1552:
1543:
1534:
1495:
1464:
1442:
1428:
1413:
1412:
1410:
1407:
1406:
1405:
1399:
1394:
1389:
1384:
1379:
1374:
1369:
1364:
1359:
1352:
1349:
1348:
1347:
1341:
1335:
1329:
1322:
1321:
1315:
1309:
1301:
1298:
1297:
1296:
1290:
1284:
1270:
1267:
1241:
1238:
1237:
1236:
1233:
1230:
1222:
1219:
1218:
1217:
1211:
1205:
1202:
1199:
1187:
1184:
1170:
1169:
1162:
1147:
1099:
1096:
1082:
1079:
1054:
1051:
980:
977:
949:Main article:
946:
943:
939:
938:
937:
936:
933:
930:
927:
924:
921:
915:
914:
913:
910:
907:
904:
883:
882:
877:
874:
869:
866:
850:user interface
827:
824:
718:
715:
713:
710:
709:
708:
705:
699:
692:
689:
664:
663:
661:
660:
653:
646:
638:
635:
634:
631:
630:
624:
621:
620:
617:
616:
613:
612:
607:
602:
596:
593:
592:
589:
588:
585:
584:
579:
574:
569:
564:
559:
554:
549:
547:IEEE standards
544:
538:
535:
534:
531:
530:
527:
526:
521:
516:
511:
506:
501:
496:
491:
486:
480:
475:
474:
471:
470:
467:
466:
461:
456:
451:
446:
441:
436:
431:
426:
421:
415:
412:
411:
408:
407:
404:
403:
398:
393:
388:
383:
378:
372:
369:
368:
365:
364:
361:
360:
355:
350:
345:
340:
335:
330:
325:
320:
315:
310:
305:
300:
295:
290:
285:
280:
275:
270:
265:
260:
254:
252:and frameworks
248:
247:
244:
243:
240:
239:
234:
229:
224:
219:
214:
209:
203:
200:
199:
196:
195:
192:
191:
186:
181:
176:
171:
166:
161:
156:
151:
146:
140:
137:
136:
133:
132:
126:
125:
117:
116:
31:
29:
22:
15:
9:
6:
4:
3:
2:
2214:
2203:
2200:
2198:
2195:
2194:
2192:
2177:
2169:
2167:
2159:
2158:
2155:
2149:
2146:
2144:
2141:
2139:
2136:
2134:
2131:
2129:
2126:
2124:
2121:
2120:
2118:
2114:
2104:
2101:
2099:
2096:
2094:
2091:
2089:
2086:
2085:
2083:
2079:
2073:
2070:
2068:
2067:Systems model
2065:
2063:
2060:
2058:
2055:
2053:
2050:
2048:
2045:
2043:
2040:
2038:
2035:
2033:
2030:
2028:
2025:
2024:
2022:
2018:
2012:
2009:
2007:
2004:
2002:
1999:
1997:
1994:
1992:
1989:
1987:
1984:
1982:
1979:
1977:
1974:
1972:
1969:
1967:
1964:
1962:
1959:
1957:
1954:
1952:
1949:
1947:
1944:
1942:
1939:
1938:
1936:
1934:Developmental
1932:
1929:
1925:
1919:
1916:
1914:
1911:
1909:
1906:
1904:
1901:
1899:
1896:
1894:
1891:
1890:
1888:
1884:
1878:
1875:
1871:
1868:
1867:
1866:
1863:
1861:
1858:
1856:
1853:
1851:
1848:
1846:
1843:
1841:
1838:
1836:
1833:
1831:
1828:
1826:
1823:
1821:
1818:
1816:
1813:
1811:
1808:
1806:
1803:
1801:
1798:
1796:
1795:Data modeling
1793:
1789:
1786:
1784:
1781:
1779:
1776:
1774:
1771:
1769:
1766:
1765:
1764:
1761:
1759:
1756:
1754:
1751:
1750:
1748:
1744:
1738:
1735:
1733:
1730:
1728:
1725:
1723:
1720:
1718:
1715:
1713:
1710:
1708:
1705:
1703:
1700:
1698:
1695:
1693:
1690:
1688:
1685:
1683:
1680:
1678:
1675:
1673:
1670:
1669:
1667:
1663:
1659:
1652:
1647:
1645:
1640:
1638:
1633:
1632:
1629:
1619:
1618:IEEE Software
1613:
1606:
1600:
1593:
1587:
1580:
1579:IEEE Software
1574:
1565:
1556:
1547:
1538:
1532:
1528:
1525:
1521:
1517:
1513:
1509:
1505:
1499:
1484:
1483:
1478:
1474:
1468:
1453:
1446:
1438:
1432:
1424:
1418:
1414:
1403:
1400:
1398:
1395:
1393:
1390:
1388:
1385:
1383:
1382:Documentation
1380:
1378:
1375:
1373:
1370:
1368:
1365:
1363:
1360:
1358:
1355:
1354:
1345:
1342:
1339:
1336:
1333:
1330:
1327:
1324:
1323:
1319:
1318:Collaboration
1316:
1313:
1310:
1307:
1304:
1303:
1294:
1293:Collaboration
1291:
1288:
1285:
1282:
1279:
1278:
1277:
1275:
1266:
1264:
1260:
1254:
1251:
1247:
1234:
1231:
1228:
1227:
1226:
1215:
1212:
1209:
1206:
1203:
1200:
1197:
1196:User analysis
1194:
1193:
1192:
1183:
1180:
1176:
1166:
1163:
1160:
1155:
1151:
1148:
1145:
1141:
1138:
1137:
1136:
1133:
1131:
1127:
1123:
1117:
1115:
1110:
1105:
1095:
1092:
1087:
1078:
1076:
1072:
1068:
1064:
1060:
1050:
1048:
1043:
1041:
1036:
1034:
1030:
1026:
1022:
1018:
1014:
1010:
1006:
1002:
998:
997:Visual Expert
994:
990:
986:
976:
974:
969:
967:
962:
958:
952:
942:
934:
931:
928:
925:
922:
919:
918:
916:
911:
908:
905:
902:
901:
899:
895:
892:
891:
890:
888:
881:
878:
875:
873:
870:
867:
864:
863:
862:
858:
855:
851:
847:
846:
840:
837:
833:
823:
820:
819:
813:
811:
805:
802:
797:
795:
789:
787:
783:
779:
775:
770:
768:
764:
760:
756:
752:
748:
744:
740:
736:
732:
727:
723:
706:
703:
700:
697:
693:
690:
687:
684:
683:
682:
680:
679:Documentation
676:
674:
670:
659:
654:
652:
647:
645:
640:
639:
637:
636:
629:
626:
625:
619:
618:
611:
608:
606:
603:
601:
598:
597:
591:
590:
583:
580:
578:
575:
573:
570:
568:
565:
563:
560:
558:
555:
553:
550:
548:
545:
543:
540:
539:
533:
532:
525:
522:
520:
517:
515:
512:
510:
507:
505:
502:
500:
497:
495:
492:
490:
487:
485:
482:
481:
478:
473:
472:
465:
462:
460:
457:
455:
452:
450:
447:
445:
442:
440:
437:
435:
432:
430:
427:
425:
422:
420:
417:
416:
410:
409:
402:
399:
397:
394:
392:
389:
387:
386:Documentation
384:
382:
379:
377:
374:
373:
367:
366:
359:
356:
354:
351:
349:
346:
344:
341:
339:
336:
334:
331:
329:
326:
324:
321:
319:
316:
314:
311:
309:
306:
304:
301:
299:
296:
294:
291:
289:
286:
284:
281:
279:
276:
274:
271:
269:
266:
264:
261:
259:
256:
255:
251:
250:Methodologies
246:
245:
238:
235:
233:
230:
228:
225:
223:
220:
218:
215:
213:
210:
208:
205:
204:
198:
197:
190:
187:
185:
182:
180:
177:
175:
172:
170:
167:
165:
162:
160:
157:
155:
152:
150:
147:
145:
144:Data modeling
142:
141:
135:
134:
131:
128:
127:
123:
122:
113:
110:
102:
91:
88:
84:
81:
77:
74:
70:
67:
63:
60: –
59:
55:
54:Find sources:
48:
44:
38:
37:
32:This article
30:
26:
21:
20:
2062:Object model
2057:Metamodeling
1986:Spiral model
1886:Orientations
1617:
1612:
1604:
1599:
1586:
1578:
1573:
1564:
1555:
1546:
1537:
1498:
1486:. Retrieved
1480:
1467:
1455:. Retrieved
1445:
1431:
1417:
1392:README files
1343:
1338:Define Roles
1337:
1331:
1325:
1317:
1311:
1305:
1292:
1286:
1280:
1274:Docs as Code
1273:
1272:
1269:Docs as Code
1263:Gamification
1255:
1243:
1224:
1189:
1171:
1164:
1149:
1139:
1134:
1118:
1111:
1108:
1088:
1084:
1075:CoffeeScript
1059:Donald Knuth
1056:
1044:
1037:
1009:EiffelStudio
982:
972:
970:
954:
940:
935:Primary keys
884:
859:
843:
841:
829:
818:user stories
817:
814:
806:
798:
790:
777:
773:
771:
722:Requirements
720:
686:Requirements
677:
668:
667:
504:UML Modeling
499:GUI designer
385:
164:Construction
154:Requirements
105:
96:
86:
79:
72:
65:
53:
41:Please help
36:verification
33:
1753:Abstraction
1306:Consistency
1179:online help
1126:API Writers
1091:annotations
1067:source code
966:API writers
726:development
222:Prototyping
217:Incremental
189:Maintenance
169:Engineering
2191:Categories
2072:View model
2037:Data model
1524:0321103289
1357:API Writer
1312:Automation
1013:Sandcastle
959:files and
845:whitepaper
763:developers
594:Glossaries
184:Deployment
99:March 2013
69:newspapers
2081:Languages
1482:Microsoft
1473:Microsoft
1377:Docstring
1150:Thematic:
1140:Tutorial:
747:marketing
735:customers
731:end users
413:Practices
237:Waterfall
212:Cleanroom
179:Debugging
149:Processes
2176:Category
2042:ER model
1908:Ontology
1820:Software
1746:Concepts
1527:Archived
1518:, 2003.
1351:See also
1157:such as
1154:thematic
1144:tutorial
1047:cron job
1040:comments
1025:TwinText
987:such as
898:enhanced
702:End user
673:software
622:Outlines
552:ISO 9001
494:Profiler
489:Debugger
484:Compiler
459:Stand-up
2166:Commons
1991:V-model
1488:15 June
1457:15 June
1214:Editing
1071:Haskell
1035:files.
1017:ROBODoc
1001:Javadoc
989:Doxygen
983:Often,
767:testers
293:Lean SD
232:V model
174:Testing
83:scholar
1927:Models
1677:DevOps
1665:Fields
1522:
957:README
854:jargon
765:, and
567:SWEBOK
288:Kanban
263:DevOps
227:Spiral
159:Design
85:
78:
71:
64:
56:
2103:SysML
2027:SPICE
2020:Other
1981:Scrum
1941:Agile
1893:Agile
1877:CI/CD
1409:Notes
1122:index
1005:JSDoc
985:tools
923:Views
743:sales
712:Types
562:PMBOK
477:Tools
338:SEMAT
333:Scrum
207:Agile
90:JSTOR
76:books
2088:IDEF
2032:CMMI
1918:SDLC
1520:ISBN
1490:2009
1459:2009
1261:and
1168:for.
1073:and
1033:HTML
993:NDoc
696:APIs
577:IREB
572:ITIL
542:CMMI
419:ATDD
328:SAFe
298:LeSS
273:DSDM
62:news
2098:USL
2093:UML
1971:RAD
1946:EUP
1404:UML
1177:to
1021:POD
961:API
582:OMG
509:IDE
464:TDD
454:SBE
444:DDD
429:CCO
424:BDD
348:TSP
343:TDD
323:RUP
318:RAD
313:PSP
308:MSF
303:MDD
283:IID
278:FDD
268:DAD
258:ASD
45:by
2193::
2001:XP
1976:UP
1514::
1479:.
1475:.
1152:A
1142:A
1132:.
1023:,
1019:,
1015:,
1011:,
1007:,
1003:,
999:,
995:,
991:,
769:.
761:,
757:,
753:,
749:,
745:,
741:,
737:,
733:,
449:PP
439:CD
434:CI
358:XP
353:UP
1650:e
1643:t
1636:v
1492:.
1461:.
1439:.
1425:.
1161:.
1106:.
896:(
698:.
657:e
650:t
643:v
112:)
106:(
101:)
97:(
87:·
80:·
73:·
66:·
39:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
