Feedback on DSA2.1_v1 by Andres:

Hi Maria,

some comments:
- 4.4.1. requirements: I believe you can start putting what requirements are needed in current software, and with the feedback complete with the future ones. You say that it does not make sense to request a document for the current software, but I think it is very important. Current fulfilled requirements are important in order to know what is done, but also to know that the current features have to be also in future releases. For the future documents, we can, with the complete list of requirements, include a traceability matrix (requirements vs tests).

- 4.4.2 software design: I agree with you. In this initial step a good Software Architecture document should be enough.


Feedback on DSA2.1_v1 by Dabnilo:

Hi Maria,
I'm not sure this is the right document to give the following feedback. Anyway, concerning section 4.1.1 SW requirements, even though it is true that many components have been there for a long time, so that we could suppose that SW requirements are clear and  bugs can be a good index of "users's further requirements",  I think there should be documentation on this point with the contribution of NA2 in collecting feedbacks in a more structured way. 
To give a practical example coming from my experience (gliteWMS) we had many feature/bugs requests from different users communities which eventually could end in conflicting architectural implementations. Another example: big HEP VOs with their submission agents have different problems (submit different bugs) than other smaller scientific communities stressing more on mpi, usability etc.etc. 
In these cases  it is very difficult to assign a priority to users's requests, cause a general framework where all requests are collected, compared, and ordered according to some priority criteria is missing. 
Also in the process of merging different middlewares (Arc, Unicore, glite) it could be a good thing to have a clear idea of:
•	which communities of users we want to satisfy
•	what do they require
•	what priority we give to their requirement and how we decide whether all these requirements will not conflict with service initial design
In my opinion this is a key point for SW quality assurance.
Cheers
Danilo