Versions Compared

Version Old Version 83 New Version 84
Changes made by

Nora Roggeveen-Sams

Nora Roggeveen-Sams

Saved on

Key

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

...

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

Section
Column
width50%
Panel
borderColor#A40000
bgColor#F8F8F8
titleBGColor#E8E8E8
titleContents
borderStyledashed
Table of Contents
minLevel1
outlinefalse
Column

SME Teams

Leads

Acquisitions/Financial: Select & Acquire

B Persing

ERMS: Under Select & Acquire

E Lynema

Cataloging: Describe-Manage

M Suranofsky - with SME lead D Herrold

Circulation: Deliver

C Case - with SME lead S Miller

Implementations/Technical: Systems Integration

C Case

Subscriptions project: GoKB

J Little

See below linked document and detailed task assignments that reflect the roles and responsibilities of the System Analyst's (SA) within SME Teams in the OLE Development Process. These are Subject Matter Experts (SME) with 50% individual or combined commitments, with either technical or functional expertise in the subject area of the team. The SA is primarily charged with overseeing all aspects of developing specifications, from overseeing user requirements by spec teams, to completing functional requirements documentation (with technical support and training by project team).

Note: "SA" or "SME Team Systems Analyst" is the name given to general analysts on the SME Teams to distinguish them from the BAs or Business Analysts on the Project Team. In some cases, these are still functional subject matter experts only, while in other cases, the SA does bring specific technical knowledge of coding or the Kuali technology framework (Rice et al).


HTML Comment

https://docs.google.com/a/kuali.org/document/d/1ybw-WwuGdFhvUDlbha1BVNnaTFObWEbLNYzHqui4MIQ/edit?hl=en_US

Task Assignments

Section
Column
width75%

In the tasks below (except review steps), we provide the templates for the required documentation for completion of technical and functional specs. Project team Business Analysts will help to guide and train SME Team System Analysts throughout the following task completions, and work closely with you in the completion of Final Specifications.

Link:DOCUMENTATION & SPECIFICATION TEMPLATES

(6) User Requirements - Spec team & SA

(see Spec Team - Roles in Spec Writing)

  1. Did you create a
    HTML Comment

    SOW template: https://docs.google.com/a/kuali.org/document/d/1LOUcNlnOd7ZXohnM5PYVxm3pN1VWiK0a1--kD9CICV4/edit?hl=en_US;

    with the SME Team for the new spec or research team?
  2. Setup email team list, KIS page, Google Docs folder for team.
    1. Request OLE Distribution list from Project Team or Help@kuali.org.
    2. Add team names to new email list & KIS page.
    3. Create team folder in your Google Docs Process (Describe, Deliver, etc) folder (model file directory after existing).
    4. "Share" team folder with distribution list and add to KIS page.
    5. Alternatively to above, SA may request BA/Project Team to process above (provide Team Name & list of members for us to set up).
  3. Prepare user requirement templates and related OLE documents for spec team
    1. Reference:
      HTML Comment

      https://docs.google.com/a/kuali.org/

