Requirements
From LiquidPubWiki
This article describes the main goals of the requirement analysis document as well as the intended approach for tackling the work and the organizational aspects. The document is produced as part of the deliverable D5.1 of the work package WP5.
Contents |
Goals and Scope
The deliverable 5.1v1 Design of the LiquidPub Integrated system is part of the work to be developed under the task 5.1 Requirement analysis for the LiquidPub platform and service center. This deliverable is a report that must describe the requirement, architecture and interfaces of the LiquidPub. As defined in the DoW document, this first version must cover:
- First version of the requirement analysis and mockup prototype.
- Initial definition of LiquidPub architecture.
- High level description of interfaces of the service center.
Breaking down the above general items, we can list the main aspects to be addressed:
- Functional and non-functional requirements
- Architecture constraints
- Definition of the global architecture (based on the constraints) and especially what is related to the plug-ins facility.
- Definition of the user interface: the layout, widget facilities, feeds, etc.
- Requirements for the service center.
Requirements Definition
Approach
The approach we are considering for this project is to follow an incremental vertical and horizontal analysis of requirements. This means that we are working on the definition of the different scenarios with their particular requirements (vertical requirements), and the definition of the common cross-scenario requirements (horizontal requirements). See Image:vert-hor-req.JPG
Sources
The first input of requirements is the DoW document, which establishes the overall expected characteristics of the system. Further information will be retrieved from different sources:
- Existing tools: The proposal must cover the main features of the existing related work.
- Collecting ideas from partners: The development is collaborative, so the partners are very involved in the definition of the requirements, principally in their area of specialization.
- Meetings and feedback: Continuous discussion in meetings as a result of incremental development will be the norm.
- Forums and mailing lists: It will be made available discussion forums and mailing lists. In doing so, we try to involve to the community of researchers and gather useful feedback.
Modeling
To present the results of the requirement analysis we prioritize the common understanding and simplicity. Therefore, we are using standard tools to model the different aspects of the system:
- UML: A general-purpose modeling language that includes a graphical notation . We use this tool to model the use cases, class diagrams and other aspects of the system.
- Entity-relationship model: A model to represent the conceptual model of information requirements. We use it to produce ER diagrams that represent (at a high level) key entities of the system.
- Other tools and notations: As this is a novel project building new concepts, it is assumed that not all its features will be able to be modeled using standard tools. Therefore, when required, it will be used notations considered more appropriated.
Validation
Validating the requirements is a main issue to be considered, because the requirements establish the scope of the project and the features to be implemented. Therefore, it is required a continuous evaluation and feedback to ensure a right output. Anticipating this situation, the requirement (as a deliverable) was broke down into versions. Even so, every version before being submitted to the EU project will pass through different review instances. There will be basically two approaches that will collaborate with the validation:
- Internal and external reviews involving the partners and the community;
- The mockup prototype and the community feedback on it to validate the functional requirements.
From the point of view of the team that develops the document, the “alpha” validation will be the bidirectional traceability of the requirements. It means that we have to ensure that every system feature have its correspondent requirement, the requirement its source and vice versa.
Organization
Base requirements
- See main article at LiquidPub base requirements
Scenarios
In general, there are six scenarios to be considered for LiquidPub: Publications, (European Union) Projects, Student Class Projects, Courseware, European Research Council Evaluation (ERC) and Future and Emerging Technologies Open Scheme (FET-Open). In the following subsections, we briefly describe each one of them.
Publications
- See main article at Publications Scenario
(European Union) Projects
- See main article at Projects Scenario
Student Class Projects
- See main article at Student Class Projects Scenario
Courseware
- See main article at Courseware Scenario
European Research Council Evaluation
Future and Emerging Technologies Open Scheme
External documents
- Functional requirements and examples (gdocs)
- Platform requirements (gdocs)
- GUI Mockup
- A LiquidPub Note: On Credit Attribution and its Imposed Restrictions on the SKO Model (pdf)
- Use cases
