By Topic

Requirements Engineering, 1994., Proceedings of the First International Conference on

Date 18-22 April 1994

Filter Results

Displaying Results 1 - 25 of 34
  • Proceedings of IEEE International Conference on Requirements Engineering

    Publication Year: 1994
    Save to Project icon | Request Permissions | PDF file iconPDF (38 KB)  
    Freely Available from IEEE
  • Attacking requirements complexity using a separation of concerns

    Publication Year: 1994 , Page(s): 2 - 5
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (396 KB)  

    As systems become more complex, the task of defining requirements must evolve to deal with this complexity. The use of the concepts of “separation of concerns” provides a successful approach for cutting problem complexity down to the level where it can be handled. Such concepts can be added to any notation or “methodology,” but are more effective if the underlying requirements definition notation provides support View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Taxonomy for requirements analysis

    Publication Year: 1994 , Page(s): 176 - 179
    Cited by:  Papers (4)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (340 KB)  

    Techniques that are claimed to be applicable to analysing requirements for software intensive systems have been available for many years, but the extent to which they address this problem for large, complex systems is open to question. The techniques tend to focus on aspects of the system that are understood by specialist system designers, rather than on the issues that concern its prospective owners and users. It is not always clear how, if at all, some of these concerns may be analysed using existing techniques. This taxonomy provides a framework for classifying techniques according to the concerns that need to be addressed and the abstract frames in which analysis might be performed. Identification of all concerns reveals analysis needs, that must be satisfied by the set of abstract frames in which aspects of the system are modelled. Populating the taxonomy can identify where techniques are already available and where further research is needed View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Software requirements as negotiated win conditions

    Publication Year: 1994 , Page(s): 74 - 83
    Cited by:  Papers (25)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (776 KB)  

    Current processes and support systems for software requirements determination and analysis often neglect the critical needs of important classes of stakeholders, and limit themselves to the concerns of the developers, users and customers. These stakeholders can include maintainers, interfacers, testers, product line managers, and sometimes members of the general public. This paper describes the results to date in researching and prototyping a next-generation process model (NGPM) and support system (NGPSS) which directly addresses these issues. The NGPM emphasizes collaborative processes, involving all of the significant constituents with a stake in the software product. Its conceptual basis is a set of “theory W” (win-win) extensions to the spiral model of software development View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Executing, viewing and explaining conceptual models

    Publication Year: 1994 , Page(s): 166 - 175
    Cited by:  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (808 KB)  

    Conceptual models are developed to assess the functional properties of information systems. Since they are used actively during the design and implementation of these systems, an important task is to make sure that the models really represent the users' needs and intentions. PPP (Phenomena, Processes, Program) is an experimental CASE environment. In the PPP environment, the conceptual modeling process is well supported. The PPP language is used during model construction, whereas three validation techniques are integrated for model validation. The combination of model execution, complexity reduction, and explanation generation provides an exposition of conceptual model properties that are difficult to detect reading the models or using standalone techniques. We explain the PPP modeling approach. Particularly, we show how the integration of these techniques work together to make the dynamic properties of PPP models more transparent to the users View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Comparative analysis of embedded computer system requirements methods

    Publication Year: 1994 , Page(s): 126 - 134
    Cited by:  Papers (6)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (632 KB)  

    Requirements methods proven practical on large embedded computer systems (ECS) are formalized, synthesized, and improved. A cross-section of methods are evaluated for robust semantics, mathematical foundation, capability for analysis and verification, and support for model construction, comprehension, reuse and modification View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A case study of applying rapid prototyping techniques in the Requirements Engineering Environment

    Publication Year: 1994 , Page(s): 66 - 73
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (768 KB)  

    Rapid prototyping techniques have been recognized as an important technology for requirements engineering. By developing and exercising executable prototypes as part of the requirements specification process, it is possible to address the well known problems of ambiguity, incompleteness, and inconsistency in capturing requirements for complex software systems. The Requirements Engineering Environment (REE), under development at Rome Laboratory since 1985, provides an integrated toolset for rapidly representing, building, and executing models of critical aspects of complex systems. This paper presents an overview of the REE toolset and describes its capabilities for modeling and analyzing functional, user interface, and performance requirements. It then discusses a case study that illustrates the approach for transitioning REE technology from the laboratory to Air Force user sites. This case study specifically concentrates on applying REE to prototyping activities associated with developing a space debris hazard analysis system. Modeling aspects covered in the study include designing user interfaces, exercising domain-specific analytical models and algorithms, and iterative modification of functional prototypes View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Underlying concepts in process specification

    Publication Year: 1994 , Page(s): 48 - 52
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (420 KB)  

    Underlying concepts in process specification are discussed, such as function, functioning, ordering and conservation. The author describes how these terms represent different forms of purpose attribution to objects. A process modelling technique is proposed in order to complement the usual techniques adopted in requirements engineering View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using formal methods for requirements specification of a proposed POSIX standard

    Publication Year: 1994 , Page(s): 118 - 125
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (644 KB)  

    Demonstrates the utility of formal methods in the development of requirements for standards. We describe the results of an exercise to generate a formal specification of the forthcoming POSIX P1003.21 standard on real-time distributed systems communications. This exercise was conducted by a relative novice in formal methods who did not have significant POSIX domain knowledge. With the assistance of both formal methods experts and domain specialists, the formal specification activity raised a number of issues early in the evolution of the standard. Resolution of these issues by the domain specialists will lead to an improved standard, whether or nor the formal specification is included in the standard. In this paper, we present a classification and analysis of the types of issues raised using our formal approach. Our experience establishes more clearly the benefits of a formal approach to requirements engineering View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Supporting multi-perspective requirements engineering

    Publication Year: 1994 , Page(s): 206 - 215
    Cited by:  Papers (11)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (904 KB)  

    Supporting collaborating requirements engineers as they independently construct a specification is highly desirable. We show how collaborative requirements engineering can be supported using a planner, domain abstractions, and automated decision science techniques. In particular we show how requirements conflict resolution can be assisted through a combination of multi-agent multi-criteria optimization and heuristic resolution generation. We then summarize the use of our tool to rationally reconstruct a library specification. This line of research is significant in that it brings conflict detection and resolution into a requirements engineering framework. This particular work expands the automation found in previous results (W. Robinson, 1993) View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Requirements critiquing using domain abstractions

    Publication Year: 1994 , Page(s): 184 - 193
    Cited by:  Papers (8)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (948 KB)  

    Reusing domain abstractions representing key domain features has been shown to aid requirement specification, however their role in requirements engineering has not been investigated thoroughly. This paper proposes domain abstractions to aid requirements critiquing as well as specification, thus maximising the payoff from retrieving domain abstractions. The requirements critic is part of a prototype intelligent requirements engineering toolkit being developed as part of the Nature project, ESPRIT basic research action 6353. The critic retrieves domain abstractions to validate requirement specifications for problems including incompleteness, inconsistencies and ambiguities. Intelligent, mixed initiative dialogue between the critic and requirements engineer permits requirements critiquing at the right time and level of abstraction View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Deriving human-error tolerance requirements from tasks

    Publication Year: 1994 , Page(s): 135 - 142
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (628 KB)  

    Shows how an understanding of a dynamic system from the point of view of the tasks that it supports and an understanding of human error can guide a process of deriving human error tolerance requirements. Our aim is to provide a means whereby, rather than relying on training as a means of improving operator performance, designers may develop interactive systems with human error tolerance in mind. We extend an established methodology, the systematic human action reliability procedure (SHARP), by employing a software engineering notation, communicating sequential processes (CSP), that provides a bridge between error theory and the practice of design and implementation. In this paper, we outline approaches to human error, describe a task notation based on CSP which helps us to elicit requirements on human-error tolerance expressed as functional properties of the system. The technique is used to analyse an engine fire recovery procedure in order to derive human error tolerance requirements View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Towards a system for the construction, clarification, discovery and formalisation of requirements

    Publication Year: 1994 , Page(s): 230 - 238
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (528 KB)  

    Requirements engineering is fraught with possibilities for misunderstanding and mistakes and it is well known that the earlier such errors occur in the lifecycle the more costly the consequences. Formal specifications provide from a developer's perspective a clear, concise and unambiguous statement of the system requirements. Prototyping enables effective user participation in the validation of requirements The authors report on work towards a system that judiciously combines the strengths of formal specification and prototyping to assist in the construction, negotiation, clarification, discovery and formalisation of requirements that could make the crucial activity of requirements engineering less problematic View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • An OOA model with system function specifications

    Publication Year: 1994 , Page(s): 16 - 23
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (464 KB)  

    A new OOA model and methodology are proposed. The proposed OOA model is composed of an object model, which specifies objects and the relationships between them, and a function model, which specifies system functions and their operation logic. The proposed OOA methodology develops the specifications of objects and system functions in parallel by following a functional refinement process. Since system functions are specified clearly in the OOA model, the user can easily understand what the system can do by tracing its specification. The object model and function model are developed in parallel, so the consistency between system functions and objects are kept throughout the OOA process View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A multimedia approach to requirements capture and modeling

    Publication Year: 1994 , Page(s): 53 - 56
    Cited by:  Papers (8)  |  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (380 KB)  

    The Advanced Multimedia Organizer for Requirements Elicitation (AMORE) embodies a synthesis of technologies adapted specifically for application to requirements elicitation processes and models. Elicitors will use AMORE as a platform for storing requirements in as close to their natural forms as possible to maximize traceability and to promote understanding of original intentions and motivations. AMORE fills the gap that exists between raw requirements source material and the more formalized requirements representations commonly used by specification methods and CASE tools. The concepts and technologies demonstrated by AMORE are suitable for inclusion as a front-end augmentation to existing CASE analysis tools View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The concept of operations: the bridge from operational requirements to technical specifications

    Publication Year: 1994 , Page(s): 40 - 47
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (756 KB)  

    The authors describe the role of a “concept of operations” (ConOps) document in the specification and development of a software-intensive system. They also describe the process of developing a ConOps, its uses and benefits, who should develop it, and when it should be developed. The ConOps described, is compared to other forms of operational concept documents. A recommended format for the ConOps document is presented View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Modeling the evolution of artifacts

    Publication Year: 1994 , Page(s): 216 - 219
    Cited by:  Papers (5)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (348 KB)  

    The particular requirements engineering (RE) process modeling approach presented, advocates the capture of the history RE artifacts. An artifact is viewed as an evolutionary object which evolves as the RE process proceeds. The author proposes a classification of the various kinds of evolution of artifacts and presents a generic model, the evolutionary object model, to structure the RE history kept in the artifact's memory according to this classification. She emphasises the role of RE decisions in the evolutionary process and shows how the rationale of an artifact evolution can be expressed in terms of decisions and stored in the evolutionary object history View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Organisational requirements definition for information technology systems

    Publication Year: 1994 , Page(s): 158 - 165
    Cited by:  Papers (2)  |  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (740 KB)  

    We describe a model of the requirements determination process based on four concurrent subprocesses which we term scoping, modelling, requirements and options. The main features of each of these subprocesses are described and we propose that the concept of responsibility is a boundary object which links them all. We also argue that analysing an organisation in terms of responsibilities leads to requirements definition in a more natural manner than basing the organisational analysis on activities View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The directorate information system at St Thomas' hospital: a study in domain analysis

    Publication Year: 1994 , Page(s): 102 - 109
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (696 KB)  

    Describes a project run at St Thomas' Hospital whose goal was to design an information system that would support the business of a `clinical directorate'. We argue that the analysis for an information system in an area as complex as this needs to be preceded by detailed domain analysis, and that conventional techniques are inadequate. The method used is described this supports the construction of formal set theoretic domain theories, and the refinement of those theories through refutation and reconstruction. The domain theory that was developed is elucidated. Some abstract properties of the domain are described and discussed. An animation of the theory is presented and examples of behavioural theorems that were refuted by domain experts are given. Some philosophical issues concerning the method are briefly discussed View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The REVIEW system: from formal specifications to natural language

    Publication Year: 1994 , Page(s): 220 - 229
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (732 KB)  

    Formal descriptions, while difficult for most human readers to understand, are convenient for specifying large software systems, where completeness and consistency are important issues. Informal specifications can offer advantages in conciseness and readability, but ambiguities and contradictions are an unavoidable side-effect. Since a specification often acts as a formal contract between the software developer and the customer, it is essential that both sides be able to fully understand the specification document. Systems have been proposed which help the software client better understand the specification by automatically paraphrasing it in natural language. The authors describe the architecture of the REVIEW system, which forms a part of the Metaview metasystem for capturing requirements information. Some example natural language outputs are shown for a sample requirements database View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • An object-oriented dual language for specifying reactive systems

    Publication Year: 1994 , Page(s): 6 - 15
    Cited by:  Papers (7)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (992 KB)  

    Descriptive software specification techniques are based on mathematical formalism and produce precise, rigorous specifications which are in general to be preferred for the design of reactive systems with respect to operational techniques. Recently, dual languages which tend to integrate these aspects have been investigated. An object-oriented specification dual language, named TROL is presented, it consists in an executable formal specification model which can be used for validation of reactive systems. TROL has the capability to describe the system behavior, its functionality and structural aspects. It allows one to describe the system at different levels of structural abstractions and specification details without boundaries among the specification steps. At each specification level, TROL helps the user in the verification of consistency, thus allowing incremental specification. TROL has a visual representation which has been supported by a CASE tool named TOOMS View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A visual software requirements definition method

    Publication Year: 1994 , Page(s): 194 - 201
    Cited by:  Papers (6)  |  Patents (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (540 KB)  

    The author proposes a visual software requirements definition method including the description of a visual software requirements specification (SRS) with a visual requirements language and executing the SRS. The method proposed provides a describer for defining both the shape and semantics of icons to specify the requirements as he imagines them. The method also provides for describing icons' movements as a scenario description. This scenario enables an execution of the SRS with animation. The describer can confirm his requirements by checking the animation. A visual requirements language named VRDL and tools are illustrated with examples. The visual requirements specification method proposed contributes to improve the understandability of an SRS and the easiness to write the SRS. The method also improves the correctness of the SRS View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The role of software architecture in requirements engineering

    Publication Year: 1994 , Page(s): 239 - 245
    Cited by:  Papers (6)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (524 KB)  

    The role of software architecture (which reflects high-level implementation constraints) in requirements engineering is clarified by providing perspectives on relevant issues, including the following: is requirements engineering merely a front end to the software development process that is concerned only with problem definition? Is software architecture an application-specific, high-level design of a system (for example, “an object-oriented system with a specified object hierarchy”)? What is the relationship between the problem definition and the solution structure? What is the relationship between the roles of requirements engineer, software architect, and application domain specialist? View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • System bounding issues for analysis

    Publication Year: 1994 , Page(s): 24 - 31
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (724 KB)  

    Defining system boundaries is an important part of analysis. Bounding is a separate process from partitioning or decomposing the problem. System boundaries show what is inside and outside the system whereas partitions manage the complexity of the problem. The authors discuss the tradeoffs between early and late bounding and conclude that the bounding process should be done late or at least repeated late in analysis. Specification of system boundaries improves when as much as possible is known about the problem. Analysis techniques should contain a representation and process to support system bounding. The authors demonstrate system bounding by comparing analyses done with structured analysis (SA) and object-oriented analysis (OOA). SA techniques bound the system at the start of analysis. OOA techniques bound the system either late in analysis or not at all. A boundary identification process for late bounding is presented and demonstrated View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Requirements engineering standardization

    Publication Year: 1994 , Page(s): 57 - 63
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (432 KB)  

    As requirements engineering becomes more widespread, practitioners have learned what works and what does not work, as well as how to communicate among themselves and with other specialists, leading to standards development efforts and an increasing number of standards. This is to be welcomed, because it reflects the maturity of the technology and the realization of the importance of the specialty. Of the many standardization efforts under way, six have been selected, based on their importance and their level of progress: (1) IEEE Standard 830 (software requirements specifications) revision; (2) Software Engineering Institute's systems engineering capability maturity model (SECMM); (3) National Council on Systems Engineering (NCOSE)-requirements; (4) IEEE Draft Standard P1233 (system requirements specification); (5) MIL-STD-499B (systems engineering) revision; and (6) IEEE Task Force on Engineering of Computer-Based Systems (ECBS)-requirements. Representatives of each of these efforts briefly present their current status and plans, how the standards will affect the way requirements engineering is performed, and how the standards will interact with each other View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.