Evaluation Framework for Tools that Manage Requirements Inconsistency

Evaluation Framework for Tools that Manage Requirements Inconsistency

Jyothi Iyer and Debbie Richards

Department of Computing, Division of ICS, Macquarie University, Sydney, Australia , 2109

{jiyer,richards}@https://www.wendangku.net/doc/fe608293.html,.au

Abstract

Management of inconsistency in requirements is an important but effort intensive task. Automated tools promise greater reliability and less effort. However, after review of a number of surveys of current commercial requirements engineering (RE) tools we found that while some forms of inconsistency are considered in the evaluations, such as version control and spell checking, the surveys themselves do not address the deeper concerns that inconsistency raises. Hence there is a need for a framework to facilitate comparative evaluation of existing tools that could also serve as a requirements specification for a new or enhanced tool. Our framework and underlying reasoning are presented.

1. Introduction

Management of requirements through the software development life cycle is essential [1]. Management of inconsistency in requirements is a particular problem. Some of the factors that make the software development environment conducive to inconsistency include: diversity of stakeholders’ backgrounds, skills, knowledge, perceptions and goals; resource constraints limiting the time available for proper inconsistency checking; informal specification of requirements; and requirements evolution and volatility. However inconsistency is inevitable in real life and sometimes intentionally desired [2][3], therefore the task is not one of plain inconsistency detection and removal, but, one of managing inconsistency. Manual management is effort intensive and impractical. While complete automation of inconsistency management is unlikely, automated tools can be used to reduce the effort involved. The 2nd International Workshop on Living with Inconsistency [4] expressed the need for tools to support the management of inconsistency. A recent Standish Report [5] too pointed to a similar need.

Although research into inconsistency has been ongoing since the 1970s, automated tool support for inconsistency management in requirements is still in its infancy. We reviewed a number of surveys [6-9] of RE tools and found that while some forms of inconsistency are considered in the evaluations, such as version control and spell checking, the surveys themselves do not address the deeper concerns that inconsistency raises. Hence there is a need for a framework to facilitate comparative evaluation of existing tools that could also serve as a requirements specification to enhance or develop a tool. Based on the research literature into tool evaluation and inconsistency management, we have developed an evaluation framework that we present in this paper.

We commence in Section 2 with a discussion on what is meant by inconsistency. Section 3 details the evaluation framework and section 4 gives our conclusions and future work.

2. Inconsistency and its Management

A simple definition of inconsistency offered by Nuseibeh et al[1, 2] is any situation in which two descriptions do not obey some relationship that is prescribed to hold between them. A relationship between descriptions can be expressed as a consistency rule against which descriptions can be checked. Van Lamsweerde et al [10] point out that inconsistency is not necessarily a binary relationship. More than two descriptions can contribute to an inconsistency.

Finkelstein et al [11] looks at inconsistency from the view of overlaps between specifications and considers overlap and inconsistency to be at two different levels of interference between specifications, the first of which is a pre-requisite for the second. The existence of an overlap implies consistency rules between specifications[12], which if breached make them inconsistent.

Having reviewed a number of surveys of commercial RE tools, we found that inconsistency was being discussed in relation to traceability links between

requirements, version control, document quality checking and consistency of datasets exported and imported between databases. This is understandable as inconsistency is a term that can be used in different contexts. For example, in the context of a configuration management environment, Schwanke and Kaiser [13] classify inconsistency into six kinds. Van Lamsweerde [14] lists nine kinds of inconsistency, based on a goal driven approach to RE. Robinson[15] gives two broad types as: syntactic and semantic inconsistency. Syntactic inconsistency are those caused by terminology inconsistency or improper grammar and semantic inconsistency concern conceptual meanings [15]. Inconsistency management has also been widely explored in the knowledge and database sciences [16-18]. However inconsistency in requirements is focused at a higher level of abstraction. For example, in a database we are concerned with a particular employee id being unique and consistently same in all relevant tables and records. At the requirements level we do not want to check the actual value but state generally that unique ids must be assigned. More closely related are concepts from meta modeling [19, 20] and deductive databases [21] which form a bridge between the high level abstractions found in requirements specifications and the practical implementation issues involved in maintaining consistent databases. As our scope is purely on supporting the requirements phase, and not implementation, we have not included Data or Database types of inconsistency.

Our focus is on a practical solution that can be supported by a tool. Description of the types of inconsistencies in requirements to be addressed would make tool support more realistic and feasible. Drawing from knowledge sciences, a notable paper by Gaines and Shaw [22] brings out the problem of eliciting knowledge from several experts in a domain and details the two most important factors as terminology and concepts. We found these broad categories covered the key notions and thus in our work we define the two main types of inconsistency as:

? Domain Term Inconsistency is when a single domain concept is described using different terms

or a single domain term designates different

domain concepts. For example, a stakeholder in a

restaurant business, might state that, at the end of

a meal a customer is presented with a check.

Another stakeholder in the same restaurant might

call the 'check' a 'bill' and state that, at the end of a

meal a customer is presented with a bill. This type

of inconsistency could also be viewed as

terminological inconsistency. ? Logical Inconsistency is the most popular form of inconsistency and the one usually implied when

type is not specified. A logical inconsistency is

when a concept contradicts another concept.

Logical inconsistency is irrespective of domains

used. The most simple form of logical

inconsistency is A and ? A, however, one could

also have A and (part of ? A) which still results in

logical inconsistency. For example, with the same

restaurant example, a stakeholder might state that

a customer gets a 20% discount on the customer's

10th visit to the restaurant and other discounts do

not apply. While another stakeholder might state

that the customer gets 10% discount on the 10th

visit in addition to other discounts such as

discount vouchers, etc.

What are the activities that constitute managing these inconsistencies in requirements? Tool support is not simply working on the content or data, but must also support the activities that constitute the task of requirements inconsistency management. How do we evaluate that a tool supports requirements inconsistency management? Both these questions are answered in the evaluation framework presented in the next section.

3. Evaluation Framework

Evaluation of software tools is not a new endeavour. Kitchenham [23-26] and Basili [27] laid down some valuable foundations for evaluating software. Kitchenham uses the term Feature Analysis

to describe comparing different packages or tools feature by feature [24]. Feature Analysis is based on identifying the requirements that users have for a particular task/activity and mapping those requirements to features that a method/tool aimed at supporting that task/activity should possess. Kitchenham [24] brings out an important point, that a comparative framework is required so as to perform feature analysis. The evaluation framework proposed here serves that purpose.

Research literature has three frameworks describing the activities that constitute the task of inconsistency management one by Finkelstein et al [12], the second by Nuseibeh et al [1] and the third by Spanoudakis et

al [28], which is a modified combination of the other two approaches. All three frameworks share the same core activities of inconsistency detection, diagnosis, handling and tracking, although Nuseibeh et al [1] do not explicitly state anything about tracking there is an indirect assumption that this will be done in their activity named measurement of inconsistency and

