Workpackage 2: Requirements Capture

This workpackage will focus on requirements capture. All partners of the project will produce user requirements and scenarios from which technical requirements will be derived. As part of this activity, we will also include scenarios derived from national projects the partners are involved in, such as e-Diamond and myGrid. The plan here is to bring requirements from other applications to make the provenance architecture to be designed and developed generic. The work package will develop 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 will be summarised and evaluated. The evaluation results will be 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 will also capture broader e-Business requirements by involving the IBM members of the project.

The definition of the user requirements will be the responsibility of the users, but the expertise of software engineers and researchers will be used to help define and review the user requirements. The scope of the software system will be established and the interfaces with other components will be identified. The following will 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 is 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 will be analysed, as stated in the URD, and a coherent, comprehensive description of what the software is to do will be built. The output will be the SRD, which contains a developer’s view of the problem, rather than the user’s. The software requirements will be produced by constructing an implementation independent logical model of what is needed by the user. The software requirements will contain the functional, performance, interface, operational, resource, verification, acceptance testing, documentation, security, portability, scalability, quality, reliability, maintainability, and safety requirements. Wherever possible, software requirements will be stated in quantitative terms to increase their verifiability. The requirements will include identifiers, references to user requirements as well as measures of need and priority. For the SRD to be complete, each requirement in the URD will be accounted for. The SRD will be checked for consistency, and duplication of requirements will be avoided whenever possible. Descriptions of functions will say what the software is to do, and must avoid saying how it is to be done. The SRD is also the reference against which both the design and the prototype will be verified. We note that software requirements include a survey of the software environment in which the provenance architecture will be deployed, including the enactment engines to interact with (and their extensibility capabilities) and the services to be invoked (Web Service, Grid Services, etc.).
to top