h2. Completing Codeable Specifications
# Review Draft User Requirements
# Use Spec Team Draft User Requirements to start and extend final specs, or,
## Combine multiple Spec Team drafts into final use case/specification document (if determined with BA), or,
## Extract portions of Spec team draft into technical or foundational spec document (to enable coding of dependencies in advance. Ex. Circulation Policy, Instance Record)
# Admin: SA must annotate and track how final specs are being combined in #2 above and reflect those changes in {link-window:https://jira.kuali.org/browse/OLE|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}OLE Jira{link-window} (exact admin process being determined for turning over specs to Project Management and Spec inventory)
# Work with Project Team, Developers and Technical Architect to inform follow-on or confirming Technical Specifications, or how we will "interpret functional requirements in KFS-Rice coding"
h2. Codeable Specs - Step-by-Step
Final or Codeable specification will need to extend the draft User Requirements, by filling in any gaps or additional details, and then augmenting those specs with Non-Functional Requirements (where applicable). In total, may include:
# Complete existing User Requirements Sections and extend for
## Complete Acceptance Criteria
## Add/edit existing AC for functional requirements
## Add AC for non-functional requirements
## Extend User Requirements for KFS/inherited functions and UI translations
## Workflow/Routing Requirements (as needed)
## Reconciliation & Additions to Roles/Permissions Matrix
## Error Handling and Messaging Requirements
## Annotate Complex Business Rules Requirements (KRMS)
# Add new functional sections:
## UI Wireframes
### including UI inventory
### Intra-spec, Intra-process UI and Navigation needs
## Maintenance Document Needs (with Data Architect)
### including workflows and permissions for each
## Federated Search extensions (iterative workshops & documentation to extend Search/Docstore)
# Add Appendices for non-functional requirements
## Document Revision History
## Index/links to Reference Documentation
## Dependencies (added to spec)
## Document & System Control Requirements
### Audit Trail Requirements
### Version Control Requirements (Docstore)
### Document Statuses
## Interoperability Requirements: API specification (from SA or TC member of SME Team) for system integration points
## Scalability/Load/Performance Requirements
## Privacy Requirements (if applicable, and as extension of Permissions)
## Design & Implementation Notes (Assumptions, Constraints, Issues)
## Sample Data & Mappings for Testing (with spec team, TC)
|