analyzing impact and risk. In the case of Finkelstein et

al [12] handling is referred to as resolution. The evaluation framework presented in this paper builds on these three frameworks, drawing also from INCOSE’s [6] good list of criteria for RE tools, in addition to incorporating several additional requirements identified by Grundy et al [29, 30] and Van Lamsweerde et al [31], which include: presentation and querying of data related to inconsistencies; the need to support multiple users; tool integration with other software tools; incremental building of specifications either top down or bottom up; richer structuring mechanisms such as stakeholder viewpoints; non-functional properties such as performance, usability and separation of concerns such as descriptive and prescriptive properties.

As can be seen, the criteria for evaluation are many and the evaluation framework could suffer from the problems identified by Kitchenham [24] of being time consuming, unwieldy, and therefore not easily usable. Striking a balance between the depth of understanding required to achieve the desired level of confidence in an evaluation and the practical difficulties in handling

a large number of criteria is required. This framework proposes to assist the user by breaking the evaluation criteria into categories. Budgen et al [32-34] defines three categories, namely evaluation against the tool’s design principles, evaluation against the needs of the user and evaluation against software engineering problems and their domains. Vessey and Sravanapudi [34] argue for a fourth category, evaluation against the work environment, in order to support collaborative work groups. The IEEE Std 1209:1994 [35] (standard for evaluation and selection of CASE tools) has 7 categories, namely reliability, usability, efficiency, functionality, maintainability, profitability and general, with functionality being the core functionality of the tool. The rest are very generic and expected criteria in tools. As we are concerned with a generic tool rather than a domain specific one, we restrict our focus to the tools functionality and usability. Usability being selected only because functionality required for requirements inconsistency management could be quite complex, however keeping it simple for the user would be the hallmark of its success. We have partitioned the criteria into the following 4 broad categories:

? Evaluation of tool’s core functionality of requirements inconsistency management (which is

the software engineering problem and domain we

are focusing on).

? Evaluation of tool’s support for real world problems within the context of requirements

inconsistency management (the users needs within

this context). ? Evaluation of tool’s usability within the context of requirements inconsistency management (usability

being the key design principle we have chosen). ? Evaluation of tool’s support for collaborative working within the context of requirements inconsistency management.

The framework is open to customization as regards which categories to include and how to score. For example, not all projects involve collaborative working, research tools may ignore usability and prototypes may ignore real world issues such as scalability. Each question expects a ‘yes’ or ‘no’ answer, perhaps yielding a 1 or 0, respectively. Weights could be assigned to some or all questions. The higher the score the more suitable the tool.

3.1 Evaluation of the tool’s core functionality

of requirements inconsistency management.

The criteria selected under this category relate to the core functionality required of the tool to support the RE analyst in doing the task of requirements inconsistency management. The activities that constitute the task of requirements inconsistency management is constructed from that found in research literature, specifically drawing from all the three inconsistency management frameworks found in [12] [1] [28] and other literature [31] [29, 30] as:

? Inconsistency Management Configuration,

? Inconsistency Detection,

? Inconsistency Diagnosis,

? Inconsistency Handling,

? Inconsistency Tracking,

? Inconsistency Measurement and Analysis and

? Modelling.

Inconsistency Management Configuration is an activity typically performed at the start of a project. Configuration options should control or direct the way inconsistency management is done with the possibility to change these options at any time during the lifecycle of the project. Configuration of the tool is required to specify:

? Inconsistency Management Policies, actions that will be taken by the tool when an inconsistency is detected. Two types of policies should be supported. Preventive Policy: Used when the RE analyst wishes to stop an anticipated inconsistency from ever occurring. The tool should reject any actions whose completion would cause the specific inconsistency to occur. Handling Policy: Used when the RE analyst wants to specify certain handling actions when an anticipated inconsistency occurs. See the Inconsistency Handling subsection.

? Project Structure and Scope for Inconsistency Management are both related. Most tools operate on a project basis i.e. an effective way of grouping

all artefacts related to a project. Similarly dividing

a project into sub-projects and hierarchically

organising these projects is also required. Top down and bottom up approaches to problem solving can then be catered for. Local and global consistency checking can be performed on individual sub-projects and the entire project respectively. For example, initially the RE analyst may want to manage inconsistency only within a small subset of requirements, incrementally expanding this to include requirements in the entire

project. Thus the need for a facility to control the Scope for Inconsistency Management where it should be possible to specify the individual subproject/s or project/s that constitute the scope of

operation for inconsistency management at any given time.

? Monitoring for Inconsistency is specifying how often the inconsistency detection process is run, whether continuous, at specified intervals or times.

For example, where a significant computational overhead is involved, monitoring need not be continuous, in which case there should be options available to the RE analyst.

Inconsistency Detection is picking up the violation of a consistency rule between two or more descriptions. Detection must be an automatic process, one that does not need any support from the user. However, the tools’ actual detection process should run as configured for monitoring for inconsistency. Detection of requirements inconsistency types such as ‘domain term’ and ‘logical inconsistency’ should be supported. Detection of inconsistencies specified in policies or those arising due to addition, deletion or modification of descriptions or those arising whilst handling other inconsistencies should also be supported.

Inconsistency Diagnosis is providing feedback on the inconsistency and facilitating the RE analyst do some investigation. Although diagnosis must essentially be an automatic process, one that does not need any support from the user, sometimes what the tool comes up with may not always make sense, hence the user should be permitted to do problem diagnosis too. The tool should be able to locate an inconsistency, identify the cause of an inconsistency and classify the type of inconsistency such as ‘logical’ or ‘domain term’.

Inconsistency Handling involves actions taken in response to the inconsistency encountered. Handling actions can range from simple trivial actions, such as modifications to descriptions, to complex handling actions, as suggested by Nuseibeh et al [1] , which are: ? Ignore – When the cost or effort in fixing an inconsistency is too great relative to the adverse

impact of the inconsistency, the RE Analyst may

choose to ignore the inconsistency. In some cases,

the inconsistency may be intentional or desired,

ignoring the inconsistency provides the RE analyst

with the facility to cater to that.

? Defer – More time may be required to attend to the inconsistency however in the interim the

inconsistency should be tolerated so that it does

not adversely impact the progress of the project. ? Circumvent – The tool may detect an

inconsistency which the RE Analyst does not

really regard as an inconsistency. This may be

because the rules being broken are wrong in the

first place or the inconsistency represents an

exception to the rule that has not been captured.

The RE Analyst may choose to circumvent the

inconsistency by modifying the rules or disabling

them for a specific scope of operation.

? Ameliorate – The RE Analyst may choose to improve a description containing inconsistencies

without necessarily resolving them all. This may

include adding information to the description that

reduces the adverse effects of the inconsistency

and/or resolves other inconsistencies as a side

effect.

The ability to simulate the results of certain parameter values will assist with exploring and selecting the various options.

