当前位置：搜档网 › 高级需求工程 Advanced Requirement Engineering -- Chapter 6

高级需求工程 Advanced Requirement Engineering -- Chapter 6

CHAPTER 6

C.A.S.E.T e c h n o l o g y

Intr o duc ti o n

The overall aim of CASE technology is to improve the productivity and quality of the resulting systems by assisting the developer throughout the different stages of the development process; from the acquisition of the functional and non-functional system requirements to the design and implementation of the system considering all the relevant technical and operational features.

CASE provides the software tools that support methodologies to employ in modelling all levels of an organisation. In this sense it is more appropriate to consider CASE in a wider context than just software production, that has normally been the case. Therefore, CASE may be described as software tools for enterprise support consisting of enterprise strategic planning, IS strategic planning, project planning, systems development, documentation and maintenance.

This chapter is organised as follows. Section 6.1 presents the possible advantages from the CASE technology and the need for CASE as part of system development and especially Requirements Engineering. Section 6.2 provides a classification of CASE technology. Distinctions are made between stand-alone CASE tools and integrated environments. Section 6.3 presents a generic architecture for CASE. Despite the plethora of CASE tools and supported methodologies in use today, the typical CASE architecture is built around the concept of a

repository used for storing the various types of models which are created during software development, which are accessed by a number of assorted tools such as editors, diagrammers etc. The same section therefore specifies the requirements for repository functionality as part of CASE for Requirements Engineering. Issues to consider when selecting and integrating CASE tool for requirements are discussed in section 6.4. Finally, section 6.5 is concerned with properties and futures of research-oriented CASE tools for Requirements Engineering. Many of such tools are based on the principle that the utilisation of problem domain and methodical knowledge stored in the tool can automate (at least to an extent) many of the human labour intensive tasks of Requirements Engineering.

In summary, this Chapter presents an overview of the role of CASE technology within Requirements Engineering, keeping the discussion as much as possible free from references to specific tools and technologies. CASE is an indispensable feature of any modern software development approach and will be even more so in the future as its potential applicability within the Requirements Engineering process increases.

6.1The N e e d f o r Co mpute r-A i de d So f tw ar e

D e v e l o pme nt

Requirements Engineering is one of the software development phases for which CASE is particularly suitable. This fact was realised in the early days of CASE and it was soon put into practice in the form of research prototypes first and commercial tools soon after. There are of course good reasons why CASE is particularly applicable to Requirements Engineering: Requirements Engineering produces vast amounts of information (in both textual and graphical forms). Obviously this information must be managed, captured, stored, retrieved, disseminated and changed. However the manual capture, storage, manipulation etc. of requirements increases the risk of errors creeping into the process and into the final outcome. Such errors cam manifest themselves in various forms i.e. as out-dated, inconsistent or incomplete or erroneous requirements models.

Another serious problem of manual practice of Requirements Engineering lies with the difficulty to enforce certain software standards. As it happens, users and software engineers have their individual ways of communication in textual or pictorial form. This however can cause serious communications problems in the context of software development. User reports written in a variety of formats and styles can be a nightmare for those responsible for their editing and translation into technical descriptions.

CASE tackles the problems related to software requirements in the following ways:

?First, by providing automated management of all the requirements related information.

?Second by enforcing standards. CASE tools provide standard formats for inputting, retrieving or changing information. Such standards can be for example

document formats for textual requirements, diagrammatic notations etc. The use of

a uniform set of standards across the software development team ensures that

problems such inconsistency and misinterpretation are eliminated or greatly

reduced.

CASE also affects the speed with which a requirements model is produced and updated. This is important, as Requirements Engineering has to deal with two contradicting demands, namely to involve the user as little as possible in the process (since users are probably too busy doing other things to participate in software development) and at the same time obtain all the information required from the user including feedback on the specified requirements. In resolving this conflict, CASE is invaluable since it offers two primary facilities, namely easy communication with the user through graphical models and prototyping. CASE allows the quick construction of quality graphical models which are easily understood by the user as well as their equally quick modification. Prototyping is also valuable in putting the user through life-like interaction with the software system in order to understand the user’s true requirements (see also Chapter 5).

Most of the arguments in favour of using CASE in Requirements Engineering apply equally to the use of systematic methods for Requirements Engineering. As a matter of fact, CASE started as nothing more than an attempt to automate paper-and-pen software methods which in turn provided the much needed standardisation of documents and models, procedures for requirements change etc. to software development. It is a truism therefore that CASE and software methodologies have been dependent on its other for their success. Methods require automation in order to be practical; CASE on the other hand is of little help unless used in a systematic way within the development process, i.e. within a method. In a 'chicken and egg' fashion therefore the structured methodologies and CASE are responsible for each other's fast spreading of popularity in the 80's and 90's.

However, as the state-of-the-art moves beyond the structured approaches and into object-oriented and knowledge-based paradigms, the importance of CASE as the enabling technology for Requirements Engineering is moving into new areas. Sections 6.3 and 6.5 discuss the new

role of CASE as a component of a Requirements Engineering approach, in both commercial and research-oriented settings.

6.2Cl assi f i c ati o n o f CA SE Te c hno l o g y

There exist several classifications of CASE in the literature. One of the first and most important ones classified CASE as language-centred, built around a programming language, structure-centred that were based on the idea of environment generation, toolkit environments that were primarily consisting of tools that supported the programming phase of the development and method-based which were centred around a specific methodology for developing software systems.

Another classification [Fuggetta 1993] is based on a framework consisting of three parts: tools that support only specific tasks in systems development, workbenches that support one or more activities and environments that support a large part of the software process. According to this classification, tools can be further classified into editing, programming, verification and validation, configuration management, metrics and measurement, and project management tools. Workbenches are classified depending on the activities that they support as: business planning and modelling, user interface development, programming, verification and validation, maintenance and reverse engineering, configuration management and project management workbenches. Finally, environments are classified as either toolkits which are integrated collections of products, language-centred, integrated, fourth generation environments or process-centred environments.

6.2.1Upper and Lower-CASE

The most popular classification of CASE technology and tools is based on the distinction made between the early and late stages of systems development. Many of the current CASE tools deal with the management of the system specification only by supporting strategy, planning and the construction of the conceptual level of the enterprise model. These tools are often termed upperCASE tools because they assist the designer only at the early stages of system development and ignore the actual implementation of the system. The emphasis in upperCASE is to describe the mission, objectives, strategies, operational plans, resources, component parts etc. of the enterprise and provide automated support for defining the logical level of the business, its information needs and designing information systems to meet these needs.

UpperCASE tools support traditional diagrammatic languages like Entity Relationship Diagrams, Data Flow Diagrams, Structure Charts etc. providing mainly draw, store as well as documentation facilities. They support a limited degree of verification, validation and integration of the system specifications due to the inherent lack of formal foundations for the requirements modelling formalisms.

