Abstract
Functional requirements (FRs) capture the intended behavior of the system, in terms of the services or tasks the system is required to perform, while non-functional requirements (NFRs) are requirements that impose restrictions on the product being developed 3. Despite the obvious importance and relevance of non-functional requirements, NFRs specified during requirement engineering are almost always left to be verified after the implementation is finished, which means NFRs are not mapped directly and explicitly from requirements engineering to architectural design. This leaves software development with potential exacerbation of the age-old problem of requirements errors that are not detected until very late in process. Modeling and analyzing NFRs in software architectures at least partially overcomes this deficiency. This position paper introduces our early research, which proposes a grouping mechanism, similar to the separation of concerns achieved in Aspect-Oriented Programming (AOP), to model NFRs in software architectures directly and explicitly. This eventually directs our ultimate research goal, which is to verify software architecture with respect to NFRs defined in requirements engineering. An example of how we model NFRs in software architecture is provided using the canonical KLAX example for the C2 architectural style.
Author supplied keywords
Cite
CITATION STYLE
Xu, L., Ziv, H., Richardson, D. J., & Liu, Z. (2005). Towards Modeling Non-Functional Requirements in Software Architecture. Aspect-Oriented Requirements Engineering and Architecture Design Workshop, Early Aspects 2005, 1–6.
Register to see more suggestions
Mendeley helps you to discover research relevant for your work.