2001
DOI: 10.1007/s007660170013
|View full text |Cite
|
Sign up to set email alerts
|

From Non-Functional Requirements to Design through Patterns

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
1
1
1

Citation Types

0
97
0
1

Year Published

2005
2005
2011
2011

Publication Types

Select...
6
2
1

Relationship

0
9

Authors

Journals

citations
Cited by 170 publications
(98 citation statements)
references
References 18 publications
0
97
0
1
Order By: Relevance
“…The source and target languages are respectively the i* modeling language and Acme architectural description language [21]. Gross and Yu [14] proposed a systematic treatment of NFRs in descriptions of patterns and when applying patterns during design. The approach organizes, analyzes and refines non-functional requirements, and provides guidance and reasoning support when applying patterns during the design of a software system.…”
Section: Requirements To Architectural Designmentioning
confidence: 99%
“…The source and target languages are respectively the i* modeling language and Acme architectural description language [21]. Gross and Yu [14] proposed a systematic treatment of NFRs in descriptions of patterns and when applying patterns during design. The approach organizes, analyzes and refines non-functional requirements, and provides guidance and reasoning support when applying patterns during the design of a software system.…”
Section: Requirements To Architectural Designmentioning
confidence: 99%
“…Many efforts for bridging the gap between the requirements and architecture have considered a goal-oriented approach (e.g. [Gro01,Liu01,Bra01,Cas02]). Among them, [Lam03] and [Jan05] describe two different processes for deriving architectural designs form goal-oriented requirements models expressed in KAOS.…”
Section: Related Workmentioning
confidence: 99%
“…E.g. safety, security, reliability, usability, maintainability, cost and development time (Gross and Yu 2001). High level nonfunctional requirements often decompose into functional requirements they are not specifically concerned with the functionality of a system, placing restrictions of the product being developed and the development process.…”
Section: Requirementsmentioning
confidence: 99%