Chung, L., Nixon, B.: Dealing with Non-Functional Requirements: Three Experimental Studies of a ProcessOriented Approach. In: Proc. of ICSE'95, pp. 25--37. ACM Press (1995)  Home/Search   Document Details and Download   Summary   Related Articles   Check

....few studies [12,13] are concerned with the integration of early and late requirements. This work extends a previous one [13] and presents a strategy for dealing with NFRs and how to integrate them into conceptual models. Part of our work was strongly influenced by Chung s work on this subject [3,5,6,14], resulting in a slight adaptation of his NFR graph to be used in earlier stages of software development. Although Chung s work aims to represent NFRs and their conflicts, it does not stress conflict detection with functional requirements. We believe that the systematic integration of NFRs into ....

....NFRs from the very early phases of the software development process, it will be impossible to represent the NFRs directly in a conceptual model that represents the functional requirements. We also need some way to represent NFRs that help us to deal with conflicts. In this context, Chung s work [2,5,6,14] is particularly important, since NFRs are treated as goals that might conflict. The NFRs must be represented as goals to be satisficed. Each goal will be decomposed into satisficing goals represented by a graph structure inspired by the and or trees used in problem solving. This satisficing goal ....

[Article contains additional citation context not shown here]

Chung L, Nixon B. Dealing with non-functional requirements: three experimental studies of a process-oriented approach. In: Proceedings of the 17th international conference on software engineering, Seattle, WA, April 1995, pp 24--28

....some nonfunctional aspects as: cost, reliability, security, maintainability, portability, accuracy among others. These non functional aspects must be treated as non functional requirements (NFR) of the software. They, still, should be dealt with from the beginning of software development process [8] [9] 10] throughout the whole life cycle. Not eliciting NFRs or dealing with then later in the process has led to a series of histories reporting failures in software development, including the deactivation of a system right after its deployment [4] 18] Studies point out these requirements as ....

Chung, L., Nixon, B. "Dealing with NonFunctional Requirements: Three Experimental Studies of a Process-Oriented Approach" Proc. 17th Int. Con. on Software Eng. Seatle, Washington, April pp: 24-28, 1995.

....issues associated with that model become relevant. A case could be made for restrictions to the conceptual model in order to permit effective conflict detection during requirements analysis. Conceptual models appropriate for conflict detection are discussed in [Mylopoulos et al. 1992, Chung Nixon, 1995]. ffl Many real world complex domains can only be understood via an exploratory methodology. For example: Menzies and Compton note that all the expert systems they have ever studied in detail are poorly understood; e.g. process control, farm management, economic modeling, biochemical ....

Chung, L. & Nixon, B. (1995). Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach. In Proceedings of ICSE '95: the International Conference on Software Engineering, pages 25--36.

....vague goals (e.g. user friendliness, security, accuracy, reliability ) into specific properties or behavior For example, prototyping is often proposed for exploring the friendliness of a user interface. There are also product oriented [Harrison Barnard 92] and process oriented [Chung Nixon 95] approaches to this problem (see Section III for a definition of these terms) 1.3. Understanding priorities and ranges of satisfaction Many requirements are not absolute; they can be satisfied partially, or only if resources permit. Requirements engineers must obtain the information necessary ....

Lawrence Chung and Brian A. Nixon. Dealing with non-functional requirements: Three experimental studies of a process-oriented approach. In Proceedings of the Seventeenth International Conference on Software Engineering, pages 25-37. ACM Press, ISBN 0-89791-708-1, 1995. 8

....Affordability : cons More effort to specify cons More effort to develop cons More effort to verify Figure 16: NFR quality knowledge: strategy knowledge from QARCC. From [6] as to the potential maintainability of the system. Two example of NFR qualityK are Chung Nixon s goal graph [18] approach and Boehm s et al. QARCC tool [6] ffl The QARCC quality KB represents the concerns of different stakeholders (e.g. user, customer, developer, developer, maintainer, interfacer, and gen 370 eral public) and the quality attributes which map into those concerns. For example, ....

L. Chung and B.A. Nixon. Dealing with Non-Functional Requirements: Three Ex- 1405 perimental Studies of a Process-Oriented Approach. In Proceedings of ICSE '95: the International Conference on Software Engineering, pages 25--36, 1995.

....after delivery has occoured and we have some track record of the system s performance in the field. 510 Nevertheless, during initial construction, we may still want to assure ourselves as to the potential maintainability of the system. Two example of NFR qualityK are Chung Nixon s goal graph [18] approach and Boehm s et al. QARCC tool [7] ffl The QARCC quality KB represents the concerns of different stakehold 515 ers (e.g. user, customer, developer, developer, maintainer, interfacer, and general public) and the quality attributes which map into those concerns. For example, ....

L. Chung and B.A. Nixon. Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach. In Proceedings of ICSE '95: the 1605 International Conference on Software Engineering, pages 25--36, 1995.

