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

....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.

....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.

....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.

....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.

....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.

....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.

....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.

.... 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.

.... 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.

....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.

....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.

....naturally to functional 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 [8] while quality softgoals are either operationalized or metricized [9]. For example, a security softgoal might be operationalized by defining interfaces which minimize input output between the system and its environment, or by limiting access to sensitive information. Alternatively, the security requirement may be metricized into something like No more than X ....

Davis, A., Software Requirements: Objects, Functions and States, Prentice Hall, 1993.

....naturally to functional 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 [7] while quality softgoals are either operationalized or metricized [8]. 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 ....

Davis, A., Software Requirements: Objects, Functions and States, Prentice Hall, 1993.

....to functional and non functional requirements. Leaving (some) goal dependencies between system actors and other actors is a novelty. Traditionally, functional goals are 10 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.

....Dataflow diagrams have been used to model systems, not just software systems, even before computers were invented. Several forward engineering techniques for developing software systems use dataflow information for analyzing the requirements and or the designs. Some such techniques are [2]: De Marco s Structured Analysis and System Specification (SASS) Gane and Sarson s Structured Systems Analysis, Orr s Structured Requirements Definition (SRD) Teichrow s Program Statement Language Program Statement Analyzer (PSL PSA) Ross s Structured Analysis and Design Technique (SADT) Ward ....

A. M. Davis. Software Requirements: Objects, Functions, and States. Prentice Hall, 1993.

....parts of the speci cation, and to re run the test suite. In principle, the taken approach has proved to be very e ective in the detection of errors. On the VDMTools side, pre and post condition checks have been used intensively. The model of SSD has a strong state transition character. In [1] a taxonomy of applications is given. According to the item relative diculty of data, control, and algorithmic aspects of problem, SSD may essentially be classi ed as a mixed data control problem. VDM SL [8] is a speci cation language that is well suited for modeling data. For event based ....

A. Davis. Software Requirements: Objects, Functions and States. Prentice Hall, Englewood Clis, 1993.

....internal behaviour of the system. ffl Functional constraints. These constitute the main part of the so called nonfunctional requirements. In general, non functional requirements define the overall qualities or attributes to be exhibited by the resulting system (Mylopoulos, Chung and Nixon, 1992; Davis, 1993). In that respect, the results returned from any computation are often only useful if they satisfy a number of constraints. Most of the times these constraints include performance, response times, capacities, numbers of users, safety standards, security standards and quality issues. As a result, ....

....4. Requirements can be consistently derived from other requirements, in order to accommodate a progressive refinement of the model and various engineering modelling decisions. 5. Various forms of traceability can be supported. Traceability can be classified into four types, according to Davis (1993): Backward from . Links requirements to their sources. Forward from . Links requirements to design and implementation. Backward to . Links design and implementation back to requirements. Forward to . Links sources of requirements (e.g. various documents) to requirements. As ....

[Article contains additional citation context not shown here]

Davis, A. M. (1993). Software Requirements: Objects, Functions and States, PrenticeHall International, Inc., Englewood Cliffs, N.J.

....for design and implementation. Requirements Engineering is one of the early but important phases in the software development life cycle and numerous studies have revealed the misidentification of requirements as one of the most significant sources of customer dissatisfaction with delivered systems [10], 22] 28] However, it is a difficult process, as it involves the elicitation, analysis and documentation of knowledge from multiple stakeholders of the system. There is an increased need to involve the users at this stage of the development life cycle [8] 29] It is recognised that the users ....

Davis, A. M. (1993). Software requirements: Objects, Functions, and States, Prentice Hall, New Jersey.

....naturally to functional 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 [7] while quality softgoals are either operationalized or metricized [8]. 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 ....

Davis, A., Software Requirements: Objects, Functions and States, Prentice Hall, 1993.

....naturally to functional 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 [Dar93] while quality softgoals are either operationalized or metricized [Dav93]. 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 ....

Davis, A., Software Requirements: Objects, Functions and States, Prentice Hall, 1993.

....naturally to functional 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 [6] while quality softgoals are either operationalized or metricized [11]. For example, Fast processing may be operationalized during late requirements analysis into particular business processes for processing claims. Likewise, a security softgoal might be operationalized by defining interfaces which minimize input output between the Claims manager Tracker Trouble ....

Davis, A., Software Requirements: Objects, Functions and States, Prentice Hall, 1993.

....system structure, data or behavior. These models are the basis for communication between expert users and system analysts, and the foundation for system design and implementation later on in the system development process. Thus, they are a decisive factor for software quality and correction costs [7]. A basic idea of system modeling is the reduction of complexity by focussing on a single system view and only a small set of system aspects at a time. In behavior modeling, a first step consists of the analysis and documentation of typical system behavior in an exemplaric way. Thus, single system ....

