7.Requirements Engineering

合集下载

《软件工程》习题汇锦

《软件工程》习题汇锦一、单项选择题提示：在每小题列出的四个备选项中只有一个是符合题目要求的，请将其代码填写在下表中。

错选、多选或未选均无分.1. ( ）If a system is being developed where the customers are not sure of what theywant, the requirements are often poorly defined。

Which of the following would be an appropriate process model for this type of development?（A）prototyping（B）waterfall（C)V-model（D）spiral2. （)The project team developing a new system is experienced in the domain.Although the new project is fairly large, it is not expected to vary much from applications that have been developed by this team in the past. Which process model would be appropriate for this type of development？（A）prototyping（B）waterfall（C）V-model（D）spiral3. （）Which of the items listed below is not one of the software engineering layers?(A）Process（B）Manufacturing（C）Methods（D)T ools4. （)Which of these are the 5 generic software engineering framework activities？（A）communication，planning，modeling，construction，deployment（B) communication, risk management, measurement，production, reviewing(C）analysis，designing，programming, debugging, maintenance（D）analysis, planning，designing，programming，testing5. （）The incremental model of software development is（A）A reasonable approach when requirements are well defined.(B）A good approach when a working core product is required quickly。

Requirements engineering (RE) is concerned with the identification

Requirements Engineering in the Year 00: A Research PerspectiveAxel van LamsweerdeDépartement d’Ingénierie InformatiqueUniversité catholique de LouvainB-1348 Louvain-la-Neuve (Belgium)avl@info.ucl.ac.beABSTRACTRequirements engineering(RE)is concerned with the iden-tiﬁcation of the goals to be achieved by the envisioned sys-tem,the operationalization of such goals into services and constraints,and the assignment of responsibilities for the resulting requirements to agents such as humans,devices, and software.The processes involved in RE include domain analysis,elicitation,speciﬁcation,assessment, negotiation,documentation,and evolution.Getting high-quality requirements is difﬁcult and critical.Recent surveys have conﬁrmed the growing recognition of RE as an area of utmost importance in software engineering research and practice.The paper presents a brief history of the main concepts and techniques developed to date to support the RE task,with a special focus on modeling as a common denominator to all RE processes.The initial description of a complex safety-critical system is used to illustrate a number of current research trends in RE-speciﬁc areas such as goal-oriented requirements elaboration,conﬂict management,and the handling of abnormal agent behaviors.Opportunities for goal-based architecture derivation are also discussed together with research directions to let theﬁeld move towards more disciplined habits.1. INTRODUCTIONSoftware requirements have been repeatedly recognized during the past25years to be a real problem.In their early empirical study,Bell and Thayer observed that inadequate, inconsistent,incomplete,or ambiguous requirements are numerous and have a critical impact on the quality of the resulting software[Bel76].Noting this for different kinds of projects,they concluded that“the requirements for a system do not arise naturally;instead,they need to be engineered and have continuing review and revision”.Boehm esti-mated that the late correction of requirements errors could cost up to200times as much as correction during such requirements engineering[Boe81].In his classic paper on the essence and accidents of software engineering,Brooks stated that“the hardest single part of building a sofware system is deciding precisely what to build...Therefore,the most important function that the software builder performs for the client is the iterative extraction and reﬁnement of the product requirements”[Bro87].In her study of software errors in NASA’s V oyager and Galileo programs,Lutz reported that the primary cause of safety-related faults was errors in functional and interface requirements [Lut93]. Recent studies have conﬁrmed the requirements problem on a much larger scale.A survey over8000projects under-taken by350US companies revealed that one third of the projects were never completed and one half succeeded only partially,that is,with partial functionalities,major cost overruns,and signiﬁcant delays[Sta95].When asked about the causes of such failure executive managers identifed poor requirements as the major source of problems(about half of the responses)-more speciﬁcally,the lack of user involve-ment(13%),requirements incompleteness(12%),changing requirements(11%),unrealistic expectations(6%),and unclear objectives(5%).On the European side,a recent sur-vey over3800organizations in17countries similarly con-cluded that most of the perceived software problems are in the area of requirements speciﬁcation(>50%)and require-ments management (50%) [ESI96].Improving the quality of requirements is thus crucial.But it is a difﬁcult objective to achieve.To understand the reason one shouldﬁrst deﬁne what requirements engineering is really about.The oldest deﬁnition already had the main ingredients.In their seminal paper,Ross and Schoman stated that“require-ments deﬁnition is a careful assessment of the needs that a system is to fulﬁll.It must say why a system is needed,based on current or foreseen conditions,which may be internal operations or an external market.It must say what system features will serve and satisfy this context.And it must say how the system is to be constructed”[Ros77b].In other words,requirements engineering must address the contex-tual goals why a software is needed,the functionalities the software has to accomplish to achieve those goals,and the constraints restricting how the software accomplishing those functions is to be designed and implemented.Such goals,functions and constraints have to be mapped to pre-cise speciﬁcations of software behavior;their evolution over time and across software families has to be coped with as well [Zav97b].This deﬁnition suggests why the process of engineering requirements is so complex.•The scope is fairly broad as it ranges from a world of human organizations or physical laws to a technical arti-fact that must be integrated in it;from high-level objec-tives to operational prescriptions;and from informal to formal.The target system is not just a piece of software,Invited paper for ICSE’2000 - To appear inLimerick, June 2000, ACM PressProc. 22nd International Conference on Software Engineering,but also comprises the environment that will surround it; the latter is made of humans,devices,and/or other soft-ware.The whole system has to be considered under many facets,e.g.,socio-economic,physical,technical,opera-tional, evolutionary, and so forth.•There are multiple concerns to be addressed beside func-tional ones-e.g.,safety,security,usability,ﬂexibility,per-formance,robustness,interoperability,cost, maintainability,and so on.These non-functional concerns are often conﬂicting.•There are multiple parties involved in the requirements engineering process,each having different background, skills,knowledge,concerns,perceptions,and expression means-namely,customers,commissioners,users,domain experts,requirements engineers,software developers,or system maintainers.Most often those parties have conﬂict-ing viewpoints.•Requirement speciﬁcations may suffer a great variety of deﬁciencies[Mey85].Some of them are errors that may have disastrous effects on the subsequent development steps and on the quality of the resulting software product-e.g.,inadequacies with respect to the real needs,incom-pletenesses,contradictions,and ambiguities;some others areﬂaws that may yield undesired consequences(such as waste of time or generation of new errors)-e.g.,noises, forward references,overspeciﬁcations,or wishful thinking.•Requirements engineering covers multiple intertwined activities.–Domain analysis:the existing system in which the soft-ware should be built is studied.The relevant stakehold-ers are identiﬁed and interviewed.Problems and deﬁciencies in the existing system are identiﬁed;oppor-tunities are investigated;general objectives on the target system are identiﬁed therefrom.–Elicitation:alternative models for the target system are explored to meet such objectives;requirements and assumptions on components of such models are identi-ﬁed,possibly with the help of hypothetical interaction scenarios.Alternative models generally deﬁne different boundaries between the software-to-be and its environ-ment.–Negotiation and agreement:the alternative require-ments/assumptions are evaluated;risks are analyzed;"best"tradeoffs that receive agreement from all parties are selected.–Speciﬁcation:the requirements and assumptions are for-mulated in a precise way.–Speciﬁcation analysis:the speciﬁcations are checked for deﬁciencies(such as inadequacy,incompleteness or inconsistency)and for feasibility(in terms of resources required, development costs, and so forth).–Documentation:the various decisions made during the process are documented together with their underlying rationale and assumptions.–Evolution:the requirements are modiﬁed to accommo-date corrections,environmental changes,or new objec-tives.Given such complexity of the requirements engineering pro-cess,rigorous techniques are needed to provide effective support.The objective of this paper is to provide:a brief his-tory of25years of research efforts along that way;a concrete illustration of what kind of techniques are available today; and directions to be explored for requirements engineering to become a mature discipline.The presentation will inevitably be biased by my own work and background.Although the area is inherently interdisci-plinary,I will deliberately assume a computing science viewpoint here and leave the socological and psychological dimensions aside(even though they are important).In partic-ular,I will not cover techniques for ethnographic observation of work environments,interviewing,negotiation,and so forth.The interested reader may refer to[Gog93,Gog94]for a good account of those dimensions.A comprehensive,up-to-date survey on the intersecting area of information model-ing can be found in [Myl98].2. THE FIRST 25 YEARS: A FEW RESEARCHMILESTONESRequirements engineering addresses a wide diversity of domains(e.g.,banking,transportation,manufacturing),tasks (e.g.,administrative support,decision support,process con-trol)and environments(e.g.,human organizations,physical phenomena).A speciﬁc domain/task/environment may require some speciﬁc focus and dedicated techniques.This is in particular the case for reactive systems as we will see after reviewing the main stream of research..Modeling appears to be a core process in requirements engi-neering.The existing system has to be modelled in some way or another;the alternative hypothetical systems have to be modelled as well.Such models serve as a basic common interface to the various activities above.On the one hand, they result from domain analysis,elicitation,speciﬁcation analysis,and negotiation.On the other hand,they guide fur-ther domain analysis,elicitation,speciﬁcation analysis,and negotiation.Models also provide the basis for documenta-tion and evolution.It is therefore not surprising that most of the research to date has been devoted to techniques for mod-eling and speciﬁcation.The basic questions that have been addressed over the years are:•what aspects to model in the why-what-how range,•how to model such aspects,•how to deﬁne the model precisely,•how to reason about the model.The answer to theﬁrst question determines the ontology of conceptual units in terms of which models will be built-e.g., data,operations,events,goals,agents,and so forth.The answer to the second question determines the structuring relationships in terms of which such units will be composed and linked together-e.g.,input/output,trigger,generaliza-tion,reﬁnement,responsibility assignment,and so forth.The answer to the third question determines the informal,semi-formal,or formal speciﬁcation technique used to deﬁne the required properties of model components precisely.The answer to the fourth question determines the kind of reason-ing technique available for the purpose of elicitation,speciﬁ-cation, and analysis.The early daysThe seminal paper by Ross and Schoman opened theﬁeld [Ros97b].Not only did this paper comprehensively explain the scope of requirements engineering;it also suggested goals,viewpoints,data,operations,agents,and resources as potential elements of an ontology for RE.The companion paper introduced SADT as a speciﬁc modeling technique [Ros97a].This technique was a precursor in many respects. It supported multiple models linked through consistency rules-a model for data,in which data are deﬁned by produc-ing/consuming operations;a model for operations,in which operations are deﬁned by input/output data;and a data/oper-ation duality principle.The technique was ontologically richer than many techniques developed afterwards.In addi-tion to data and operations,it supported some rudimentary representation of events,triggering operations,and agents responsible for them.The technique also supported the step-wise reﬁnement of global models into more detailed ones-an essential feature for complex models.SADT was a semi-formal technique in that it could only support the formaliza-tion of the declaration part of the system under consideration -that is,what data and operations are to be found and how they relate to each other;the requirements on the data/opera-tions themselves had to be asserted in natural language.The semi-formal language,however,was graphical-an essential feature for model communicability.Shortly after,Bubenko introduced a modeling technique for capturing entities and events.Formal assertions could be written to express requirements about them,in particular, temporal constraints[Bub80].At that time it was already recognized that such entities and events had to take part in the real world surrounding the software-to-be [Jac78]. Other semi-formal techniques were developed in the late seventies,notably,entity-relationship diagrams for the mod-eling of data[Che76],structured analysis for the stepwise modeling of operations[DeM78],and state transition dia-grams for the modeling of user interaction[Was79].The popularity of those techniques came from their simplicity and dedication to one speciﬁc concern;the price to pay was their fairly limited scope and expressiveness,due to poor underlying ontologies and limited structuring facilities. Moreover they were rather vaguely deﬁned.People at that time started advocating the beneﬁts of precise and formal speciﬁcations,notably,for checking speciﬁcation adequacy through prototyping [Bal82].RML brought the SADT line of research signiﬁcantly further by introducing rich structuring mechanisms such as generali-zation,aggregation and classiﬁcation[Gre82].In that sense it was a precursor to object-oriented analysis techniques. Those structuring mechanisms were applicable to three kinds of conceptual units:entities,operations,and con-straints.The latter were expressed in a formal assertion lan-guage providing,in particular,built-in constructs for temporal referencing.That was the time where progress in database modeling[Smi77],knowledge representation [Bro84,Bra85],and formal state-based speciﬁcation [Abr80]started penetrating ourﬁeld.RML was also proba-bly theﬁrst requirements modeling language to have a for-mal semantics,deﬁned in terms of mappings toﬁrst-order predicate logic [Gre86].Introducing agentsA next step was made by realizing that the software-to-be and its environment are both made of active components. Such components may restrict their behavior to ensure the constraints they are assigned to.Feather’s seminal paper introduced a simple formal framework for modeling agents and their interfaces,and for reasoning about individual choice of behavior and responsibility for constraints[Fea87]. Agent-based reasoning is central to requirements engineer-ing since the assignment of responsibilities for goals and constraints among agents in the software-to-be and in the environment is a main outcome of the RE process.Once such responsibilities are assigned the agents have contractual obligations they need to fulﬁll[Fin87,Jon93,Ken93]. Agents on both sides of the software-environment boundary interact through interfaces that may be visualized through context diagrams [War85].Goal-based reasoningThe research efforts so far were in the what-how range of requirements engineering.The requirements on data and operations were just there;one could not capture why they were there and whether they were sufﬁcient for achieving the higher-level objectives that arise naturally in any require-ments engineering process[Hic74,Mun81,Ber91,Rub92]. Yue was probably theﬁrst to argue that the integration of explicit goal representations in requirements models pro-vides a criterion for requirements completeness-the require-ments are complete if they are sufﬁcient to establish the goal they are reﬁning[Yue87].Broadly speaking,a goal corre-sponds to an objective the system should achieve through cooperation of agents in the software-to-be and in the envi-ronment.Two complementary frameworks arose for integrating goals and goal reﬁnements in requirements models:a formal framework and a qualitative one.In the formal framework [Dar91],goal reﬁnements are captured through AND/OR graph structures borrowed from problem reduction tech-niques in artiﬁcial intelligence[Nil71].AND-reﬁnement links relate a goal to a set of subgoals(called reﬁnement); this means that satisfying all subgoals in the reﬁnement is a sufﬁcient condition for satisfying the goal.OR-reﬁnement links relate a goal to an alternative set of reﬁnements;this means that satisfying one of the reﬁnements is a sufﬁcient condition for satisfying the goal.In this framework,a con-ﬂict link between goals is introduced when the satisfaction of one of them may preclude the satisfaction of the others. Operationalization links are also introduced to relate goals to requirements on operations and objects.In the qualitative framework[Myl92],weaker versions of such link types are introduced to relate“soft”goals[Myl92].The idea is that such goals can rarely be said to be satisﬁed in a clear-cut sense.Instead of goal satisfaction,goal satisﬁcing is intro-duced to express that lower-level goals or requirements are expected to achieve the goal within acceptable limits,ratherthan absolutely.A subgoal is then said to contribute partially to the goal,regardless of other subgoals;it may contribute positively or negatively.If a goal is AND-decomposed into subgoals and all subgoals are satisﬁced,then the goal is sat-isﬁceable;but if a subgoal is denied then the goal is deniable. If a goal contributes negatively to another goal and the former is satisﬁced, then the latter is deniable.The formal framework gave rise to the KAOS methodology for eliciting,specifying,and analyzing goals,requirements, scenarios,and responsibility assignments[Dar93].An optional formal assertion layer was introduced to support various forms of formal reasoning.Goals and requirements on objects are formalized in a real-time temporal logic [Man92,Koy92];one can thereby prove that a goal reﬁne-ment is correct and complete,or complete such a reﬁnement [Dar96].One can also formally detect conﬂicts among goals [Lam98b]or generate high-level exceptions that may prevent their achievement[Lam98a].Requirements on operations are formalized by pre-,post-,and trigger conditions;one can thereby establish that an operational requirement“imple-ments”higher-level goals[Dar93],or infer such goals from scenarios [Lam98c].The qualitative framework gave rise to the NFR methodol-ogy for capturing and evaluating alternative goal decomposi-tions.One may see it as a cheap alternative to the formal framework,for limited forms of goal-based reasoning,and as a complementary framework for high-level goals that can-not be formalized.The labelling procedure in[Myl92]is a typical example of qualitative reasoning on goals speciﬁed by names,parameters,and degrees of satisﬁcing/denial by child goals.This procedure determines the degree to which a goal is satisﬁced/denied by lower-level requirements,by propagating such information along positive/negative sup-port links in the goal graph.The strength of those goal-based frameworks is that they do not only cover functional goals but also non-functional ones; the latter give rise to a wide range of non-functional require-ments.For example,[Nix93]showed how the NFR frame-work could be used to qualitatively reason about performance requirements during the RE and design phases. Informal analysis techniques based on similar reﬁnement trees were also proposed for speciﬁc types of non-functional requirements,such as fault trees[Lev95]and threat trees [Amo94]for exploring safety and security requirements, respectively.Goal and agent models can be integrated through speciﬁc links.In KAOS,agents may be assigned to goals through AND/OR responsibility links;this allows alternative bound-aries to be investigated between the software-to-be and its environment.A responsibility link between an agent and a goal means that the agent can commit to perform its opera-tions under restricted pre-,post-,and trigger conditions that ensure the goal[Dar93].Agent dependency links were deﬁned in[YuM94,Yu97]to model situations where an agent depends on another for a goal to be achieved,a task to be accomplished,or a resource to become available.For each kind of dependency an operator is deﬁned;operators can be combined to deﬁne plans that agents may use to achieve goals.The purpose of this modeling is to support the veriﬁcation of properties such as the viability of an agent's plan or the fulﬁlment of a commitment between agents. Viewpoints, facets, and conﬂictsBeside the formal and qualitative reasoning techniques above,other work on conﬂict management has emphasized the need for handling conﬂicts at the goal level.A procedure was suggested in[Rob89]for identifying conﬂicts at the requirements level and characterizing them as differences at goal level;such differences are resolved(e.g.,through nego-tiation)and then down propagated to the requirements level. In[Boe95],an iterative process model was proposed in which(a)all stakeholders involved are identiﬁed together with their goals(called win conditions);(b)conﬂicts between these goals are captured together with their associ-ated risks and uncertainties;and(c)goals are reconciled through negotiation to reach a mutually agreed set of goals, constraints, and alternatives for the next iteration.Conﬂicts among requirements often arise from multiple stakeholders viewpoints[Eas94].For sake of adequacy and completeness during requirements elicitation it is essential that the viewpoints of all parties involved be captured and eventually integrated in a consistent way.Two kinds of approaches have emerged.They both provide constructs for modeling and specifying requirements from different view-points in different notations.In the centralized approach,the viewpoints are translated into some logic-based“assembly”language for global analysis;viewpoint integration then amounts to some form of conjunction[Nis89,Zav93].In the distributed approach,viewpoints have speciﬁc consistency rules associated with them;consistency checking is made by evaluating the corresponding rules on pairs of viewpoints [Nus94].Conﬂicts need not necessarily be resolved as they arise;different viewpoints may yield further relevant infor-mation during elicitation even though they are conﬂicting in some respect.Preliminary attempts have been made to deﬁne a paraconsistent logical framework allowing useful deduc-tions to be made in spite of inconsistency [Hun98]. Multiparadigm speciﬁcation is especially appealling for requirements speciﬁcation.In view of the broad scope of the RE process and the multiplicity of system facets,no single language will ever serve all purposes.Multiparadigm frame-works have been proposed to combine multiple languages in a semantically meaningful way so that different facets can be captured by languages thatﬁt them best.OMT’s combina-tion of entity-relationship,dataﬂow,and state transition dia-grams was among theﬁrst attempts to achieve this at a semi-formal level[Rum91].The popularity of this modeling tech-nique and other similar ones led to the UML standardization effort[Rum99].The viewpoint construct in[Nus94]pro-vides a generic mechanism for achieving such combinations. Attempts to integrate semi-formal and formal languages include[Zav96],which combines state-based speciﬁcations [Pot96]andﬁnite state machine speciﬁcations;and[Dar93], which combines semantic nets[Qui68]for navigating through multiple models at surface level,temporal logic for the speciﬁcation of the goal and object models[Man92, Koy92],and state-based speciﬁcation[Pot96]for the opera-tion model.Scenario-based elicitation and validationEven though goal-based reasoning is highly appropriate for requirements engineering,goals are sometimes hard to elicit. Stakeholders may have difﬁculties expressing them in abstracto.Operational scenarios of using the hypothetical system are sometimes easier to get in theﬁrst place than some goals that can be made explicit only after deeper understanding of the system has been gained.This fact has been recognized in cognitive studies on human problem solving[Ben93].Typically,a scenario is a temporal sequence of interaction events between the software-to-be and its environment in the restricted context of achieving some implicit purpose(s).A recent study on a broader scale has conﬁrmed scenarios as important artefacts used for a variety of purposes,in particular in cases when abstract modeling fails[Wei98].Much research effort has therefore been recently put in this direction[Jar98].Scenario-based techniques have been proposed for elicitation and for valida-tion-e.g.,to elicit requirements in hypothetical situations [Pot94];to help identify exceptional cases[Pot95];to popu-late more abstract conceptual models[Rum91,Rub92];to validate requirements in conjunction with prototyping [Sut97],animation[Dub93],or plan generation tools [Fic92]; to generate acceptance test cases [Hsi94].The work on deﬁciency-driven requirements elaboration is especially worth pointing out.A system there is speciﬁed by a set of goals(formalized in some restricted temporal logic), a set of scenarios(expressed in a Petri net-like language), and a set of agents producing restricted scenarios to achieve the goals they are assigned to.The technique is twofold:(a) detect inconsistencies between scenarios and goals;(b) apply operators that modify the speciﬁcation to remove the inconsistencies.Step(a)is carried out by a planner that searches for scenarios leading to some goal violation. (Model checkers might probably do the same job in a more efﬁcient way[McM93,Hol97,Cla99].)The operators offered to the analyst in Step(b)encode heuristics for speci-ﬁcation debugging-e.g.,introduce an agent whose responsi-bility is to prevent the state transitions that are the last step in breaking the goal.There are operators for introducing new types of agents with appropriate responsibilities,splitting existing types,introducing communication and synchroniza-tion protocols between agents,weakening idealized goals, and so forth.The repeated application of deﬁciency detec-tion and debugging operators allows the analyst to explore the space of alternative models and hopefully converge towards a satisfactory system speciﬁcation.The problem with scenarios is that they are inherently par-tial;they raise a coverage problem similar to test cases,mak-ing it impossible to verify the absence of errors.Instance-level trace descriptions also raise the combinatorial explo-sion problem inherent to the enumeration of combinations of individual behaviors.Scenarios are generally procedural, thus introducing risks of overspeciﬁcation.The description of interaction sequences between the software and its envi-ronment may force premature choices on the precise bound-ary between st but not least,scenarios leave required properties about the intended system implicit,in the same way as safety/liveness properties are implicit in a pro-gram trace.Work has therefore begun on inferring goal/ requirement speciﬁcations from scenarios in order to support more abstract, goal-level reasoning [Lam98c].Back to groundworkIn parallel with all the work outlined above,there has been some more fundamental work on clarifying the real nature of requirements[Jac95,Par95,Zav97].This was motivated by a certain level of confusion and amalgam in the literature on requirements and software speciﬁcations.At about the same time,Jackson and Parnas independently made aﬁrst impor-tant distinction between domain properties(called indicative in[Jac95]and NAT in[Par95])and requirements(called optative in[Jac95]and REQ in[Par95]).Such distinction is essential as physical laws,organizational policies,regula-tions,or deﬁnitions of objects or operations in the environ-ment are by no means requirements.Surprisingly,the vast majority of speciﬁcation languages existing to date do not support that distinction.A second important distinction made by Jackson and Parnas was between(system)require-ments and(software)speciﬁcations.Requirements are for-mulated in terms of objects in the real world,in a vocabulary accessible to stakeholders[Jac95];they capture required relations between objects in the environment that are moni-tored and controlled by the software,respectively[Par95]. Software speciﬁcations are formulated in terms of objects manipulated by the software,in a vocabulary accessible to programmers;they capture required relations between input and output software objects.Accuracy goals are non-func-tional goals requiring that the state of input/output software objects accurately reﬂect the state of the corresponding mon-itored/controlled objects they represent[Myl92,Dar93]. Such goals often are to be achieved partly by agents in the environments and partly by agents in the software.They are often overlooked in the RE process;their violation may lead to major failures[LAS93,Lam2Ka].A further distinction has to be made between requirements and assumptions. Although they are both optative,requirements are to be enforced by the software whereas assumptions can be enforced by agents in the environment only[Lam98b].If R denotes the set of requirements,As the set of assumptions,S the set of software speciﬁcations,Ac the set of accuracy goals,and G the set of goals,the following satisfaction rela-tions must hold:S, Ac, D|== R with S, Ac, D|=/=falseR, As, D|== G with R, As, D|=/=falseThe reactive systems lineIn parallel with all the efforts discussed above,a dedicated stream of research has been devoted to the speciﬁc area of reactive systems for process control.The seminal paper here was based on work by Heninger,Parnas and colleagues while reengineering theﬂight software for the A-7aircraft [Hen80].The paper introduced SCR,a tabular speciﬁcation technique for specifying a reactive system by a set of parallel ﬁnite-state machines.Each of them is deﬁned by different types of mathematical functions represented in tabular for-mat.A mode transition table deﬁnes a mode(i.e.a state)as a transition function of a mode and an event;an event table deﬁnes an output variable(or auxiliary quantity)as a func-。

工程常用专业英语

平整度
flatness
同心度
concentricity
同轴度
axiality
平行度
parallelism
圆度
roundness
平面度
planeness
随机的
random
不平
uneven
空心
hollow
同心
concentricity
偏心
eccentric
表面粗糙度
surface roughness
尺寸公差
基准
datum
水平基准线
horizontal reference line
精度
accuracy
余量
allowance
组件
assemble
分装件
subassemble
包装
package
外协件
cooperation
外购件
purchase part
备件
spare part
裸装件
nudes
散装件
odd lot, odds & ends
清除
decontaminate
失败，故障
failure
断裂
fracture
塌陷，凹陷
collapse
中断
discontinuity
裂缝
crack
发裂
flaw
龟裂
fissure
毛细裂纹
capillary crack
起始裂纹
incipient crack
断层裂纹
fault fissure
积水
stagnant water
保证
assure

建筑施工质量管理体系外文翻译参考文献

建筑施工质量管理体系外文翻译参考文献1. GB/T -2016 英文名称：Quality management systems--Requirements《质量管理体系要求》2. GB/T -2016 英文名称：Quality management systems--Guidelines for the application of ISO 9001:2015《质量管理体系应用指南》3. GB -2013 英文名称：Code for construction quality acceptance of building engineering《建筑工程质量验收规范》4. GB -2011 英文名称：Code for acceptance of constructional quality of masonry engineering《砌体工程施工质量验收规范》5. GB -2010 英文名称：Code for design of concrete structures《混凝土结构设计规范》6. GB -2013 英文名称：Standard for building drawing standardization《建筑施工图件编制规范》7. GB -2001 英文名称：Code for acceptance of construction quality of pile foundation engineering《桩基工程施工质量验收规范》8. /T 11-2017 英文名称：Technical specification for concrete structure of tall building《高层建筑混凝土结构技术规范》9. 63-2013 英文名称：Technical specification for strengthening of building structures using carbon fiber reinforced plastics 《建筑结构加固碳纤维布增强复合材料技术规范》10. 81-2002 英文名称：Technical specification for application of sprayed mortar in building construction and acceptance of quality 《建筑喷涂砂浆工程施工及质量验收技术规定》。

Requirements_Definition

Requirements Definition How we should (attempt to) specify exactly what is needed before we start designing12Requirements DefinitionRequirements describe the necessary functions and features of the system we are to conceive, design,implement and operate.PerformanceScheduleCost Other Characteristics (e.g. lifecycle properties)Requirements are often organized hierarchically At a high level requirements focus on what should be achieved, not how to achieve itRequirements are specified at every level, from the overall system to each hardware and software component.Critically important to establish properly4Importance of TechnicalRequirements Development (2/2)Provides a baseline for verificationOrganizations can develop their validation and verification plans much more productively from a good requirements document.The requirements document provides a baseline against which compliance can be measured.The requirements are also used to provide the stakeholders with a basis for acceptance of thesystem.Facilitates transfer of the product tonew users or new machines. Serve as a basis for later enhancement or alteration of the finished product.MOE, MOP, TPMRelationship8Technical Requirements Definition Best Practice Process Flow DiagramActivitiesInputOutput910Requirements AllocationDecompose system requirements into lower levels of design.Define all the lower level functions which must be performed to satisfy the requirement Create architecture of sub-components to provide thosefunctionsAllocate a level of performance to each lower level functionSpecify interface requirements to other sub-systems Closure -Ensure that satisfaction of the set of requirements at the lower level will guarantee satisfaction of the higher level requirement .Requirements Analysis. The requirementsanalysis is this: First we determine thefunctions that must be accomplished for thesubsystem to meet its requirement. Then wecreate an architecture for the subsystem madeup of sub-components and define therequirements for each sub-component. Willthis set of requirements ensure satisfaction ofthe requirements at the higher level? Is the setboth necessary and sufficient? Then we iteratethe allocation of requirements to optimize thedesign. As we proceed down into therequirement/architecture tree, we may learnthat we need to revise an upper level of thearchitecture, using different subsystems orrequirement allocation to optimize the overalldesign.11Requirement Allocation Process.Requirements are always developed fromthe top down. We begin with the top-levelfunctional requirements and decompose itinto what is necessary to achieve itsfunctional capability. Then we specify whateach sub-component will have to do, howwell it will have to function to provide thatcapability. This process often includesnegotiation and balancing betweensubsystems to minimize the overall effort.13Sometimes it is necessary to push back onrequirements when the cost to achieve thestated capability is too great. We also prioritizerequirements when not all requirements can beachieved. The set of subsystems, togetherwith the requirements necessary and sufficientto guarantee the performance of the systemabove, is called an architecture. It is only onearchitecture of potentially many and may notbe optimum. We continue to iterate the designand apportionment of requirements to optimizethe design, maximizing some performancefactor or minimizing cost or schedule.1415VerificationEvery requirement must be verified to ensure that the proposed design actually satisfies the requirement byExamination, Test,Demonstration, orAnalysisRequirement documentation specifies the development phase and method of verification。

需求工程资料

需求工程资料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）：是一个不明确的功能性需求或者是一个质量需求。

需求工程的英语

需求工程的英语In the realm of software development, the art of gathering and understanding user requirements is crucial. It forms the foundation upon which successful applications are built.The process of requirement engineering involves active listening and communication, ensuring that the end product meets the users' expectations. It's about translating the users' needs into a language that developers can understand and implement.One of the key challenges in requirement engineering is managing change. As projects evolve, so do the needs of the users. It's essential to be flexible and adaptive, incorporating these changes without compromising theproject's integrity.Another aspect is prioritization. Not all requirements are created equal. Some are critical to the success of the application, while others may be less so. Identifying and prioritizing these requirements is vital for efficient resource allocation.Testing is also an integral part of requirement engineering. It ensures that the developed product aligns with the initial requirements and is fit for its intended purpose.Finally, documentation is a critical component. It serves as a reference point throughout the development process and is essential for future maintenance and updates.In essence, requirement engineering is a meticulous and dynamic process that requires a blend of technical acumen and interpersonal skills to bridge the gap between users and developers.。

工程施工质量英文缩写

In the field of engineering construction, ensuring quality is of paramount importance. To streamline communication and documentation, various abbreviations are used to refer to different aspects of construction quality assurance. Below is a comprehensive list of common abbreviations related to construction quality in engineering projects, along with their full forms and explanations.1. QA (Quality Assurance)- Full Form: Quality Assurance- Explanation: QA refers to the set of activities and processes implemented to ensure that a product or service meets the required quality standards.2. QC (Quality Control)- Full Form: Quality Control- Explanation: QC involves monitoring and controlling the quality of a product or service during the manufacturing or construction process to ensure that it meets the specified requirements.3. ISO (International Organization for Standardization)- Full Form: International Organization for Standardization- Explanation: ISO is an international standard-setting body that develops and publishes standards for quality management systems, environmental management systems, and other areas relevant to construction quality assurance.4. SS (Standard Specification)- Full Form: Standard Specification- Explanation: SS refers to a set of technical specifications that define the requirements for materials, workmanship, and design in construction projects.5. CM (Construction Management)- Full Form: Construction Management- Explanation: CM is a professional service that involves planning, organizing, and managing construction projects to ensure that they are completed on time, within budget, and to the required quality standards.6. CQA (Construction Quality Assurance)- Full Form: Construction Quality Assurance- Explanation: CQA is a systematic approach to managing the quality of construction projects, which includes planning, implementation, and control activities to ensure that the project meets the required quality standards.7. FQC (Final Quality Control)- Full Form: Final Quality Control- Explanation: FQC is the final stage of quality control, where the completed product or service is inspected to ensure that it meets the specified requirements before delivery or acceptance.8. PQ (Pre-Qualification)- Full Form: Pre-Qualification- Explanation: PQ is a process by which contractors or suppliers are evaluated to determine their capability to meet the quality requirements of a construction project.9. PQS (Pre-Qualification System)- Full Form: Pre-Qualification System- Explanation: PQS is a structured system used to assess the qualifications of contractors or suppliers before they are allowed to participate in a construction project.10. NQA (Non-Quality Assurance)- Full Form: Non-Quality Assurance- Explanation: NQA refers to any activity or process that does not contribute to the quality assurance of a construction project.11. PQI (Pre-Qualification Inspection)- Full Form: Pre-Qualification Inspection- Explanation: PQI is an inspection conducted to evaluate the compliance of contractors or suppliers with the pre-qualification requirements.12. SPC (Statistical Process Control)- Full Form: Statistical Process Control- Explanation: SPC is a method of quality control that uses statistical tools to monitor and control a process, ensuring that it operates within the desired specifications.13. PPM (Parts Per Million)- Full Form: Parts Per Million- Explanation: PPM is a unit of measurement used to express the level of impurities or defects in a material or product.14. PPM (Percentage Point Margin)- Full Form: Percentage Point Margin- Explanation: PPM refers to the margin of error allowed in a quality control process, often expressed as a percentage of the total population.15. NCR (Non-Conformance Report)- Full Form: Non-Conformance Report- Explanation: NCR is a document used to report any deviation from the required quality standards during the construction process.These abbreviations are widely used in the construction industry to facilitate communication and ensure that all stakeholders are alignedwith the quality requirements of engineering projects. By understanding these terms, professionals can effectively manage and maintain the quality of construction projects from inception to completion.。

Requirements Engineering Processes

Requirements Engineering ProcessesObjectivesy o describe the principal requirements engineering T activities and their relationshipsy T o introduce techniques for requirements elicitation and analysisd ib i lid i d h l f y T o describe requirements validation and the role of requirements reviewsy T o discuss the role of requirements management in support of other requirements engineering processesTopics coveredF ibilit t diy Feasibility studiesy Requirements elicitation and analysis y Requirements validationy Requirements managementRequirements engineeringq g g processesy The processes used for RE vary widely depending on the application domain the people involved and the the application domain, the people involved and theorganisation developing the requirements.H th b f i ti itiy However, there are a number of generic activities common to all processesly Requirements elicitation;y Requirements analysis;y Requirements validation;q g.y Requirements management.The requirements engineering processRequirementsFeasibilitystudy elicitation andanalysisRequirementsspecificationRequirements Feasibilityvalidation reportSystemmodelsd lyUser and systemrequirementsRequirementsdocumentRequirements engineeringRequirementsspecificationSystem requirementsifi i dspecification andmodelingUser requirementsspecificationBusiness requirementsspecificationSystemrequirements elicitationUserrequirementsFeasibilitystudyequ e e tselicitationPrototypingRequirementsvalidationRequirementselicitation ReviewsSystem requirementsdocumentFeasibility studiesy yy A feasibility study decides whether or not the proposed system is worthwhile.y A short focused study that checksy If the system contributes to organisational objectives;y If the system can be engineered using current technology and within budget;y If the system can be integrated with other systems that are used.y y pFeasibility study implementation(q), y Based on information assessment (what is required), information collection and report writing.Q ti f l i th i tiy Questions for people in the organisationy What if the system wasn’t implemented?y What are current process problems?yy How will the proposed system help?y What will be the integration problems?gyy Is new technology needed? What skills?y What facilities must be supported by the proposed system?Elicitation and analysisS ti ll d i t li it tiy Sometimes called requirements elicitation or requirements discovery.y Involves technical staff working with customers topp,find out about the application domain, the services that the system should provide and the system’s operational constraints.operational constraintsy May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.Problems of requirements analysisy yy Stakeholders don’t know what they really want.y Stakeholders express requirements in their own terms.ff k h ld h fly Different stakeholders may have conflicting requirements.y Organisational and political factors may influence the system requirements.system requirementsy The requirements change during the analysis process.k h ld d h bNew stakeholders may emerge and the business environment change.gThe requirements spiralRequirementsRequirements classification andorganisation prioritization and negotiationRequirements R i tdocumentationRequirements discoveryProcess activitiesy Requirements discoveryy Interacting with stakeholders to discover theirrequirements. Domain requirements are also discovered at this stage.gy Requirements classification and organisationy Groups related requirements and organises them intocoherent clusters.y Prioritisation and negotiationy Prioritising requirements and resolving requirementsconflicts.conflictsy Requirements documentationR i d d d i i hy Requirements are documented and input into the nextround of the spiral.Requirements discoveryy The process of gathering information about the proposed and existing systems and distilling the user and system requirements from thisd f h information.y Sources of information include documentation, system stakeholders and the specifications of similar systems.ATM stakeholdersB ky Bank customersy Representatives of other banksy Bank managersy Counter staffy Database administratorsS iy Security managersy Marketing departmenty Hardware and software maintenance engineers y Banking regulatorsViewpointsy Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified different stakeholders Stakeholders may be classified under different viewpoints.y This multi-perspective analysis is important as thereg y y yis no single correct way to analyse system requirements.Types of viewpointpy Interactor viewpointsy People or other systems that interact directly with thesystem. In an ATM, the customer’s and the accounty,database are interactor V Ps.py Indirect viewpointsy Stakeholders who do not use the system themselves butwho influence the requirements. In an ATM, managementq,g and security staff are indirect viewpoints.py Domain viewpointsy Domain characteristics and constraints that influence the requirements. In an ATM, an example would be standardsq,pfor inter-bank communications.Viewpoint identificationIdentif ie points usingy Identify viewpoints usingy Providers and receivers of system services;S h i di l i h h b iy Systems that interact directly with the system beingspecified;R l ti d t d dy Regulations and standards;y Sources of business and non-functional requirements;E i h h t d l d i t i th ty Engineers who have to develop and maintain the system; y Marketing and other business viewpoints;LIBSYS viewpoint hierarchyAll VPsInteractor Indirect DomainArticleLibraryLibraryUI providers Finance manager staff Users Classification system standardsSystem External Staff Students CataloguersmanagersInterviewingy In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed.ypy There are two types of interviewy Closed interviews where a pre-defined set of questions are answered.y Open interviews where there is no pre-defined agendaand a range of issues are explored with stakeholders.g pInterviews in practicepy Normally a mix of closed and open-ended interviewing.i i iy Interviews are good for getting an overall understanding of what stakeholders do and how theyg ymight interact with the system.y Interviews are not good for understanding domain qrequirementsy Requirements engineers cannot understand specificdomain terminology;gy;y Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.gEff ti i t iEffective interviewersy Interviewers should be open-minded, willing to listen to stakeholders and should not have pre listen to stakeholders and should not have pre-conceived ideas about the requirements.Th h ld h i i i h i y They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’.ScenariosS iy Scenarios are real-life examples of how a system can be used.y They should includeA d i ti f th t ti it tiy A description of the starting situation;y A description of the normal flow of events;y A description of what can go wrong;y Information about other concurrent activities;y A description of the state when the scenario finishes.LIBSYS scenario (1)Initial assumption: The user has logged on to the LIBSYS systemand has located the journal containing the copy of the article. Normal: The user selects the article to be copied. He or she is thenprompted by the system to either provide subscriber informationfor the journal or to indicate how they will pay for the article for the journal or to indicate how they will pay for the article.Alternative payment methods are by credit card or by quoting anorganisational account number.The user is then asked to fill in a copyright form that maintainsdetails of the transaction and they then submit this to the LIBSYSsystem.The copyright form is checked and, if OK, the PDF version of thearticle is downloaded to the LIBSYS working area on the user’scomputer and the user is informed that it is available. The user isd h i i f d h i i il bl h iasked to select a printer and a copy of the article is printed. If thegg p yarticle has been flagged as ‘print-only’ it is deleted from the user’ssystem once the user has confirmed that printing is complete.LIBSYS scenario (2)What can go : The user may fail to fill in the copyright form What can go wrong:The user may fail to fill in the copyright correctly. In this case, the form should be re-presented to the user for correction. If the resubmitted form is still incorrect then the user’s request for the article is rejectedfor the article is rejected.The payment may be rejected by the system. The user’s request for the article is rejected.jThe article download may fail. Retry until successful or the user terminates the session.It may not be possible to print the article. If the article is not flagged as ‘print-only’ then it is held in the LIBSYS workspace. Otherwise, the article is deleted and the user s account credited with the cost of the article.is deleted and the user’s account credited with the cost of the article.Other activities: Simultaneous downloads of other articles.System state on completion: User is logged on. The downloaded article has System state on completion:User is logged on.The downloaded article has been deleted from LIBSYS workspace if it has been flagged as print-only.Use casesUse cases are a scenario based technique in the UML y Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.describe the interaction itselfy A set of use cases should describe all possible interactions with the system.Sequence diagrams may be used to add detail to use y Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.the s stemLIBSYS use casesArticle searchAr ticle printingLibraryUserUser administration Library yStaff Supplier Catalogue servicesPrint article sequenceqitem: Ar ticle copyrightF orm:F ormmyW orkspace:W orkspacemyPrinter:Printe rUserrequestcompleterequestreturncopyright OKdeliverarticle OKiprint sendinform confirm deleteSocial and organisational factors S ft t d i i l dy Software systems are used in a social and organisational context. This can influence or even dominate the system requirements.y Social and organisational factors are not a single viewpoint but are influences on all viewpoints.G d l b i i h f b y Good analysts must be sensitive to these factors but currently no systematic way to tackle their analysis.Requirements validationd h d h hy Concerned with demonstrating that theyrequirements define the system that the customer really wants.y Requirements error costs are high so validation is very importantF f d ly Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.Requirements checkingV lidit D th t id th f tiy Validity. Does the system provide the functions which best support the customer’s needs?y Consistency. Are there any requirements conflicts?Are all functions required by the y Completeness. Are all functions required by the customer included?y Realism. Can the requirements be implemented given available budget and technologyg g gyy Verifiability. Can the requirements be checked?Requirements validation techniques Re uirements re ie sy Requirements reviewsy Systematic manual analysis of the requirements.y Prototypingy Using an executable model of the system to checkrequirements. Covered in Chapter 17.d hy T est-case generationy Developing tests for requirements to check testability.Requirements reviewsl h ld b h ld h l hy Regular reviews should be held while thegrequirements definition is being formulated.y Both client and contractor staff should be involved in reviews.reviewsy Reviews may be formal (with completed documents) or informal. Good communications betweenpdevelopers, customers and users can resolve problems at an early stage.R i h k Review checksy V ifi bilit I th i t li ti ll t t bl ?Verifiability . Is the requirement realistically testable?y Comprehensibility . Is the requirement properly understood?y Traceability . Is the origin of the requirement clearly y g q y stated?y Adaptability . Can the requirement be changed without a large impact on other requirements?Requirements managementy Requirements management is the process of managing changing requirements during the requirements engineering process and system development.i i d t d l ty Requirements are inevitably incomplete and inconsistentq g g py New requirements emerge during the process as businessneeds change and a better understanding of the system isdeveloped;p;y Different viewpoints have different requirements and these are often contradictory.are often contradictoryRequirements changey The priority of requirements from different viewpoints changes during the development process. S f fy System customers may specify requirements from a business perspective that conflict with end-user requirements.y The business and technical environment of the system changes during its development.Requirements evolutionCh d I iti lChanged understanding of pr ob lemInitial understandingof pr ob lem Changed Initialrequir ementsr equir ements TimeEnduring and volatile requirementsg q qy Enduring requirements. Stable requirements derived from the core activity of the customer organisation.E.g. a hospital will always have doctors, nurses, etc.E g a hospital will always have doctors nurses etc May be derived from domain modelsy Volatile requirements. Requirements which changeg p yduring development or when the system is in use. In a hospital, requirements derived from health-care policyRequirements management planningDuring the re uirements engineering process ou y During the requirements engineering process, you have to plan:R i id ifi iy Requirements identificationy How requirements are individually identified;A h ty A change management processy The process followed when analysing a requirements change;y Traceability policiesy The amount of information about requirements relationships thatis maintained;;y CASE tool supportpp q p g q g y The tool support required to help manage requirements change;TraceabilityT bilit i d ith th l ti hiy Traceability is concerned with the relationships between requirements, their sources and the system designy Source traceability yy Links from requirements to stakeholders who proposed theserequirements;y Requirements traceabilityy Links between dependent requirements;y Design traceabilityq gy Links from the requirements to the design;A traceability matrixReq.Req11121321222331321.1 1.2 1.32.1 2.2 2.33.1 3.2 id1.1D R1.2D D D 121.3R R2.1R D D 2.2D2.3R D3.1R 3.2RCASE t l tCASE tool supporty Requirements storagey Requirements should be managed in a secure,d dmanaged data store.g gy Change managementy The process of change management is a workflowp gprocess whose stages can be defined and informationflow between these stages partially automated.y Traceability managementy Automated retrieval of the links between requirements.Requirements change management y Should apply to all proposed changes to the requirements.P ly Principal stagesy Problem analysis. Discuss requirements problem andpropose change;hy Change analysis and costing. Assess effects of change onother requirements;th i ty Change implementation. Modify requirements documentand other documents to reflect change.and other documents to reflect changeCh tChange management IdentifiedRevised Change implementation Change analysis and costing Problem analysis &change specification problem requirementsKey pointsK i ty The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirementsi t ifi ti d i t management.y Requirements elicitation and analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation.y Systems have multiple stakeholders with different qrequirements.K i t Key pointsy Social and organisation factors influence system requirements.l d d h h k y Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability.y Business changes inevitably lead to changing g y g g requirements.y Requirements management includes planning and change management.。

工业工程的专业英语词汇

工业工程专业英语词汇industrial engineering:工业工程accredited:认可的、授权的accrue：增值acoustics：声学acquisition：并购address:处理、针对、重点提出affiliate：隶属于aggregation:总体、集合体Agile Manufacturing (AM)：敏捷制造aircraft:飞机,航空器align：适应alliance：联盟ample：足够的、充裕的anatomical：解剖的ancillary：辅助的、附属的anthropometry：人体测量学appropriation: 占用artificial material：人工材料ASME: American Society of Mechanical Engineers：美国机械工程师协会assembly line：装配线assess:评估assiduity：勤奋、刻苦audit：审计automatic pallet changer：自动托盘转换装置automation:自动化ballistic：自然带弧形的bar code：条形码b atch p ro d uctio n：批量生产bench：工作台bill:清单bin:箱子biomechanical：生物力学的blade:刀片、叶片brand new:全新的b ud g e t-o rie nte d:面向预算的capacity:生产能力capital turnover:资金周转capital：资金carbon-filament:钨丝causal method:因果法cause and effect diagram：因果图cellular layout：单元式布局certification：认证change over :换模checksheet：检查表chronological:严密逻辑的chuck：卡盘circulate：循环、流通civil engineering：土木工程clamp:夹住closed loop:闭环CNC machine tools：计算机数控机床cockpit：飞机座舱、驾驶员座舱cognitive：认知的coil feeder：卷料进料器Co m m unicatio n Te chniq ue s in Lo g isticscompetitiveness：竞争力component:零件、组件、部件comprehensive interest:综合利益Computer Integrated Manufacturing Systems (CIMS):计算机集成制造系统computerized numerical controlconsecutive: 连续的continous improvement:持续改进continuous improvement：持续改进conveyor：输送机convoluted：复杂的、回旋的、弯曲的coordination：协调corkscrew: 螺丝刀co st-e ffe ctive：有成本效益的、划算的crank：曲柄critical examination technique:关键检测技术crossbar:十字杠culminate:达到顶点curricula: 课程(or curriculum)customer satisfaction：顾客满意cutback：缩减cylindrical:圆柱的prismatic：棱柱的dam：水坝decision-making:决策defective:有瑕疵的,有缺陷的definable:可定义的demonstrate：示范、说明dependent demand: 相关需求discipline:学科discrete：离散的dispersion：分散性distribution：配送、分销division：部门、分配、分开drill press：钻床drop delivery:堕送装置due date：交货期d ye：染料earning:收益、利润E-business：电子商务economic and knowledge-based era:知识经济时代economic batch quantity:经济批量economic globalization：经济全球化ECRS(eliminate combine rearrange simplify):取消、合并、重排、简化EDM: electron discharge machining：放电加工effectiveness:效果efficiency:效率ejector:斜槽、导轨electrical engineering：电气工程electricity: 电、电学、电流、电气electronic data interchange：电子数据交换E-Manufacturing：网络化制造engulf：吞没EOS:电子订货系统electronic ordering system ergonomically：工效学地ergonomics:工效学exaggerated:过大的、许多的explosion:爆炸法eyestrain:视觉疲劳,眼睛疲劳fabrication：制造facility:设备、设施factory layout：工厂布局family：簇fatigue：疲劳fatigue：疲劳feat：合适的feed grinding machine: 进给式磨床feedback：反馈feedback:反馈file：锉刀final product:最终产品fish bone diagram：鱼骨图fitness for use：适用性fixed position layout:定位布局fixture：固定设备、夹具flapped operation：节拍式加工flexible manufacturing system：柔性制造系统flow diagram：线路图flow process chart：流程程序图fluctuate: 波动forcible：强制的、有说服力的trunk：躯干torso forearm:前臂upper arm:大臂forecast:预测forge:锻造fo rg e：锻造formulate：阐述、制定fortification：防御工事forward-looking:有远见的fo und ry：铸造friction: 摩擦frustration：挫折fuel：燃料fully automated：全自动化gang process chart：联合程序图garment industry:制衣业gauge：计量器general packet radio service geographic information systems geometry：几何形状GIS:地理信息系统GPRS:通用分组无线业务GPS:全球定位系统global positioning system gravity feed：重力自流进料group technology：成组技术hand in hand :合作hard ware：硬件harmonious society:和谐社会haul: 拖、拉health-care delivery: 卫生保健服务high-tech：高科技hindrance：妨碍histogram：直方图hoist：起重机human factor：人因human-centered design：以人为中心设计hybrid layout：混合式布局hypotenuse:斜边（hypothesis:假设）identical:相同的idleness:空闲IE engineers:工业工程师（IEs）IE graduates:工业工程毕业生（IEs）impede：妨碍，阻止implicitly:隐含地incentive：鼓励inclined plane:斜面inclusive design：全方位设计inconsistency:不一致independent demand: 独立需求independent variable:自变量inevitable：不可避免的inspection：检测Institute of Industrial Engineers：工业工程师学会(IIE) instructor：讲师、教练instrument：仪器、器械intangible:无形的integrated equipment：集成设备interchangeability:互换性interface：界面、接口intermediary:中间人intermittent：间歇的internal combustion engine：内燃机International Accreditation Forum：国际认证论坛International Organization for Standardization:国际标准化组织（ISO）inventory control：库存控制Inventory：库存inventory:清单、库存invoicing:开发票item:物料项目jig：夹具job shop production：车间任务型生产judgment method:判断方法jumbled：混合的、混乱的knuckle：指关节wrist：腕关节elbow：肘关节lag:落后，延迟lathe：车床layout：布局lead time：提前期Lean Production (LP)：精益生产literature:文献loading:装载locomotive：火车头logistics:物流long and short-term memory：长短时记忆lot for lot:批对批lot size:批量low-volume, high-variety production:多品种、小批量生产lubricant：润滑剂luggage：行李machine cell：机器单元machine tool：机床magnetism：磁学maintainability：可维护性maintaining:维护malfunction：故障manipulate:处理，使用，操纵man-machine process chart：人机程序图manufacturing industry:制造业manufacturing resources planning:制造资源计划market share:市场占有率master production scheduling:主生产计划material handling ：物料搬运material requirements planning:物料需求计划mechanical engineering：机械工程mechanized：机械化的mental demand:脑力需求metal-working job shop :金工车间method study:方法研究methodology:方法metrics：度量m ilitary：军事的milling machine：铣床mission:使命、任务、目标MIT: 麻省理工学院Massachuse tts Institute o f Te chno lo g y molecular:分子的momentum：动量monetary：货币的、金融的morale：士气、纪律motion analysis：动作分析motion economy principles：动作经济原则motivation:激励multi-disciplinary：多学科性质的muscle：肌肉muscle：肌肉musculoskeletal disorder：肌骨失调navigation：导航netting:净需求计算normative：标准的notch: V型凹槽、切口nutrition：营养observe value：观察值offset:偏置法operation analysis：作业分析operation management:运作管理operation process chart: 工艺程序图opportunity：缺陷机会order fulfillment: 订单执行order lots：订单批量、订货量orient：定向otiose：无效的、多余的outlets:品牌直销购物中心overengineer：高于工程要求的package：包装pallet：托盘parameter:参数pareto chart：排列图part period cover:零件周期批量participation:参与partition：分割parts feeder：送料器physical science ：自然科学（natural science）physiology：生理学pivot：轴、支点、中心点plot:以图的形式表示Pmts: predetermined motion time system：预定动作时间系统portable powered tool：便携式电动工具portray：描绘POS:销售时点系统point of sale systempositioning device：定位装置positioning：定位potentiality:潜能practitioner：开业者pre-assessment:预评估precondition :前提prediction:预言preliminary：预备的、初级的pre-positioned：预放在工作位置上proceed:行进、继续进行process analysis：程序分析process layout：工艺布局procurement：采购product layout：产品布局product life cycle: 产品生命周期production line:生产线production planning:生产计划production process：生产过程production scheduling：生产调度production system：生产系统productive：有生产价值的、多产的productivity :生产率profitability:收益率psychology：心理学pull production:拉动式生产Pythagorean theorem:勾股定理qualitative method:定性方法quality of conformance：符合性质量quality of design：设计质量quantitative method:定量方法rapid changeover:快速换模raw material：原材料rectangular：矩形的cube：立方体registrar:注册人员reliability:可靠性repetition:重复、复制品repetitive strain injury：重复性劳损replenishment:补充、补给re p ro ach：责备、谴责reputation:声誉requirement:需求reservation：预定resharpen：重磨retailer:零售商revenue：收入、税收RFID:无线射频技术radio frequency identificationrough cut capacity:粗能力计划saturation：饱和scatter diagram：散布图scheduling:调度、排程scheme：计划、设计screwdriver：螺丝刀seasonal patterns:季节模式semi-automatic(automated)：半自动化sem inar:研讨班senso ry：感觉的service system:服务系统setup time：生产准备时间Shakespeare industry :莎士比亚产业sheet:薄板状的shroud：罩、遮蔽物simple lever:单杠杆simultaneously:同时地six sigma methodology: 六西格玛法socialize joint distribution:社会化共同配送specialization: 专业化specialty:专业specification：规范specs：规范、规格stamp：冲压standard data：标准资料standard deviation：标准偏差standardization: 标准化static electricity:静电学statistic：统计的statistical:统计学的steam engine:蒸汽机stock：库存sto re :仓库strategic planning:战略规划Stratfo rd-o n-Avo n, as we all kn o w, has only one Shake sp e are－b ut there are two distinctly se p arate and branches.subassembly:组件、部件substandard：低于标准的suite：软件包industry－William increasingly hostilesupply chain：供应链symmetrical：对称、匀称synchronous：同步的synthesize：综合tangible:有形的team spirit：团队精神Te chn ical Co m m itte e（TC）176:品质保证技术委员会template：模板template：模型thermal process:热处理thermal：热量的，热的third-party logistics:第三方物流threbligs：动素time study：时间研究time-series analysis:时间序列分析tolerance：容许偏差tote bin：搬运箱trade-off: 权衡transaction:业务、交易transformation：转换transmission:传送transportation:运输trivial：琐碎的tune:调整turbine:涡轮机、汽轮机two-hand process chart：双手程序图underengineer：低于工程要求的unloading:卸载unpredictable：不可预测的use r-ce nte re d:用户为中心的variable:变量vessel:管道vibration：振动vicinity：邻近visionary:远景warehouse:仓库warehouse：仓库、仓储weld：焊接wholesaler:批发商work measurement：作业测定work piece：工件work related upper limb disorder:工作引起的上肢功能障碍work sampling：工作抽样work unit：工件workhead：工作台、机台workholder：工件夹具wo rk-in-p ro ce ss：在制品workshop:车间、研讨会workstation：工作站。

Chapter 4 Requirements Engineering

编码
编译
2. Why RE ？ --From Practices (1)
2. Why RE ？ --From Practices (2) ,Standish Group 1995
成功项目的影响要素用户参与高层管理支持
清晰的需求说明正确的项目计划切合实际的期望细化的项目里程碑员工能力主人翁精神清晰的目标和前景努力工作其他
Make usage of characteristics of Stakeholders
3. Activities of RE---Inception
Identify stakeholders
“who else do you think I should talk to?”
Recognize multiple points of view
然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。
业务需求业务需求指导需求获取
用户需求转化用户需求为系统需求
系统需求
图2－5、不同抽象层次需求之间的联系
约束进行系统构造时需要遵守的约束，例如编程语言、硬件设施等
1. What is requirement? －－功能需求的层次性
目标任务系统行为
业务需求用户需求系统需求
1. What is requirement? －－功能需求的层次性
业务需求
系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统
basic understanding of the problem (Objectives) the nature of the solution that is desired (Vision) How many things needed to developing the solution

prompt engineering 简单理解

prompt engineering 简单理解什么是工程？工程是一门应用科学，它涉及解决实际问题的设计、构建和维护。

工程师使用他们的知识和技能来创造新的产品、结构和系统，并解决现有产品、结构和系统的问题。

工程师们的工作包括研究、设计、测试、建造、改进和维护各种类型的项目。

工程师是工程的关键组成部分。

他们可以专注于特定的领域，如土木工程、机械工程、电气工程等。

但无论领域如何，工程师们在项目的不同阶段都需要使用一系列的技能和工具。

工程的主要步骤：1. 需求分析和问题定义：在开始解决任何工程问题之前，工程师需要充分了解客户的需求和问题的本质。

这通常需要进行面对面的会议、讨论和研究。

在这一阶段，工程师将确保对问题的理解达成一致，并明确所需的结果。

2. 概念设计：一旦问题被定义明确，工程师将开始进行创意和概念的设计。

他们会生成多个可能的解决方案，并评估每个方案的可行性和效果。

在这个过程中，工程师需要应用他们的技术和工程知识，同时也考虑到实用性、成本、时间和资源的因素。

3. 详细设计：在概念设计阶段完成后，工程师会对选定的解决方案进行更详细的设计。

这将包括制定详细的计划、确定所需的材料和设备、制定相关标准和规范，以及评估解决方案的可行性和潜在风险。

4. 制造和建设：在设计完成后，工程师将开始制造或建造所需的产品、结构或系统。

这可能涉及到采购所需的材料和设备，组装和安装各个组件，以及进行必要的测试和调整。

工程师需要密切关注质量控制和安全标准，以确保产品的可靠性和性能达到预期。

5. 测试和验证：一旦制造或建造完成，工程师需要对产品、结构或系统进行测试和验证。

这可以包括对其性能、可靠性、耐久性和安全性进行各种测试。

工程师需要运用各种测试方法和仪器，收集数据并进行分析，以确保符合设计规范和标准。

6. 优化和改进：如果在测试和验证阶段发现任何问题或不足，工程师将尝试进行优化和改进。

这可能涉及到对设计的再次修改、使用改进的材料或工艺，并重新进行测试。

软件工程关键术语中英文对照表

软件工程关键术语中英文对照表课程关键术语中英文对照表1、S oftware 软件2、U ser 用户3、D eveloper 开发者4、C onstituent 组成5、P rogram 程序6、D ocument 文档7、D ata 数据8、S oftware Crisis 软件危机9、S afety-Critical 安全忧关的10、Software Engineering 软件工程11、Maintenance 维护12、Bug 故障13、Failure 失效14、Correctness 正确性15、Reliability 可靠性16、Maintainability 可维护性17、Reusability 可重用性18、Traceability 可跟踪性19、Portability 可移植性20、Interoperability 互操作性21、Efficiency 有效性23、Modularity 模块化24、Information Hiding 信息隐藏25、Localization 局部化26、Consistency 一致27、Completeness 完整28、Verifiability 可验证29、Software Lifecycle 软件生命周期30、Feasibility Investigation 可行性分析31、Requirement 需求32、Requirement Analysis 需求分析33、Software Delivery 软件发布34、Prototype 原型35、Software Requirement Specification (SRS) 软件需求规格说明书36、Software Architecture 软件体系结构37、Refinement 精化38、Software Architecture Design Specification 软件体系结构规格说明书39、Integration Test Plan 集成测试计划40、Detailed Design 详细设计41、Detailed Design Specification 详细设计规格说明书42、Unit Test Plan 单元测试计划43、Integration Test 集成测试45、Validation Test46、Maintenance 维护47、Process 过程48、Software Process 软件过程49、Process Framework 过程框架50、Software Process Model 软件过程模型51、Incremental Model 增量模型52、RAD Model 快速应用开发53、Spiral Model 螺旋模型54、Unified Process 统一过程55、CASE 计算机辅助软件工程56、Software requirement 软件需求57、Function 功能58、Performance 性能59、Constraint 约束60、Schedule 进度61、Requirement Engineering 需求工程62、Analyst 分析人员63、Stakeholder 利益相关者64、Software Requirement Specification 软件需求规格说明书65、Inception 开始67、Elaboration 精化68、Negotiation 协商69、Specification 规格说明70、Validation 确认71、Management 管理72、Modeling 建模73、Refinement 精炼74、Conflict 冲突75、Multiple Viewpoints 多视点76、Prototype 原型77、Standardization 标准化78、Rules of Thumb 经验原则79、Requirement Analysis 需求分析80、Methodology 方法学81、Data Flow Oriented Modeling 面向数据流建模82、Data Flow Oriented Methodology 面向数据流方法学83、Structure Software Development Methodology 结构化软件开发方法学84、Data Flow Diagram（DFD）数据流图85、Data Dictionary (DD) 数据字典86、Process Specification (PS) 处理规格说明87、External Entity 外部实体89、Data storage 数据存储90、Data flow 数据流91、Software Design Specification (SDS) 软件设计规格说明书92、Design Models 设计模型93、Formal Technical Review 正式技术评审94、Architecture Design Model 体系结构设计模型95、Data design Model 数据设计模型96、Interface Design Model 接口设计模型97、Component Design Model 部件设计模型98、Deployment Design Model 部署设计模型99、Design Principle 设计原则100、Abstraction 抽象101、Architecture 体系结构102、Patterns 模式103、Modularity 模块化104、Hiding 隐藏105、Functional Independence 功能独立106、Refinement 精化107、Refactoring 重构108、Program Design Language(PDL) 程序设计语言109、User interface (UI) 用户界面111、Transform Flow 变换流112、Transaction Flow 事务流113、Incoming Flow 输入流114、Transform Center 处理中心115、Outgoing Flow 输出流116、Transaction 事务117、Transaction Flow 事务流118、Transaction Center 事务中心119、Action Paths 动作路径120、Transform Mapping 变换映射121、Transaction mapping 事务映射122、Error-free 无错误123、Software Error 软件错误124、Software Testing 软件测试125、Delivery 交付126、Debug 跟踪127、Evaluate Result 评估结果128、T est Case 测试用例129、Tester 测试人员130、Unit Testing 单元测试131、Integration Testing 集成测试133、Stub 桩134、Testability 可测试性135、Observability 可观察性136、Understandability 可理解性137、Cover 覆盖138、White-Box Testing 黑盒测试139、Black-Box Testing 白盒测试140、Basic Path Testing 基本路径测试141、Flow Diagram 流图142、Flowchart 流程图143、Path 路径144、Basic Path 基本路径145、Equivalence Partitioning 等价分类146、Boundary Value Analysis 边界取值分析147、Regression Tests 回归测试。

第三讲需求工程(requirementsengineering)资料

两种描述都叫做需求文档，分别对应于用户需求和系统需求。
Page 10
2.2 需求的类型
用户需求
从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操作要受到的约束进行的声明。
系统需求
系统需求是一种结构化文档，要运用一些专业的模型详细的描述系统的功能及其约束。系统需求文档有时也称为功能描述，应该是精确的，它可以成为双方之间合同的重要内容，同时作为开发工作的依据。
这种需求来自于系统的应用领域，反映领域特征。可能是功能需求也可能是非功能需求。
Page 13
2.3.1 功能需求
功能需求描述系统所应提供的功能或服务。
取决于待开发软件的类型、未来的用户以及开发的系统类型。
功能性的用户需求只需要对系统应提供的服务进行高层一般描述，对于系统需求，则应该详细的描述系统功能、输入输出及异常。
Sy stem req uirements elicitatio n
User req uirements elicitatio n
Feasibility stud y Prototyp in g
Requ iremen ts elicitatio n
Reviews
Requ iremen ts v alidatio n
你坐在办公室舒展着紧张了几个月的身躯，头脑中盘算着如何让客户痛快的付清合同款。这时，客户走进你的办公室，坐下，直视着你的眼睛
说道：“我知道你认为你理解了我说的是什么，但
你恐怕不知道，我所说的其实不是我想要的。”
Page 4
需求工程过程
需求工程过程并不具有唯一的模型，按照不同的应用领域、不同的客户与开发团队，需求工程的过程有很大的差异。然而，在所有的过程中都会涉及一些共同的活动，它们是：

华东交大软件学院外教课程Lecture 6_Requirements Engineering

Page 2
LOGOΒιβλιοθήκη Requirements Engineering (RE)
The process of establishing the services that the customer requires from a system and the constraints under which it is operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated or produced during the requirements engineering process.
LOGO
Functional Requirements
Statements of services the system should provide, how the system react to particular inputs and how the system should behave in particular situations. Let us consider the example of Hospital Management System, the functional requirements related with this system are: ‘The system shall maintain the history of all patients both prior and ongoing.’ ‘The system shall be able to manage the access rights for all users.’ ‘Patient record shall be accessible to only authorized users.’

建筑与市政工程施工现场专业技术及技能人员配备标准-河北地方标准

3.0.3与发包方签订合同的总承包单位应根据国家和河北省相关规定和承包合同约定组建施工现场项目管理机构，配备人员。施工现场专业技术人员和技能人员应是与施工企业或分包单位建立劳动关系的人员。
3.0.4无特别规定或约定的，一个承包合同或标段应建立一个项目管理机构。
3.0.5标准中的工程规模、面积、金额的规定，应以施工承包合同约定值为准。建筑工程分类及规模划分标准应符合注册建造师执业工程规模标准。市政工程的大中小型工程划分标准应符合本标准附录A的规定。
本标准共分8章和4个附录，主要内容有：1、总则；2、术语；3、基本规定；4、专业技术人员配备标准；5、专业技术人员的任职条件；6、专业技术人员的工作职责；7、技能人员配备要求；8、管理要求；4个附录和条文说明。
本规程由河北省建设工程标准编制研究中心负责管理，由河北建筑设计研究院有限责任公司负责具体内容的解释。
4.1一般规定5
4.2建筑工程5
4.3市政工程7
4.4劳务分包8
5专业技术人员的任职条件9
5.1一般规定9
5.2专业技术人员任职条件9
6专业技术人员的工作职责11
6.1一般规定11
6.2专业技术人员的工作职责11
7技能人员配备要求22
8管理要求23
8.1人员管理23
8.2人员变更、撤离24
附录A市政工程规模划分标准26
统一书号：155160▪XXX
版权所有翻印必究
河北省住房和城乡建设厅
公告
2019年第x号
河北省住房和城乡建设厅
关于发布《建筑与市政工程施工现场专业技术及技能人员配备标准》的公告
《建筑与市政工程施工现场专业技术及技能人员配备标准》（编号为：DB13(J)/T219-2019）已经本机关审查并分别批准为河北省工程建设标准和标准设计，现予发布，自2019年x月x日起实施。

ch7 软件工程Requirement Engineering

华南理工大学软件学院
21
Quality Function Deployment 质量功能部署
Software Engineering: A Practitioner’s Approach, 6/e
Chapter 7,8 Requirements Engineering 需求工程) (需求工程)
华南理工大学软件学院
1
How is Software usually Constructed …
华南理工大学软件学院
10
Why RE.is so important?
3）需求分析要占用整个软件开发时间或工作量的 30%左右左右。 30%左右。需求获取中的错误，（4）需求获取中的错误，属于软件开发中的早期错误，错误，它会在后续的设计和实现中进行发散式的传播。传播。根据以上四项原因，IT企业的高层经理企业的高层经理，根据以上四项原因，IT企业的高层经理，对需求分析特别重视，分析特别重视，常常派经验最丰富的人员去作项目需求。正因为如此，系统分析员” 目需求。正因为如此，“系统分析员”才是软件行业中的最高技术职称
中国的国有企业正处在变动期（中国的国有企业正处在变动期（体制改革与企业重组），中国的民营企业正处在成长期（），中国的民营企业正处在成长期重组），中国的民营企业正处在成长期（发展壮大与不完全成熟）。）。而处于变动期和成长期的企大与不完全成熟）。而处于变动期和成长期的企业需求是不成熟、不稳定和不规范的，业需求是不成熟、不稳定和不规范的，这就给信息系统的需求分析，无疑增加了难度系数。息系统的需求分析，无疑增加了难度系数。
华南理工大学软件学院
12
需求的层次
华南理工大学软件学院
13