Inconsistency Tracking is the recording of the events and actions, and information associated with these, through the life span of an inconsistency. This is different from tracking requirements, which is discussed in section 3.4 under change management. Details to be recorded about inconsistency are (a) the reasoning underpinning the detection of an inconsistency (b) the source and cause of inconsistency (c) the handling actions that were considered and (d) the arguments underpinning the decision to select one of these options and reject the other.

Inconsistency Measurement is needed to ensure efficient and effective inconsistency management. Measures are needed such as the cost, benefit and risks associated with the various handling actions and the number and severity of inconsistencies. Measures relating to make a decision on which choice is “more consistent”, which inconsistencies are urgent are factors that are of interest. Being able to query and

report on this data is another feature that is important in tools.

Modelling of the domain involving a description of the problem is a precursor to management of inconsistency. The tool should support the representation of a wide range of descriptions, whether diagrammatic or language oriented, descriptive or prescriptive. The tool should support describing the requirement, giving it a unique identifier, associating properties with requirements, such as priority, establishing links between requirements, hierarchical organization of requirements and structuring requirements into project and sub-projects. The tool should also support relatively new RE approaches such as viewpoints, goals and scenarios. In addition to building a requirements model, the tool should assist in building a domain model defining the domain terms used.

3.2 Evaluation of the tool’s support to real

world problems.

A second part of the framework is consideration of whether the tool supports usage for real projects rather than just toy problems. Criteria here could be numerous, however limiting criteria to the most essential in this category is of importance, keeping in mind that this is an evaluation framework for an RE tool specifically concerned with requirements inconsistency management.

Checking for inconsistency will involve some computational overhead and as the number of requirements grows so too will the overheads, hence performance scalability is definitely a criteria. Of great importance is the data within the tool i.e. the requirements, the RE analyst may want to query this data for analysis or print reports or export/import data from/to the tool. A variety of software tools are typically used on modern day software projects and therefore tool integration is another important criteria. These are all real world problems. Thus, the specific criteria to be evaluated are,

? Performance Scalability

? Integration with other software tools

? Data Import/Export

? Presentation Output

3.3 Evaluation of the tool’s usability

Several authors have their own list of evaluation criteria for usability, for example, Nielsen’s 10 heuristics for assessors of HCI’s [36], Norman’s ‘Seven Principles for Transforming Difficult Tasks into Simple Once’[37] and Schneiderman’s 8 Golden Rules[38]. Bobeva et al [39] have quite concisely integrated the three sets of heuristic evaluation criteria namely Nielsen’s [36], Norman’s [37] and Schneiderman’s [38] into eight criteria. Dix et al [40] has provided a simplistic categorisation of usability principles into three categories, namely learnability, robustness and flexibility. ‘Usability Engineering’ can be quite detailed in its own right, however the focus of this project is not a detailed analysis of the usability of the tool, the focus of this project is the tool’s usability to a RE analyst in managing inconsistency of requirements. The tool should be easy to learn, use and flexible not just for the RE analyst but also for common lay users, such as the stakeholders who, for example, could have read-only access. The tool should provide good error handling and support with the ability to reverse actions when required, for example, on performing a mistake while handling inconsistency the RE analyst may need to rewind to a previous state. The authors propose to use the criteria suggested by Bobeva et al [39], however categorised as suggested by Dix et al [40], grouping some criteria together as also adding multi-tasking and access flexibility (web access, etc.) which are thought necessary for current generation tools. The specific criteria and sub-criteria to be evaluated are:

? Leanability

o Documentation

o Feedback

o Consistency

? Robustness

o Error Handling

o Error Messaging

o Reversal Actions

? Flexibility

o Multi-tasking

o Access Flexibility

3.4 Evaluation of the tool’s support for collaborative working

Typically a project team consists of more than one person and projects in today’s world are increasingly being done in multiple locations around the world. Tools generally store the requirements or data in an in-built repository of some sort, which is most usually a database. Thus the important factors are the number of people working on a project, the number of locations and the number of databases used in recording requirements. The RE analyst should be able to control access to data for different users and manage change

requests. Version control too should be supported. Recording ‘who’ has done ‘what’, ‘when’ and ‘where’ is important as this information will support the RE analyst in handling requirements inconsistency. Thus the tool should support the RE analyst in managing requirements inconsistency across people, locations and databases. The specific criteria and sub-criteria to be evaluated are:

? Team usage

o Multi-User o Single-Site o Multi-Site

? Configuration Management

o Change Requests o Change Logging o Access Control o Version Control

Table 2: The Framework At A Glance.

Category Evaluation Criteria Evaluation Sub-Criteria

Inconsistency Management Policies Project Structure Scope for Inconsistency

Management Inconsistency Management Configuration Monitoring Setup

Inconsistency Detection Inconsistency Diagnosis Inconsistency Handling Inconsistency Tracking Inconsistency Measurement

Evaluation of tool’s core functionality of requirements inconsistency management. Modelling

Performance Scalability Integration with other software tools Data Import/Export Evaluation of tool’s support for real world problems within the context of requirements inconsistency management. Presentation Output

Multi-User Single-Site Team Usage Multi-Site Change Requests

Evaluation of tool’s support for collaborative working within

the context of

Change Management Change Logging

Access Control

requirements

Version Control Help and

Documentation Feedback Learnability

Consistency Errors

Robustness Reversal Actions User Multi-tasking Evaluation of tool’s usability within the context of requirements inconsistency management.

Flexibility

Access Flexibility

4. Conclusions and Future Work.

The framework we have presented is based on an in-depth review of literature both into requirements inconsistency management and tool evaluation. Viewed another way and turned around appropriately, the evaluation framework can be transformed to a set of requirements that can facilitate RE tool vendor’s develop/enhance their tool products. To determine whether the set of requirements are indeed representative of the needs of potential users, a detailed online questionnaire survey has been developed to be completed by RE practitioners and academics subscribed to an RE mailing list at re-online@https://www.wendangku.net/doc/fe608293.html,.au (around 750 subscribers). The questionnaire is structured along the lines of the evaluation framework with a set of proposed requirements for each criteria/sub-criteria of the evaluation framework. The survey begins by eliciting the background of the participant and requests scoring each proposed requirement using the scale “Mandatory, Optional, Delete or Do not care”. The

survey can be found at https://www.wendangku.net/doc/fe608293.html,.au:8080/quiz/. Initial results show that we have found support for most of the features in our framework, but we have encountered some interesting findings such as little interest in an RE tool supporting measures on cost, benefits and risks with handling the inconsistencies. Our complete results will be published in a future paper.

5. References

[1]

B. Nuseibeh, S. Easterbrook, and A. Russo, Making Inconsistency Respectable in Software Development, Journal of Systems and Software , vol. 58(2), pp. 171-180, 2001.

[2] S. Easterbrook and B. Nuseibeh, Using ViewPoints for Inconsistency Management, Software