Other CASE tools deal with the application development itself with regard to the efficient generation of code. These are termed lowerCASE tools because they assist the developer at the stage of system generation and ignore the early stages of system requirements specification. The starting point of the system development with lowerCASE tools is the conceptual model of the information system. The conceptual modelling formalism is usually, based on formal foundations in order to allow for automatic mapping to executable specifications and efficient validation and verification of the system specification itself.

LowerCASE tools employ mapping algorithms to automatically transform formal specifications into an executable form. This includes, among others, transformation of specifications to relational database schemas, normalisation of database relations and SQL code generation. The majority of these tools facilitate rapid prototyping of specifications in terms of the functionality of the system. They do not support the development process itself but rather, they offer a powerful tool for making system design more effective and efficient.

The state of the art products of the CASE market nowadays claim that provide support for both the early stages as well as the implementation stages of information systems development. Clearly, from a users' perspective, this move towards integrated CASE (ICASE) is far more important [Gibson et al, 1989]. In this architecture, the repository plays a more active role in that all tools can interface and exchange data with it. A repository, holds data fields and definitions and ensures that data integrity is maintained throughout the development lifecycle. As a consequence, ICASE allow tools to work together relatively seamlessly and alleviates much of the stop-start nature of non-ICASE environments.

All the CASE environments mentioned above are often rigid and do not support the users' native methodology nor different methodologies. To avoid this, more flexible and customisable tools, called CASE shells, are emerging. They allow customisation of the CASE shell to a given methodology. Users are able to describe their methodology either through a set of meta-modelling editors or through a set of formal languages and tailor it to their specific requirements in order to create dedicated CASE tools. Many of the products and research prototypes of CASE shells move towards the support of different methodologies during the development of a single information system.

6.2.2Integrated Software Development Environments

Central to the issue of CASE integration, is the concept of an Integrated Software Development Environment (ISDE). ISDE as the term implies, provides support for the coordination of all the different activities that take place during a software project. There are different types of support that an ISDE can provide. Typical examples of ISDE support include:

?automated coordination of development activities. For example, mechanisms may be provided which trigger the design activity at the end of the specification activity

?mechanisms for inter-activity communication. This means that data produced, for example by a specification tool can be filtered and subsequently transmitted to the

design tool, to the project planning tool etc.

A major approach towards ISDEs is the European project PCTE (Portable Common Tool environment [Boudier et al, 1988]). The PCTE approach is similar to the idea of a modern operating system such as UNIX which offers a set of standard facilities such as text formatters, filters, process communications etc. which can provide the building blocks for creating sophisticated applications. In analogy, PCTE provides common building blocks to the developers of CASE tools which will run under PCTE. In turn, this can facilitate compatibility between the tools since they all use common facilities for storing and communicating their data.

6.3A Ge ne r i c CA SE A r c hi te c tur e

6.3.1Overview

Central to any CASE architecture is the concept of data dictionary or repository [Bruce et al, 1989; Burkhard, 1989; Martin, 1989b]. The role of the repository is to store all the logical and physical objects whose task is to provide control and integration in the development and maintenance of information systems. Essentially, the repository is the single point of definition in the software life cycle. In this role, the repository holds the metadata (data about data) which not only defines what and where the data is, but how it relates to other data and how the logical manipulation of data is mapped across physical structures like databases, file systems and, ultimately, physical objects such as networks and CPUs [McClure, 1988; Martin, 1989a]. In terms of the development life cycle, this means that any program or flow chart which is used in

the building of an application and any tools which are employed in its construction, must receive and enter data to and from the repository.

The repository provides true integration of specifications from the different tools because it permits sharing specifications rather than converting and passing them between tools. CASE tools connect directly with the repository for specification storage and retrieval. The repository uses these specifications to drive an application generator and to generate operating systems commands, database calls, communication commands and user documentation.

A generic architecture for CASE tools is shown in Figure 6.1

Database Level

Repository Level

Interfaces Level

Tools Level

Figure 6.1: Architecture of a CASE tool

According to the architecture of Figure 6.1, a CASE tool consists of the following major components:

?The repository. This is usually a database or file system in which all the information about the current status of the development process is held. Depending

on the particular phase of software development (i.e. analysis, design, testing etc.)

different types of data are recorded (e.g. diagrams, text, test data etc.) in a CASE repository. Note that a repository is frequently shared amongst different CASE tools. When all the tools are used within the same development phase (e.g.

analysis) the repository must be capable of maintaining data about the individual projects that go on concurrently as well as about their inter-communication requirements. A repository that holds data from different development phases (e.g.

analysis, design, etc.) must make them accessible from all tools which require them (i.e. analysis data must be accessible by the design tools, design data by the program generation tool etc.).

?The assistant modules.These can be considered as tools in their own right, responsible for performing some task within the particular development phase either in an entirely automatic fashion, or by assisting the user of the tool. In the requirements phase, assistant tools can, for example, automatically produce drawings (graphical models) from textual descriptions, check for consistency and completeness of the requirements models, propagate the changes in some of the models to the rest of the models (e.g. redrawing the corresponding graphical models when the user changes some textual descriptions etc.). In the following sections we will distinguish between assistant modules which are responsible for the most mundane/clerical tasks (such as screen drawing) and the ones which are capable of completely or in part undertaking intelligent tasks such as model validation, consistency maintenance etc.

?The human-computer interface (HCI) component. This component is responsible for handling the tool's communication with the user. The HCIs for CASE tools folow the general trends in user interface technology. There has been therefore a continuous evolution in the HCI technology employed by CASE tools from the early teletype style of interaction to the latest types of interaction using graphical user interfaces (GUIs) in multitasking environments.

?The communications component. The communications component is responsible for exchanging data with other CASE tools. This usually implies that the communications component receives data about the software project which was created in a previous development phase and transmits data for use by tools in subsequent development phases. Effective communication between CASE tools is

a problem still to be solved in a satisfactory manner for a variety of reasons. The

lack of widely acceptable standards between the CASE tool developers has

resulted in a plethora of proprietary and often mutually incompatible formats used

by the tools for the internal storage of development information.

6.3.2Architecture and Functionality of a Repository for Requirements

Engineering

The task of a repository is to help manage Requirements Engineering data by offering a variety of services that promote data sharing, data integrity and convenient access. The repository can:

? help users logically associate the various products of the process (documentation, formal specifications etc.)

? keep track of users' annotations which contain explanations and assumptions

? manage different versions of requirements, and the associated documentation

? control different views of the system under development

? help the managerial side of a team development (e.g. estimate required development effort)

? maintain historical data about the decisions taken through the process of eliciting, specifying requirements.

