{"id":750,"date":"2023-01-12T18:46:25","date_gmt":"2023-01-12T18:46:25","guid":{"rendered":"https:\/\/webresources-uat.com\/nchrp1918\/?page_id=750"},"modified":"2023-01-12T18:46:25","modified_gmt":"2023-01-12T18:46:25","slug":"28-system-design-documents","status":"publish","type":"page","link":"https:\/\/crp.trb.org\/nchrpwebresource2\/setup\/28-system-design-documents\/","title":{"rendered":"(28) System Design Documents"},"content":{"rendered":"\n
\n
\n
\n
RESEARCH AND PLANNING<\/a>  |   SETUP<\/a><\/span>  |   ONGOING OPERATIONS<\/a>  | TRANSITIONING AND GROWING<\/a><\/div><\/div> \n
\n

System Design Documents (28)<\/h1>\n

Description:<\/strong><\/h3> \n

\n \n \n<\/p>

In this building block, the project team develops the technical system design documents based on the concept of operations and other previously developed documents. At a minimum, these documents must include a system requirements specification document and any needed interface control documents. Optionally, they may also include user interface or experience guidelines or specifications. The main goal of these documents is system procurement and development and record maintenance. Specifications should include the entire system\u2014both state and vendor components\u2014though these may be specified in separate chapters.\n <\/p>\n

\n \n
\n

Details:<\/strong><\/h3>\n

Use systems engineering processes to develop these documents. The first document to develop is the system requirements specifications. Interface control documents should be developed only when separate systems from separate vendors must interface. User-experience documents are generally guidelines, not requirements.\n <\/p>\n <\/div>\n

\n
\n

Primary Use:<\/strong><\/h3>\n

Specify system for procurement.\n <\/p>\n <\/div>\n \n

\n \n
\n

Best Practices\/Lessons Learned:<\/strong><\/h3>\n