A. M. Davis. Software Requirements: Objects, Functions and States. Prentice-Hall, Englewood Cliffs, NJ, 1993. Home/Search Document Not in Database Summary Related Articles Check |
This paper is cited in the following contexts:
First 50 documents Next 50
Goal-Based Requirements Analysis - Annie Ant Anton (1996) (30 citations) (Correct)
....ranging from information about the organization (i.e. enterprise goals) to system specific information (i.e. requirements) for the purpose of identifying, organizing and classifying goals. It is often assumed that software systems are constructed with some goal(s) or purpose in mind [3]. However, what happens when the goal or purpose is not clear Goals are often not given, so where do they originate Enterprise goals do not always reflect what actually takes place [1] Thus, it is important to gather as much information as possible in order to obtain a broad un derstanding of ....
....the developer s viewpoint, we wish for goals and software requirements to remain as stable as possible. Although it is true that requirements are volatile and constantly changing, much iteration in the refinement process is due to the requirements simply being misunderstood and or misinterpreted [3]. Each stakeholder has different, and sometimes conflicting, requirements and priorities. Often the strategies for conflict identification and resolution are inadequate. In our experience, goals axe characteristically more stable than the processes, organizational structures and operations of a ....
A.M. Davis, Software Requirements: Objects, Func- ticas, f States, Prentice-ttall, 1993.
Towards a Methodology for Coordination Mechanism Selection.. - Miles, Joy, Luck (Correct)
....aided by taking prospective users through usage scenarios [7] for example. Agent oriented approaches to development should not force any change in an applications requirements. Therefore, the techniques used in requirements engineering for agent based systems will be the same as those elsewhere [3, 12] (see Tropos [1] for an agent oriented software engineering methodology based on requirements engineering) A common requirements engineering technique is to describe the requirements in terms of functional goals it is intended to achieve and priorities and restrictions which, jointly, we call ....
A. M. Davis. Software Requirements: Objects, States and Functions. Prentice Hall, 1993.
A Requirement Specification Language for - Configuration Dynamics Of (Correct)
....of which those properties can be specified. A prototypical scenario for an agentmediated system is discussed and some important requirements for this system are specified. 1 Introduction Requirements Engineering is today a well studied field of research within Software Engineering; e.g. [2], 14] 11] Requirements describe the required properties of a system (this may include the functions of the system, structure of the system, static and dynamic properties) In recent years requirements engineering for distributed and agent systems has been studied in some depth, e.g. in [3] ....
Davis, A.M. (1993). Software requirements: Objects, Functions, and States, Prentice Hall, New Jersey.
Senior Design Project: ABET 2000 Certification - Brouse (1999) (Correct)
....of the systems engineering life cycle. During this time, they conducted both problem analysis and product description as part of the reguirements engineering phase of the life cycle. Doing a better job of defining and specifying software is not only worthwhile but also possible and cost effective [3]. Therefore more time was devoted to this activity. The students discovered the difficulty of understanding a problem, and then being able to transform that problem into a documented description of the required product. The requirements research included looking at the processes that Systems ....
) Davis, A. M., Software Requirements: Objects, Functions and States, Prentice Hall, 1993, pp. 20.
BaSyRE: A Lightweight Combination of Proven RE Techniques - Nikula, Sajaniemi (Correct)
....are interrelated and absence of any single element can vitiate the benefits of the other elements. This wide scope of the method leads also to a need to simplify it in some other respects in order to keep it from growing so much that it deters potential users only by its sheer size [16] Davis [17] has observed that different techniques have been developed or are specifically suitable for particular application domains. Accordingly we limit the variety of techniques in the method by focusing it to a single domain. The application domain of interest to us is small projects developing ....
....with a dash. Table 1. Books reviewed for the method development. A l character indicates a full compliance with column expectations, a character partial compliance, and a dash lack of compliance. Reference RD Templ RDev Techn RDev Process RM Techn RM Process Method Davis 1993 [17] l l Graham 1998 [22] l Hooks Farry 2000 [23] l l Jacobson al. 1998 [21] l Kotonya Sommerville 1997 [9] l l l l l Kovitz 1998 [24] l Kulak Guiney 2000 [25] l l l Lauesen 2002 [26] l l l Leffingwell Widrig 1999 [10] l l l l ....
A. M. Davis, Software Requirements: Objects, States, and Functions: Prentice Hall, 1993.
Towards Requirements-Driven Information Systems.. - Castro, Kolp, Mylopoulos (2002) (40 citations) (Correct)
....to functional 10 and non functional requirements. Leaving (some) goal dependencies between system actors and other actors is a novelty. Traditionally, functional goals are operationalized during late requirements [13] while quality softgoals are either operationalized or metricized [14]. For example, Billing Processor may be operationalized during late requirements analysis into particular business processes for processing bills and orders. Likewise, a security softgoal might be operationalized by defining interfaces which minimize input output between the system and its ....
A. Davis. Software Requirements: Objects, Functions and States. Prentice Hall, 1993.
A Five Year Perspective on Software Engineering - Graduate Programs At (Correct)
....techniques for the analysis and specification of software requirements. It includes a group project. SWSE 620 has been taught with an emphasis on prototyping and with an emphasis on object oriented analysis according to Rumbaugh s OMT [RBP 91] The main requirements 5 text is Davis s [Dav93] A variety of prototyping tools are used including PC Access, Oracle C, Hypercard, Toolbook and Expert Problem Solving System (EPSS) SWSE 621: Software Design. This is a course in concepts and methods for the architectural design of software systems of sufficient size and complexity to require ....
A. Davis. Software Requirements: Objects, Functions, and States. Prentice-Hall, Englewood Cliffs, NJ, 1993.
Process Improvement Proposals in System Requirements.. - Karlsson, Martinsson (Correct)
.... Is there a clear link between software requirements and more general systems engineering requirements [Kotonya, Sommerville, 1997] Correctness A requirements specification is correct if and only if every requirement stated therein represents something required of the system to be built [Davis, 1993]. Ambiguity Are the requirements expressed using terms, which are clearly defined Could readers from different backgrounds make different interpretations of the requirements [Kotonya, Sommerville, 1997] Verifiability A requirements specification is verifiable if every requirement stated ....
....make different interpretations of the requirements [Kotonya, Sommerville, 1997] Verifiability A requirements specification is verifiable if every requirement stated therein is verifiable. A requirement is verifiable if a person or machine can check that the built product meets its specification [Davis, 1993]. Understandability Can readers of the document understand what the requirements mean This is probably the most important attribute of a requirement document if it cannot be understood the requirements cannot be validated [Kotonya, Sommerville, 1997] Modifiable A requirements ....
[Article contains additional citation context not shown here]
Davis, A. M., (1993), Software requirements -- objects, functions and states, Prentice Hall Comments: Focuses on the early phases of software development lifecycle commonly called software requirements analysis or software requirements specification.
Conceptual Modelling in Software Engineering and.. - Dieste, Juristo.. (2000) (Correct)
.... known as conceptual models (CMs) The process of creating CMs in software development is generally referred to as conceptual modelling, although it may be given other pet names depending on the actual discipline in which it is performed; for example, problem analysis in Software Engineering (SE) [1] or conceptualisation in Knowledge Engineering (KE) 2] there are specific materials about Knowledge Engineering in The Knowledge Modelling Paradigm in Knowledge Engineering , by E. Motta, in this same volume) The design of CMs is a crucial activity in traditional and intelligent software ....
....CMs has been defined in the discipline of SE. Firstly, the underlying ontology of all these CMs is very diverse. Ontology means the type of problem domain concepts that each CM is capable of representing [29] In this respect, the CMs in SE range from models like the state transition diagram [1], which can represent only changes of state over time, to models like KAOS [30] which can represent a huge amount of both static (entities, relations, etc. and dynamic (goals, processes, etc. aspects of the problem domain. Secondly, the intermediate representations, also known as builders, ....
[Article contains additional citation context not shown here]
A.M. Davis, Software requirements: Objects, functions and states. Prentice-Hall International, 1993.
Deriving Goals from a Use Case Based Requirements.. - Antón, Dempster, Siege (2000) (2 citations) (Correct)
....risks. Since the scenarios were developed by the authors and were not validated by system users, we suspect the scenarios may be plagued due to assumptions made about typical and or expected user and system interactions. This lack of validation is problematic during product design and development [Dav93]. The fact that the authors only investigated scenarios from one actors viewpoint also introduces risk, since exploring into multiple viewpoints yields more comprehensive coverage of the requirements. 3)# Poor traceability leads to inconsistency Traceability is a measure of quality that reduces ....
Davis, A.M. Software Requirements: Objects, Functions, & States,. Prentice-Hall, 1993.
Designing Agent-Oriented Systems by Analysing Agent Interactions - Miles, Joy, Luck (2000) (4 citations) (Correct)
....may take different forms determining, for instance, the measures of success for goals or restrictions on resources. Examples of preferences are given below. Now, traditional requirements analysis attempts to decompose systems into objects, functions and states so as to understand the problem [5]. Agent interaction analysis, however, is concerned with design, i.e. reaching an implementable solution. Therefore, the technique and end product of the artefacts derived from the requirements may be very different. Nevertheless, regardless of the way in which agent interaction analysis produces ....
....states which functions should achieve. Importantly, because of the attention to the highlevel and the goal orientation, this stage of the design process can usefully borrow from requirements analysis ideas. A range of requirements analysis techniques are available (with several being described in [5], and one aimed at agent based systems described in [1] It is interesting to note that these techniques derive relations between agents both internal and external to the system being designed and, because we are concerned primarily with interactions, there is no explicit distinction between ....
A. M. Davis. Software Requirements: Objects, States and Functions. Prentice Hall, 1993.
Tropos: An Agent-Oriented Software Development.. - Bresciani, Perini.. (2004) (12 citations) Self-citation (Giunchiglia) (Correct)
No context found.
A. Davis and F. Giunchiglia, Software Requirements: Objects, Functions and States, Prentice Hall, 1993.
A Service-Sharing Methodology for Integrating COTS-Based.. - Dean Jin Department (Correct)
No context found.
A. M. Davis. Software Requirements: Objects, Functions and States. Prentice-Hall, Englewood Cliffs, NJ, 1993.
Requirements Engineering: a Close Look at Industry Needs.. - Curricula Oliver Minor (2004) (Correct)
No context found.
A. M. Davis, Software Requirements: objects, functions and states. New Jersey: Prentice Hall, 1993.
Teaching Software Testing: Lessons Learned - Drake (2003) (Correct)
No context found.
Davis, Allan, Software Requirements: Objects, Functions, & States, Revision, Prentice Hall, Upper Saddle River, New Jersey, 1993
A Formally Founded Description Technique for Business Processes - Thurner (1997) (6 citations) (Correct)
No context found.
A.M. Davis. Software Requirements -- Objects, Functions, and States. Prentice-Hall International, Inc., Englewood Cliffs, New Jersey,1993.
Modelling an Enterprise Perspective for - Software Requirements.. (Correct)
No context found.
Davis, A. (1993) Software Requirements: Objects, Functions, and States, Prentice Hall.
A Formally Founded Description Technique for Business.. - Veronika Thurner.. (1997) (6 citations) (Correct)
No context found.
A. Davis. Software Requirements -- Objects, Functions, and States. Prentice-Hall International, Inc., Englewood Cliffs, New Jersey, 1993.
Requirements Engineering: a roadmap - Nuseibeh, Easterbrook (2000) (28 citations) (Correct)
No context found.
A. Davis, Software Requirements: Objects, Functions and States, Prentice Hall, 1993.
Management View on Current Requirements Engineering.. - Nikula, Sajaniemi.. (2000) (Correct)
No context found.
Davis, Alan M. (1993), Software Requirements: Objects, Functions, and States. Prentice Hall.
From Contract Drafting to Software Specification: Linguistic.. - Berry, al. (2000) (Correct)
No context found.
Davis, A., Software Requirements: Objects, Functions, and States, Prentice Hall, Englewood Cliffs, NJ (1993). 77
Requirements Engineering for Survivable Systems - Mead (2003) (Correct)
No context found.
Davis, Alan. Software Requirements: Objects, Functions, & States. Englewood Cliffs, N.J: Prentice-Hall Inc., 1993.
An Evaluation of Methods for Prioritizing Software.. - Karlsson, Wohlin, Regnell (1998) (2 citations) (Correct)
No context found.
A. Davis, Software Requirements: Objects, Functions and States. Prentice-Hall International, Englewood Cliffs, New Jersey, 1993.
Building Information Systems Development Methods.. - Fowler, Swatman (Correct)
No context found.
Davis A. (1993) Software Requirements: Objects, Functions and States, Prentice Hall, Englewood Cliffs.
Integrating Semi-formal and Formal Requirements - Roel Wieringa Eric (1997) (Correct)
No context found.
A.M. Davis. Software Requirements: Objects, Functions, States. Prentice-Hall, 1993.
First 50 documents Next 50
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