A CASE environment places specific demands on the repository technology used, especially in the case of large-scale team projects. It must support simultaneous access by team members, editing, and authorship in a computer network. Different versions of requirements must coexist, where team members work independently and then merge their specifications back into the main project. Analysts must be allowed to build specific configurations and version trees, and subsequently merge versions together. In summary, a CASE repository supporting Requirements Engineering must exhibit functionality in terms of:

Complex Information Modelling.A repository for Requirements Engineering must be able to store large variable-length objects, such as documents and graphical specification models.

Integrity Constraints and Triggers. Due to the size and complexity of the requirements models, the maintenance of data consistency should be performed by enforcing constraints as the data evolves over time.

Transaction Management.Advanced transaction management features for collaborative Requirements Engineering must be provided. The classical notion of serializability of a transaction is no more adequate, as it significantly reduces concurrency and is largely unsuitable for Requirements Engineering environments at large.

Specification Updates.The process of Requirements Engineering is incremental by nature. It is therefore compulsory to provide the means for changing and updating freely the structure of a preliminary requirements model as modelled by the schema of the repository.

Data Sharing.One of the key issues in collaborative Requirements Engineering is the sharing of data between various analysts. As in client-server architectures, requirements data may be partitioned based on various criteria. However, data must be accessible by all.

Distribution and Cooperative Work.Effective communication protocols between analysts is essential, since they are often unaware of each others developments. This sometimes results in lack of coordination, reduced parallelism, a considerable waste of time and resources, and faulty specifications due to misinterpretations of data. Mechanisms to support the distribution of tools such as distribution of the repository itself or at least distributed access to a repository residing on a database server are needed. In the same spirit, tools for handling and controlling the distribution must also be provided.

Concurrency.The repository should offer the same services as current database systems with respect to the handling of multiple users.

Recovery.In case of hardware or software failures, the system should recover, i.e., bring itself back to some coherent state of the data.

6.3.3Features of CASE Technology

This section discusses the properties of contemporary CASE tools used in the Requirements Engineering phase. The common characteristic of all such tools is that they are built in order to automate aspects of software methodologies. Most of these methodologies existed before the

introduction of CASE, albeit in a manual form. The origin of such methodologies is the paradigm of structured development which was initially applied to programming and subsequently to the design and analysis phases [Jackson, 1983] [Yourdon, 1989]. Structured methodologies are based on the principle of 'divide and conquer' i.e. on the stepwise decomposition of data and functional elements of a system to their parts. This approach ensures the efficient dealing of tasks of arbitrary size since the original task is progressively decomposed into smaller and easier to be dealt with sub-tasks. One serious drawbacks of the structured methodologies (especially when practised without tool support) is that they are usually cumbersome to apply, mainly because of the large amounts of information (documents, drawing etc.) they generate. The most important task of a CASE tool which supports a structured methodology therefore is to provide automated functions for the storage and manipulation of the information generated during software development.

The major application of CASE tools developed in the Seventies and early Eighties therefore, was to assist in the collection and manipulation of the voluminous information generated by the structured methodologies. The progress in the ability of CASE tools to store and manipulate project information, closely followed the progress in areas such as hardware (processor and graphics technologies), databases and computer communications.

Early CASE tools for Requirements Engineering support were handling requirements specifications, either as free text (in which case they were little more than word processors) or in a stylised form which allowed for some limited automatic processing of the requirements. Such automatic processing of requirements specifications usually included checking for inconsistencies (e.g. terms with multiple definitions) and incompleteness (i.e. terms which are used but not defined).

Advances in hardware technology such as high resolution graphics screens made possible the development of tools capable of manipulating graphical requirements models. The ability to manipulate graphical definitions has given an important boost to the acceptability of the CASE technology since the structured methodologies which the early CASE tools support, rely heavily on the use of graphical requirements models. Even in today's CASE the ability to draw and manipulate graphical specifications models on the screen remains the most heavily used and essential feature.

Technological progress, together with a more mature understanding of the Requirements Engineering (and more general of the software development) process, guided the incorporation of additional functionality in the CASE technology. Today's Requirements Engineering tools utilise the latest advances in processing, graphical user interfaces, database and communications

facilities in order to provide effective support to the most fundamental activities of Requirements Engineering. Whilst proprietary tools differ on a number of issues such as the methodology they support, whether they are standalone or parts of an integrated environment etc., they nevertheless share a number of features such as:

?Facilities for prototyping. The importance of prototyping in activities such as requirements acquisition and validation is now generally accepted. The increased

use of prototyping as an important technique within Requirements Engineering

influenced the CASE developers into incorporating facilities for prototyping in

their tools. Basic prototyping facilities usually encountered in CASE tools include

report generation and screen painting. More advanced prototyping facilities include

animation and symbolic execution of the requirements models. Also limited code

generation (which allows for a crude program to be quickly generated from the

specifications) is a facility offered by the more sophisticated tools.

?Facilities for data management. Whilst, the early CASE tools used simple file structures for storing the requirements models, contemporary ones utilise database

technology in order to offer facilities such as concurrent access to the data by many

developers, version control etc.

?Inter-tool Communications facilities. As the relationship between Requirements Engineering and other development phases becomes better understood, so does the

ability of requirements CASE tool to communicate with other CASE responsible

for tasks such as project planning, configuration control, design etc.

?Graphical user interface. It allows the representation of requirements models using the graphical notations used by the methodology which the tool supports . Usually

the tool proves facility for dynamic redrawing of the model on the screen, each

time the user changes some part of it. This facility significantly reduces the time it

would take to manually redraw the model from scratch.

?Data administration. Managing the data generated during Requirements Engineering entails tasks such as keeping lists of the various types of data,

enforcing standards (e.g. that the names of the various concepts follow certain

naming conventions), checking for inconsistencies and omissions (e.g. duplicate

names).

?Utilities for requirements animation and prototyping. Such utilities may include screen painters, program generators etc. which support the requirements validation

process (Chapter 5)

?Data communication facilities. This includes facilities for importing and exporting data to and from other tools. A Requirements Engineering tool usually exports data

to design tools and to project planning tools which use such data to inform about

the current progress with the project and to plan ahead).

6.4Se l e c ti ng,Inte g r ati ng and U si ng CA SE to o l s f o r

Re qui r e me nts Eng i ne e r i ng

6.4.1Desired features of Requirements Engineering CASE

Modern CASE technology integrates the different categories of CASE that were mentioned before into the concept of an Integrated Software Development environment (ISDE for short). Very often therefore, these days, the prospective buyer/user of CASE has to choose between different ISDE options rather than the stand-alone CASE which is gradually becoming a rarity. Assuming that the dilemma of choosing between the ISDE and standalone one is circumvented, a number of technical and organisational issues that must be considered in the CASE selection process arises, i.e.:

