 | SD-Systems | 14 Members |
| Systems Engineering riot room for Space Decentral | 1 Servers |
| SD-Systems | 14 Members |
| Systems Engineering riot room for Space Decentral | 1 Servers |
| Sender | Message | Time |
|---|---|---|
| 16 Dec 2018 | ||
 udit.kumar.sahoo | Requirements have attributes, some are mentioned above. And more importantly traces. | 00:39:26 |
| udit.kumar.sahoo | Even before we go for requirements or use cases, we need to discuss on the stakeholders. | 00:42:02 |
| udit.kumar.sahoo | Watch "Stakeholders and Stakeholder Mapping" on YouTube https://youtu.be/gc55hPIFW8w | 00:44:54 |
| udit.kumar.sahoo | Watch "System Stakeholder Analysis" on YouTube https://youtu.be/rLS9Gaocex4 | 00:51:34 |
 outbound | Wow, you folks have been busy busy. I'll have to wade through it all... | 02:35:31 |
| udit.kumar.sahoo | https://github.com/spacedecentral/Coral/commit/befa2d77f48b2141bde5462195705db3eb0878c4 | 03:27:37 |
| udit.kumar.sahoo | Added a WIP template for requirements | 03:27:54 |
 sean | @Udit spreadsheet sounds fine for now, though if possible, I'd advocate for a format that's also viewable in github. Unfortunately, I don't have a perfect solution for this, as the formats that come to mind are csv or a markup language that supports tables. Thoughts? | 04:45:45 |
| sean | I'm also working on (what hopefully will be) a YAML schema for storing requirements, among other data pertaining to a system model, for more extensible use cases, but I'll hold off that discussion 'til it becomes more relevant | 04:46:34 |
| udit.kumar.sahoo | The best part of the table is that it can be easily linked and converted to several representations. I am interested to see what you will have sean | 04:49:02 |
| sean | Will keep the channel posted once there're some interesting updates (I usually try and spare these channels of boring data management and semantic web talk). Regardless of data format, it seems requirements (among other things) hinge on the need for id numbers, if we want some local or universal means of referencing them? I've seen systems engineering tools use a uuid's, but for requirements in particular, they've often used a local id, s.a., REQ001 used in conjunction with a uuid, but haven't worked with them in practice. Any thoughts as to how we should we go about generating requirement id numbers? | 05:18:57 |
| udit.kumar.sahoo | First and foremost, we need a unique number generator. May be a macro or something for excel spreadsheet, until we move on to something better. | 05:26:41 |
| udit.kumar.sahoo | But as we move beyond into Subsystems, we would define acronyms to each sub system and associate unique numbers to each | 05:27:48 |
| udit.kumar.sahoo | For example, MAN/235/1 | 05:28:27 |
 suzi.bianco | What's wrong with just req001 and sequence? Sorry guys ðŸ¤ðŸ¤ðŸ¤ | 05:28:38 |
| udit.kumar.sahoo | Where MAN - Manufacturing, 235 - some requirement, 1- requirement version | 05:29:23 |
| suzi.bianco | Do what you must, all I ask is to keep letters not capitalized for the sake of better reading. 😉 | 05:29:45 |
| udit.kumar.sahoo | suzi.bianco: as our requirements cascade below down to subsystem, it will become problematic for us to just speak numbers, alpha numeric requirements will give some context | 05:30:51 |
| udit.kumar.sahoo | Version would say if the requirement is changed or not | 05:31:36 |
| sean | I'm going to hate myself for suggesting this... but we cOuld generate the id as (truncated version of?) a hash of the requirements text. That way, if the requirements change, it'll be reflected in the id. | 05:45:48 |
| sean | In reply to @suzi.bianco:matrix.orgone problem with sequential id no's is it requires more "bookkeeping". Someone or something has to keep track of the latest id no that was generated in order to generate a new one. it also restricts teams from working in parallel, since you always have to be "in sync" with the master record that maintains the latest count id | 05:48:27 |
| udit.kumar.sahoo | It'll become difficult to manage if the requirement id changed every time | 05:48:28 |
| sean | In reply to @udit.kumar.sahoo:matrix.orgthat's where the uuid comes in handy, since that only gets generated upon first instance, then never changes from there | 05:49:23 |
| sean | a version 1 uuid also has embedded date & time stamps if for whatever reason we wanted to take advantage of that feature | 05:50:25 |
| sean | i.e., we use both a truncated hash (similar to github's commit history) for identifying changes, and a uuid as a sort of "social security number" that's assigned at birth. (yes, hate myself already) | 06:03:31 |
| udit.kumar.sahoo | I might need an example to understand it :) | 06:06:00 |
| sean | udit.kumar.sahoo: created a feature branch just for this demo https://colab.research.google.com/drive/15wTzAoQRGyH4IdxQYHgoY_UEtTa5--rn | 07:28:22 |
 neutronstar | If we go with using GitHub issues it will handle IDs for us, though the ID will not say anything about what kind of requirement it is. I'm not really happy with using a document for requirements. Getting all the links correctly will be such a pain. Using issues GitHub will help with this. I don't see using issues is more (or less) complicated than a spreadsheet. | 07:28:46 |
| neutronstar | With tools I've used (Jira) it's possible to select what view you want when looking at the issues, meaning you could create a view with e.g. only requirements for your subsystem, or only requirements that can be tested using regression testing, or something else. This would be hard using spreadsheet. | 07:31:27 |
| udit.kumar.sahoo | I'm happy to try out issues in Github. Can we create some samples and test out? | 07:39:48 |