Rumbaugh, J., Getting Started: Using use cases to capture requirements. Journal of Object-Oriented Programming, 1994: p. 8-23.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....assuring the quality of security work by reuse, avoiding over specification and premature design decisions by reuse at the generic level and focussing on security early in the requirements stage of development. 1. Introduction Use cases [1 3] have become popular for eliciting requirements [4, 5]. Many groups of stakeholders turn out to be more comfortable with descriptions of operational activity paths than with declarative specifications of software requirements [6] As use cases specifically address what users can do with the system, they are most relevant for functional requirements. ....

J. Rumbaugh, "Getting Started: Using use cases to capture requirements," Journal of Object-Oriented Programming, pp. 823, 1994.

.... often without being named (e.g. BBG 88] A good introduction to collaboration based design can be found in the presentation of the OORAM approach [RAB 92] A detailed treatment of collaboration based designs, together with a discussion of how to derive them from use case scenarios [Rum94] can be found in VanHilst s Ph.D. dissertation [Van97] 2.1 Collaborations and Roles In an object oriented design, objects are encapsulated entities but are rarely self sufficient. Although an object is fully responsible for maintaining the data it encapsulates, it needs to cooperate with other ....

J. Rumbaugh, "Getting Started: Using use cases to capture requirements", Journal of Object-Oriented Programming, 7(5): Sep 1994, 8-23.

....or peripherals) Since use cases were introduced in OOSE [5] they have received widespread attention. Many object oriented methods have adopted the idea of using use cases in different parts of the development process. Table 1 [4] shows an overview of four of these methods; OOSE [5, 6] OMT [7, 8], Booch [9] and ROOM [10] with respect to concepts, notation, process and methodology. The overview is not com plete, but highlights some similarities and differences between the methods. Later, the concepts in OOSE, OMT and Booch were combined and included in UML[33] As can be seen above, all ....

Rumbaugh J., "Getting Started - Using use cases to capture require ments", Journal of Object-Oriented Programming, September 1994

....above, roles can directly support the least privilege principle, but to do so there must be some method to assign only the needed rights to each role. One of the most accepted methods to determine functional requirements for the design of object oriented systems is the definition of use cases [Jaco92, Rumb94a]. The users of the system are interviewed to elicit their ways of interacting with the system and their interaction descriptions are recorded in a specific format. Use cases are the basis for precise requirement documents, for finding class operations and even for finding classes. In our work, we ....

J. Rumbaugh, "Getting started: Using use cases to capture requirements", Journal of Object-Oriented Programming, September 1994, pp.8-12, 23.

.... the methodology as OOSE [14] has received a number of positive reviews in a wide variety of the popular forums for object oriented issues [1] Additonally, the use case approach, as an early, upfront focus in system modeling, is now being adopted or adapted by many other OO methodologies 6 [9, 22], and behavior modeling of systems from the user s perspective is included in some form and at some stage in most current methodologies [6] However, our consideration and choice of Objectory was guided more by our positive experience in using it on complex industry and research projects [10, 12] ....

James Rumbaugh: "Getting started: using use cases to capture requirements", Journal of Object-Oriented Programming (JOOP), September 1994, Vol.7, No.5.

....pathways map directly into a decision table and do not need intermediate conclusions to be mapped to primitive conditions (Richards and Compton 1997) as many rule bases require. To gain the benefits of the RDR approach it is important that a suitable source of cases be available for RE. Use cases (Rumbaugh 1994) have gained popularity as a means of eliciting and specifying requirements. We propose use cases as a possible source of cases. Cases used by RDR are often historical cases such as pathology results for a patient. Cases in a case based reasoning sense are more general and represent stereotypical ....

Rumbaugh, James (1994) Getting Started: Using Use Cases to Capture Requirements JOOP Sept.

....in requirements analysis (Pohl, 1993) This Chapter concentrates on use case modelling for eliciting, analysing and documenting functional requirements. The use case concept has gained widespread acceptance within methods and notations such as OOSE (Jacobson, 1992) OMT (Rumbaugh et al. 1991; Rumbaugh 1994), the Booch method (Booch, 1994) ROOM (Selic et al. 1994) Fusion (Coleman, et al. 1994) and UML (Fowler and Scott, 1997) Bjrn Regnell, Per Runeson and Claes Wohlin 10 Accepted for publication in Journal of Systems and Software There are many different possibilities of applying use cases ....

Rumbaugh, J.,"Getting Started - Using Use Cases to Capture Requirements", Journal of Object-Oriented Programming, pp. 12-23, June 1994.

....The way this works is that when a concept is found to be in conflict we pass the case or cases associated with that concept to the other stakeholder for KA. This should either resolve the conflict or at least ensure that both parties have given their views based on the same information. Use cases [35] have gained popularity as a means of eliciting and specifying requirements. We propose use cases as a possible source of cases. Cases used by RDR are often historical cases such as pathology results for a patient. Cases in a case based reasoning sense are more general and represent stereotypical ....