?Support for specific formalisms and methodologies. The vast majority of commercial CASE support only one or two of the mainstream software

methodologies, e.g. Structure Analysis [Yourdon, 1989] Jackson System

Development [Jackson, 1983] Structured Systems Analysis and Design Method

(SSADM) [NCC, 1990], Information Engineering [Macdonald, 1986] etc.

Usually, there is little flexibility for customisation of the models used by the tool to

suit the individual users' need. One exception, to this is the class of Generic or

Meta-CASE [Alderson, 1993] tools which allow the customisation of existing

models or even the creation of entirely new ones to support in-house developed

methods.

?Support for specific types of applications. Although, most CASE tools can be used with varying degree of success for any type of application (e.g. data

intensive, real time, process control, expert system etc.), some formalisms and

methods better accommodate the needs of specific application types. It is essential

therefore that, for example, CASE used for real time applications should provide

support for formalisms such as StateCharts, Petri Nets etc., whilst data intensive

CASE should be able to handle the entity-Relationship model or some of its

variants.

?Repository capabilities. The majority of the modern CASE tools provide repository facilities similar to those discussed in Section 3. It is important however

that a checklist is drawn by the prospective user which includes the following

capabilities: Fully integration of data in the repository, database facilities, project

management information, shareability of data amongst developers, automatic

report generation and support for ad-hoc querying, import/export capabilities to

other repositories, automatic analysis and control of changes in the data.

In the majority of real life software projects, even the most sophisticated CASE or ISDE tool on its own will fail to meet one hundred percent the demands of the requirements phase. One possible way to overcome this is by acquiring and using a set of different CASE with complimentary abilities, e.g. a diagramming tool combined with a prototyping tool and an executable formal specification language. An obvious problem in this approach is cost, since three times as many tools (compared with the one-tool option) will have to be purchased. Even if cost is not an obstacle, communication between the tools is also a potential source of difficulty. In many cases, special software (called bridges) will have to be written to allow the transferring of data between tools. Hopefully, this situation will gradually become a rarity as we move towards standard environments and repositories for CASE.

6.4.2Integrating CASE tools

Integration and communication can be aimed at three levels.

The first level is that of tools integration. An example approach for tool integration is presented in Figure 6.2. The tools themselves are responsible for data structuring and control activities; in this way co-operation between tools is achieved through passing of streams of bytes. The advantage of this approach is that tools can be developed almost independently and generic file transfer utilities can be used for the communication between tools. There are however, many disadvantages with this approach such as difficulty in expansion, duplication of role and effort in tools, manual co-operation between tools rather than assistance in a team effort and loss of relationships between design data.

The second level is that of data integration. A set of data structures is agreed by all tools within an environment. A meta-schema is agreed upon by all tools before any development of these tolls commences. Any future expansion will need to conform to this meta-schema. The advantage of this approach is that most of the actions necessary for analysing, validating and converting data structures are no longer required within each tool. The disadvantage is that the way that the tools are used is not constrained or guided in any way. This can only be achieved by agreeing not only on the data structures but also on the process within which the tools will be used. The interest lies only in the management of information as a consistent whole and not how parts of the information are transformed or operated upon.

The third level is that of method integration. A set of data structures and the process model are agreed by all tools which then interact effectively in support of a defined process.

Data integration and method integration imply that the tools communicate by interacting at a level of abstraction higher than the operating system i.e. there is a project level interface which provides facilities and services for controlling the requirements specification process.

Project Level Interface

Operating System Interface

Hardware Interface

Figure 6.2: Tool Integration

6.5Re se ar c h CA SE f o r Re qui r e me nts Eng i ne e r i ng

6.5.1 Introduction

In contrast to commercial CASE, research tools for Requirements Engineering do not fall easily into predefined categories. Generally, CASE research prototypes do not attempt to provide complete or integrated support to the tasks of Requirements Engineering, focusing instead on specific problems such as acquisition, specification, validation etc. Such tools have already been discussed in Chapters 3 and 6.

Research prototypes are usually concerned with proving the validity, feasibility or applicability of a certain paradigm for practising Requirements Engineering. A paradigm, in general, is a specific way of doing things (solving problems) and as such it cannot easily be proved true or false. Research paradigms for Requirements Engineering often materialise as 'tools' or 'environments' which are exclusively used in controlled experiments rather than real-life applications. Eventually, some of the research ideas find their way to real life practice by being incorporated in commercial tools and methodologies.

In recent years, the paradigm that has received the most attention in Requirements Engineering research has been Knowledge-based Requirements Engineering. The rationale behind viewing Requirements Engineering as a knowledge-based process has been discussed in many different occasions in previous chapters of this book. Viewing Requirements Engineering as a process which relies to a large extent to the availability of knowledge of various sorts, invokes a number of research issues:

?what types of knowledge is used in Requirements Engineering?

?how can such knowledge be formalised and represented within computers?

?how can the availability of this knowledge improve and sometimes automate the practising of Requirements Engineering?

Research addressing the above questions, has produced tools which can represent and store knowledge about the domain the software application belongs to (Domain Knowledge). This knowledge is used for purposes such as completing and validating the requirements model. Reusable requirements knowledge speeds up the overall process (since less interaction with the users is required) as well as improves the quality of the requirements model. Problems that are still to overcome in this approach are related with the difficulty of identifying suitable sources of reusable requirements knowledge and the cost of eliciting and formalising reusable requirements models.

Another source of knowledge which some research tools are based upon is method knowledge. It is fairly easy to automate the steps of a requirements method defined in an algorithmic way which has well defined inputs ad outputs. Structured methodologies fall into this category, i.e. some of their steps and deliverables can be applied mechanistically and are therefore suitable candidates for automation. Unfortunately, this cannot be said for the more unstructured processes such as elicitation and validation. Tools which attempt to (even partially) automate

such processes therefore, are equipped with knowledge and methods of reasoning which mimics human knowledge and reasoning. Such tools are frequently called intelligent requirements assistants [Anderson and Fickas, 1989] [Reubenstein and Waters 1991]. Again, before such tools acquire commercially applicable a number of important issues related to their ability to stand up to real life software systems requirements must be resolved. Figure 6.3 shows a generic architecture for an 'intelligent' Requirements Engineering CASE tool.

Requirements Engineer

Figure 6.3: Architecture of an 'Intelligent' Requirements Engineering Tool

6.5.2Intelligent CASE in Requirements Analysis and Specification

In general, these tools can be distinguished along two dimensions. The first dimension is concerned with tools supporting building of the specification whereas the second dimension is concerned with those supporting the management of the specification and the building of the application out of a given system specification.

