|
Link: [*DOCUMENTATION & SPECIFICATION TEMPLATES*|Specification & Documentation Templates]
h6. TEMPLATES (6) - User Requirements - Spec team & SA
1. User Requirements Template
The {link-window:http://goo.gl/ATxOX|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}User Requirements Template{link-window}{HTMLcomment}[
The
]{HTMLcomment} (for use with "User Story" specifications) should be used as the basis of all spec-writing by functional spec teams. Some efforts (such as architecture specs, ingest/load specs) may be documented via alternate documentation approaches, in order to convey detailed technical, API, or rules/overlay logic.
2. Data Requirements Template
The {link-window:http://goo.gl/6RD6I|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}Data Requirements Template{link-window}{HTMLcomment}[
The
]{HTMLcomment} is provided so that SMEs can annotate all data fields required for the specifications, and include details on field types, required/not required, default values, descriptions. See also: {link-window:http://goo.gl/ob4MJ|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}Previous Data Models{link-window}
{HTMLcomment}[also:
]{HTMLcomment}
3. List [Acceptance criteria|OLE:Acceptance Criteria, Test Scripts & Testing]
Writing Acceptance Criteria is part of the User Requirements template above, but as these are so important, we are providing additional examples to illustrate what is needed (as the precursor to Test Scripts).
4. Roles/Permissions
In order to code specific security, permissions, and workflow in OLE, we need SMEs to annotate "sample" Roles and Permissions as part of the above User Requirements template. This can also be clarified with SAs as specs are completed for coding. See: [Tiger Team SA - Spec Writing & Analysis-User Roles & Permissions|OLE:Tiger Team SA - Spec Writing & Analysis#roles]
5. Workflows, Approvals, Notifications, & Document Routing
The Kuali technology framework allows us to "route" certain documents or transactions for Approval or Notification. In addition to or in place of simple permissions schemes, OLE can build workflows and approval steps into its architecture, or allow users to "ad hoc" route documents. See: [Tiger Team SA - Spec Writing & Analysis\- Workflow|OLE:Tiger Team SA - Spec Writing & Analysis#workflow]
* ex. Purchase Order exceeds user permissions for $$. Instead of just not processing, a workflow could "route" the PO for approval.
* ex. Specific fund codes or collections, on the basis of metadata (last month of fiscal year, last week of semester) could create an "FYI" or "Acknowledgement".
6. Additional Business Rules
In addition to any specific data validations that may be included in the Data Requirements template above, are there other business rules you wish to capture? Include these in the User Requirements template. See: [Tiger Team SA - Spec Writing & Analysis - Business Rules|OLE:Tiger Team SA - Spec Writing & Analysis#rules]
* ex. The minimum requirement to Save a Requisition is a Title on the line item.
* ex. All purchase orders must have accounting lines/allocations to be submitted to the vendor.
h6. (12), (17) - Handoffs and Reviews
# Participate in handoffs to developers if requested by SA (due to complexity of specs, or clarifications needed for how we implement).
# Be available for periodic emails as follow-up and Q&A continue once coding starts.
h6. (16) - Test Scripts
Once development is begun, then SA and Spec Team work with QA Manager/team to develop Test Scripts for each set of coded specs (note: some user stories in initial spec writing may have been adapted to Kuali technology OR been combined to code core functions).
h6. (23), (25)-(26) Testing: Spec Team, Tiger Team
See:[OLE:Acceptance Criteria, Test Scripts & Testing]
criteria
Writing Acceptance Criteria is part of the User Requirements template above, but as these are so important, we are providing additional examples to illustrate what is needed (as the precursor to Test Scripts). 4. Roles/Permissions
In order to code specific security, permissions, and workflow in OLE, we need SMEs to annotate "sample" Roles and Permissions as part of the above User Requirements template. This can also be clarified with SAs as specs are completed for coding. See: SME Team SA - Spec Writing & Analysis-User Roles & Permissions 5. Workflows, Approvals, Notifications, & Document Routing
The Kuali technology framework allows us to "route" certain documents or transactions for Approval or Notification. In addition to or in place of simple permissions schemes, OLE can build workflows and approval steps into its architecture, or allow users to "ad hoc" route documents. See: SME Team SA - Spec Writing & Analysis- Workflow - ex. Purchase Order exceeds user permissions for $$. Instead of just not processing, a workflow could "route" the PO for approval.
- ex. Specific fund codes or collections, on the basis of metadata (last month of fiscal year, last week of semester) could create an "FYI" or "Acknowledgement".
6. Additional Business Rules
In addition to any specific data validations that may be included in the Data Requirements template above, are there other business rules you wish to capture? Include these in the User Requirements template. See: SME Team SA - Spec Writing & Analysis - Business Rules - ex. The minimum requirement to Save a Requisition is a Title on the line item.
- ex. All purchase orders must have accounting lines/allocations to be submitted to the vendor.
(12), (17) - Handoffs and Reviews - Participate in handoffs to developers if requested by SA (due to complexity of specs, or clarifications needed for how we implement).
- Be available for periodic emails as follow-up and Q&A continue once coding starts.
(16) - Test Scripts Once development is begun, then SA and Spec Team work with QA Manager/team to develop Test Scripts for each set of coded specs (note: some user stories in initial spec writing may have been adapted to Kuali technology OR been combined to code core functions). (23), (25)-(26) Testing: Spec Team, SME Team See:Acceptance Criteria, Test Scripts & Testing |
