search

AhmedAl-Hayali / GenreGuru

Music Featurization, Recommendation, and Generation
MIT License
3 stars 1 forks source link

admin[SRS-9-17]: follow up on rev0 feedback #242

Open AhmedAl-Hayali opened 1 week ago

AhmedAl-Hayali commented 1 week ago

Hunter says there's "Too much mentioning of languages/libraries/APIs that will be used, this should still be abstract" but multiple internal reviews and cross-checking with other teams contradicts this.

AhmedAl-Hayali commented 1 week ago

Hi @cer-hunter, avenue feedback states that our SRS sections 9-17 have "[t]oo much mentioning of languages/libraries/APIs that will be used," which "should still be abstract." I suspect we'll likely be overhauling section 9[^1], but we're curious as to where we went wrong here nonetheless. No regrade requested or necessary, we just don't see the issue raised in the feedback.

[^1]: Project scope has changed and we have more visibility on functions going forward. We may augment the scientific SRS component despite not being a scientific/research project exclusively because we'll be diving deep into feature extraction and audio analysis :)

cer-hunter commented 1 week ago

Hey, so for the SRS design decisions are still meant to be abstract (so like you can say you want a library that does x thing, but you shouldn't specify which library your going to use yet). This is because someone should be able to make your project from scratch from the SRS, and as long as they meet requirements, their design choices could be completely different. It also leaves room incase you want to change things later... you wouldn't have to go back and change the entire design doc. Hopefully that makes sense.

AhmedAl-Hayali commented 1 week ago

Hey, so for the SRS design decisions are still meant to be abstract (so like you can say you want a library that does x thing, but you shouldn't specify which library your going to use yet). This is because someone should be able to make your project from scratch from the SRS, and as long as they meet requirements, their design choices could be completely different. It also leaves room incase you want to change things later... you wouldn't have to go back and change the entire design doc. Hopefully that makes sense.

@cer-hunter Makes sense, but we made an effort to keep things abstract and can't see which requirement(s) violated the rule even in retrospect - would love a pointer towards the requirement(s) of concern if possible 🙏