The requirements for the next generation methods and CASE environments that are discussed in this section revolve around the activities of requirements capture and analysis, validation and management of the captured knowledge. These issues give rise to two lines of investigation regarding the requirements for the next generation development methods and CASE environments:

?Improved tools and techniques for assisting the process of deriving a conceptual specification of an enterprise.

?Improved tools and techniques for managing a conceptual specification and the building of the application out of a given system specification once such a

specification has been developed.

These requirements give rise to a number of research issues discussed in the following sections that aim at providing intelligent support facilities during the process of conceptual specification design, conceptual specification management and the generation of the application itself.

6.5.3CASE for Conceptual Specification Design

During the last decade, an intensive effort has been made by the industrial community as well as the research community to develop conceptual modelling formalisms that allow to describe Information System (IS) in high level terms, the so-called conceptual schema, and to reason upon this description. However, little effort has been paid to model the process by which one can reach the conceptual schema of an IS to be built. In other words, there exists a plethora of formalisms for the representation of the Requirements Engineering (RE) product whereas the number of techniques which deal with the RE process is very small (see also Chapter 2). As a consequence, CASE tools only concentrate on supporting the population of the repository in that they assist the requirements engineer to (1) enter the RE product in a diagrammatic form (2) store its contents in a repository and (3) document it. They do not help the requirements engineer in constructing the requirements product itself by supporting the transition process from an informal requirements description to a formal IS specification.

The upperCASE strand of research is strongly influenced by the application of Artificial Intelligence (AI) techniques. The purpose of applying AI techniques is to better understand and consequently, formalise the conceptualisation process. In contrast with the lowerCASE approach, emphasis is placed on the way that requirements are acquired and the way that these are transformed to populate the conceptual schema of the business and the information system.

The system development process is characterised as non-deterministic because of the difficulties in identifying the limits of the problem area, the scope and goals of the information system and the approach to conceptual schema definition. However, from a management point of view, developers wish to control the development process through the use of formal techniques and experimental knowledge.

Taking these two dimensions of the information system development process into account, it is clear that its automation cannot be based solely, on a pure algorithmic solution. This has been recognised by some researchers who developed CASE prototype toolsets based on an expert system approach (SECSI [Bouzeghoub, 1985], OICSI [Rolland, 1986; Cauvet, 1988]). In such an approach, both experimental and formal knowledge are represented in the knowledge base whereas the application domain knowledge is stored within the fact base. The development process is viewed as a knowledge based process which, progressively, through the application of the knowledge base rules on elements of the fact base, transforms the initial requirements into the final information system conceptual schema.

Some approaches to process modelling attempt to employ metamodelling formalisms and toolsets to explicitly represent the knowledge about the development method as well as the development product. The SOCRATES project [Wijers, 1991] follows this approach in that it aims at offering automated support of the information modelling processes by representing and manipulating the experienced practitioners' information modelling knowledge. This approach advocates a model independent architecture where the designer will be able to describe his method and the underlying modelling process using a number of formal languages.

Other approaches, attempt to automatically acquire the knowledge used in the analysis process. Whereas in most of the approaches the development process knowledge is provided by human experts, here it is deduced using automatic learning techniques. For instance, the INTRES tool [Pernici,1989] uses explanation based generalisation for specifying static properties of elements of well understood applications, based on examples of documents. In [Mannino, 1988], the ap-proach is based on the strategy of learning from examples employed in a form definition system, they develop specific learning algorithms. The tool automatically induces the form properties and some functional dependencies. This work has been extended further in [Talldal, 1990] where the learning algorithms are optimised and the induced conceptual schema is expressed in an extended ER formalism.

Summar y

This Chapter has been concerned with Computer Aided Software Engineering technology as applied to the Requirements Engineering phase. In the last two decades we witnessed a changing role of CASE in Requirements Engineering from simple clerical task handling to automating essential activities such as formal specification and validation.

Today's State-of-the-Art CASE tool acts as an editor and repository for the various models created during Requirements Engineering (discussed in Chapter 4) as well as an interface between Requirements Engineering and other software development phases. CASE technology particularly suits those Requirements Engineering methodologies which rely on graphical models, mainly because such models can be quickly drawn, manipulated and communicated (i.e. by using techniques such as prototyping, animation etc.) to the users.

The application of CASE technology to Requirements Engineering has been less effective when dealing with more 'hard' problems such as requirements elicitation and formal validation. Research however into intelligent CASE attempts to overcome the limitations of today's tools by utilising expert system technology as well as our improved understanding of the processes involved in Requirements Engineering.

An architecture for a Requirements Engineering CASE tool of the future is presented in Figure 6.4. Such a tool will be capable of performing tasks which are currently the responsibility of the human engineer. These will include:

?automatically completing the requirements model by utilising preexisting reusable requirements knowledge

?advising and supporting the human requirements engineer using domain and method-dependent knowledge and rules

?validating the requirements model using techniques such as natural language paraphrasing, symbolic execution etc.

?generating test cases directly from the requirements.

2014-需求工程复习

需求工程复习一、简述 1、业务需求、用户需求、系统需求。要求掌握其概念，并且能根据实际案例进行描述。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，描述了组织为什么要开发一个系统。用户需求是描述用户使用产品能完成什么任务，怎么完成任务的需求，描述了用户能使用系统来做些什么。功能需求是对用户需求的分析、提炼、整理，是需求分析与建模的产物，能生成指导开发的、更精确的软件需求。 2、简述系统需求的三种类型并举例说明。 1．功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 2．非功能需求描述了系统展现给用户的行为和执行的操作等。 3．设计约束是对开发人员在软件产品设计和构造上的限制，是产品必须遵守的标准、规范和合约。 3、软件开发的各阶段，为什么只有需求阶段称为需求工程？随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。 4、简述需求的开发过程 1.需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求； 2.需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义； 3.形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约； 4.需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性； 5.需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。 5、需求分析主要用来做什么？需求分析的任务是通过详细调查现实世界要处理的对象，充分了解原系统工作概况，明确用

需求工程期末复习总结

