Planguage Basics and Process Control

Gilb, Tom; Brodie, Lindsey

doi:10.1016/b978-075066507-0/50005-2

Cited by 22 publications

(30 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In other words: of all the Requirements in an RfP, the NFRs have the biggest role in the Architectural Design. Several approaches exist for capturing NFRs [3], [4] and deriving a solution's architecture from them [1], [3], [5]. However, as already noted by Boehm [6], the notion that an architecture can be derived from requirements in one go is an oversimplification.…”

Section: Rementioning

confidence: 96%

“…Even though that study was not specifically targeted at NFRs, the results strongly confirm our position that proper NFR determination requires knowledge of the solution architecture. Tom Gilb [4] appears to be a strong opponent to this position, advocating 'How Good' and 'How Much' before 'How' as a matter of principle. However, in the same list of principles Gilb also states: "You cannot have correct knowledge of all the interesting requirements' levels for a large and complex system in advance," indicating at least partial agreement with our position.…”

Section: A Related Work 1) Negotiating and Uncertainty In Requirementsmentioning

confidence: 99%

“…However, in the same list of principles Gilb also states: "You cannot have correct knowledge of all the interesting requirements' levels for a large and complex system in advance," indicating at least partial agreement with our position. The Design Engineering process presented in [4] requires the same "three essentials" of cost knowledge, value knowledge and communication to work, indicating that it too would suffer from the communication limitations often encountered in formal client/supplier relationships.…”

Section: A Related Work 1) Negotiating and Uncertainty In Requirementsmentioning

confidence: 99%

“…They can also be expressed in quantified values. A lot of literature is available on the benefits of quantifying NFRs [3], [4].…”

Section: Nfr Quantification As An Economic Problemmentioning

confidence: 99%

See 3 more Smart Citations

Issues Dealing with Non-Functional Requirements across the Contractual Divide

Poort

Key²,

Vliet³

2012

2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture

View full text Add to dashboard Cite

Abstract-Agreement on Non-Functional Requirements between customer and supplier is crucial to a successful IT solution delivery project. In an ideal world, stakeholders and architects cooperate to achieve their common goals in a win-win situation. In a commercial setting, however, one dominant feature often introduces powerful forces from outside the technical realm. That feature is the customer/supplier relationship, usually formalized in bidding rules or as a delivery contract. Formal customer/supplier relationships often place severe limitations on information exchange between stakeholders and architects. In this paper, we explore the effect of such limitations on the interaction of architectural design with the quantification of Non-Functional Requirements, and explore a number of avenues to deal with them.

show abstract

Section: Rementioning

confidence: 96%

Section: A Related Work 1) Negotiating and Uncertainty In Requirementsmentioning

confidence: 99%

Section: A Related Work 1) Negotiating and Uncertainty In Requirementsmentioning

confidence: 99%

“…They can also be expressed in quantified values. A lot of literature is available on the benefits of quantifying NFRs [3], [4].…”

Section: Nfr Quantification As An Economic Problemmentioning

confidence: 99%

See 2 more Smart Citations

Issues Dealing with Non-Functional Requirements across the Contractual Divide

Poort

Key²,

Vliet³

2012

2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture

View full text Add to dashboard Cite

show abstract

“…And the resulting missing requirements and poorly specified requirements have major consequences that negatively impact many important stakeholders. We recommend the reader to read Tom Gilb's latest book [Gilb 2005] that provides excellent guidance on how to unambiguously and quantitatively specify quality requirements.…”

Section: Resultsmentioning

confidence: 99%

Architecture-Related Requirements.

Firesmith¹,

Capell²

2006

JOT

View full text Add to dashboard Cite

The engineering of architecture-related requirements has proven to be a very difficult task for requirements engineers. It is also a task that experience has shown could use significant improvements in practice. These requirements are critically important because they drive the development of the system and software architectures, which in turn largely determine if major product qualities are adequately achieved. They also form the basis against which the architectures are assessed. In this column, we describe the three major kinds of architecture-related requirements, discuss the most important characteristics they should have, describe the responsibilities of their stakeholders, and warn of the major negative consequences they can have on downstream activities when they are not properly engineered.

show abstract

11.4.1 From Waterfall to Evolutionary Development (Evo): How we rapidly created faster, more user‐friendly, and more productive software products for a competitive multi‐national market

Johansen

Gilb²

2005

INCOSE International Symp

Self Cite

View full text Add to dashboard Cite

Evolutionary development (Evo) focuses on early delivery of high value to stakeholders, and on obtaining and utilizing feedback from stakeholders. This paper describes from a project manager's viewpoint, the positive experiences that one organization rapidly achieved on switching from using the Waterfall method to Evo. Major benefit came from paying greater attention to the quality requirements as opposed to the previous practice of concentrating solely on the required functionality.

show abstract

Planguage Basics and Process Control

Cited by 22 publications

References 0 publications

Issues Dealing with Non-Functional Requirements across the Contractual Divide

Issues Dealing with Non-Functional Requirements across the Contractual Divide

Architecture-Related Requirements.

11.4.1 From Waterfall to Evolutionary Development (Evo): How we rapidly created faster, more user‐friendly, and more productive software products for a competitive multi‐national market

Contact Info

Product

Resources

About