SME Team SA - Spec Writing & Analysis

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

Contents

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

Task Assignments

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

    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: - 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 - Not sure (Archive?)(linked samples)
    3. Reference: - original workflow modeling if able to reuse

    4. Pre-populate and as able

    5. Link other helpful collections or documents via Google Collections into Spec Team folder
  4. Train the spec teams - utilize this wiki!
    1. Google Docs
    2. Webex
    3. Spec Writing
  5. Organize and oversee spec writing by spec teams
  6. Complete with Spec Team "User Requirements" template
  7. 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
  8. Assist spec team in annotation and understanding of "Acceptance criteria" in user requirements
  9. 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
  10. 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)
  11. Document routing: Model for approval steps if any
  12. 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 - Not sure (Archive?))
  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.
 
Phases:
(info) For the complete model, see
OLE Development Cycle

Spec Writing


Coding


Testing

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.

Reference Documentation

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

Summary: Business Rules

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

Summary: Workflows, Routing

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

Summary: Roles, Permissions
Summary: Document Statuses

Operated as a Community Resource by the Open Library Foundation