link to architecture page
link to applications page
link to software page
link to open specification page
link to project information page
link to bibliography page
link to follow-on activities page
link to news page

link to index page

Provenance Requirements

All partners of the project produced user requirements and scenarios from which technical requirements of the Provenance Architecture were derived. As part of this activity, we also included scenarios derived from national projects, such as e-Diamond and myGrid, and other grid applications to make the provenance architecture to be designed and developed generic. The System Development Department of SZTAKI developed an on-line questionnaire to be filled in by the project partners, other partners from national projects as well as EU FP6 projects in the grid area. The results of the questionnaire were summarised and evaluated. The evaluation results were captured in the User Requirements Document (URD) and the Software Requirements Document (SRD), which are in conformance with the recommendations of the ESA Software Engineering Standard and covers the first two phases of the software life cycle. Beyond the scientific and engineering domains, we also captured broader e-Business requirements by involving the IBM members of the project.

The definition of the user requirements was the responsibility of the users, but the expertise of software engineers and researchers was used to help define and review the user requirements. The scope of the software system was established and the interfaces with other components were identified. The following were determined: the operational environment of the system; capabilities needed by users to solve the problem; constraints placed by users on how the problem is to be solved; the human computer interaction requirements; usage scenarios; the quality attributes of adaptability, availability, portability, scalability and security.

The purpose of the software requirements phase was to analyse the statement of user requirements in the URD and produce a set of technical and software requirements as complete, consistent and correct as possible. The problem was be analysed, as stated in the URD, and a coherent, comprehensive description of what the software is to do was built. The output was the SRD, which contains a developer’s view of the problem, rather than the user’s. The SRD was the reference against which both the design, as well as the aerospace and medical prototypes were verified.