Rumbaugh, James (1994) Getting Started: Using Use Cases to Capture Requirements JOOP September 1994, 8-23.

....development from a programming languages standpoint. A good introduction to collaboration based design can be found in the presentation of the OORAM approach [RAB 92] A detailed treatment of collaboration based designs, together with a discussion of how to derive them from use case scenarios [Rum94] can be found in VanHilst s Ph.D. dissertation [Van97] 2.2.1 Collaborations and Roles In an object oriented design, objects are encapsulated entities but are rarely selfsufficient. Although an object is fully responsible for maintaining the data it encap1. Parts of this section and Section ....

....keeps track of the data structure size. The design is simple and we will not concern ourselves with its schematic representation (in the form of Figure 2.1) or the way we obtained it. We remind the reader that a good reference on how to obtain collaboration based designs from use case scenarios [Rum94] is VanHilst s Ph.D. dissertation [Van97] A mixin layer implementing a binary tree collaboration has the form: 1 template class Super class BINTREE : public Super public: class Node : public Super: Node Node parent link, left link, right link ; Node data members public: ....

J. Rumbaugh, "Getting Started: Using use cases to capture requirements", Journal of Object-Oriented Programming, 7(5): Sep 1994, 8-23. 130

....flow of a scenario, they are not sufficient to completely bridge the requirements gap between user and developer. According to James Rumbaugh . a combination of direct domain analysis and use cases is an effective approach to starting analysis, rather than depending on use cases alone. [21]. SEPA uses several different graphical models for requirements capture and verification (e.g. task hierarchy, semantic net, Venn diagram, entity relationship diagram, use cases) While the use of functional oriented and data oriented graphical models is natural for requirements capture and ....

J. Rumbaugh, "Getting started -- Using use cases to capture requirements," in Software Requirements, R. H. Thayer and M. Dorfman, Eds. Los Alamitos, CA: IEEE Computer Society Press, 1997, pp. 123-127.

....time. Also, behaviouralK may be restricted to only observables on the interface of a program (exception: case libraries in case based reasoning in 140 x2.3.2) 2.3. 1 BehavioralK in UML This section notes that behaviouralK can be collected from object oriented specifications via uses cases [7,54,97,98]. A use case has a very simple text structure. Developers write a short story (say less than 2 pages) describing some flow of page 10 of 73 phone rings answer phone ringing stops caller lifts receiver dial tone ends dial(1) ringing tone dial tone begins Dieter: Caller Tim: Callee dial(6) ....

....behaviouralK from business users. 160 2.3. 2 BehavioralK in Case based Reasoning Case based reasoning (CBR) is an inference strategy where new situations are managed by reviewing prior situations [56, 57] Knowledge in a CBR system is 2 For a short tutorial introduction to use cases, see [98]. For an intricate use of use cases for tracing the link between requirements and code, see [97] page 11 of 73 Limited cardiac output Dyspnea on exertion General flow deficit Unstable angina Unstable angina Chest pain Aortic valve disease Aortic stenosis Fixed high outflow resistance Slow ....

J. Rumbaugh. Getting Started: Using Use Cases to Capture Requirements. JOOP, pages 8--23, 1994. 1590

.... perspective with an object perspective (x2.3) The Olle process and behaviour perspectives have a similar 155 meta level structure (e.g. pre conditions to activities events) Hence, we will use the term Process to denote the representations of the Scenarios elicited during requirements capture [25]. A Process is a Graph containing Flows between Actions (which may be either Activities or Events) Flows have pre Conditions and post Conditions (which must just be True) All components of a Process are Concepts 160 (recall Figure 7) and may use services defined in B usinessClasses; i.e. the ....

J. Rumbaugh. Getting Started: Using Use Cases to Capture Requirements. JOOP, Menzies; page 18 of 18 pages 8--23, 1994.

....use cases [5] A use case is an informal technique for requirements capture which have, in various forms, been adopted by all the major methodologies. Use cases are the basis of defining functional requirements, deriving objects, allocating functions to objects, and designing the interface (e.g. [14]) Use cases are useful at all stages of the OO software life cycle. Business users can communicate their goals to a designer via a use case. Designers can audit their design by performing walk throughs of the use cases. Missing classes can be detected when no actor is present to handle some ....

J. Rumbaugh. Getting Started: Using Use Cases to Capture Requirements. JOOP, pages 8--23, 1994.

....dial(6) dial(2) 612 :Phone Line tone stops Time Figure 8: A use case expressed as a sequence diagram. exception: case libraries in case based reasoning in x3.3.2) 3.3. 1 Behavioral in UML This section notes that behaviouralK can be collected from object oriented specifcations via uses cases [8, 56, 103, 104]. A use case has a very simple text 290 structure. Developers write a short story (say less than 2 pages) describing some flow of events within their system. The text of the use case is mapped into classes via sequence diagram such as Figure 8. The arrows on a sequence diagram represent the ....