填空： 1.在导致需求问题的原因中，一个最为重要的原因是：未能很好的掌握应用型软件的模拟特性以及由此产生的一系列的影响和要求。 2.面向专业用户的纯工具型软件的首要成功标准是：要具有功能的复杂性和使用的高效性。 3.需求开发过程中产生的主要文档有三种：项目前景和范围文档，用户需求文档，需求规格说明文档。 4.系统用例图和上下文图通常被用来定义系统的边界。 5.在需求建模时，常用的技术包括：数据流图，实体联系图，状态转换图，类图等半形式化建模技术。 6.业务需求，高层解决方案及系统特性都应该被记录下来，定义为项目前景与范围文档。 7.每一个明确，一致的问题都意味着涉众存在一些相应的期望目标，即业务需求。 8.业务需求中需要特别注意的特征是可行性和可验证性。 9.在会谈中使用的问题基本上可以分为两种：开放式和封闭式问题 10.面谈的类别：结构化，半结构化和非结构化面谈 11.原型的需求内容可以从三个纬度上分析：外观，角色，实现 12.民族志一个主要的应用目的就是研究和解决复杂的协同问题 13.分类框架将场景方法从场景的形式（又分为描述和外观两个方面），目的，内容和生命周期四个方面进行了分类和描述 14.工程利用场景的目的有三种：描述，探索，解释 15.抽象和分解是建模最为常用的两种手段 16.抽象通过强调本质的特征，减少了问题的复杂性；分解的手段体现了分而治之的思想 17.分析模型是半形式化的 18.建模语言有三个要素：语法，语义，语用 19.按照Zachman的矩阵框架，分析技术就是用来对第二行（企业模型）的各列进行建模和描述的技术 20.面向对象分析方法以对象为基础，结构化分析方法以功能和数据为基础 21.结构化，信息工程和面向对象三中方法学下的需求分析技术都是面向解系统的 22.使用面向问题的技术称为前期需求阶段的分析，使用面向解系统的技术称为后期需求阶段的分析 23.数据流图建模时使用的基本模型元素有四种：外部实体，过程，数据流和数据存储 24.DFD定义了三个层次的DFD图：上下文图，0层图和N层图 25.实体联系图用实体，属性和关系三个基本构建单位来描述数据模型 26.除了静态的事物和抽象的概念之外，行为和事件也是常见的实体类型 27.在关系的命名上通常使用动词 28.用例模型的基本元素：用例，参与者，关系，系统边界 29.UML的行为模型有三种：交互图，状态图，活动图 30.在目标模型中使用的其他模型元素有行为者，场景，操作，任务，资源，UML元素等// 31.需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力

软件的需求的工程期末复习资料

☆什么是软件需求工程？请说明软件需求工程中各阶段的主要任务。p5 1 定义一般定义：指应用工程化的方法、技术和规格来开发和管理软件的需求。需求工程的目标：获取高质量的软件需求。与软件工程中传统的需求分析概念相比，需求工程突出了工程化的原则，强调以系统化、条理化、可重复化的方法和技术进行与软件需求相关的活动，从而有利于提高所有与软件需求相关的活动及其过程的可管理性，降低需求开发和管理的难度和成本。其它定义： Alan.Davis：直到（但不包括）把软件分解为实际架构组建之前的所有活动，即软件设计之前的一切活动。该定义虽然没有详细说明需求工程是什么，但其给出了需求工程的范围。Lan K. Bray：对问题域及需求做调查研究和描述，设计满足那些需求的解系统的特性，并用文档给予说明。这个定义明确指出了需求工程的任务就是获取、分析和表达软件的需求。需求工程= 需求的开发活动+ 需求的管理活动 2 各阶段主要任务需求获取阶段：获取用户的需求信息。需求分析阶段：分析和综合已经收集到的需求信息。需求建模阶段：根据待开发软件系统的需求利用某种建模方法建立该系统的逻辑模型。需求定义阶段：根据用户需求编写出需求规格说明。需求的形式化描述阶段：用严格的数学知识和符号来构造系统的需求模型。需求验证阶段：检验软件需求规格说明。需求管理阶段：开发人员在与提出更改的请求者协商的基础上，评估需求变更带来的潜在影响及可能的成本及费用，然后实施更改，一级有效的管理需求规格说明文档和跟踪更改需求

的状态。 ☆什么是软件需求？软件需求有哪些类型，并分别给出它们的定义。p2 软件需求的定义: A. Davis：软件需求是从软件外部能发现的，软件所具有的，满足于用户的特点、功能及属性等的集合。 I. Sommerville：需求是问题信息和系统行为、特性、设计和实现约束的描述的集合。M. Jackson等：需求是客户希望在问题域内产生的效果。 IEEE软件工程标准：（1）用户解决问题或达到目标所需的条件或能力；（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。通俗定义：软件需求是指软件系统必须满足的所有功能、性质和限制。软件需求的类型: 目标需求：反映组织机构或客户对系统和产品提出的高层次的目标要求，其限定了项目的范围和项目应达到的目标。业务需求：主要描述软件系统必须完成的任务、实际业务或工作流程等。软件开发人员通常可从业务需求进一步细化出具体的功能需求和非功能需求。功能需求：指开发人员必须实现的软件功能或软件系统应具有的外部行为。性能需求：指实现的软件系统功能应达到的技术指标，如：计算效率和精度，可靠性，可维护性和可扩展性等。约束与限制：指软件开发人员在设计和实现软件系统时的限制，如：开发语言，使用的数据库等。

需求工程作业

第2章需求基础案例分析：分析下列实际项目的需求书写片段，说出需求的类型，是否存在问题？ 1.系统A—招标书系统目标 1、实现各部门的公文流转无纸化、文档一体化、业务管理的规范化、自动化和网络化； 2、实现工作流程合理化、高效化，决策支持科学化、准确化； 3、统一办公流程、规范公文格式，加强信息交流和共享，提高工作效率。系统质量要求 1、先进性：软件系统采用三层B / S 系统结构，以“界面表示层－逻辑处理层－数据访问层”分层设计实现。采用国际上先进成熟的、厂商广泛支持的计算机技术、网络技术与软件技术对系统进行规划，保证系统整体架构在未来几年内都处于国际领先的地位。 2、安全性：软件系统具有较高的安全要求，系统必须具备充分的安全措施，包括具备严格的权限控制机制和完备的日志记录，以确保信息安全。 3、可靠性：保证系统核心功能可以7×24小时连续运行； 4、规范性：系统必须遵循国家有关法律法规要求，符合国家有关标准要求以及关于信息系统建设的各项标准和规范。系统功能收文管理应包括: ?来文登记、拟办、领导审批、办理、归档、查询统计等功能。附件支持WORD 、PDF 、EXCEL 、HTML 等文档类型格式；需提供方便、灵活、直观的文件批示处理；对收文的处理全过程进行自动化管理、跟踪和记录；在收文处理的过程中，支持电子印章、电子签名或手写批注等功能。 ?来文登记：完成来文登记功能。登记来文基本信息（来文编号、来文标题、主题词、来文单位、来文时间），还要对原文进行扫描处理，引入到公文库中。并可完成收文办文单打印功能。完成后启动收文流转流程。 ?拟办：查看公文的基本信息，原文内容。签录拟办意见，发送给领导审批。 ?领导审批：查看公文的基本信息，原文内容。签录批示意见，确定主办部门、协办部门。 ?办理：办理人根据领导批示办理，记录办理情况。 ?归档：对办理完结的来文归档，将来文信息、拟办意见、领导批示、办理情况等信