Engineering Journal , vol. 11(1), pp. 31-43, 1996. [3]

D. Gabbay and A. Hunter, Making Inconsistency Respectable: Part 2 --- Metalevel handling of

inconsistency, In Proceedings of the Symbolic and

Qualitative Approaches to Reasoning and

Uncertainty (ECSQARU'93), vol. 747 of Lecture

Notes in Computer Science, pp. 129--136, Berlin,

1993.

[4] Steve Easterbrook and Marsha Chechik, Workshop

and conference summaries: 2nd international

workshop on living with inconsistency

(IWLWI01), ACM SIGSOFT Software Engineering

Notes, vol. 26(6), pp. 76-78, 2001.

[5] What are your requirements? 2003, The Standish

Group International,Inc., West Yarmouth, MA

2003.

[6] "Tools Survey: Requirements Management (RM)

Tools," International Council on Systems

Engineering, 2004,

https://www.wendangku.net/doc/fe608293.html,/tools/tooltax.html,

DateUpdated:December 29, 2002,

DateAccessed:Jan.2004.

[7] "Requirements Tools," The Atlantic Systems Guild

Inc., 2004, https://www.wendangku.net/doc/fe608293.html,/tools.htm,

DateUpdated:Nov. 2003, DateAccessed:Jan. 2004.

[8] I. F. Alexander, "Requirements Engineering Tool

Vendors and Freeware Suppliers," 2004,

https://www.wendangku.net/doc/fe608293.html,/~iany/other/vendors.h

tm, DateUpdated:7 May 2003, DateAccessed:Jan.

2004.

[9] R. R. Sud and J. D. Arthur, Requirements

Management Tools: A Quantitative Assessment,

Department of Computer Science, Virginia Tech

Technical Report TR-03-10, 2003.

[10] A. v. Lamsweerde, R. Darimont, and E. Letier,

Managing conflicts in goal-driven requirements

engineering, IEEE Transaction on Software

Enginering:special issue on Managing

Inconsistency in Software Development, vol.

24(11), pp. 908-926, 1998.

[11] G. Spanoudakis and A. Finkelstein, Overlaps

Among Requirements Specifications, International

Conference on Software Engineering Workshop on

Living with Inconsistency, 1997.

[12] A. Finkelstein, G. Spanoudakis, and D. Till,

Managing Interference, ACM SIGSOFT 96

Workshop - Viewpoints 96, 1996.

[13] R. W. Schwanke and G. E. Kaiser, Living With

Inconsistency in Large Systems, In Proceedings of

the International Workshop on Software Version

and Configuration Control, pp. 98-118, Grassau,

Germany: B.G. Teubner, Stuttgart, 1988.

[14] A van Lamsweerde, R. Darimont, and E. Letier,

Managing conflicts in goal-driven requirements

engineering, IEEE Transactions on Software

Engineering: Special Issue on Managing

Inconsistency in Software Development, vol.

24(11), pp. 908-926, 1998.

[15] W. N. Robinson, I Didn't Know My Requirements

were Consistent until I Talked to My Analyst, In

Proceedings of the 19th International Conference

on Software Engineering, Living With

Inconsistency Workshop, Boston, USA, 1997. [16] P. Anokhin and A. Motro, Data Integration:

Inconsistency Detection and Resolution Based on

Source Properties, In Proceedings of the FMII-01,

International Workshop on Foundations of Models

for Information Integration (the 10th workshop in

the series Foundations of Models and Languages

for Data and Objects), Viterbo, Italy, September

2001.

[17] V. S. Subrahmanian, Amalgamating knowledge

bases, ACM Transactions on Database Systems,

vol. 19(2), pp. 291 - 331, 1994.

[18] W. A. Carnielli, S. d. Amo, and J. Marcos, A

logical framework for integrating inconsistent

information in multiple databases, In Proceedings

of the II International Symposium on Foundations

of Information and Knowledge Systems, pp. 67–

84, Germany, 2002.

[19] W. N. Robinson and S. D. Pawlowski, Managing

Requirements Inconsistency with Development

Goal Monitors, IEEE Transactions on Software

Engineering, vol. 25(6), pp. 816-835, 1999.

[20] H. Nissen, M. Jeusfeld, M. Jarke, G. Zemanek, and

H. Huber, Managing Multiple Requirements

Perspectives with Metamodels, IEEE Software, pp.

37-47, 1996.

[21] G. Moerkotte and P. C. Lockemann, Reactive

Consistency Control in Deductive Databases, ACM

Transactions on Database Systems, vol. 16(4), pp.

670--702, 1991.

[22] M. L. G. Shaw and B. R. Gaines, Comparing

conceptual structures: consensus, conflict,

correspondence and contrast, Knowledge

Acquisition: An International Journal, vol. 1, pp.

341--363, 1989.

[23] B. A. Kitchenham, Evaluating Software

Engineering Methods and Tools Part 2: Selecting

an appropriate evaluation method - technical

criteria, ACM SIGSOFT Software Engineering

Notes, vol. 21(2), 1996.

[24] B.

Kitchenham,

DESMET: A method for

evaluating Software Engineering methods and

tools, Department of Computer Science, University

of Keele, Keele, Staffordshire, UK. TR96-09,

1996.

[25] B. A. Kitchenham, Evaluating software

engineering methods and tool part 1: The

evaluation context and evaluation methods, ACM

SIGSOFT Software Engineering Notes, vol. 21(1),

pp. 11 - 14, 1996.

[26] B. A. Kitchenham, S. L. Pfleeger, L. M. Pickard, P.

W. Jones, D.C. Hoaglin, K. E. Emam, and J.

Rosenberg, Preliminary Guidelines for Empirical

Research in Software Engineering., IEEE

Transactions on Software Engineering,, vol. 28(8),

pp. 721--734, 2002.

[27] V. R. Basili, The role of experimentation in

software engineering: Past, current, and future, In

Proceedings of the 18th Intl. Conf. on Software

Engineering, pp. 442-449, 1996.

[28] G. Spanoudakis and A. Zisman, "Inconsistency

Management in Software Engineering: Survey and

Open Research Issues," in Handbook of Software

Engineering and Knowledge Engineering, Vol. 1,

(Ed) Chang S. K.: World Scientific Publishing Co,

2001, pp. 329-380.

[29] J. C. Grundy, J. G. Hosking, and W. B. Mugridge,

Inconsistency Management for Multi-view

Software Development Environments, EEE

Transactions on Software Engineering: Special

Issue on Managing Inconsistency in Software

Development, IEEE CS Press, vol. 24(11), 1998. [30] J. C. Grundy, W. B. Mugridge, and J. G. Hosking,

Constructing component-based software

engineering environments: issues and experiences,

Information and Software Technology, Special

Issue on Constructing Software Engineering Tools,

vol. 42(2), pp. 117-128, 2000.

[31] A. v. Lamsweerde, "Formal Specification: a

Roadmap (2000)," in ICSE - Future of SE Track,A.

Finkelstein (ed.), ACM Press, 2000.

[32] D. Budgen and M. Thomson, CASE tool

evaluation: experiences from an empirical study,

Journal of Systems and Software, vol. 67(2), pp.

55-75, 2003.

Software Design: Addison Wesley, [33] D.

Budgen,

1993.

[34] Vessey and Sravanapudi, CASE tools as

collaborative support technologies,

Communications of the ACM, vol. 38(1), pp. 83-95,

1995.

[35] IEEE Standards Collection - Software

Engineering: Institute of Electrical and Electronics

Engineers, Inc., 1994.

Usability Engineering. MA: AP [36] J.

Nielson,

Professional, 1993.

Things that make us smart. MA: [37] D.

Norman,

Addison Wesley, 1993.

[38] B.

Designing the User Interface, 3rd Scheiderman,

ed. MA: Addison Wesley, 1998.

[39] M. Bobeva and B. Williams, A tale of four shifts

and three frameworks: An empirical evaluation of

the effectiveness of human-computer interface

design, In Proceedings of the 10th European

Conference on Information Technology

Evaluation, pp. 69-78, Madrid, Spain, 2003. [40] A. Dix, J. Finlay, G. Abowd, and R. Beale,

Human-Computer Interaction, 2nd ed: Prentice

Hall, 1998.

新编英语语法教程(第6版)练习参考答案

新编英语语法教程（第6版）第21讲练习参考答案Ex. 21A was sorry to learn… will be sad to hear… would be very surprised to receive… is happy to have found… was afraid to go… was pleased to hear… am very anxious to meet you. were delighted to receive your telegram. were sensible to stay indoors. clerk was prompt to answer the call. rule is easy to remember. are reluctant to leave this neighbourhood. house is difficult to heat. you ready to leave would be foolish to go out in this weather. is quick to see the point. is very keen to get on. are proud to have him as a friend. was rude not to answer your letter. are happy to have you with us this evening. Ex. 21B decision to resign surprised all of us. showed no inclination to leave.

新编英语语法教程

导论———语法层次 0.1 词素 1）自由词素 2）粘附词素 0.2 词 1）简单词、派生词、符合词 2）封闭词类和开放词类 0.3 词组 1）名词词组 2）动词词组 3）形容词词组 4）副词词组 5）介词词组 0.4分句 1）独立分句和从属分句 2）简单分句和复杂分句 3）主句和从句 4）限定分句、非限定性分句、无动词分句0.5 句子 1）完全句和不完全句 2）简单句、并列句、复杂句、并列复杂句 第1讲句子结构 1.1 主谓结构和句子分析 1）主语和谓语 2）句子分析 1.2 基本句型及其转换与扩大 1）基本句型 2）基本句型的转换与扩大 第2讲主谓一致（一） 2.1指导原则 1）语法一致 2）意义一致和就近原则 2.2 以-s 结尾的名词作主语的主谓一致问题1）以-s结尾的疾病名称和游戏名称 2）以-s结尾的学科名称 3）以-s结尾的地理名称 4）其他以-s结尾的名词 2.3 以集体名词作主语的主谓一致问题 1) 通常作复数的集体名词 2）通常作不可数名词的集体名词 3）既可作单数也可作复数的集体名词 4）a committee of 等+复数名词