document/d/1LOUcNlnOd7ZXohnM5PYVxm3pN1VWiK0a1--kD9CICV4/edit?hl=en_US];{HTMLcomment} with the SME Team for the new spec or research team? # Setup email team list, KIS page, Google Docs folder for team. ## Request OLE Distribution list from Project Team or Help@kuali.org. ## Add team names to new email list & KIS page. ## Create team folder in your Google Docs Process (Describe, Deliver, etc) folder (model file directory after existing). ## "Share" team folder with distribution list and add to KIS page. ## Alternatively to above, SA may request BA/Project Team to process above (provide Team Name & list of members for us to set up). # Prepare user requirement templates and related OLE documents for spec team ## Reference: {link-window:http://goo.gl/2bt80|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}OLE Data Modeling Team{link-window}{HTMLcomment}[https://docs.google.com/a/kuali.org/open?id=0B2bXKznsS-3GNzAyYzU4MDEtMmU3Mi00NDk3LWIzNDItN2I0OTM4YTI5YmM3]{HTMLcomment} \- original Data-Entity modeling ### Work with OLE Data Architect to identify/pre-populate data requirements worksheet with past Data Modeling Team entities ## Previous specifications (see Google Docs) or [OLE:Specification & Documentation Templates](linked samples) ## Reference: {link-window:htttp://goo.gl/pWn05|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}OLE Workflows Team{link-window}{HTMLcomment}[https://docs.google.com/a/kuali.org/open?id=0B2bXKznsS-3GMzVlYzM2OTgtOThmYS00YmVlLWFiMDYtMjE2NTAwMzA1NjFl]{HTMLcomment} \- original workflow modeling if able to reuse ## Pre-populate {link-window:http://goo.gl/3trf7|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} and {link-window:http://goo.gl/WE6Ob|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}Data Requirements Worksheet{link-window}{HTMLcomment}[https://docs.google.com/a/kuali.org/spreadsheet/ccc?key=0AlzG4eNDtxYpdFVZekVWUzdhT0U5M0JrcEwxNllTZUE&hl=en_US#gid=1]{HTMLcomment} as able ## Link other helpful collections or documents via Google Collections into Spec Team folder # Train the spec teams - utilize this wiki\! ## Google Docs ## Webex ## Spec Writing ## {link-window:http://goo.gl/CvvXS|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}Tips folder: Google Docs, Webex, Jira{link-window}{HTMLcomment}[https://docs.google.com/a/kuali.org/open?id=0B1zG4eNDtxYpZGM1ZGY2ZjYtNzJlOS00OTNlLTlmNDMtY2RhODdhZDgwZmIx]{HTMLcomment} # Organize and oversee spec writing by spec teams # Complete with Spec Team "User Requirements" template # Complete with Spec team "Data Requirements" template ## including default values/fields ## notes on any progressive disclosure or rules ## including noted required fields # Assist spec team in annotation and understanding of "Acceptance criteria" in user requirements # Table for roles/permissions ## from user requirements, assist spec team in annotating "mock" user roles with permissions ## refer to complete list of ongoing user roles, and resources for completion # Model for workflow ## has spec team included an illustration of required workflow process, or sequential model ("step one, step two")? ## does narrative adequately communicate the workflow, or should an illustration be inserted (Google Drawing or other illustration tool) # Document routing: Model for approval steps if any # Business rules h6. \(-) UI Mockups\- SA with designated BA or limited SMEs * [OLE:OLE UI & UX] * [OLE:OLE Wireframe Templates] h6. (8) Review - SME Team (see [SME Teams - Roles in Spec Writing & Analysis|SME Teams- Roles in Spec Writing & Analysis]) # Review and approve specs # Finalize or add Acceptance Criteria - what and how? # Note anything out of scope # Meet with PM to help determine prioritization # Sample data needs identified - given to SA and TC # Sample technical integration points culled by TC (ie for APIs, other tech specs needed) h6. (9) Spec Inventory (See: [Specification & Documentation Templates]) # Report completed specs to Project Team and Project Management (specs now available for assessment of complexity, prioritization, and scheduling) # Update {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} with drafted specs (admin process now being determined for attaching specs; updating workflows; and, combining or deleting or adding user stories as needed) h6. (11) Codeable Specs See: [*Final Functional Specifications*|Codeable (Final) Specifications] (template, instructions) Once SME Team has completed its spec review, and handed off the specs to Project Management in the spec inventory, user stories and tasks will be formally assigned to the project schedule. From that re-prioritization, the SA and BA (with spec team or SME Team where needed) complete Functional Specs/Requirements docs for coding # Complete UI templates or translations (if applicable) # Annotate sample roles/permissions table # Annotate testable document workflows/routing, approvals (if applicable) # Are Acceptance Criteria reviewed and completed? # Insert any additional Business Rules, KRMS (see BA & template) # Completion of full Functional and non-Functional specs h6. (12), (17) Handoffs and Reviews - SA, Spec Team, SME Team # Lead handoffs with Project Team to HTC. # Participate in Q&A with developers to "translate" and manage functional requirements, as liaison to Spec Team. # Coordinate developer questions with Spec Teams. # Work with Project Team in any additional spec translations or technical specs. # Report and manage Variations and iterative Gap Analysis as coding varies from specs due to time or technology. 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 based on Acceptance Criteria (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, SA, SME Team For above, see: [OLE:Acceptance Criteria, Test Scripts & Testing] h6. (iterative) Gap Analysis: SA, SME Team # Participate in Gap Analysis with - [SME Team - Gap Analysis|SME Teams- Roles in Spec Writing & Analysis#gap] # Maintain Jira and organize gap reporting. # General oversight h6. (iterative) Jira Maintenance # <coming soon> # {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} administration process being modified to reflect new OLE Development Process. Responsibilities of SME Team, SA's and Project Team being determined. # Jira is the definitive project administration tool for OLE, and all User Stories. # Draft and final specifications are to be attached to User Stories in Jira. {column} {column} {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} {column} {section} h2. Role Overview (T. McGeary, former Functional Council Chair) The main goal of the new development process is to remove some of the technical barriers we had in the process we used before. We effectively create three stages: * Partner/Functional * Core/Technical * HTC/Programming The Partner/Functional phase is to produce an inventory of functional specs as fast as possible, removing any need for SMEs to know Rice or any of the underlying technologies. In short, answer the user story by answering who, what, how. Functional details about this cataloger adds data to these fields in this order. The Core/Technical is to translate that to technical specs for HTC to program. Because the SMEs will not be educated on the underlying technologies, we need some role to overlap functional and technical. That is the System Analyst: owning the functional spec, assisting the technical translation. This does not mean that the SA will be an expert in Rice or another technology, but by owning the functionality of the spec, the SA can collaborate with Core and HTC (who will be learning Rice) on how a UI can be built based on Rice constraints or how Routing should work given Rice routing engine. In short, as SA's are informed by Core/HTC about how the technology needs to work, the SA can advise/collaborate/compromise with Core/HTC on each spec to be sure that the functionality is still clear when the technology is applied. {anchor:ref} h2. Reference Documentation *BABOK: Business Analyst Body of Knowledge* For SA & BA only, in managing requirements analysis and brainstorming with spec teams * {link-window:http://goo.gl/WY5cZ|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}BABOK Guide (full){link-window}{HTMLcomment}[https://docs.google.com/a/kuali.org/viewer?a=v&pid=explorer&chrome=true&srcid=0B1zG4eNDtxYpMzI1OTA3NjctMWJiYS00MmM2LWFiOWMtNThmNjAzNGJmNzAz&hl=en_US]{HTMLcomment} * {link-window:http://goo.gl/WX3ou|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}BABOK Guide (brief){link-window} {HTMLcomment}[https://docs.google.com/a/kuali.org/viewer?a=v&pid=explorer&chrome=true&srcid=0B1zG4eNDtxYpOWY3ZGQwMmUtZjk5MS00Zjc3LWJiY2EtZjZjZTMyZTc0YjY3&hl=en_US]{HTMLcomment} {anchor:rules}{*}Summary: Business Rules* {link-window:http://goo.gl/DbgEG|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}Draft Combined Business Rules for OLE 0.3 Acquisitions functions{link-window} {HTMLcomment}[https://docs.google.com/a/kuali.org/document/d/1yFmLo1dwZ4rZgwcs8QeoBxyvfO2vdd7uAS5gB9AFgww/edit?hl=en_US]{HTMLcomment} * See also: OLE DEMO > Administration > Configuration > Functional> Parameter {anchor:workflow}{*}Summary: Workflows, Routing* {link-window:http://goo.gl/9CtFn|scrollbars=true|menubar=true|location=true|statusbar=true|resizable=true|width=800|height=600|icon=false}Draft Combined Workflows for OLE 0.3 Acquisitions functions{link-window} {HTMLcomment}[

    1. open?id=0B2bXKznsS-3GNzAyYzU4MDEtMmU3Mi00NDk3LWIzNDItN2I0OTM4YTI5YmM3

      - original Data-Entity modeling
      1. Work with OLE Data Architect to identify/pre-populate data requirements worksheet with past Data Modeling Team entities
    2. Previous specifications (see Google Docs) or Specification & Documentation Templates(linked samples)
    3. Reference:
      HTML Comment

      https://docs.google.com/a/kuali.org/open?id=0B2bXKznsS-3GMzVlYzM2OTgtOThmYS00YmVlLWFiMDYtMjE2NTAwMzA1NjFl

      - original workflow modeling if able to reuse
    4. Pre-populate
      HTML Comment

      https://docs.google.com/a/kuali.org/document/d/1D8y8UXddgG02hvd-Zi9GYokt2e53QP3LKxInUfNsMUM/edit?hl=en_US

      and
      HTML Comment

      https://docs.google.com/a/kuali.org/spreadsheet/ccc?key=0AlzG4eNDtxYpdFVZekVWUzdhT0U5M0JrcEwxNllTZUE&hl=en_US#gid=1

      as able
    5. Link other helpful collections or documents via Google Collections into Spec Team folder
  2. Train the spec teams - utilize this wiki!
    1. Google Docs
    2. Webex
    3. Spec Writing
    4. HTML Comment

      https://docs.google.com/a/kuali.org/open?id=0B1zG4eNDtxYpZGM1ZGY2ZjYtNzJlOS00OTNlLTlmNDMtY2RhODdhZDgwZmIx

  3. Organize and oversee spec writing by spec teams
  4. Complete with Spec Team "User Requirements" template
  5. Complete with Spec team "Data Requirements" template
    1. including default values/fields
    2. notes on any progressive disclosure or rules
    3. including noted required fields
  6. Assist spec team in annotation and understanding of "Acceptance criteria" in user requirements
  7. Table for roles/permissions
    1. from user requirements, assist spec team in annotating "mock" user roles with permissions
    2. refer to complete list of ongoing user roles, and resources for completion
  8. Model for workflow
    1. has spec team included an illustration of required workflow process, or sequential model ("step one, step two")?
    2. does narrative adequately communicate the workflow, or should an illustration be inserted (Google Drawing or other illustration tool)
  9. Document routing: Model for approval steps if any
  10. Business rules