....shown in Figure 3. In that figure: ffl x y denotes that y being up or down can be explained by x being up or down respectively; Menzies: RE Qualitative Causal Diagrams; page 5 of 15 P[1] domesticSalesDown, inflationDown P[2] foriegnSalesUp, publicConfidenceUp, inflationDown P[3]: domesticSalesDown, companyProfitsDown, corporateSpendingDown, wagesRestraintUp P[4] domesticSalesDown, inflationDown, wagesRestraintUp P[5] foriegnSalesUp, publicConfidenceUp, inflationDown, wagesRestraintUp P[6] foriegnSalesUp, companyProfitsUp, corporateSpendingUp, investorConfidenceUp ....

.... company profits foriegn sales corporate spending wages restraint domestic inflation sales public confidence corporate spending wages restraint inflation public confidence 10 10 10 10 10 10 10 Figure 6: World #2 is generated from Figure 3 by combining P[1] P[2] P[3], and P[4] World #2 assumes companyProfitsDownand covers 67 of the known OUT puts. proof P [i] is in W [j] if that proof does not conflict with the environment ENV [j] In our example, ENV[1] fcompanyProfitsUpgand ENV[2] fcompanyProfitsDowng. 125 Hence, W[1] fP[2] P[5] P[6]g and W[2] fP[1] ....

[Article contains additional citation context not shown here]

L. Chung and B.A. Nixon. Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach. In Proceedings of ICSE '95: the International Conference on Software Engineering, pages 25--36, 1995. 315

....are aimed to suggest some reality check through the choice of real domains in which the problem occurs. Researchers use various aspects of the exemplars to demonstrate the strengths and applicability of their own approaches in such real settings [Jones 1990] Hayes 1993] Lano Haughton 1994] [Chung and Nixon 1995]. From the base exemplars, it is easy to construct plausible variants and extensions that further the goals of a researcher using that exemplar. The library problem is a typical instance of an exemplar that has undergone multiple variants and extensions in the literature. Such lack of closure may ....

L. Chung and B. Nixon, "Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach", Proc. ICSE17 - Seventeenth International Conference on Software Engineering, IEEE-ACM, April 1995, pp. 25-37.

....discipline (e.g. computer security, personnel security or physical security) to security assertions in other disciplines; a gap in this mapping indicates a vulnerability. Many notations and tools support certain aspects of the definition of assurance strategies, such as tracing requirements [2, 13, 31] and recording design rationale [22, 39] CASE tools usually focus on a specific method involving design decomposition or code analysis that is too narrow to document a complete assurance strategy. They may support requirements traceability, but not usually for non functional requirements such as ....

L. Chung and B.A. Nixon. Dealing with non-functional requirements: Three experimental studies of a process-oriented approach. In Proc. of International Conference on Software Engineering, pages 25--37, Seattle, Washington, 1995. ACM.

....quality knowledge: strategy knowledge from QARCC. From [9] of the system s performance in the field. Nevertheless, during initial construction, we may still want to assure ourselves as to the potential maintainability of 610 the system. Two example of NFR qualityK are Chung Nixon s goal graph [20] approach and Boehm s et al. QARCC tool [9] ffl The QARCC quality KB represents the concerns of different stakeholders (e.g. user, customer, developer, developer, maintainer, interfacer, and 615 general public) and the quality attributes which map into those concerns. For example, maintainers ....

L. Chung and B.A. Nixon. Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach. In Proceedings of ICSE '95: the International Conference on Software Engineering, pages 25--36, 1995.

....the NFRs required, it is our opinion that the NFRs such as adaptability should be considered at the first step in the development of software solution, viz. in the software architecture itself. In order to systematically support adaptation at the architectural level, we adapted the NFR Framework [15,16,17,50]. The NFR Framework allows goal oriented development of software and software adaptability is treated as one of the goals to be achieved during development. Through this adaptation, consideration of design alternatives, analysis of tradeoffs and rationalization of design decisions are all carried ....