第3讲主谓一致（二） 3.1 以并列结构作主语的主谓一致问题 1）由and/both... And 连接的并列主语 2）由or/nor/either...or 等连接的并列主语 3）主语+as much as 等 4）主语+as well as 等 3.2 以表示数量概念的名词词组作主语的主谓一直问题1）以表示确定数量的名词词组作主语 2) 以表示非确定数量的名词词组作主语 3.3 其他方面的主谓一致问题 1）以名词性分句作主语的主谓一致问题 2）以非限定分句作主语的主谓一致问题 3）关系分句中的主谓一致问题 4）分裂句中的主谓一致问题 5）存在句中的主谓一致问题 第4讲 4.1 名词分类和名词词组的句法功能 1）名词分类 2）名词词组的句法功能 4.2 名词的数 1）规则复数和不规则复数 2）集体名词、物质名词、抽象名词、专有名词的数4.3 单位词 1）一般表示个数的单位词 2）表示形状的单位词 3）表示容积的单位词 4）表示动作状态的单位词 5）表示成双、成对、成群的单位词 第5讲 5.1 名词属格的构成、意义和用法 1）名词属格的构成 2）名词属格的意义 3）名词属格的用法 5.2 独立属格和双重属格 1）独立属格 2）双重属格 第6讲限定词（一） 6.1限定词与三类名词的搭配关系 1）能与三类名词搭配的限定词 2）只能与单数名词搭配的限定词 3）只能与复数名词搭配的限定词

新编英语语法教程期末考试试卷

大学英语语法模拟试题 1. Mr. and Mrs. Burns feel more comfortable on a ship than they would be if they ______________any other way. A. would travel B. travelled C. are travelling D. have travelled 2. We______________ that Jim be there. A. hope B. wish C. expect D .ask 3. Lucy is glad she didn’t stay on the farm. She______________ bored. A. may be B. will be C. could be D. might have been 4. The dean of studies would have come to see you had it been possible, but he ______________so busy then. A. had been B. was C. were D. would be 5. They would certainly have come and helped us ______________time. A. did they have B. had they had C. had they have D would they have 6. If you were in better health, we______________ you to join in the work last week. A. would have allowed B. would allow C. should allow D. had allowed 7. She cried for her______________ lover. A. departed B. being departed C. departing D. having departed 8. ______________ in an important examination, one of the students in his class lost interest in his work A. Failing B. Failed C. Having been failed D. Having Failed 9. If it______________ tomorrow, I’ll stay at home. A. rained B. will rain C. had rained D. rains 10. “It’s getting very late.”“Yes, it’s time______________.” A. that we left B. we leave C. we’ll leave D. we have left a bus to go there, but he preferred to walk.

《新编英语语法教程》语法术语精编

《新编英语语法教程》主要章节语法术语Introduction: Grammatical Hierarchy (导论—语法层次) 2. Parts of speech (word class) 3. Phrases 词组 4. Clause 分句 5. Sentence 句子 1. Morpheme 词素 Free morpheme 自由词素 Bound morpheme 粘附词素 Allomorph 词素变体 Noun phrase Verb phrase Adjective phrase Adverb phrase Preposition phrase Conjunction