软件需求工程选择题

选择题 1.软件生命周期包括哪些阶段A A. 需求、设计、编码、单元测试、接收测试和维护阶段。 B. 设计、编码、单元测试、接收测试和维护阶段。 C. 需求、设计、编码、单元测试和接收测试阶段。 D. 需求、设计和编码阶段。 2. 好的软件需求具有哪些特性A A. 一致性和全面性。 B. 易读性和充分性。 C.充分性。 D.易读性。 3.RUP的十大要素是：开发一个前景、达成计划、标识和减小风险、分配和跟踪任务、检查商业理由、设计组件构架、对产品进行增量式的构建和测试、验证和评价结果、_________和_________。A A. 管理和控制变化及提供用户支持。 B. 迭代的开发和提供用户支持。 C. 迭代的开发和管理和控制变化。 D. 建立模版和迭代的开发。 4.下列哪个不是RUP的核心工作流C A. 业务建模 B. 分析和设计 C. 用户需求了解。 D. 需求 5.RAD的缺点不包括___D______。 A. 如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响。 B. 要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降。 C. 盲目应用时，会缺乏成本概念和项目完成的时间限制。项目有永远不能完结的风险。 D. 工作重点从文档转为构建，所见即所得。 6.螺旋模型的优点不包括____C______。 A. 能够及时找到项目存在的风险，避免因为克服不了的困难而造成大的损失。 B. 使用户能够尽早将信息经常反馈给开发人员，保证了产品的正确性和高质量。 C. 大量的中间阶段会产生额外的内外部文档。 D. 可以方便地评估和验证每次迭代的成果；实现从开发到维护的无缝连接。 7.迭代方法中的常见问题不包括___B________。 A. 过分详细的规划 B. 项目收敛 C. 回避棘手问题 D. 不同的小组按自己的进度进行工作 8.用户故事的书写遵循一定的原则，其中不包括___C_____。 A. 作为（系统的一个涉众） B. 我想要（做一件事） C. 是什么（用户的需求是什么） D. 从而（达到一个商业价值） 9.指出RUP的核心工作流不包括__D______。

需求工程考试答案

下面是邵坤老师给的一些复习资料，帮忙发给大家吧主要内容都在PPT上，好好复习PPT中的内容，重点在前面的三讲，最后一讲方法内容仅仅是一些概念！主要答题是如下五题中得三题。这些题目都没有标准的答案，请同学根据自己学习需求工程课程的理解答题！答案不可雷同，如果有雷同的答案，将以分值除以雷同数计算分数！请将上述内容转达到每位参加考试的同学！谢谢！ 1．“我知道你有很多材料。那些材料里到底有什么？”Betty Kant问道，她是MIS特别工作组的负责人。MIS特别工作组是你的系统团队联络Sawder家具公司的桥梁。你拖了一大堆材料，正准备离开这栋楼“哦，是过去6个月的一些财政决算、生产报表，还有Sharon给我的一些业绩报表，业绩报表涵盖了过去6个月的目标和工作业绩。”你在回答时，有些纸掉到了地上，“你为什么问这个问题呢？”。 Betty为你拾起纸并把它放到最近的桌子上，回答道：“因为你根本不需要这些垃圾。你来这里要做一件事情，就是和我们这些用户谈话。从这些材料中得不到任何有益的信息。” 问题 1.）只有告诉Betty你从每份文档中找到的东西才能使她相信每份文档都是重要的。用一段文字解释文档为需求工程师提供了什么帮助？ 2.）在你和Betty谈话的时候，意识到实际上也需要其他的定量文档。列出你缺少的东西。 1.阅读、研究得到的硬数据，从中发现需求信息问题域信息工作流程业务细节从这些报表中就可以看出报表数据要求的数据大小、精度与格式等其他业务细节。 2.员工的工作指南和公司规章手册：解释业务的详细执行过程，反映业务的具体细节公司的成员以及职位、职责组织管理结构表图。门户网站各种业务的统计报表，如财务报表业务备忘记录：反映业务的实际执行情况 2.请说出下列引号内的文字的需求的类型，是否存在问题？ “开发意图: 片面性

软件需求工程.doc

第1章软件需求工程概述 IEEE 关于软件需求的定义 1) 用户解决问题或达到目标所需的条件或能力；（用户的角度） 2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（软件系统的角度）软件需求的分类 1) 目标需求； 2) 业务需求； 3) 功能需求； 4) 性能需求； 5) 约束与限制。 6) 软件需求间的层次关系需求规格说明需求规格说明是软件所应满足的全部需求，并可以文档的方式完整和精确陈述这些需求。一个好的需求规格说明应该具有的特征 1) 完整性。 2) 正确性。 3) 可行性。 4) 必要性。 5) 划分优先级。 6) 无二义性。 7) 可验证性。第2章软件工程与需求工程软件开发过程模型 1) 瀑布式模型 2) 快速原型模型 3) 渐增式模型

4)螺旋式模型 5)面向对象的开发模型所谓面向对象就是应用对象、类、继承、封装、消息、对象或类之间的关系等面向对象的概念对问题进行分析和求解的软件开发技术，或者说，是以对象（类）为数据中心、对象之间的动态行为模式作为运行机制的一种问题求解方法。软件需求工程特点 1)有一部分分析工作必须在设计之前进行，而另外一些分析工作则需与其他部分的设计与实现工作并行地进行，因而呈现出非线性的工作方式。 2)软件系统的表达形式在整个开发模型中都是相同的，即面向对象方法中把类及其结构作为系统的表达单元，无论哪一个阶段都以渐增的方式不断地进化或细化这些表达单元。 3)开发模型支持软件的重用。需求工程对软件开发的影响如下： 1)需求是制定项目计划的基础。 2)需求工程所产生的最终产物——需求规格说明——是软件设计和软件实现的基础。 3)需求规格说明也是测试工作和用户验收软件系统的依据。 4)需求规格说明也是软件维护工作的依据。软件需求的开发和管理过程软件需求的开发和管理过程是由导出、确认和维护软件系统需求规格说明的一系列活动组成的。根据需求工程开发和管理过程可大致划分需求开发和需求管理两个阶段。其中需求开发主要产生正式的需求规格说明，需求管理主要是根据需求的变化对需求规格说明的内容及版本进行管理。

需求工程思考题