.... x S S,where meet(S, need(E) The meet function above involves the two tasks of validation and verification, which confirm that the changed system (S) indeed meets the needs of the changed environment (E) The predicate meet is intended to take the notion of goal satisficing of the NFR Framework [15,16,17,50], which assumes that development decisions usually contribute only partially (or against) a particular goal, rarely accomplishing or satisfying goals in a clear cut 4 sense. Consequently generated software is expected to satisfy NFRs within acceptable limits, rather than absolutely. Figure ....

[Article contains additional citation context not shown here]

Chung, L., and Nixon, B.A. Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach; Proc., IEEE 17th International Conference on Software Engineering, Seattle, April 24-28, 1995., pp. 25-37.

....and organised in such a way to be available to the developer at the time of both the initial development and its subsequent changes. An important role of the NFR Framework is to help in organising such knowledge and to make them available to the developer as needed. In several of our studies [14, 47, 9, 10, 48, 49], this cataloguing of knowledge has been helpful, and was typically performed early. The NFR Framework allows for acquisition and representation of knowledge about the domain being developed. This might include representation of functional requirements, schema, priorities and workload. Memory ....

....guidelines presented in Section 5. Studies would also help determine how easily the framework and its notation can be learned and applied by practitioners, as raised 40 by experts in other domains (governmental and medical computing) who reviewed some of our previous studies of dealing with NFRs [14]. 9 Conclusions Our overall long term goals are to help developers deal with change. This involves offering support for dealing with quality requirements, decreasing developers effort (by decreasing development time and cost) and offering schemes for concise representation as well as ....

L. Chung, B. A. Nixon, "Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach." Proc., 17th ICSE, Seattle, WA, U.S.A., Apr. 1995, pp. 25--37.

....generates a unique and consistent assignment of labels. Studies would also help determine how easily the framework and its notation can be learned and applied by practitioners, as raised by experts in other domains (medical and governmental computing) who have reviewed our previous studies [12]. Conclusion. In dealing with change, our overall longterm goals are to increase quality, decrease development time and cost, and to improve conciseness of representation and schemes for assisting reasoning. We have taken an existing framework [9, 27] for dealing with quality requirements, and ....

L. Chung, B. A. Nixon, "Dealing with Non-Functional Requirements: Three Experimental Studies of a ProcessOriented Approach." To appear in Proc., 17th ICSE, Seattle, WA, U.S.A., Apr. 1995.

....i.e. it provides support for systematically dealing with NFRs during the process of architectural design. The NFR Framework [7] 30] aims to improve software quality [9] 10] and has been tested on system types with a variety of NFRs, including accuracy, security and performance. Systems studied [13] include credit card [34, 8] public health insurance [7] government administration (Cabinet Documents [7] and Taxation Appeals [35] and bank loan [12] information systems. The last study considered dealing with changes in requirements, including informativeness. The NFR Framework also has an ....

Lawrence Chung and Brian A. Nixon, Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach. Proceedings, 17th International Conference on Software Engineering, Seattle, WA, U.S.A., April 24--28, 1995.

.... [CNYMForthcoming] Status and Open Issues The NFR Framework has been tested on several system types with a variety of NFRs: studies of research expense management, credit card, public health insurance and government administration (Cabinet Documents and Taxation Appeals) information systems [CN95]. Adaptation of the framework has also been considered in the context of software architecture [CNY95] and applied to an initial study of dealing with change in a bank loan system, with the combination of performance and requirements for accuracy, timeliness and informativeness [CNY96] The ....

L. Chung, B. A. Nixon, "Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach." Proc., 17th ICSE, Seattle, WA, U.S.A., Apr. 1995, pp. 25--37.

No context found.

Lawrence Chung and Brian A. Nixon, Dealing with Non-Functional Requirements: Three Case Studies. Working paper, September 1993.

....leading up to code is as much a part of the product as the code itself. They must be represented and encoded in a suitable form to support the ongoing evolution of the product [MBY96] Status and Open Issues The NFR Framework has been tested on several classes of systems with a variety of NFRs [CN95]. Adaptation of the framework has also been considered in the context of software architecture [CNY95] and applied to an initial study of dealing with change in a bank loan system, with the combination of performance and requirements for accuracy, timeliness and informativeness [CNY96] A ....

L. Chung, B. A. Nixon, "Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach." Proc., 17th ICSE, Seattle, WA, U.S.A., Apr. 1995, pp. 25--37.

No context found.

Chung, L., Nixon, B.: Dealing with Non-Functional Requirements: Three Experimental Studies of a ProcessOriented Approach. In: Proc. of ICSE'95, pp. 25--37. ACM Press (1995)

No context found.

L. Chung and B. A. Nixon. Dealing with NonFunctional Requirements: Three Experimental Studies of a Process-Oriented Approach. The Proceedings of the 17th International Conference on Software Engineering, pages 25--37, 1995.

No context found.

L. Chung and B. Nixon. Dealing with non-functional requirements: Three experimental studies of a process-oriented approach. In Proc. of ICSE'95, 1995.

No context found.

Chung, L., Nixon, B. "Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach" Proc. 17th Int. Con. on Software Eng. Seatle, Washington, April pp: 24-28, 1995.

No context found.

L. Chung and B. Nixon. Dealing with non-functional requirements: Three experimental studies of a process-oriented approach. In Proc. of ICSE'95, 1995.

No context found.

L. Chung and B. Nixon. Dealing with non-functional requirements: Three experimental studies of a process-oriented approach. In Proc. of ICSE'95, 1995.

No context found.

L. Chung, B. A. Nixon, "Dealing with NonFunctional Requirements: Three Experimental Studies of a Process-Oriented Approach." Proeedings of the 17th ICSE, Seattle, WA, U.S.A. April 1995.

No context found.

Chung, L., Nixon, B. "Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach" Proc. 17th Int. Con. on Software Eng. Seatle, Washington, April pp: 24-28, 1995.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC