K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....each section introduces the main concepts design heuristics. The last section concludes the paper and in troduces the future work. H. REQUIREMENTS ELICITATION The major influence on our approach to requirements engineering is Axel van Lamsweerde s KAOS work [3] Work by Lamsweerde [3] and Yue [9]) introduced a new approach to requirements engineering. Their goaloriented approach makes the why of requirements explicit by tying requirements to goals. A goal is a somewhat abstract and long term objective the system should achieve through cooperation of agents (user and software) in the ....

K. Yue. What Does It Mean to Say that a Specification is Complete? In Proceedings of lWSSD-4 - the Fourth International Workshop on Software Specification and Design, Monterey, CA, USA, 1987.

.... in software modeling research has been to abstract programming constructs up to requirements level rather than propagate requirements abstractions down to programming level [My199] Requirements engineering research has increasingly recognized the leading role played by goals in the RE process [Yue87, Rob89, Be91, Dar91, My192, Jar93, Zav97b] Such recognition has led to a whole stream of research on goal modeling, goal specification, and goal based reasoning for multiple purposes, such as requirements elaboration, verification or conflict management, and under multiple forms, from informal ....

....High level goals often refer to both systems. The system to be is in essence composite; it comprises both the software and its environment, and is. made of active components such as humans, devices and software. As opposed to passive ones, active components have choice of behavior [Fea87, Yue87, Fic92] henceforth we will call them agents. Unlike requirements, a goal may in general require the cooperation of a hybrid combination of multiple agents to achieve it [Din93] In a train transportation system, for example, the high level goal of safe transportation will typically require the ....

[Article contains additional citation context not shown here]

K. Yue, "What Does It Mean to Say that a Specification is Complete ?", Proc. 1WSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.

.... (such as FlightPathAngle mode engaged until aircraft near desired altitude ) Goals play a prominent role in the RE process [Lam01] They drive the elaboration of requirements to support them [Rub92, Dar93, Ant98, Kai00] They provide a criterion for requirements completeness and pertinence [Yue87]. They induce rich specification structuring mechanisms such as goal AND decomposition composition for specification refinement abstraction and OR decomposition for reasoning about alternatives [Myl92, Dar93, Chu00] Goals thereby provide a rationale for requirements and allow one to trace ....

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, IEEE, 1987.

....with the world, programs are concerned solely with the machine, specifications are the bridge between the two. Section 4 will use these concepts in working out the boundaries between world and machine within our framework. 2.2. Goal oriented Requirements Engineering The seminal works by Yue [17] and van Lamsweerde [6] opened a new direction in requirements engineering: the goal oriented approach. The key achievement of this new approach is that it makes explicit the why of requirements. Quoting van Lamsweerde, before goal oriented requirements engineering] the requirements on data and ....

K. Yue. What Does It Mean to Say that a Specification is Complete? In Proceedings of IWSSD-4 -- the Fourth International Workshop on Software Specification and Design, Monterey, CA, USA, 1987. 6

....case behaviour, to fix problems which occur when descriptions are tested. Detailed tracing and recording of dependencies throughout the knowledge base is therefore desirable. As a specification evolves, it will frequently become inconsistent, and at all times will be (to some degree) incomplete [Yue 1987]. At times there will be temporary inconsistencies, overgeneralisations, and over simplifications. However, participants will need to manipulate the specification as it evolves, as part of the exploratory process, and so the reasoning mechanisms must cope with inconsistency and incompleteness. ....

....these would form an editing language, as when Paddle is used to structure sets of transformations on programs. Treating specification as a planning process has certain advantages. It makes the goals (or purposes) of a specification explicit [Mostow 1985] and so aids the validation process. Yue [1987] points out that information about goals is vital to demonstrate completeness, and suggests that sufficiency and pertinence can be used as formal measures of completeness with regard to a particular goal. However, while planning based approaches allow the analyst to model the goals of the ....

Yue, K., 1987, "What Does It Mean To Say That a Specification Is Complete?", Proceedings, Fourth IEEE International Workshop on Software Specification and Design, Monterey, CA., April 3-4,1987.

....makes true all specified properties taken together. It must be unambiguous, that is, it may not have multiple interpretations of interest making it true. It must be complete with respect to higherlevel ones, that is, the collection of properties specified must be sufficient to establish the latter [Yue87]. It must be satisfied by lower level ones. It should be minimal, that is, it should not state properties that are irrelevant to the problem or that are only relevant to a solution for that problem [Mey85] Why specify formally Problem specifications are essential for designing, validating, ....

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.

.... process [Hic74, Mun81, Ber91, Rub92] Yue was probably the first to argue that the integration of explicit goal representations in requirements models provides a criterion for requirements completeness the requirements are complete if they are sufficient to establish the goal they are refining [Yue87]. Broadly speaking, a goal corresponds to an objective the system should achieve through cooperation of agents in the software to be and in the environment. Two complementary frameworks arose for integrating goals and goal refinements in requirements models: a formal framework and a qualitative ....

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.

....leading part played by goals during requirements elaboration. Goals drive the elaboration of requirements to support them [Ros77, Dar91, Rub92] they provide a completeness criterion for the requirements specification the specification is complete if all stated goals are met by the specification [Yue87]; they provide a rationale for requirements a requirement exists because of some underlying goal which provides a base for it [Dar91, Som97] goals represent the roots for detecting conflicts among requirements and for resolving them eventually [Rob89, Lam98b] goals are generally more stable ....

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.

....and document requirements throughout the software lifecycle; and so on. On the downside, scenarios are inherently partial; they raise a coverage problem similar to test cases, making it impossible to verify the absence of errors such as, e.g. incompleteness with respect to stated goals [73, 13] or conflicts among goals requirements [62, 45] Instance level trace descriptions also raise the combinatorial explosion problem inherent to the enumeration of combinations of individual behaviors. Scenarios in the form of interaction sequences are also procedural, thus introducing risks of ....

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.

....reasons why goals must be made explicit in the requirements engineering process. Goals drive the elaboration of requirements to support them; they provide a completeness criterion for the requirements specification the specification is complete if all stated goals are met by the specification [30]; goals provide an explanation to clients of the rationale underpinning requirements; they represent the roots for detecting conflicts among requirements and for resolving them eventually [26] they generally represent the most stable information in the requirements product. In short, requirements ....

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.

No context found.

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.

No context found.

K. Yue, What does it mean to say that a specification is complete?, in: Proceedings of the IEEE International Workshop on Software Specifications and Design (IWSSD'87), 1987, pp. 42--49.

No context found.

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design , Monterey, 1987.

No context found.

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. IWSSD-4, Fourth International Workshop on Software Specification and Design, Monterey, 1987.

No context found.

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. of the Fourth International Workshop on Software Specification and Design (IWSSD-4), Monterey, CA, USA, 1987.

No context found.

K. Yue, "What Does It Mean to Say that a Specification is Complete?", Proc. of the Fourth International Workshop on Software Specification and Design (IWSSD-4), Monterey, CA, USA, 1987.

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