Lecture 1 Sentence Structure（L1）Sentence elements: S (subject) 主语V (predicate verb) 谓语动词 O (object) 宾语 C (complement) 补足语 A (Adverbial) 状语 1. Two ways of sentence analysis 1) SVO Sentence Clause NP VP NP Subject Predicate verb Object All the man have done their best. Sentence = Subject + Predicate (Predicate Verb + Object, Complement, Adverbial, etc.) ●句子由主语和谓语构成，进一步把谓语剖析为谓语动词、宾语、补语、状语等。 2) Subject + Predicate (= operator + predication) Sentence Clause Subject Predicate Operator Predication All the man have done their best. ●句子由主语和谓语构成，进一步把谓语剖析为操作词（operator）和述谓成分（predication）。 2. Basic clause types SVC, SV, SV A, SVO, SVOA, SVOC, SV oO Lecture 2 Subject-Verb Concord （L2-3） Guiding principles: Grammatical Concord Notional Concord Principle of Proximity 语法一致原则意义一致原则就近原则 Nominal clause Non-finite clause Relative clause Cleft sentence Existential clause 名词性分句非限定分句关系分句分裂句存在句Lecture 3 Noun and Noun Phrase（L4-5） 1. Classification of nouns

(word完整版)It+willbe+时间段+before等表示“在……之后……才”的句型总结,推荐文档

It + will be + 时间段 + before等表示“在……之后……才”的句型总结 一、用于句型“It + will be + 时间段 + before...”句型中，表示“要过多久才…”，也可用于“It + may be + 时间段 + before...”，表示“也许要过多久才……”。Before 后的句子中用一般现在时态。 其否定形式“It will/would not be +时间段+ before…”表示“不久就……，过不了多久就……”。 【典型考例】 （1）The field research will take Joan and Paul about five months; it will be a long time _____ we meet them again.（2007安徽卷） A. after B. before C. since D. when （2）—How long do you think it will be ______China sends a manned spaceship to the moon? （2006福建卷） —Perhaps two or three years. A. when B. until C. that D. before （3）It ________ long before we _______ the result of the experiment.( 上海春招2002) A. will not be...will know B. is...will know C. will not be...know D. is...know (4) Scientists say it may be five or six years_________ it is possible to test this medicine on human patients. （2004福建） A. since B. after C. before D. when 解析：答案为BDCC。考题 （1）(2)before 用于肯定的“It + will be + 时间段 + before...”句型中，表示“要过多久…才…”。 （3）before在本题中用于否定句,意为“过不了多久就会……”, 状语从句要用一般现在时代替一般将来时，可知C项为正确答案,句意是:要不了多久我们就会知道试验的结果了。 （4）宾语从句中含有句型“It + may be + 时间段 + before...”，表示“也许要过多久才……”，故选择答案C。 二、用于句型“it was +时间段+ before …”表示“过了（多长时间）才……”。其否定形式“ it was not +时间段+ before …”意为“不久就……”, “没过（多长时间）就……”。 【典型考例】 It was some time ___________we realized the truth. （2005山东） A. when B. until C. since D. before 解析：答案为D。before用于句型“it was +时间段+ before …”表示“过了（多长时间）才……”。该题题意是“过了一段时间我们才意识到事情的真相”。故正确答案为C项。

before用法归纳

before用法知多少？ 在高考中，状语从句是每年高考单项填空部分必考的题目之一，考查的重点是考生容易混淆并且近似的连词在逻辑行文和语篇结构中的使用。before作连词的用法一直是高考的重点，也是学生感觉掌握起来比较头疼的地方。下面选取近几年各省市的高考试题进行归纳分析，使考生通过典型实例，把握高考对before所引导的句型的命题规律，帮助同学们更好地解答此类题目。 1. before作为连词时的基本意义是“在……之前”，用于表示时间或顺序。 You can’t borrow books from the school library ______ you get your student card. (2009上海，32) A. before B. if C. while D. as 【解析】选A。考查连词，该句的意思是：在你得到你的学生卡之前你不能从学校图书馆借书。before表示先后顺序。 2. 表示“过了多久才……”，说明主句的持续时间比较长而从句的动作缓缓来迟。 (1) The American Civil War lasted four years _______ the North won in the end. (2005广东，30) A. after B. before C. when D. then 【解析】选B。本题考查连词before表示“在多久之后才……”的用法，根据本句含义“美国南北战争持续了四年，北方才最终取得胜利”，可知本题应选B。 (2) Several weeks had gone by I realized the painting was missing. (2004宁夏，39) A. as B. before C. since D. when 【解析】选B。before表示“过多久才……”。句意：几个星期已经过去了，我才意识到油画丢了。内含的意思是油画丢了好几个星期了，我才意识到。 3. 表示从句动作还没来得及发生或完成，主句动作就已经发生或完成了，意为“尚未……就”，“没来得及……就”，常用于before sb. can/ could…。 —Why didn’t you tell him about the meeting? ( 2006四川，35) — He rushed out of the room _________ I could say a word. A. before B. until C. when D. after 【解析】选A。本题考查连词before表示“还没来得及……就……”的用法。句意为：我还没来得及说一句话，他就冲出了房间。 4. 表示“以免，以防，趁……还没有……”，强调动作的必要性，以避免或防止从句动作的发生。 He made a mistake, but then he corrected the situation _____ it got worse.（2003北京） A. until B. when C. before D. as 【解析】选C。由made a mistake和转折词but可知本题句意是“他犯了一个错误，但在事情进一步恶化之前他改变了形势。”故答案正确答案为C项。

新编英语语法教程期末考试试卷.doc

大学英语语法模似试题 1. Mr. and Mrs. Burns feel more comfortable on a ship than they would be if they any other way. A. would travel B. travelled C. are travelling D. have travelled 2. We that Jim be there. A. hope B. wish C. expect D .ask 3. Lucy is glad she didn^ t stay on the farm. She bored. A. may be B. will be C. could be D. might have been 4. The dean of studies would have come to see you had it been possible, but he so busy then. A. had been B. was C. were D. would be 5. They would certainly have come and helped us time. A. did they have C. had they have 6. If you were in better health, wc. A. would have allowed C. should allow 7. She cried for her A. departed B. being departed C. departing D. having departed _____________ in an important examination, one of the students in his class lost interest in his work A. Failing B. Failed C. Having been failed D. Having Failed 9. Tf it _____________ tomorrow, P 11 stay at home. A. rained B. will rain C. had rained D. rains 10. “Tt’ s getting very late. n “Yes, it’ s time __________________________ . ” A. that we left B. we leave C. we^ 11 leave D. we have 1 eft 1 Ule ______________ a bus to go there, but he preferred to walk. A. should have taken B. could take C. could have taken IX hadn^ t taken 12. _____________ the English examination I would have gone to the concert last Sunday- A. Tn spite of B. But for C. Because of D. As for 13- _____________ , we can hardly get to the station by sixclock. A. As it wi 11 be B. As it seemed C. As it is D. As if it seems 14. We hung out a lantern lest he ___________________ lost in the mist. A. gets B. get C. will get D. got 15- Tt is quite natural that such fears _______________________ . A. rise B. should arise C. should rise D. are arisen 16. Pm sorry to _________________ your private thoughts, but T think we should get on with some work. A. break in B. break on C. break in on D. break out 17. Do you think he will_________________ a cook wearing that hat? pass for B> pass as C. pass through D. pass on B. had they had D would they have ___________ you to join in the work last week. B. would allow D. had allowed 1 over. 8.

