Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

Section
Column
width50%
{toc:outline=false|minLevel=1}
Panel
borderStyle
borderColor#A40000
bgColor#F8F8F8
titleBGColor#E8E8E8
borderStyledashed
titleContents
Wiki Markup
Table of Contents
dashed
minLevel1
outlinefalse
Column

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".

...

Task Assignments & Documentation

{table:border=0} {tr} {td:align=right} *Phases:* (i) For the complete model, see \\ [OLE:OLE Development Cycle] \\ \\ Spec Writing {td} {tr} {td:align=right} !OLEDevPhase1.jpg|thumbnail,border=1! {td} {tr} {td:align=right} \\ Coding {td} {tr} {td:align=right} !OLEDevPhase2.jpg|thumbnail,border=1! {td} {tr} {td:align=right} \\ Testing {td} {tr} {td:align=right} !OLEDevPhase3.jpg|thumbnail,border=1! {td} {tr} {table}

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
  1. Participate in handoffs to developers if requested by SA (due to complexity of specs, or clarifications needed for how we implement).
  2. 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

Section

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

Column
width75%
Wiki Markup
HTML Comment

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}[


The

HTML Comment

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}[

also:

HTML Comment

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: [SME Team SA - Spec Writing & Analysis-User Roles & Permissions|SME 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: [SME Team SA - Spec Writing & Analysis\- Workflow|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|SME 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, SME Team See:[OLE:Acceptance Criteria, Test Scripts & Testing]
Column
Wiki Markup
Column
HTML Table
border0
Table Row (tr)
Table Cell (td)
alignright
Phases:
(info) For the complete model, see
OLE Development Cycle

Spec Writing
Table Cell (td)
alignright
Image Added
Table Row (tr)
Table Cell (td)
alignright


Coding

Table Cell (td)
alignright
Image Added
Table Row (tr)
Table Cell (td)
alignright


Testing

Table Cell (td)
alignright
Image Added
Table Row (tr)

Spec Timeline

Section
Column
width60%

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)

Column

Anchor
timeline
timeline

Sample Timeline

(info) For reference only to assist in managing assignments and expectations

(click on above thumbnail to see enlarged readable view)