A. Davis. Software Requirements -- Objects, Functions, and States. Prentice-Hall International, Inc., Englewood Cliffs, New Jersey, 1993.

....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 understanding 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 are characteristically more stable than the processes, organizational structures and operations of a ....

A. M. Davis, Software Requirements: Objects, Functions, & States, Prentice-Hall, 1993.

....being put into use. But we can make the requirement specification as close as possible with the needs of the customers and let the unmatched parts be smaller and smaller. A variety of techniques to enhance requirements have been developed during the past years: SADT[7, 6] objectoriented analysis[3, 13], and rapid prototyping[14, 23] ect. Recently because of the acknowledge that multiple participants are necessarily involved in system development, multiple viewed approaches have been studied[1, 22, # This work is partly supported by the Royal Society of the UK, the National Key Project of China, ....

Alan M.Davis. Software Requirements: Object, Functions and States. Prentice-Hall, 1993.

....on the human user, our approach makes explicit the causality of the system to be built on the overall system. We also cannot give here a comprehensive overview of all the proposed approaches to requirements engineering. Especially for the traditional ones, the interested reader is referred to [5]. More recent work on scenarios in the context of requirements engineering [8, 13] made useful contributions, but these approaches do not address the purposes of scenarios. Recent object oriented analysis methods (for an overview see [6] challenge the traditional ones. RETH heavily builds on ....

A. M. Davis. Software Requirements: Objects, Functions, and States. Prentice Hall, Englewood Cliffs, NJ, 1993.

.... informally (in unrestricted natural language) semi formally (e.g. in restricted natural language or with the help of diagrams) or formally (e.g. in logical or algebraic formalisms) The distinction between needs analysis, solution space definition and conceptual modeling is also found in Davis [3], who uses a slightly different terminology. The reason to separate requirements engineering from conceptual modeling is that requirements engineering focuses on utility and conceptual modeling focuses on validity. The key question during requirements engineering is are we specifying an answer ....

A.M. Davis. Software Requirements: Objects, Functions, States. Prentice-Hall, 1993.

....with each one of these stages. While individual process models vary in detail, they largely agree on the existence of an analysis or requirements stage, followed by a design stage, an implementation and unit testing stage, an integration testing stage, and finally a maintenance stage. In [3] Davis cites various studies that analyze the impact that early life cycle software engineering has on the overall cost of software projects. In particular, according to these studies removing a bug at the requirements stage can be 200 times less costly than removing it at the maintenance stage. ....

....class. When replicated capsule instances have non private data objects an index notation will be used to refer to a particular instance of that capsule. Consider that the third instance of a capsule of type Terminator provides a public data object digit, then this could be referred to as Z. Y[3]: digit where Z is the name of the containing instance of class POTS. v Promela provides for a global array variable procid which stores the information whether a particular capsule instance exists at any point in time, or not. Messages. A message in v Promela consists of two parts, a message ....

A. Davis. Software Requirements: Objects, Functions and States. Prentice-Hall, 1993.

.... (and tools) including a wide range of features such as theorem proving, interpretation and automatic code generation from specifications [25, 15] At the end of the domain problem understanding phase, VDM SL has been selected as a specification language and IFAD s VDMTools for tool support: In [7] a taxonomy of applications is given. According to the item relative difficulty of data, control, and algorithmic aspects of problem, SSD may essentially be classified as a mixed data control problem. VDM SL [21] is a specification language that is well suited for modeling data. VDM SL has been ....

Davis A. M. Software Requirements: Objects, Functions and States. Second Edition. Prentice Hall, Englewood Cliffs, 1993.

....tempting to just focus on the programming of these agents, for more sophisticated information agent applications it is essential to design them on a higher conceptual level. A principled design process not only involves conceptual design specifications but also requirements specifications (e.g. [11], 28] 32] and verification e.g. 30] In the first place, in order to develop a system with appropriate properties, such a design process includes the analysis of requirements on the functionality or behaviour of the overall (multi agent) system consisting of the information agents. ....

....of requirements and scenarios for this example domain are discussed in section 2. In section 3 design structures are discussed. Verification is the topic of section 4 while section 5 concludes with a brief discussion. 2 Specification of Requirements and Scenarios In Requirements Engineering (cf. [11], 13] 14] 15] 22] 28] 29] 32] the role of scenarios, in addition to requirements, has gained more importance; e.g. see [17] 34] Traditionally, scenarios or use cases are examples of interaction patterns between the users and a system; they are often used during the requirement ....

Davis, A. M., Software requirements: Objects, Functions, and States, Prentice Hall, New Jersey, 1993.

....the lack of user participation throughout the use case specification process, the scenarios were not validated by system users; thus, 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 [Dav93]. The fact that the authors only investigated scenarios from one viewpoint also introduces risk, since exploring multiple viewpoints yields more comprehensive requirements coverage. Poor traceability leads to inconsistency Traceability is a measure of quality that reduces the risk of, for ....

