Project Description

Create a requirements management tool (RMT) based on a graph database.

This is my personal space page where I will be keeping notes and such:

Why?

  • First, I'm a requirements engineer, have been for 15 years, and I've used a variety of RMTs in that time. Most are cumbersome, expensive beasts that most engineers hate to use. I think I have the experience and insight to design an RMT that does its job well and won't earn the ire of its users.

  • Second, graph databases fascinate me and I would love the chance to learn about them in the context of an RMT. A cornerstone of requirements management is traceability, i.e. linking between requirements. I believe a graph database would naturally solve problems that RMTs have in traceability.

  • Third, my programming language of choice is Ruby and I would like to learn Ruby on Rails.

Example RMTs (strong, heavy engineering, expensive, used in automotive, aviation, etc. industries) include DOORS, DOORS Next Generation, Polarion, Jama. I would consider Jira a weak RMT, in that it can be wrestled into being an RMT but was not designed for it.

Project Goals

Primary Goals:

  • Learn to use graph database Neo4j in the context of managing requirements.

  • Learn to use Ruby on Rails in the context of submitting searches to Neo4j and displaying/interacting with results.

Secondary Goals:

  • I learn by example so I would like to make examples of what I/we learn that could be easily dissected and copied.

Of course, if you joined and had other goals I would love to hear about them!

Project Plan

Infrastructure:

  • Setup server/VM thingy to host the project.

  • Install Neo4j graph database and be able to manipulate data and query from the command line.

  • Come up with small dataset of requirements including linking to initially populate graph database.

  • Install Ruby on Rails and make sure initial canned page can be accessed from outside the server/VM thingy.

  • Setup git somewhere to version control the project.

Essentially, what I want to have in the end is this:

  • Login page, something standard and secure.

  • Query page, where you type in the search query. First step would be entering "cypher" which is what the Neo4j search language is called. The next two are stretch goals... Second step would be coming up with some kind of JQL (Jira Query Language) like thing that typical users are used to. Third step is developing a search/results chain - this idea I would have to explain to you with pictures, it's hard to describe in pure text.

  • Results page, where you see and interact with the search results. First step would be displaying the results in a traditional spreadsheet-like matrix. Rows are nodes, columns are attributes. Rows come from the search results. Would need a way to add columns including linked content. Second step would be interacting with the results like changing attribute values and linking. Also sorting of results. Would really need to implement all of this for the project to be useful.

  • Port page, where you can export the results. First step is export to CSV, Excel, XML, JSON, YAML, whatever. Second step would be importing to change database. The whole Port page is a stretch goal.

I have a bunch more notes and drawings about how I want it to look and work and I will try to get those added here before Hack Week starts.

Collaborators

I could really use someone experienced in setting up, configuring, and developing Ruby on Rails, or at least willing to learn with me. I know Ruby but have never worked with Ruby on Rails.

Someone has expressed interest in helping me here = I could really use someone experienced in setting up and configuring the infrastructure. My main problem with these kinds of projects is the infrastructure and initial setup. I usually fail miserably in this regard. Or even if you could help me pre-Hack Week during off hours, that would be a big help! Learning how to do this stuff is not a goal of mine. I've always been bad at this and I have no interest in getting better. I just want it done.

And this is Hack Week after all, so anyone is welcome to join me!

By the way, I don't know if this is a Hack Week thing but I would certainly accept partial commitments of some hours. Especially for infrastructure. I would like to focus on my primary goals and not wrestling with setup.

Keywords

requirements, requirements management, requirements engineering, graph, graph database, ruby, ruby on rails

Post Mortem

That didn't go well... I won't complain though; I am very appreciative to SUSE for giving me the opportunity to work on the project on their dime and time.

Looking for hackers with the skills:

ruby rubyonrails graphdb graphql requirements

This project is part of:

Hack Week 20

Activity

  • over 3 years ago: radolin liked this project.
  • over 3 years ago: llansky3 liked this project.
  • over 3 years ago: mknop started this project.
  • over 3 years ago: mknop liked this project.
  • over 3 years ago: mknop added keyword "rubyonrails" to this project.
  • over 3 years ago: mknop added keyword "graphdb" to this project.
  • over 3 years ago: mknop added keyword "graphql" to this project.
  • over 3 years ago: mknop added keyword "requirements" to this project.
  • over 3 years ago: mknop added keyword "ruby" to this project.
  • over 3 years ago: mknop originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

    Description

    "LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

    However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

    The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

    Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

    Goals

    Goals of this project:

    • Modify the RSpec tests and run them against a real LDAP server
    • Replace the net-ldap rubygem with the ruby-ldap rubygem

    Achieving the above mentioned goals will:

    • Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
    • Make a step towards officially supporting LDAP in OBS.

    Resources


    Recipes catalog and calculator in Rails 8 by gfilippetti

    My wife needs a website to catalog and sell the products of her upcoming bakery, and I need to learn and practice modern Rails. So I'm using this Hack Week to build a modern store using the latest Ruby on Rails best practices, ideally up to the deployment.

    TO DO

    • Index page
    • Product page
    • Admin area -- Supplies calculator based on orders -- Orders notification
    • Authentication
    • Payment
    • Deployment

    Day 1

    As my Rails knowledge was pretty outdated and I had 0 experience with Turbo (wich I want to use in the app), I started following a turbo-rails course. I completed 5 of 11 chapters.

    Day 2

    Continued the course until chapter 8 and added live updates & an empty state to the app. I should finish the course on day 3 and start my own project with the knowledge from it.

    Hackweek 24

    For this Hackweek I'll continue this project, focusing on a Catalog/Calculator for my wife's recipes so she can use for her Café.

    Day 1


    Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

    Description

    "LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

    However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

    The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

    Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

    Goals

    Goals of this project:

    • Modify the RSpec tests and run them against a real LDAP server
    • Replace the net-ldap rubygem with the ruby-ldap rubygem

    Achieving the above mentioned goals will:

    • Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
    • Make a step towards officially supporting LDAP in OBS.

    Resources