Reference Hub1
Modeling Business and Requirements Relationships to Facilitate the Identification of Architecturally Significant Requirements

Modeling Business and Requirements Relationships to Facilitate the Identification of Architecturally Significant Requirements

Javier Berrocal, Jose Garcia-Alonso, Juan Manuel Murillo
Copyright: © 2014 |Volume: 2 |Issue: 1 |Pages: 16
ISSN: 2166-7160|EISSN: 2166-7179|EISBN13: 9781466656598|DOI: 10.4018/ijsi.2014010102
Cite Article Cite Article

MLA

Berrocal, Javier, et al. "Modeling Business and Requirements Relationships to Facilitate the Identification of Architecturally Significant Requirements." IJSI vol.2, no.1 2014: pp.9-24. http://doi.org/10.4018/ijsi.2014010102

APA

Berrocal, J., Garcia-Alonso, J., & Murillo, J. M. (2014). Modeling Business and Requirements Relationships to Facilitate the Identification of Architecturally Significant Requirements. International Journal of Software Innovation (IJSI), 2(1), 9-24. http://doi.org/10.4018/ijsi.2014010102

Chicago

Berrocal, Javier, Jose Garcia-Alonso, and Juan Manuel Murillo. "Modeling Business and Requirements Relationships to Facilitate the Identification of Architecturally Significant Requirements," International Journal of Software Innovation (IJSI) 2, no.1: 9-24. http://doi.org/10.4018/ijsi.2014010102

Export Reference

Mendeley
Favorite Full-Issue Download

Abstract

In architectural decision making, the architects have to acquire a complete picture of the system. This picture is obtained analysing the business information and the system requirements. The relationships between business elements or between requirements are particularly important to know the impact of each quality requirement on the system. However, due to the focus of each artefact and notation on documenting specific elements, the relationships between elements of different kind are kept implicit. This requires an in-depth analysis of the models generated on the part of the architect in order to make them explicit. Misunderstandings that take place during this stage can lead to an incorrect design. Here, a set of BPMN and UML profiles to explicitly represent these relationships is presented, together with a model for documenting how each non-functional requirement impacts on the system views. Thus, more information is provided to the architect, thereby decreasing the risk of misinterpretation.

Request Access

You do not own this content. Please login to recommend this title to your institution's librarian or purchase it from the IGI Global bookstore.