第三章 1. 除了需求开发的四个活动和需求管理活动之外，需求工程当中还有没有需要执行的活动？如果有的话，它们是哪些活动？给出你的理由。答：过程管理活动和项目管理活动。过程管理活动是跟踪项目开发过程，记录项目开发过程当中所遇到的问题或者教训项目管理活动是管理项目开发的一系列问题与进度，管理人员配置，以达到最该效益。 2. 需求开发过程具有迭代特性，但是不是所有项目的需求开发过程都必须是迭代完成的？如果不是，请给出举例和理由。答：不是，一般对于业务领域不熟悉的项目，需求是具有迭代性的，需要对业务领域的认知，有一个从认识到知识重构的过程。对于某些固定需求且熟悉的项目，就不需要迭代开发需求获取——>需求分析——>需求规格说明——>需求验证。当然并不是所有项目的需求开发过程是迭代完成的，当某一项目开发过程中，用户需求非常简单，开发人员已经相当明确用户需求，这时，就不需要返回到需求获取阶段以继续用户需求的获取，这样，也就不需要迭代完成。 3. 需求开发的迭代特性与软件开发过程的迭代式开发有什么关系？它们之间会互相影响吗？如果会，那么有哪些影响？答：需求开发的迭代特性只是软件开发过程的迭代式开发的一个子过程，软件开发过程是一个相当庞大的工程，需要在软件开发过程的各个阶段都需要进行开发工作的迭代，当然也包括需求开发中的迭代。它们之间互相影响。如果需求开发中的迭代不能很好地完成需求分析任务，就必将影响到软件开发过程的其他迭代阶段的进行。 4.需求工程细节知识的实践性对不同项目的需求开发过程的差异性有没有影响？如果有，请说明影响是什么。如果没有，请说明是哪些因素产生了不同项目的需求开发过程的差异性。答：没有影响。其实是需求开发过程的差异性一定程度上导致了细节知识的实践性。现实世界问题的复杂性和差异性主要导致了需求开发过程的差异性。第四章 3. 在各种关于软件的调研中，无一例外地发现“缺乏用户参与”是导致软件失败的最大原因，试说明有哪些原因会使得用户参与不足？应该怎样解决？答：（1）用户数量太多，选择困难；（2）用户认识不足，不愿参与；（3）用户情绪抵制，消极参与；（4）没有明确的用户；解决：要求开发者在进行需求获取时，能够对系统的用户以及用户的替代源等相关涉众进行分析，了解他们的特征、类别、任务、取向等，并在需求获取中采取对策避免用户参与不足现象的发生。第五章 3. 要完整地描述系统的高层解决方案，需要描述哪些方面？答：（1）方案描述：概要描述解决方案；（2）业务优势：该解决方案所能带来的业务优势；（3）代价：该解决方案将花费的代价；第六章 1. “以用户为中心”和“重视用户价值”是20世纪90年代之后的一种软件开发趋势，涉众分析可以从哪些方面实现“用户为中心”和“重视用户价值”？

需求工程复习资料

4个上下文刻面：主体、使用、IT系统、开发 3类需求制品：目标、场景、面向方案的需求 3个核心活动：获取、文档化、分析 2个横切活动：确认、管理软件工程（Software Engineering）：对于软件开发、操作以及维护的系统化、规范化和可量化的应用方法。需求工程（requirement engineering）：是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应，需求工程是软件工程关于现实世界的目标、功能和软件系统约束的一个分支，它也关注着上述因素之间的关系来精确软件行为的规格说明和它们随时间随产品族的演化。需求（Requirements）： ⑴用户解决某个问题或者达到某个目标所需要的条件或能力； ⑵一个系统或系统组件为了实现某个契约、标准、规格说明（规约）或其他需要遵循的文件而必须满足的条件或拥有的能力； ⑶对⑴或⑵中所描述的条件或能力的文档化表示。需求制品（requirement artifacts）：需求制品是文档化的需求。需求类型（requirement types）： ⑴domain, application ⑵system, software, user ⑶function, quality(nonfunctional, performance), constraints ⑷目标需求、商业需求用户需求（User requirement）：用户或其他涉众期望系统实现的目标或功能。系统需求（System Requirement）：系统作为一个整体所实现的需求。功能性需求（Functional Requirement）：是关于系统应提供的服务、系统针对特定输入如何响应，以及系统在特定情况下的行为的陈述。在某些情况下，功能性需求还会陈述系统不应做什么。非功能性需求（Non-Functional Requirements）：是一个不明确的功能性需求或者是一个质量需求。质量需求（Quality Requirement）：定义了一个整个系统或一个系统组件、服务或功能的质量特性。质量属性（quality attributes）：系统完成工作的质量，如可靠性等。约束（Constraints）：一种限制了系统开发方式的组织或技术要求。涉众（stakeholder）：涉众是与待开发系统有利益关系的人员或组织。涉众对于系统通常有着他们自己的需求。一个人可以代表不同涉众（人和/或组织）的利益，即一个涉众可以有多个角色并代表多个涉众。上下文（Context）：是系统所处的环境中与定义、理解和解释系统需求相关的那些部分。上下文刻面（Context Facets）：系统上下文被结构化为在需求工程阶段针对软件密集型系统需要考虑的4个上下文刻面，包括主体刻面、使用刻面、IT系统刻面以及开发刻面。上下文方面（Context Aspects）：是系统上下文中的各种物质和非物质的对象，如人、技术与非技术性系统、过程、物理规律等。系统边界（System Boundary）：将待开发系统和系统上下文分割开来。系统边界将属于系统之内、在开发过程中可以被改变的那些部分和那些在开发过程中不可改变、属于系统上下文的部分分隔开。

目标管理-面向目标的需求工程方法

面向目标的需求工程方法Goal-Oriented RE G l O i t d RE 刘璘 Course for MSE Students @ School of Software, Tsinghua U

标G l 目标Goal ? A goal is an objective the system under consideration h ld h should achieve ?Goal formulation refers to intended properties to be ensured ? They are optative statements , as opposed to indicative y p pp ones , and bounded by the subject matter 目标定义为系统想要达到的状态或条件是对系统?目标定义为系统想要达到的状态或条件，是对系统设计意图的一种说明和陈述，隐含地表达了期望系统所体现出的行为以及要满足的约束2 统所体现出的行为，以及要满足的约束。

基于目标的方法 Goal-based Approaches G l b d A h ?Approach ?Focus on why systems are constructed 重点放在为什么要建立一个系统 ?Express the ‘why’ as a set of stakeholder goals 将建立系统的原因表示为干系人要实现的目标集合?Use goal refinement to arrive at specific requirements 进行目标精化得到具体的需求 Goal analysis ?Goal analysis 目标分析 ?document, organize and classify goals 对目标进行组织、分类、建立文档 ?Goal evolution目标演化 ?refine, elaborate, and operationalize goals 对目标求精、细化、操作化 ?Goal hierarchies show refinement and obstacle relationships between goals 运用目标层次结构表示目标间的精化及阻碍关系 l次构表间的精关系 4