but,than引导定语从句和before,until用法辨析

but和than引导定语从句的用法 一、but可被看作关系代词，引导定语从句，在句中作主语，在意义上相当于 who not或that not，即用在否定词或具有否定意义的词后，构成双重否定。 如：①There is no mother but loves her children．没有不爱自己孩子的母亲。 ②There was no one present but knew the story already．在场的人都知道这个故事。 二、than作关系代词时，一般用在形式为比较级的复合句中，其结构为形容词比较级（more）．．．than＋从句，than在从句中作主语，相当于that，代表它前面的先行词。（这时，它兼有连词和代词的性质，也有学者认为这种用法的than是连词，后面省略了主语what。） 如：①The indoor swimming pool seems to be a great deal more luxious than is necessary．室内游泳池过于豪华。 ②He got more money than was wanted．他得到了更多的钱。运用上述知识翻译下列句子： 1．任何人都喜欢被赞扬。（but） 2．我们大家都想去桂林。（but） 3．没有人不同情那些嗷嗷待哺的孩子。（but） 4．我们班上没有一个人不想帮你。（but） 5．无论多么荒凉，多么难以行走的地方，人们也能把它变成战畅（but）6．这件事情比想象的要复杂。（than） 7．这个广告的效果比预想的要好。（than） 8．这个问题看起来容易，实际上很难。（than） 9．他爸妈给他的零用钱总是超过他的需要。（than） 10．因为这项工程非常困难，所以需要投入更多的劳动力。（than） 答案： 1．There is no one but likes to be praised． 2．There is no one of us but wishes to visit Guilin． 3．There is no man but feels pity for those starving children．4．There is no one in our class but wants to help you． 5．There is no country so wild and difficult but will be made a theatre of war． 6．This matter is more complex than is imagined． 7．This advertisement is more affective than is expected． 8．The problem may be more difficult in nature than would appear．9．He got more pocket money from his parents than was demanded．

新编英语语法教程(第6版)第10讲练习参考答案

新编英语语法教程（第 6 版）第 10 讲练习参考答案 Ex. 10A When it comes to making a conscious effort to help keep a public place clean, most people just don ’ t make the effort. I ’ m a maintenance man for a department store. If people did make the effort, I probably wouldn ’ t haveob. a j The area that I have to spend the most time cleaning is the employees ’lunchroom . Employees go there during breaks, lunch, and dinner. The maintenance department supplies containers for garbage and ashtrays for cigaret te butts. But when they finish their food the employees will either throw their papers on the floor or leave them on the table. Some employees will on occasion throw their papers in the garbage container, but most of them who smoke will eithe r flick their ashes on the floor or in the half-filled soda cups. Cigarette butts are found anywhere other than in the ashtray, because the ashtrays may have been stolen or have been filled with gum. Sometimes an employee will remark, “ Aren ’ t these people pigs? They don ’ t even up after themselves,” as they proceed to walk away fromtheir littered table. Ex. 10B 1. its 2. his, he 3. them 4. it has 5. it, it has to 6. its / their 7. its8. him / them 9. he is / they are 10. it 11. it 12. his / their 13. isn’ t it14. take / takes 15. his / their 16. has, her 17. their 18. has, his 19. they, themselves 20. tends, itself Ex. 10C 1. it / she 2. It 3. it / her 4. her 5. his / one ’ s, he / one, his / one ’ s

before句型辨析与解析

before句型辨析与解析 It + will be + 时间段+ before等表示“在……之后……才”的句型总结 一、用于句型“It + will be + 时间段+ before...”句型中，表示“要过多久才…”，也可用于“It + may be + 时间段+ before...”，表示“也许要过多久才……”。Before 后的句子中用一般现在时态。 其否定形式“It will/would not be +时间段+ before…”表示“不久就……，过不了多久就……”。 （1）The field research will take Joan and Paul about five months; it will be a long time _____ we meet them again. A. after B. before C. since D. when （2）—How long do you think it will be ______China sends a manned spaceship to the moon? —Perhaps two or three years. A. when B. until C. that D. before （3）It ________ long before we _______ the result of the experiment. A. will not be...will know B. is...will know C. will not be...know D. is...know (4) Scientists say it may be five or six years_________ it is possible to test this medicine on human patients. A. since B. after C. before D. when 解析：答案为BDCC。考题 （1）(2)before 用于肯定的“It + will be + 时间段+ before...”句型中，表示“要过多久…才…”。 （3）before在本题中用于否定句,意为“过不了多久就会……”, 状语从句要用一般现在时代替一般将来时，可知C项为正确答案,句意是:要不了多久我们就会知道试验的结果了。 （4）宾语从句中含有句型“It + may be + 时间段+ before...”，表示“也许要过多久才……”，故选择答案C。 二、用于句型“it was +时间段+ before …” 表示“过了（多长时间）才……”。其否定形式“ it was not +时间段+ before …” 意为“不久就……”, “没过（多长时间）就……”。 It was some time ___________we realized the truth. A. when B. until C. since D. before 解析：答案为D。before用于句型“it was +时间段+ before …” 表示“过了（多长时间）才……”。该题题意是“过了一段时间我们才意识到事情的真相”。故正确答案为C项。 表示“在……之后……才”。副词“才”在汉语中强调某事发生得晚或慢。如果在含有before从句的复合句中，强调从句动作发生得晚或慢时，就可以应用这种译法。 The American Civil War lasted four years _______ the North won in the end. A. after B. before C. when D. then 解析：答案为B。本题考查连词before表示“在……之后才……”之的用法，根据本句含义“美国南北战争持续了四年，北方才最终取得胜利”，可知本题应选B。 三、表示“……还没来得及……就……”。目的在于强调从句动作发生之前，主句动作已发生。 —Why didn't you tell him about the meeting? — He rushed out of the room _________ I could say a word. A. before B. until C. when D. after 解析：答案为A。本题考查连词before表示“……还没来得及……就……”的用法。句意是“我还没来得及说一句话，他就冲出了房间”。 四、表示“在……之前就……”。这时主句与before从句中的两个动作按时间先后依次发生。 It was evening______ we reached the little town of Winchester. A. that B. until C. since D. before 解析：答案为D。本题考查连词before表示“在……之前就……”的用法。句意是“我们到达小镇Winchester 之前就已经是傍晚时分了”。 五、表示“趁……”，“等到……”，或“没等……就…… ”等。

Before用作连词时