(-) UI Mockups- SA with designated BA or limited SMEs
(8) Review - SME Team

(see SME Teams - Roles in Spec Writing & Analysis)

  1. Review and approve specs
  2. Finalize or add Acceptance Criteria - what and how?
  3. Note anything out of scope
  4. Meet with PM to help determine prioritization
  5. Sample data needs identified - given to SA and TC
  6. Sample technical integration points culled by TC (ie for APIs, other tech specs needed)
(9) Spec Inventory (See: Specification & Documentation Templates)
  1. Report completed specs to Project Team and Project Management (specs now available for assessment of complexity, prioritization, and scheduling)
  2. Update with drafted specs (admin process now being determined for attaching specs; updating workflows; and, combining or deleting or adding user stories as needed)
(11) Codeable Specs

See: Final Functional Specifications (template, instructions)

Once SME Team has completed its spec review, and handed off the specs to Project Management in the spec inventory, user stories and tasks will be formally assigned to the project schedule. From that re-prioritization, the SA and BA (with spec team or SME Team where needed) complete Functional Specs/Requirements docs for coding

  1. Complete UI templates or translations (if applicable)
  2. Annotate sample roles/permissions table
  3. Annotate testable document workflows/routing, approvals (if applicable)
  4. Are Acceptance Criteria reviewed and completed?
  5. Insert any additional Business Rules, KRMS (see BA & template)
  6. Completion of full Functional and non-Functional specs