Davis, A.M. Software Requirements: Objects, Functions, & States,. Prentice-Hall, 1993.

....different aspects of requirements engineering[284] Central to the definition is a user, or stakeholde r, need. For example, Davis states that a requirement is a user need or a necessary feature, function, or attribute of a system that can be sensed from a position external to that system [45]. The IEEE standard 610 (1990) has a similar definition: A condition or capacity needed by a user to solve a problem or achieve an objective . A condition or capacity that must be met or possessed by a system or systems component to satisfy a contract, standard, specification or other formally ....

Davis, A., Software Requirements: Objects, functions, and states, Prentice Hall, 1993.

....project risks. Since the scenarios were developed by the authors and were not validated by system users, we suspect the scenarios provide some misinformation 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 is also an area of potential risk, since exploring into multiple viewpoints yields more comprehensive coverage of the requirements. ### ################################### Due to the lack of requirements management ....

Davis, A.M. Software Requirements: Objects, Functions, & States,. Prentice-Hall, 1993.

....engineering is focused primarily on formulating improved notations and analyses, and on developing methods and mechanisms for requirements elicitation, rationale capture, and traceability. In practice, requirements engineers are responsible for partitioning, abstraction, and projection [23]. Partitioning amounts to organizing the functionality of the desired system. Abstraction is used to create hierarchical relationships among the problem domain entities. Projection selects salient views of a system, use cases for example. Partitioning and abstraction are required to identify the ....

A.M. Davis. Software Requirements - Objects, Functions, & States. Prentice-Hall, Englewood Cliffs, New Jersey, 1993.

....help avoiding inconsistencies in the requirements, they are the basis for deriving correct system designs, they are essential in establishing the system s correctness by serving as a basis for testing and formal verification, and they are important in the documentation of system requirements. [20] suggests that proper requirements engineering, of which requirements specification is an important step, is pivotal in avoiding pitfalls of what is called the software crisis . Facets of the software crisis include systems that have low reliability or even unusability at time of delivery to the ....

....is an important step, is pivotal in avoiding pitfalls of what is called the software crisis . Facets of the software crisis include systems that have low reliability or even unusability at time of delivery to the customer, and software projects that exceed budget limits and project deadlines. [20] argues that the cost of repairing a bug due to a falsely stated requirement at the maintenance stage of the system s life cycle is about 200 times higher than the cost of repair at the requirements specification stage. The complexity of software projects in the area of embedded real time and ....

[Article contains additional citation context not shown here]

A. M. Davis. Software Requirements: Objects, Functions and States. PrenticeHall, 1993.

No context found.

A. Davis and F. Giunchiglia, Software Requirements: Objects, Functions and States, Prentice Hall, 1993.

No context found.

A. M. Davis. Software Requirements: Objects, Functions and States. Prentice-Hall, Englewood Cliffs, NJ, 1993.

No context found.

A. M. Davis, Software Requirements: objects, functions and states. New Jersey: Prentice Hall, 1993.

No context found.

Davis, Allan, Software Requirements: Objects, Functions, & States, Revision, Prentice Hall, Upper Saddle River, New Jersey, 1993

No context found.

A.M. Davis. Software Requirements -- Objects, Functions, and States. Prentice-Hall International, Inc., Englewood Cliffs, New Jersey,1993.

No context found.

Davis, A. (1993) Software Requirements: Objects, Functions, and States, Prentice Hall.

No context found.

A. Davis. Software Requirements -- Objects, Functions, and States. Prentice-Hall International, Inc., Englewood Cliffs, New Jersey, 1993.

No context found.

A. Davis, Software Requirements: Objects, Functions and States, Prentice Hall, 1993.

No context found.

Davis, Alan M. (1993), Software Requirements: Objects, Functions, and States. Prentice Hall.

No context found.

Davis, A., Software Requirements: Objects, Functions, and States, Prentice Hall, Englewood Cliffs, NJ (1993). 77

No context found.

Davis, Alan. Software Requirements: Objects, Functions, & States. Englewood Cliffs, N.J: Prentice-Hall Inc., 1993.

No context found.

A. Davis, Software Requirements: Objects, Functions and States. Prentice-Hall International, Englewood Cliffs, New Jersey, 1993.

No context found.

Davis A. (1993) Software Requirements: Objects, Functions and States, Prentice Hall, Englewood Cliffs.

No context found.

A.M. Davis. Software Requirements: Objects, Functions, States. Prentice-Hall, 1993.

No context found.

A. Davis, Software Requirements: Objects, Functions, and States, Prentice Hall, (1993).

No context found.

Davis, A. (1993). Software Requirements: Objects, Functions and States. Prentice Hall.

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