...
Spec Writing Process Overview
The Tiger SME Team will be available to the Spec Team to answer any scoping questions, and the Tiger Team SA will coordinate all start-up and mentoring to Spec Teams to ensure completion of requirements, documentation, and related modeling. Spec Writing will follow a basic process:
- User Requirements/fSpecs completed by Spec Team.
- fSpecs reviewed by Tiger SME Team - may come back to Spec Team with questions.
- When evaluated as a "completed draft", the specs will be given to Project Management and placed into Spec Inventory.
- Specs from all the teams, as completed, are reviewed against planned release schedules and scheduled for development.
- Once scheduled for development, the SA (Systems Analyst) from the Tiger SME Team and the Project Team will complete any final documentation, and will restart the process with SMEs. This may include:
- Q&A
- User Interface/User Design workshops
- Gap analysis discussions
- Clarifications on how we're coding.
- As development gets underway, some of the SMEs (those designated for Testing) will begin to draft Test Scripts.
- Test Scripts will then be used in the execution of User Acceptance Testing.
...
Section |
---|
Column |
---|
| Wiki Markup |
---|
Link: [*DOCUMENTATION & SPECIFICATION TEMPLATES*|Specification & Documentation Templates]
h6. (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}[https://docs.google.com/a/kuali.org/document/d/1D8y8UXddgG02hvd-Zi9GYokt2e53QP3LKxInUfNsMUM/edit?hl=en_US]{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}[https://docs.google.com/a/kuali.org/spreadsheet/ccc?key=0AlzG4eNDtxYpdFVZekVWUzdhT0U5M0JrcEwxNllTZUE&hl=en_US#gid=0]{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}[https://docs.google.com/a/kuali.org/open?id=0B2bXKznsS-3GNzAyYzU4MDEtMmU3Mi00NDk3LWIzNDItN2I0OTM4YTI5YmM3]{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: [TigerSME 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: [TigerSME 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: [TigerSME 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, TigerSME Team
See:[OLE:Acceptance Criteria, Test Scripts & Testing]
|
|
Column |
---|
HTML Table |
---|
| Table Cell (td) |
---|
| |
Table Cell (td) |
---|
| |
Table Cell (td) |
---|
| |
|
|
|
...