(12), (17) Handoffs and Reviews - SA, Spec Team, SME Team
  1. Lead handoffs with Project Team to HTC.
  2. Participate in Q&A with developers to "translate" and manage functional requirements, as liaison to Spec Team.
  3. Coordinate developer questions with Spec Teams.
  4. Work with Project Team in any additional spec translations or technical specs.
  5. Report and manage Variations and iterative Gap Analysis as coding varies from specs due to time or technology.
(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 based on Acceptance Criteria (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, SA, SME Team

For above, see: Acceptance Criteria, Test Scripts & Testing

(iterative) Gap Analysis: SA, SME Team
  1. Participate in Gap Analysis with - SME Team - Gap Analysis
  2. Maintain Jira and organize gap reporting.
  3. General oversight
(iterative) Jira Maintenance
  1. <coming soon>
  2. administration process being modified to reflect new OLE Development Process. Responsibilities of SME Team, SA's and Project Team being determined.
  3. Jira is the definitive project administration tool for OLE, and all User Stories.
  4. Draft and final specifications are to be attached to User Stories in Jira.
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)

Role Overview

(T. McGeary, former Functional Council Chair)

The main goal of the new development process is to remove some of the technical barriers we had in the process we used before. We effectively create three stages:

  • Partner/Functional
  • Core/Technical
  • HTC/Programming

The Partner/Functional phase is to produce an inventory of functional specs as fast as possible, removing any need for SMEs to know Rice or any of the underlying technologies. In short, answer the user story by answering who, what, how. Functional details about this cataloger adds data to these fields in this order.

The Core/Technical is to translate that to technical specs for HTC to program. Because the SMEs will not be educated on the underlying technologies, we need some role to overlap functional and technical. That is the System Analyst: owning the functional spec, assisting the technical translation.

This does not mean that the SA will be an expert in Rice or another technology, but by owning the functionality of the spec, the SA can collaborate with Core and HTC (who will be learning Rice) on how a UI can be built based on Rice constraints or how Routing should work given Rice routing engine. In short, as SA's are informed by Core/HTC about how the technology needs to work, the SA can advise/collaborate/compromise with Core/HTC on each spec to be sure that the functionality is still clear when the technology is applied.

Anchor
ref
ref

Reference Documentation

BABOK: Business Analyst Body of Knowledge
For SA & BA only, in managing requirements analysis and brainstorming with spec teams

...

...

Anchor
rules
rules
Summary: Business Rules

HTML Comment

https://docs.google.com/a/kuali.org/document/d/1yFmLo1dwZ4rZgwcs8QeoBxyvfO2vdd7uAS5gB9AFgww/edit?hl=en_US

  • See also: OLE DEMO > Administration > Configuration > Functional> Parameter

Anchor
workflow
workflow
Summary: Workflows, Routing

HTML Comment

https://docs.google.com/a/kuali.org/viewer?a=v&pid=explorer&chrome=true&srcid=0B1zG4eNDtxYpZTZkZjY3NzMtMjEzZi00ZTM3LWFlZTgtMWMzZjNkYTFiN2E3&hl=en_US


OLE Roles/Workflows PDF Reference Guide (OLE 0.3 Drivers Manual)

Anchor
roles
roles
Summary: Roles, Permissions

HTML Comment

https://docs.google.com/a/kuali.org

...

/spreadsheet/ccc?key=0AlzG4eNDtxYpdDBxbFgyMGxRNGZaSVJCc1JOMnl2cFE&hl=en_US#gid=0

Summary: Document Statuses

HTML Comment

https://docs.google.com/a/kuali.org/document/d/1b3kTdVympZY8oA8HAVn-Bn4eTsCA-5nOLltUVYq6rZ0/edit?hl=en_US

...