Versions Compared

Old Version 22

changes.mady.by.user Jay Hill (Unlicensed)

Saved on

compared with

New Version 23

changes.mady.by.user Jay Hill (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleSection Explanation. Click to expand.

The product requirements document (PRD) is a central document used to align all stakeholders (product management, engineering, QA, designers, and leadership) on how we will solve a specific problem with the proposed solution.

When creating the PRD, provide just as much information as needed and nothing more. If the document is too long and complex, it will quickly become outdated, and readers will lose interest.

In this latest iteration of the Unified Compliance PRD template, we changed the template to help raise visibility of how the proposed product (or feature set) adheres to Unified Compliance’s strategic plan including details on why this product proposal is important to Unified Compliance.

Strategic Planning and Decision Making

Expand
titleSection Explanation. Click to expand.

  • Vision and Goal Setting: articulates the vision alignment, problem being addressed, and goals of the product proposal describing what the product is, who it is for, and how it will benefit the users and the organization.

  • Decision-Making Framework: helps in making informed decisions throughout the product development process acting as a reference point for evaluating progress and making changes.

  • Performance Measurement: sets the criteria for measuring the success of the product through specified metrics and key performance indicators (KPIs) including potential financial impact.

    • Basis for Prioritization: helps in prioritizing features based on the product strategy, market needs, and resource constraints

    Describe the problem we are solving, the high-level approach, and goals so that before we get too far into the details, readers will have a good understand of where we are headed.

    Expand
    titleThe Problem

    What problem are we trying to solve?

    We currently rely on a team of expert mappers to meticulously add content into the UCF. The process works well but is slow. With the advent of automation and AI, Unified Compliance risks attacks from competitors who will use technology to accelerate content acquisition.

    We risk losing customers to other platforms if we fall behind on the extent of coverage.

    We will also find it difficult to take on new market segments without automation.

    ...

    Expand
    titleSection Explanation. Click to expand.

    The intent of this section is for the following:

    Scope Definition: defines the scope of the proposed product (or features), including what will and will not be included helping manage expectations and focus development efforts.

    Guideline for Development: provides detailed information on the product’s features, functionalities, user flow, and interface to guide the development team in building the productsection focusses on the details of the solution including what is in scope, what is out of scope and additional information to help in the product and engineering collaboration process.

    Expand
    titleFeatures

    Describe the product features that will bring value to customers and fulfill underserved need(s).

    Feature

    Use Case / Problem Solved

    Automatic Citation and Glossary Extraction from Authority Documents

    Out of all the ancillary information found in Authority Documents, specific passages containing Mandates (requirements) and related contextual information such as stubs, informational, and informational gathering are extracted from the Authority Documents.

    Human-in-the-loop Training for Content Extraction AI Models

    Expert mappers can validate and make changes about the correctness of the AI-driven Citation extraction helping train the AI model to produce increasingly better results.

    Automated Compliance Content Ingestion into the Common Data Format

    Authority Documents (initially targeted for STIGs, NIST 800-53, FedRAMP, and eCFR) are loaded into the UCF platform with minimal human intervention.

    Monitoring and Logging

    Administrators can make informed decisions and take action on the ingestion process based on meaningful information is collected throughout compliance content ingestion process.

    Metadata and Data Change Detection

    Compliance professionals are kept to up to date with changes made by compliance content providers.

    Statistical Data Capture and Reporting

    Product and engineering teams can review statistical results captured during the document ingestion process to help make objective data-driven decisions about the accuracy and effectiveness the process automation.

    Expand
    titleOut of Scope / Future Functionality

    List the known features that are out of scope for this project or might be revisited at a later time.

    As is case with the assumptions, it is important to list these out so that architects and engineers can plan accordingly for these later updates.

    Feature

    Comments

    Tagging and Mapping of content to the Common Controls.

    This project ends at the AD, Citation and Glossary extraction, transformation, and load.

    Follow-on projects will include the tagging and mapping.

    Human-in-the-loop for content capture.

    Later projects can include additional human validation. To limit scope of this project, steps such as metadata change detection can be reviewed and validated after the fact looking at logs and other information.

    Human-in-the-loop for the AD cataloging.

    Same as above

    Human-in-the-loop for transformation into the common data format

    Same as above

    Human-in-the-loop for loading into the UCF

    Same as above

    Corpora Management and Administration

    A non-production version of a corpora exists. Any work on the corpora is out of scope for this product.

    Corpora Data Loads

    The focus of this PRD is to load compliance content into the UCF 4.0 application for customer consumption over the API.

    Follow-on projects can tap into the pipeline and use the content for other purposes.

    Fit-for-purpose frontend for each step in the content ingestion process.

    UX/UI for any other aspect of the process outside of human review and approval of suggested citations and suggested term-definition pairs.

    Later product updates could include additional front-end steps for tasks throughout the process.

    Link to mockups, prototypes, or screenshots
    Expand
    titleUser Interaction Process flows and Design
    UX

    If we have them, link to:

    Links to user journeys, process flow, or other diagrams

    • user journeys, process flow, or other diagrams related to the requirements.

    For this PRD, the focus of the user interaction is on the reviewing of suggested citations and term-definition pairs.

    Expand
    titleProcess Flow Diagrams

    • mockups, prototypes, or screenshots related to the requirements.

    Expand
    titleImpacted Product Components

    If this project is a component to other areas or an update to an existing product, specifically call out where this product will interact with other areas.

    Expand
    titleOpen Questions

    List any open questions that come to mind throughout the lifecycle of this initiative.

    Question

    Answer

    Date Answered

    What do we do with deprecated authority documents?

    For STIGs, how do we identify which files are authority documents?

    For NIST 800-53, how do we identify which files are authority documents?

    For FedRAMP, how do we identify which files are authority documents?

    For eCFRs, how do we identify which files are authority documents?

    Specifically, what is required to catalog an AD?

    In this first pass, what should constitute content changes?

    We don’t want to get too crazy and make this a massive project.

    Need to discuss.

    Expand
    titleAlternative Solutions
    Provide a high-level evaluation criterion for alternative solutions (build, buy, partner) to evaluate different routes to success

    .

    Milestones and Launch Checklist

    Expand
    titleSection Explanation. Click to expand.

    The intent of this section is for the following:

    Technical Risk Mitigation: Identifies potential technical risks and propose mitigation strategies.

    Launch Readiness: launch checklist including high-level go-to-market plan to ensure cross-departmental alignmentis mostly focused on getting the solution “out the door” and who else is affected outside the product and engineering teams.

    Expand
    titleTechnical Risk Mitigation

    If applicable, identifies potential technical risks and propose mitigation strategies.

    Risk

    Mitigation Strategy

    The eCFR content volume could cause multiple challenges including impact on API responses, searches, dominate other content sources …

    ...