Closed albermax closed 2 years ago
Hi @leanderweber @enryH @rachtibat
here is a first draft. Please let me know if this makes sense to you and what you think.
Cheers, Max
Hi @albermax ,
thanks for the draft! I think moving to Google Docs would be a great idea, since editing/updating of the requirements, and commenting would be easier.
For now I would suggest the following additions/changes:
Stakeholder requirements:
Software requirements:
Hi Max,
Thank you for writing everything out! Yes, I think we should switch over to google docs. And we should speak more about the points during the meeting - especially in regards of performance.
Best
since come comments indicate activity towards a 2.0 version (I cannot wait :-) ) I have two questions:
is there some approx. ETA for tf2 compatible innvestigate 2.0 that you could share with us (users)?
and if there is some branch that already works in some cases it would be quite interesting to know where to find (at least I could not figure out the most recent code version)
Hi Moritz,
We are aiming for a first release before August.
In the meantime you can use the updates_towards_tf2.0
dev branch, which already implements LRP analyzers in TF2.
Hello, thank you for offering us such convenient explaining tools! I wonder if the method Grad-CAM could be added in iNNvestigate 2.0?
@adrhill it would be great, if you give an update on the release schedule or point us to information about it. in particular I am strongly interested when pattern attribution is available for tf2
Hi Moritz,
thanks for your patience! We're currently working on exactly that: making the pattern attribution methods run on TF2. Once they work, we might release a final TF1 version that runs on the tf.keras
backend (as there are several open issues asking for this) and soon after the TF2 version.
Hi @moritzaugustin, this took longer than anticipated, but iNNvestigate 2.0 is now released!
I suggest we approach the planning in the following way:
I know many things are "trivial", but IMHO it is good to have them listed and in mind when making decisions. Also compared to coding the whole package, planning it takes not that much time. :-)
Also, those requirements change over time. The idea is to then update accordingly the derived requirements/architecture/interfaces/implementations.
Stakeholder requirements
Stakeholder is someone how will interact with this package in some way. Such requirements give a broad direction to the planning and are use case oriented. Mind stakeholders are more of a role than real persons - one person can have several roles.
Software requirements
SW requirements are software oriented and typically derive from stakeholder requirements.
Architecture & interfaces
fit
/analyze
pattern?Open questions:
Todos: