Requirement Document Creation and Maintenance

What’s this issue all about?

We believe there's value in providing users a way to document and manage requirements for both regulated and non-regulated industries. We want to explore the needs of these users and possibly attempt to offer a way to provide these options.

Users in regulated industries often require a way to manage requirements. Additionally, users in non-regulated industries often desire a way to assess completeness / correctness through testing - which would lend itself to documenting requirements.

Who is the target user of the feature?

What questions are you trying to answer?

  1. Is this useful to our target users? If so, why? If not, why not?
  2. What are they currently using for requirement documentation? What are their pain points and delights with those applications?
  3. Do needs differ in terms of requirement documentation for regulated and non-regulated industries? If so, how?
  4. What needs do they have in terms of documentation features? Assumptions: WYSIWYG standard editing capabilities such as bold, list creation, image and link addition options.
  5. What do they need to be able to do with the requirements documentation?
  6. At what point in their process do they need the ability to create this documentation?
  7. How frequently do they need to revisit or edit requirements?
  8. What exactly is a requirement document?
  9. Does the concept of a requirement vary from one org to another and, if so, how?
  10. What is the competition offering?
Core questions
  1. What exactly is a requirement document?
  2. What are they currently using for requirement documentation?
  3. What is the competition offering?
  4. What do they need to be able to do with the requirements documentation?
  5. Is this useful to our target users? If so, why? If not, why not?

What hypotheses and/or assumptions do you have?

Ideally, we should begin by defining what makes up a requirement. To begin, it makes sense to think of a requirement as an artifact which describes the specific behavior of the product.

In industries where requirements are flowed to a development team, these teams generally will follow the steps outlined here:

  • Capture and control the customer (high level) requirements. These are generally somewhat generic and not implementation specific, but offer constraints related to how the product will interact with other existing products, or the outside system. (Product Managers / Technical Architects)
  • Decompose the high level requirements into lower level requirements (behaviors). These lower level requirements are linked to the higher level requirements which they satisfy. In many instances, these lower level requirements are made up of the product design. (Technical Architects / Engineers / Designers)
  • Implement the lower level requirements. This often causes iteration on both the implementation and the lower level requirements. (Engineers / Designers)
  • Where necessary, develop testing to verify either the high level requirements, or the lower level requirements. These tests (and associated results) ideally link to the requirements being tested. (Test Engineers)
  • Where necessary, verification results are gathered into a report showing necessary coverage of requirements or compliance. (Quality Engineers / Compliance Engineers)

Because requirements would be a development artifact, they could be considered similar to source code or test procedures. In the future, issues should be able to be written to create and modify requirements through the familiar issues / merge request process.

What decisions will you make based on the research findings?

Proceed with exploring design options for implementing research.

What's the latest milestone that the research will still be useful to you?

12.6

Methodology

Competitive analysis. Exploratory research and calls to build a better understanding of the space. This will feed into the MVC.

Progress

Holly - Competitive Analysis

Katherine - Exploratory Calls

  • Contact Sales & Customer Success [Deadline: Fri Nov 15th]
    • Reach out to Jay Jewell regarding customers interested [Deadline: Fri Nov 15th]
    • Schedule call with Chris Rennie to discuss government perspective [Deadline: Mon Nov 18th]
    • Schedule calls with external POC [Deadline: Fri Nov 22nd]
  • Draft an interview guide [Deadline: Mon Nov 18th]

Links

Edited by Justin Farris