....a library of prior cases. Inference at runtime consists of matching prior cases 310 that are most like the new situation, then adapting those prior cases to the new situation. CBR fixK controls the finding and adaptation of cases (x4.4. 7) 2 For a short tutorial introduction to use cases, see [104]. For an intricate use of use cases for tracing the link between requirements and code, see [103] page 13 of 56 Limited cardiac output Dyspnea on exertion General flow deficit Unstable angina Unstable angina Chest pain Aortic valve disease Aortic stenosis Fixed high outflow resistance Slow ....

J. Rumbaugh. Getting Started: Using Use Cases to Capture Requirements. JOOP, pages 8--23, 1994. 1800

....several sequences of events (so called scenarios or flow variants) A use case may be described either from an external (black box) point of view suitable for requirements, or from an internal (white box) point of view suitable for design. Related work on use case modelling can be found in, e.g. [3, 4, 5, 6, 7]. The FRED method has been developed over a period of several years, taking previous method engineering efforts at Ericsson into account. FRED has been evaluated in three industrial pilot projects with real requirements, and experiences from each of these studies have resulted in incremental ....

Rumbaugh, J.,"Getting Started - Using Use Cases to Capture Requirements", Journal of Object-Oriented Programming, September 1994.

....updates. Sizeof simply keeps track of the data structure size. The design is simple and we will not concern ourselves with its schematic representation (in the form of Figure 1) or the way we obtained it. For a good reference on how to obtain collaboration based designs from use case scenarios [29] see VanHilst s Ph.D. dissertation [40] A mixin layer implementing a binary tree collaboration has the form 4 : template class Super class BINTREE : public Super public: class Node : public Super: Node Node parent link, left link, right link ; Node data members public: Node ....

J. Rumbaugh, "Getting Started: Using use cases to capture requirements", Journal of Object-Oriented Programming, 7(5): Sep 1994, 8-23.

....systems) such test cases libraries might be naturally available. A second class of test cases may come from government legislation. That is, 65 in certain circumstances, certain events must happen. A third class of test cases may come from scenario driven analysis methods such as uses cases [2, 14, 18, 19]. A use case has a very simple text structure. Developers write a short story (say less than 2 pages) describing some flow of events within their system. The text of the use case is mapped into classes via 70 sequence diagram such as Figure 2. The arrows on a sequence diagram represent the flow ....

J. Rumbaugh. Getting Started: Using Use Cases to Capture Requirements. JOOP, pages 8--23, 1994.

.... to have representations of requirements models that are easily understood by the different stakeholders that take part in requirements analysis [2] Use cases (also called scenarios) introduced in OOSE [3] have been given increasing attention in other object oriented development methods, e.g. [4, 5]. In requirements engineering use cases are of special interest, as this concept has proven to be valuable in elicitation, analysis and documentation of requirements [6, 7, 8] Use cases also provide traceability of requirements throughout the design, implementation and verification and validation ....

....hierarchical use case model with graphical notation is presented. Section 5 provides conclusions and covers some issues of further research and tool support. 2. Use Cases in Current Methods This section discusses how use cases currently are applied in four development methods; OOSE [3, 13] OMT [14, 5], Booch [4] and ROOM [15] The main focus here is on the role of use cases in requirements elicitation and analysis. Table 1 shows an overview of these four methods with respect to concepts, notation, process and methodology. The overview is not complete, but highlights some similarities and ....

[Article contains additional citation context not shown here]

Rumbaugh, J.,"Getting Started - Using use cases to capture requirements", Journal of Object-Oriented Programming, September 1994.

....to manage class collaboration knowledge in OO designs. A use case is an informal technique for requirements capture. For example, Rumbaugh argues that use cases are the basis of defining functional requirements, deriving objects, allocating functions to objects, and designing the interface [17]. Use cases are becoming a dominant theme in OO design and have been adopted by all the major methodologies. Our work also gives some support for the OO design patterns paradigm [5] This call graph research suggests that the natural unit of division in a OO system is not the class or the class ....

J. Rumbaugh. Getting Started: Using Use Cases to Capture Requirements. JOOP, pages 8--23, 1994.

No context found.

Rumbaugh, J., Getting Started: Using use cases to capture requirements. Journal of Object-Oriented Programming, 1994: p. 8-23.

No context found.

J. Rumbaugh. Getting Started Using Use Cases to Capture Requirements. In Richard H. Thayer and Merlin Dorfman, editors, Software Requirements Engineering, pages 123-127. IEEE Computer Society Press, second edition, 1997.

No context found.

James Rumbaugh. Getting started: Using use cases to capture requirements. Journal of Object--Oriented Programming, September 1994.

No context found.

J. Rumbaugh, "Getting Started: Using use cases to capture requirements", Journal of ObjectOriented Programming, September 1994, pp. 8-23.

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