Before用作连词时，意思是“在……之前”。(注：此为核心概念，其它皆是繁衍派生之义)其实，它引导状语从句时，在不同的句式中以及汉英表达习惯的不同，before含有不同的含义和用法。（注：翻译意思不同而已）。（注：当主从句动作有先有后的时候，用before，after居多，但其他的呢？居多是多少？有什么使用条件？） （最容易错的就是和when难以区分，这主要是受到中文翻译法的影响，但如何辨别？） 从历年的高考试题可以看出，before是高考考查的热点词汇之一。为了帮助大家掌握，现就对它的用法归纳如下： 一、表示“在……之后……才”。副词“才”在汉语中强调某事发生得晚或慢。如果在含有before从句的复合句中，强调从句动作发生得晚或慢时，就可以应用这种译法。 【典型考例】 The American Civil War lasted four years _______ the North won in the end.(2005广东) A. after B. before C. when D. then 解析：答案为B。本题考查连词before表示“在……之后才……”之的用法，根据本句含义“美国南北战争持续了四年，北方才最终取得胜利”，可知本题应选B。 （注：这种题目比较难，因为学生如果用中文翻译成“当”when的时候，句子也读得顺，如果来明显区分？） 二、表示“……还没来得及……就……”。目的在于强调从句动作发生之前，主句动作已发生。 【典型考例】 —Why didn't you tell him about the meeting? ( 2006四川卷) — He rushed out of the room _________ I could say a word. A. before B. until C. when D. after 解析：答案为A。本题考查连词before表示“……还没来得及……就……”的用法。句意是“我还没来得及说一句话，他就冲出了房间”。 三、表示“在……之前就……”。这时主句与before从句中的两个动作按时间

Itsinceitbefore句型和练习

2. It will be two years the economic situation improves. It+be+ 时间 +before/since/when/that 句型辨析 I. since 1.It is/has bee n+ 时间段+si nee sb did sth 某个动作发生持续多久 eg:It is/has been three years since he finished the work. 自从他完成这项工作已经三年了 . 2. 该句型中若 since 后跟延续性动词，要翻译成否定含义 , 即“没做某事已经多 久了”. eg:It has been three years since he worked here. 他不在这工作已经三年 了. It has been three years since he smoked. 他已经戒烟三年了 . 但是：It has been three years since he began to smoke. 他吸烟有三年了。 II .before. 1.It was/will be+ 时间段+before... 过多长时间将发生某动作或事情；或过 了多久发生了某事或动作。 eg:It was three years before he finished the work. 项工作. It will be three years before he finishes the work. 这项工 作 . 2.It won't be/take long before... 不久就会… eg:It won't be long before he finishes the work. 作. III when. when 没有固定与It is …连用的句型.when 可表示时间点或时间段，因此从句 中短暂性动词或延续性动词均可用 .when 还可作并列连词，表示突然发生一个 动作, 等于 and at that time. 常用句型 : 1 主语 +was/were doing whe n... 2 主语 +was/were about to do whe n... It+be+ 时间 +before/si nce/whe n/that 重要考点练习 It +be+时间+before/s in ce/whe n/that 是高考中每年必考的重要考点，而学生却对这个句型 中几个关联词的选择把握不准，造成失分。我在试题讲解的过程中设计了以下几个小题， 让学生去分析，整理，归纳，效果很好。 1. It was two years _______ h e realized the truth. 3. It was two years later _______ he realized the truth. 他花了三年才完成这 他得花三年才能完成 他不久就会完成这项工

It is +时间+since when before

It+be+时间+before/since/when/that句型辨析 I since 1. 翻译 “It is/ has been + 时间段 + since从句” (1) 当从句谓语动词为非延续性动词时，表示这段时间从该动作开始时算起，即“自从做……以来已经多久了”。 (2) 当从句谓语动词为延续性动词时，表示这段时间从动作结束时算起，即“自从不做……以来已经多久了”。 It is two years since he joined the army. 他参军两年了。 (从参军那一刻算起) It is two years since he was a soldier. 他退役两年了。 (从他不再是士兵算起) 2. 时态 主句为现在时（一般或完成），从句都是一般过去时。 主句为过去式（一般性都用was就够了），从句都是过去完成时 II before 1. 翻译 It was/will be+时间段+before... 过多长时间将发生某动作或事情；或过了多久发生了某事或动作。 It was three years before he finished the work.他花了三年才完成这项工作. It will be three years before he finishes the work.他得花三年才能完成这项工作. 2.It won't be/take long before...不久就会… It won't be long before he finishes the work.他不久就会完成这项工作. 2. 时态 主句为过去式（一般性都用was就够了），从句用过去时 主句为将来时，从句用现在时（用一般现在时表示将来） III when 1. 翻译 It is + 时间点+ when… 当发生什么的时候是什么时候… It was one o’clock when he came in . 2. 时态 主句是什么时态，从句就是什么时态 3.常考 与强调句的区别 It was five o'clock when we arrived at the small mountain village. It was at five o'clock that we arrived at the small mountain village.

before 用法

before句型辨析与解析| It + will be + 时间段+ before等表示“在……之后……才”的句型总结 一、用于句型“It + will be + 时间段+ before...”句型中，表示“要过多久才…”，也可用于“It + may be + 时间段+ before...”，表示“也许要过多久才……”。Before 后的句子中用一般现在时态。 其否定形式“It will/would not be +时间段+ before…”表示“不久就……，过不了多久就……”。 【典型考例】 （1）The field research will take Joan and Paul about five months; it will be a long time _____ we meet them again.（2007安徽卷） A. after B. before C. since D. when （2）—How long do you think it will be ______China sends a manned spaceship to the moon? （2006福建卷） —Perhaps two or three years. A. when B. until C. that D. before （3）It ________ long before we _______ the result of the experiment.( 上海春招2002) A. will not be...will know B. is...will know C. will not be...know D. is...know (4) Scientists say it may be five or six years_________ it is possible to test this medicine on human patients. （2004福建） A. since B. after C. before D. when 解析：答案为BDCC。考题 （1）(2)before 用于肯定的“It + will be + 时间段+ before...”句型中，表示“要过多久…才…”。 （3）before在本题中用于否定句,意为“过不了多久就会……”,状语从句要用一般现在时代替一般将来时，可知C项为正确答案,句意是:要不了多久我们就会知道试验的结果了。（4）宾语从句中含有句型“It + may be + 时间段+ before...”，表示“也许要过多久才……”，故选择答案C。 二、用于句型“it was +时间段+ before …” 表示“过了（多长时间）才……”。其否定形式“ it was not +时间段+ before …” 意为“不久就……”, “没过（多长时间）就……”。 【典型考例】 It was some time ___________we realized the truth. （2005山东） A. when B. until C. since D. before 解析：答案为D。before用于句型“it was +时间段+ before …” 表示“过了（多长时间）才……”。该题题意是“过了一段时间我们才意识到事情的真相”。故正确答案为C项。 表示“在……之后……才”。副词“才”在汉语中强调某事发生得晚或慢。如果在含有before从句的复合句中，强调从句动作发生得晚或慢时，就可以应用这种译法。 【典型考例】 The American Civil War lasted four years _______ the North won in the end.(2005广东) A. after B. before C. when D. then