Spec Team- Roles in Spec Writing

Team pages for roles and responsibilities with Development Process Model are being updated and reformatted.

Contents

Library functional or technical staff (SME - Subject Matter Experts) will be called upon to complete User Requirements or fSpecs as the first step of the OLE Development Process. SME's on Spec Teams will be asked to complete the following documentation as part of the task of "Spec Writing".

See Getting Started with OLE - OLE 101

Spec Writing Process Overview

The SME Team will be available to the Spec Team to answer any scoping questions, and the 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 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 SME Team and the Project Team will complete any final documentation, and will restart the process with SMEs. This may include:
1. Q&A
2. User Interface/User Design workshops
3. Gap analysis discussions
4. 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.

Task Assignments & Documentation

Link: DOCUMENTATION & SPECIFICATION TEMPLATES

(6) - User Requirements - Spec team & SA

1. User Requirements Template
The (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 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:

3. List Acceptance 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

Phases:

For the complete model, see
OLE Development Cycle

Spec Writing

Coding

Testing

Spec Timeline

*Timeframe*	*Tasks*
(pre)	Team is formed
Week one	Kickoff meeting, team organization & assignments
	Prioritization of user stories & straight line path
Week two	Depending on size of team, 3-5 draft fspecs are completed
	Team meets to review draft fspecs
Week three	Draft specs finalized
	Data model reviewed, entities edited
	Review drafts with project team-initial questions: specs into inventory
Week four	Fspec team determines next priorities
	Recruit additional team members as needed
….	n# Fspecs assigned to sprint N
	Assigned specs reviewed w/developers; questions back to Fspec team
[2 weeks]	n# Fspecs complete initial coding
[2 weeks]	Acceptance Testing - subset of team participates
	** Feedback calls with project team as needed throughout process
….	n# additional Fspecs completed
…..	n# Fspecs assigned to additional sprints
…..	(cycling)

Sample Timeline

For reference only to assist in managing assignments and expectations

(click on above thumbnail to see enlarged readable view)