9.4.1 Why avoiding how when defining what? Towards an OSLC-based approach to support Model-Driven Requirements Engineering

The present paper debates the concept of requirement in the contexts of software and systems engineering. Requirements are usually extracted from documents, stakeholders and existing systems generating a natural language specification. On the other hand system models are designed to define system behavior and to validate and verify the system against a specification. That is why requirements, as a basic unit of specification, must be aligned and linked to a model with the aim of supporting the whole development lifecycle of any product or service. Although some Model-based systems engineering (MBSE) methodologies have tried to bridge the gap between natural language and models moving from document-centric to model or requirement-based approaches, there is still a lack of interoperability and integration between requirements and models that prevent a proper (re) use of requirements in the whole lifecycle. Furthermore this situation is becoming a major challenge in critical systems since a complete verification and validation must be ensured. In this light the Open Services for Lifecycle Collaboration (OSLC) initiative pursues the creation of specifications to unify under a common and shared data model (the Resource Description Framework-RDF) all pieces of information and data involved in the development of a system. This initiative applies the principles of Semantic Web and the Linked Data initiative to provide a web standards-based environment for systems development. More specifically, OSLC defines the Requirements Management specification to deliver a common environment for managing and exchanging requirements. In this sense the on-going work implementing this specification and an example of modeling a controlled vocabulary for requirements management under the principles of the Linked Data and OSLC specifications is provided to demonstrate the capabilities and intentions of both initiatives. Finally some discussion, conclusions and future directions are also presented.