共查询到20条相似文献,搜索用时 0 毫秒
1.
In many applications, especially from the business domain, the requirements specification mainly deals with use cases and
class models. Unfortunately, these models are based on different modelling techniques and aim at different levels of abstraction,
such that serious consistency and completeness problems are induced. To overcome these deficiencies, we refine activity graphs
to meet the needs for a suitable modelling element for use case behaviour. The refinement in particular supports the proper
coupling of use cases via activity graphs and the class model. The granularity and semantics of our approach allow for a seamless,
traceable transition of use cases to the class model and for the verification of the class model against the use case model.
The validation of the use case model and parts of the class model is supported as well. Experience from several applications
has shown that the investment in specification, validation and verification not only pays off during system and acceptance
testing but also significantly improves the quality of the final product. 相似文献
2.
Deriving Goals from a Use-Case Based Requirements Specification 总被引:2,自引:2,他引:0
Annie I. Antón Ryan A. Carter Aldo Dagnino John H. Dempster Devon F. Siege 《Requirements Engineering》2001,6(1):63-73
Use cases and scenarios have emerged as prominent analysis tools during requirements engineering activities due to both their
richness and informality. In some instances, for example when a project’s budget or schedule time is reduced at short notice,
practitioners have been known to adopt a collection of use cases as a suitable substitute for a requirements specification.
Given the challenges inherent in managing large collections of scenarios, this shortcut is cause for concern and deserves
focused attention. We describe our experiences during a goal-driven requirements analysis effort for an electronic commerce
application. In particular, we identify the specific risks incurred, focusing more on the challenges imposed due to traceability,
inconsistent use of terminology, incompleteness and consistency, rather than on traditional software project management risks.
We conclude by discussing the impact of the lessons learned for requirements engineering in the context of building quality
systems during goal and scenario analysis. 相似文献
3.
Requirements Engineering-Based Conceptual Modelling 总被引:1,自引:1,他引:1
The software production process involves a set of phases where a clear relationship and smooth transitions between them should
be introduced. In this paper, a requirements engineering-based conceptual modelling approach is introduced as a way to improve
the quality of the software production process. The aim of this approach is to provide a set of techniques and methods to
capture software requirements and to provide a way to move from requirements to a conceptual schema in a traceable way. The
approach combines a framework for requirements engineering (TRADE) and a graphical object-oriented method for conceptual modelling
and code generation (OO-Method). The intended improvement of the software production process is accomplished by providing
a precise methodological guidance to go from the user requirements (represented through the use of the appropriate TRADE techniques)
to the conceptual schema that properly represents them (according to the conceptual constructs provided by the OO-Method).
Additionally, as the OO-Method provides full model-based code generation features, this combination minimises the time dedicated
to obtaining the final software product. 相似文献
4.
This paper presents an automated tool for scenario-driven requirements engineering where scenario analysis plays the central
role. It is shown that a scenario can be described by three views of data flow, entity relationship and state transition models
by slight extensions of classic data flow, entity relationship and state transition diagrams. The notions of consistency and
completeness of a set of scenarios are formally defined in graph theory terminology and automatically checked by the tool.
The tool supports automatic validation of requirements definitions by analysing the consistency between a set of scenarios
and requirements models. It also supports automatic synthesis of requirements models from a set of scenarios. Its utility
and usefulness are demonstrated by a non-trivial example in the paper. Case studies of the tools are also presented. 相似文献
5.
The requirements specification – as outcome of the requirements engineering process – falls short of capturing other useful
information generated during this process, such as the justification for selected requirements, trade-offs negotiated by stakeholders
and alternative requirements that were discarded. In the context of evolving systems and distributed development, this information
is essential. Rationale methods focus on capturing and structuring this missing information. In this paper, we propose an
integrated process with dedicated guidance for capturing requirements and their rationale, discuss its tool support and describe
the experiences we made during several case studies with students. Although the idea of integrating rationale methods with
requirements engineering is not new, few research projects so far have focused on smooth integration, dedicated tool support
and detailed guidance for such methods. 相似文献
6.
Scenario Management: An Interdisciplinary Approach 总被引:2,自引:0,他引:2
7.
The application of object oriented concepts (OO) to the requirements phase of information systems (IS) and software development
has been adopted by many proponents of IS and software development methodologies. Although many claims have been made about
the effectiveness of OO techniques for improving requirements analysis, very few experimental studies have been done to substantiate
these claims. This paper addresses this gap in the literature by conducting an experimental study that attempts to validate
the effectiveness of object-oriented analysis (OOA) by comparing it to structured analysis (SA) for producing requirements.
We argue that the quality of the requirements specification can be measured and that measurement can be used to compare the
effectiveness of OOA and SA. We present an overview of the basic models and principles associated with OOA and SA, a discussion
of quality in requirements definition, and a detailed discussion of the research methodology used. A review of relevant research
is also presented and directions for further research are suggested. Our findings suggest that the OOA methodology does not
necessarily produce better requirements statements. 相似文献
8.
A case study of requirements engineering practice is reported. The application, a decision support system for the Greek Ministry
of Health, was investigated by studying the process of requirements analysis through to design and implementation. A usability
analysis was then conducted on the designed system with the users. Several usability problems were discovered, and interviews
uncovered further problems with the system that could be attributed to failure in requirements engineering (RE). Even though
requirements were explicitly stated and the system was an evolution from an existing legacy system, functionality was defective
and usability was poor. The client’s prime concern for redeveloping the system was to improve usability; unfortunately communications
problems in the RE process meant that the developers did not appreciate this. The implications for RE methods and understanding
the RE process are discussed. 相似文献
9.
By analogy with a Software Requirements Specification (SRS), it is argued that a Method Requirements Specification (MRS) should
be introduced in method engineering. It shares with the SRS the property of implementation-independence. This means that an
MRS must be an instance of an abstract metamodel and not of a technical metamodel like GOPRR (Graph, Object, Property, Relationship,
and Role). The MRS is then translated to be an instantiation of a technical metamodel. We develop a representation system
for an MRS and describe an automated process for instantiating a technical metamodel with an MRS. This instantiation is used
to produce the actual method which is then given to a metaCASE to produce a CASE tool. Thus, we propose a method engineering
approach rooted in the MRS. 相似文献
10.
Requirements Engineering and Technology Transfer: Obstacles, Incentives and Improvement Agenda 总被引:1,自引:0,他引:1
Hermann Kaindl Sjaak Brinkkemper Janis A. Bubenko Jr Barbara Farbey Sol J. Greenspan Constance L. Heitmeyer Julio Cesar Sampaio do Prado Leite? Nancy R. Mead John Mylopoulos Jawed Siddiqi 《Requirements Engineering》2002,7(3):113-123
For many years, research results in requirements engineering (RE) have been developed without much interaction with, or impact
on, industrial practice. Why is it so difficult to introduce RE research results into mainstream RE practice? This paper attempts
to provide answers to this question by describing obstacles that researchers and practitioners have encountered when they
attempted technology transfer. In addition, major incentives for using RE methods are discussed, along with ideas for improving
current RE practice. The paper summarises, clarifies and extends the results of two panel discussions, one at the Twelfth
Conference on Advanced information Systems Engineering (CAiSE’00) and the other at the Fourth IEEE Conference on Requirements
Engineering (ICRE’00). 相似文献
11.
Cynthia E. Irvine Timothy Levin Jeffery D. Wilson David Shifflett Barbara Pereira 《Requirements Engineering》2002,7(4):192-206
Requirements specifications for high-assurance secure systems are rare in the open literature. This paper examines the development
of a requirements document for a multilevel secure system that must meet stringent assurance and evaluation requirements.
The system is designed to be secure, yet combines popular commercial components with specialised high-assurance ones. Functional
and non-functional requirements pertinent to security are discussed. A multidimensional threat model is presented. The threat
model accounts for the developmental and operational phases of system evolution and for each phase accounts for both physical
and non-physical threats. We describe our team-based method for developing a requirements document and relate that process
to techniques in requirements engineering. The system requirements document presented provides a calibration point for future
security requirements engineering techniques intended to meet both functional and assurance goals.
RID="*"
ID="*"The views expressed in this paper are those of the authors and should not be construed to reflect those of their employers
or the Department of Defense. This work was supported in part by the MSHN project of the DARPA/ITO Quorum programme and by
the MYSEA project of the DARPA/ATO CHATS programme.
Correspondence and offprint requests to: T. Levin, Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943-5118, USA. Tel.: +1 831 656 2339;
Fax: +1 831 656 2814; Email: levin@nps.navy.mil 相似文献
12.
面向对象方法正在逐渐取代传统的方法,日益成为当今软件工程领域的主流方法。在系统需求设计方法中用例模型已成为获取系统需求的主要技术,通过用例模型的建立和对用例的分析软件开发者可以准确地了解用户需求和系统功能。它是用户和软件开发者一起剖析系统需求的关键一步,可以推动需求分析后各阶段的开发工作。 相似文献
13.
Jean-Charles Pomerol 《Requirements Engineering》1998,3(3-4):174-181
In this paper, we address the question of how flesh and blood decision makers manage the combinatorial explosion in scenario
development for decision making under uncertainty. The first assumption is that the decision makers try to undertake ‘robust’
actions. For the decision maker a robust action is an action that has sufficiently good results whatever the events are. We
examine the psychological as well as the theoretical problems raised by the notion of robustness. Finally, we address the
false feeling of decision makers who talk of ‘risk control’. We argue that ‘risk control’ results from the thinking that one
can postpone action after nature moves. This ‘action postponement’ amounts to changing look-ahead reasoning into diagnosis.
We illustrate these ideas in the framework of software development and examine some possible implications for requirements
analysis. 相似文献
14.
G. Kotonya 《Requirements Engineering》1999,4(3):115-133
The notion of viewpoints as a means of eliciting and formulating requirements is now well known. However, there is little
practical evidence that viewpoint-based requirements methods scale up to address real problems. This paper presents a detailed
case study based on a medium-sized system, and illustrates how a viewpoint-based requirements method can be used to structure
and specify system requirements. The case study is intended to serve two purposes: first, to demonstrate the scalability of
viewpoint-based requirements methods; and second, to act as a shared example for other researchers in the field to test their
techniques and methods. The case study is based on an electronic document delivery and interchange system (EDDIS). The requirements
are presented as they appeared in the original user requirements document. The paper concludes by outlining the lessons learnt
in applying VORD to EDDIS, and proposes a set of 10 comparators that other researchers can use to compare their approaches
and techniques. 相似文献
15.
I. Alexander 《Requirements Engineering》2002,6(4):252-255
Scenarios are ways of representing knowledge. They may take many forms, from films of real events through acted scenes to
documented procedures. These forms differ in many ways, including how vivid or abstract they are, how accessible they are
as specifications, and how effective they are in helping to elicit requirements. Scenarios, especially as Use Cases, are in
use or proposed for many aspects of systems engineering. Understanding of the different forms scenarios may take, and then
of the costs and benefits of applying these forms in practice, may be valuable. 相似文献
16.
User interface and requirements prototyping is a requirements elicitation technique. A user interface and requirements prototype
is built during the requirements engineering phase of a software system development. Along with the user interface prototype
are produced various documents such as the system requirement specification. When a prototype and other documents exist, they
may not describe the same functionality, particularly because there may be behaviour of the prototype, artefacts of prototyping,
that may not be intended. The problem is that in later development stages, when there is a prototype and other documents,
it is often difficult to reconcile the difference between the prototype and the other documents. This paper presents an approach
for avoiding this difficulty. It demonstrates the approach by showing its application to parts of a real software development. 相似文献
17.
The system requirements specification (SRS) is a highly dynamic document that grows and evolves throughout a software development
project, and it is critical that it be carefully engineered and managed. Because the SRS fulfils many roles and is of interest
to a diversity of stakeholders, its management should be a collaborative process supported by an automated tool. Commercial
requirements management tools are at present insufficiently versatile to support collaboration between a multidisciplinary
and potentially distributed team of stakeholders. The requirements for such a collaborative tool are herein presented, alongside
the design of a prototype and the findings of its application in a case study. 相似文献
18.
Variability is a central concept in software product family development. Variability empowers constructive reuse and facilitates
the derivation of different, customer specific products from the product family. If many customer specific requirements can
be realised by exploiting the product family variability, the reuse achieved is obviously high. If not, the reuse is low.
It is thus important that the variability of the product family is adequately considered when eliciting requirements from
the customer.
In this paper we sketch the challenges for requirements engineering for product family applications. More precisely we elaborate
on the need to communicate the variability of the product family to the customer. We differentiate between variability aspects
which are essential for the customer and aspects which are more related to the technical realisation and need thus not be
communicated to the customer. Motivated by the successful usage of use cases in single product development we propose use
cases as communication medium for the product family variability. We discuss and illustrate which customer relevant variability
aspects can be represented with use cases, and for which aspects use cases are not suitable. Moreover we propose extensions
to use case diagrams to support an intuitive representation of customer relevant variability aspects.
Received: 14 October 2002 / Accepted: 8 January 2003
Published online: 27 February 2003
This work was partially funded by the CAFé project “From Concept to Application in System Family Engineering”; Eureka Σ! 2023
Programme, ITEA Project ip00004 (BMBF, F?rderkennzeichen 01 IS 002 C) and the state Nord-Rhein-Westfalia. This paper is a
significant extension of the paper “Modellierung der Variabilit?t einer Produktfamilie”, [15]. 相似文献
19.
Why do the business requirements and the final software product often have little in common? Why are stakeholders, developers
and managers reluctant to embrace a full requirements process? Why does everybody say, ‘We don’t have time for requirements’?
Why is the potentially most beneficial part of the development process ignored or short-changed?
Following are some observations about why the real requirements for the product often go undiscovered. We will address this
by focusing on the different concerns of the people involved in requirements. 相似文献
20.
Luiz Marcio Cysneiros Julio Cesar Sampaio do Prado Leite Jaime de Melo Sabat Neto 《Requirements Engineering》2001,6(2):97-115
The development of complex information systems calls for conceptual models that describe aspects beyond entities and activities.
In particular, recent research has pointed out that conceptual models need to model goals, in order to capture the intentions
which underlie complex situations within an organisational context. This paper focuses on one class of goals, namely non-functional
requirements (NFR), which need to be captured and analysed from the very early phases of the software development process.
The paper presents a framework for integrating NFRs into the ER and OO models. This framework has been validated by two case
studies, one of which is very large. The results of the case studies suggest that goal modelling during early phases can lead
to a more productive and complete modelling activity. 相似文献