Requirements Engineering manuscript No. (will be inserted by the editor) Specifying and Ana
- 格式:pdf
- 大小:197.24 KB
- 文档页数:18
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-tification 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,specification,assessment, negotiation,documentation,and evolution.Getting high-quality requirements is difficult and critical.Recent surveys have confirmed 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-specific areas such as goal-oriented requirements elaboration,conflict management,and the handling of abnormal agent behaviors.Opportunities for goal-based architecture derivation are also discussed together with research directions to let thefield 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 refinement 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 confirmed 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 significant 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 specifically,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 specification(>50%)and require-ments management (50%) [ESI96].Improving the quality of requirements is thus crucial.But it is a difficult objective to achieve.To understand the reason one shouldfirst define what requirements engineering is really about.The oldest definition already had the main ingredients.In their seminal paper,Ross and Schoman stated that“require-ments definition is a careful assessment of the needs that a system is to fulfill.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 specifications of software behavior;their evolution over time and across software families has to be coped with as well [Zav97b].This definition 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,flexibility,per-formance,robustness,interoperability,cost, maintainability,and so on.These non-functional concerns are often conflicting.•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 conflict-ing viewpoints.•Requirement specifications may suffer a great variety of deficiencies[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 areflaws that may yield undesired consequences(such as waste of time or generation of new errors)-e.g.,noises, forward references,overspecifications,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 identified and interviewed.Problems and deficiencies in the existing system are identified;oppor-tunities are investigated;general objectives on the target system are identified therefrom.–Elicitation:alternative models for the target system are explored to meet such objectives;requirements and assumptions on components of such models are identi-fied,possibly with the help of hypothetical interaction scenarios.Alternative models generally define 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.–Specification:the requirements and assumptions are for-mulated in a precise way.–Specification analysis:the specifications are checked for deficiencies(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 modified 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 specific domain/task/environment may require some specific 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,specification analysis,and negotiation.On the other hand,they guide fur-ther domain analysis,elicitation,specification 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 specification.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 define the model precisely,•how to reason about the model.The answer to thefirst 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,refinement,responsibility assignment,and so forth.The answer to the third question determines the informal,semi-formal,or formal specification technique used to define 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,specifi-cation, and analysis.The early daysThe seminal paper by Ross and Schoman opened thefield [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 specific 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 defined by produc-ing/consuming operations;a model for operations,in which operations are defined 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 refinement 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 specific 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 defined.People at that time started advocating the benefits of precise and formal specifications,notably,for checking specification adequacy through prototyping [Bal82].RML brought the SADT line of research significantly further by introducing rich structuring mechanisms such as generali-zation,aggregation and classification[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 specification [Abr80]started penetrating ourfield.RML was also proba-bly thefirst requirements modeling language to have a for-mal semantics,defined in terms of mappings tofirst-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 fulfill[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 sufficient for achieving the higher-level objectives that arise naturally in any require-ments engineering process[Hic74,Mun81,Ber91,Rub92]. Yue was probably thefirst 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 sufficient to establish the goal they are refining[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 refinements in requirements models:a formal framework and a qualitative one.In the formal framework [Dar91],goal refinements are captured through AND/OR graph structures borrowed from problem reduction tech-niques in artificial intelligence[Nil71].AND-refinement links relate a goal to a set of subgoals(called refinement); this means that satisfying all subgoals in the refinement is a sufficient condition for satisfying the goal.OR-refinement links relate a goal to an alternative set of refinements;this means that satisfying one of the refinements is a sufficient condition for satisfying the goal.In this framework,a con-flict 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 satisfied in a clear-cut sense.Instead of goal satisfaction,goal satisficing 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 satisficed,then the goal is sat-isficeable;but if a subgoal is denied then the goal is deniable. If a goal contributes negatively to another goal and the former is satisficed, 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 refine-ment is correct and complete,or complete such a refinement [Dar96].One can also formally detect conflicts 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 specified by names,parameters,and degrees of satisficing/denial by child goals.This procedure determines the degree to which a goal is satisficed/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 refinement trees were also proposed for specific 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 specific 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 defined 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 defined;operators can be combined to define plans that agents may use to achieve goals.The purpose of this modeling is to support the verification of properties such as the viability of an agent's plan or the fulfilment of a commitment between agents. Viewpoints, facets, and conflictsBeside the formal and qualitative reasoning techniques above,other work on conflict management has emphasized the need for handling conflicts at the goal level.A procedure was suggested in[Rob89]for identifying conflicts 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 identified together with their goals(called win conditions);(b)conflicts 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.Conflicts 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 specific consistency rules associated with them;consistency checking is made by evaluating the corresponding rules on pairs of viewpoints [Nus94].Conflicts need not necessarily be resolved as they arise;different viewpoints may yield further relevant infor-mation during elicitation even though they are conflicting in some respect.Preliminary attempts have been made to define a paraconsistent logical framework allowing useful deduc-tions to be made in spite of inconsistency [Hun98]. Multiparadigm specification is especially appealling for requirements specification.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 thatfit them best.OMT’s combina-tion of entity-relationship,dataflow,and state transition dia-grams was among thefirst 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 specifications [Pot96]andfinite state machine specifications;and[Dar93], which combines semantic nets[Qui68]for navigating through multiple models at surface level,temporal logic for the specification of the goal and object models[Man92, Koy92],and state-based specification[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 difficulties expressing them in abstracto.Operational scenarios of using the hypothetical system are sometimes easier to get in thefirst 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 confirmed 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 deficiency-driven requirements elaboration is especially worth pointing out.A system there is specified 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 specification 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 efficient way[McM93,Hol97,Cla99].)The operators offered to the analyst in Step(b)encode heuristics for speci-fication 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 deficiency detec-tion and debugging operators allows the analyst to explore the space of alternative models and hopefully converge towards a satisfactory system specification.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 overspecification.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 specifications 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 specifications.At about the same time,Jackson and Parnas independently made afirst 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 definitions of objects or operations in the environ-ment are by no means requirements.Surprisingly,the vast majority of specification 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)specifications.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 specifications 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 reflect 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 specifications,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 specific area of reactive systems for process control.The seminal paper here was based on work by Heninger,Parnas and colleagues while reengineering theflight software for the A-7aircraft [Hen80].The paper introduced SCR,a tabular specification technique for specifying a reactive system by a set of parallel finite-state machines.Each of them is defined by different types of mathematical functions represented in tabular for-mat.A mode transition table defines a mode(i.e.a state)as a transition function of a mode and an event;an event table defines an output variable(or auxiliary quantity)as a func-。
jec投稿要求和须知Submissions to the Journal of Engineering and Computing (JEC) must adhere to strict requirements and guidelines to ensure the quality and consistency of the content. Authors are expected to submit original, unpublished work that contributes significantly to the field of engineering and computing. The manuscript should be formatted in accordance with the journal's style guidelines, including the use of appropriate headings, subheadings, and citations.向《工程与计算杂志》(JEC)投稿需遵循严格的要求和须知,以确保内容的质量和一致性。
作者应提交原创、未发表的作品,并对工程与计算领域作出重要贡献。
稿件应按照杂志的样式指南进行格式化,包括使用适当的标题、副标题和引文。
In terms of length, manuscripts should be concise yet comprehensive, typically ranging between 4000 and 6000 words. Authors are encouraged to provide clear and precise language, avoiding jargon or technical terms that may not be familiar to a general readership. The use of figures, tables, and equations should be sparing and only when they effectively enhance the understanding of the presented material.就篇幅而言,稿件应简洁明了且内容全面,通常字数在4000至6000字之间。
international journal of pavementengineering 稿件要求International Journal of Pavement Engineering: Submission RequirementsIntroduction:The International Journal of Pavement Engineering (IJPE) is a renowned publication that focuses on the latest advancements, research, and innovations in the field of pavement engineering. As a leading platform for disseminating knowledge and promoting excellence in this domain, IJPE has specific requirements for manuscript submissions. This article aims to provide a comprehensive overview of these requirements, highlighting key points that authors should consider when submitting their work.I. Manuscript Structure:1. Title and Abstract:1.1 The title should be concise, informative, and accurately reflect the content of the manuscript.1.2 The abstract should provide a brief summary of the research objectives, methodology, key findings, and significance of the study.2. Introduction:2.1 Clearly state the research problem and its significance in the field of pavement engineering.2.2 Provide a comprehensive literature review to establish the context and identify the research gap.2.3 Clearly state the research objectives and the scope of the study.3. Methodology:3.1 Describe the research design, experimental setup, or computational methods used in the study.3.2 Explain the data collection process, including the selection criteria for samples or data sources.3.3 Detail the data analysis techniques or statistical methods employed.4. Results and Discussion:4.1 Present the findings in a logical and organized manner, using tables, figures, or graphs where appropriate.4.2 Analyze and interpret the results, comparing them with existing literature or theoretical expectations.4.3 Discuss the implications of the findings, highlighting their significance and contributions to the field.5. Conclusion:5.1 Summarize the main findings and their implications.5.2 Discuss the limitations of the study and suggest potential areas for future research.5.3 Emphasize the practical relevance and application of the research.II. Formatting and Style:1. Manuscript Length:1.1 The manuscript should be concise, typically between 6,000 and 8,000 words, excluding references and appendices.1.2 Avoid excessive repetition or redundancy in the content.2. Language and Grammar:2.1 Ensure the use of clear, concise, and grammatically correct language.2.2 Follow the journal's preferred spelling and punctuation style.3. Figures and Tables:3.1 Include high-quality figures and tables that enhance the understanding of the research.3.2 Clearly label and reference all figures and tables within the text.III. Citations and References:1. Citation Style:1.1 Follow the journal's preferred citation style, such as APA, MLA, or IEEE.1.2 Ensure accurate and consistent citation throughout the manuscript.2. References:2.1 Include a comprehensive list of all cited references at the end of the manuscript.2.2 Follow the journal's guidelines for formatting the references, including the use of DOI or URL where applicable.IV. Ethical Considerations:1. Plagiarism:1.1 Ensure that all content is original and properly cited.1.2 Avoid self-plagiarism by properly referencing any previously published work by the same authors.2. Conflict of Interest:2.1 Disclose any potential conflicts of interest that may influence the research or its interpretation.3. Ethical Approval:3.1 If applicable, mention any necessary ethical approvals obtained for the research involving human subjects or animals.Conclusion:In conclusion, the International Journal of Pavement Engineering has specific requirements for manuscript submissions. Authors should carefully adhere to these guidelines to ensure their work is accurately and professionally presented. By following the recommended structure, formatting, and ethical considerations, researchers can increase their chances of publication in this prestigious journal and contribute to the advancement of pavement engineering knowledge.。
系统工程与电子技术英文版投稿指南Submission Guidelines for System Engineering and Electronic TechnologyThank you for considering submitting your work to System Engineering and Electronic Technology journal. To ensure smooth processing of your submission, please carefully read and follow the guidelines below:1. Manuscript Preparation:- All manuscripts should be written in English and formatted according to the journal's guidelines.- Manuscripts should be submitted in Microsoft Word format.- Ensure the manuscript is double-spaced, with 1-inch margins, and utilizes Times New Roman font with 12-point size.- Include a title page with the title (concise and informative), author(s) name and affiliation, corresponding author's contact information, and a list of keywords.- The abstract should be no more than 250 words and provide a brief overview of the research conducted, methods used, and key findings.- References should be cited in APA style and listed at the end of the manuscript.2. Submission Process:- Authors are required to submit their manuscripts online through the journal's submission system. Register an account and follow the instructions to upload your manuscript.- Authors may track the status of their submission through the online system.- Only original work that has not been published elsewhere will be considered for publication.- Ensure all necessary permissions and copyrights are obtained for any figures, tables, or supplementary material used in the manuscript.3. Peer Review Process:- All submitted manuscripts will undergo a rigorous peer review process to ensure quality and relevance to the journal.- The review process is double-blind, where both authors and reviewers remain anonymous.- Authors may suggest potential reviewers during the submission process, but the final selection is at the discretion of the editorial board.4. Ethical Considerations:- Authors should ensure that their work is original and has not been plagiarized from any other source.- Proper acknowledgment and citation should be given for any contributions or sources used in the research.- Any conflicts of interest should be disclosed in the manuscript.5. Publication Fees:- System Engineering and Electronic Technology does not charge any submission or publication fees.We look forward to receiving your submission and thank you for considering System Engineering and Electronic Technology journal for publication. If you have any questions or concerns, please contact the editorial office at [email protected]Best regards,Editorial TeamSystem Engineering and Electronic Technology。
英文版学报审稿流程详解The manuscript review process for English academic journals is a crucial step in ensuring the quality and integrity of published research. This process involves a thorough evaluation of the submitted manuscript by a panel of experts in the field, with the ultimate goal of selecting high-quality, impactful, and original contributions that meet the journal's standards. The review process can vary slightly across different journals, but generally, it follows a similar structure.The first step in the review process is the initial screening by the journal's editorial team. This phase involves a cursory examination of the manuscript to ensure that it aligns with the journal's scope, follows the required formatting and submission guidelines, and meets the minimum criteria for further consideration. The editorial team may also check for potential ethical concerns, conflicts of interest, or instances of plagiarism. If the manuscript passes this initial screening, it will be forwarded to the next stage of the review process.The second step is the peer review process. The manuscript is typically assigned to one or more subject-matter experts, known as peer reviewers, who are selected based on their expertise and relevant research experience. These reviewers are tasked with conducting a comprehensive evaluation of the manuscript, which includes assessing the research methodology, the validity of the findings, the accuracy of the literature review, the clarity of the writing, and the overall contribution to the field.The peer reviewers are often required to provide a detailed, constructive feedback to the authors, highlighting the strengths and weaknesses of the manuscript. This feedback may include suggestions for improving the manuscript, such as clarifying the research questions, strengthening the data analysis, or enhancing the presentation of the findings. The peer reviewers are also expected to provide a recommendation to the journal's editorial team regarding the suitability of the manuscript for publication.Once the peer review process is complete, the editorial team will carefully consider the feedback and recommendations provided by the reviewers. They may engage in further discussions with the authors, requesting additional information or revisions to address the concerns raised by the reviewers. This stage of the review process is often referred to as the "revise and resubmit" phase, during which the authors have the opportunity to address the issuesidentified by the reviewers and resubmit their manuscript for further consideration.If the manuscript is deemed suitable for publication, the editorial team will typically provide the authors with a formal acceptance letter, outlining the next steps in the publication process. This may include additional editorial and formatting requirements, as well as information about the expected timeline for the publication.It is important to note that the manuscript review process can be a lengthy and iterative process, as the editorial team and peer reviewers strive to ensure the highest level of quality and rigor in the published research. Authors may need to be patient and responsive throughout this process, as the journal's staff works diligently to provide a fair and thorough evaluation of their work.In addition to the standard peer review process, some journals may also incorporate additional review mechanisms, such as open peer review or post-publication peer review. Open peer review allows the authors and the public to access the reviewers' comments and engage in discussions about the manuscript, while post-publication peer review encourages ongoing feedback and commentary on the published work.The manuscript review process is not only crucial for maintaining theintegrity of academic research but also plays a vital role in the advancement of knowledge within a particular field. By subjecting manuscripts to rigorous scrutiny, journals can ensure that the research published within their pages is of the highest quality, making a meaningful contribution to the broader academic community.In conclusion, the detailed explanation of the manuscript review process for English academic journals highlights the importance of this crucial step in the publication process. From the initial screening to the final decision, the review process is designed to uphold the standards of academic excellence, foster the development of new knowledge, and promote the dissemination of high-impact research. By understanding and respecting this process, authors can better navigate the publication landscape and contribute to the ongoing progress of their respective fields.。
Materials LettersIntroductionMaterials Letters is a reputable scholarly journal focused on the latest advancements and research in the field of materials science. It provides a valuable platform for researchers, scientists, and engineers to publish their original contributions and share their findings with the scientific community. This document aims to provide an overview of Materials Letters, including its scope, submission process, and the benefits of publishing in this prestigious journal.ScopeMaterials Letters covers a wide range of topics in materials science, including but not limited to:1.Advanced materials2.Biomaterialsposites4.Electronic materials5.Energy materials6.Nanomaterials7.Optical materials8.Sustainable materials9.Thin filmsThe journal accepts submissions from various disciplines, such as chemistry, physics, engineering, and biology. It encourages interdisciplinary research and promotes the integration of different approaches to materials science.Submission ProcessSubmitting a manuscript to Materials Letters is a straightforward process. Authors are required to adhere to the journal’s guidelines and formatting requirements. The submission process can be summarized as follows:1.Manuscript preparation: Authors should carefullyprepare th eir manuscript, ensuring it meets the journal’sformatting guidelines. This includes organizing the content with headings, subheadings, figures, and tables.2.Online submission: Authors can submit theirmanuscript online through the journal’s submission syst em.They are required to provide information about thearticle’s title, authors, affiliations, and abstract. Themanuscript should be uploaded as a well-formatted PDFfile.3.Peer review: Once the manuscript is submitted, itgoes through a rigorous peer review process. Experts in the field evaluate the manuscript’s scientific validity,methodology, and significance. The peer reviewers provideconstructive feedback to the authors, who may be required to make revisions based on this feedback.4.Acceptance and publication: If the manuscriptsuccessfully passes the peer review process, it is accepted for publication. The authors are notified about theacceptance, and the article is scheduled for publication in one of the upcoming issues of Materials Letters. The journal follows a continuous publication model, ensuring timelydissemination of research.Benefits of Publishing in Materials LettersPublishing in Materials Letters offers several benefits for researchers and scientists in the field of materials science:1.Visibility and Impact: Materials Letters has a widereadership and is indexed in various scientific databases,increasing the visibility and impact of published articles.This enhances the reputation and recognition ofresearchers and their work.2.Rapid Publication: Materials Letters strives toensure rapid publication of accepted manuscripts. Thisallows researchers to share their findings with the scientific community promptly, accelerating the dissemination ofknowledge.3.Quality and Rigor: As a reputable journal, MaterialsLetters maintains high standards for scientific rigor andquality. It follows a rigorous peer review process, ensuring that published articles meet the highest scientific standards.4.Interdisciplinary Collaboration: Materials Lettersencourages interdisciplinary collaboration by acceptingarticles from various disciplines within materials science.This fosters the integration of different approaches andfacilitates collaborations between researchers from diverse backgrounds.5.Open Access Options: Materials Letters offers openaccess options, allowing articles to be freely accessible to a wider audience. This promotes the democratization ofknowledge and facilitates global collaboration.ConclusionMaterials Letters is a premier journal in the field of materials science, providing a platform for researchers to publish and share their original contributions. With its wide scope, rigorous peer review process, and reputation for quality, the journal offers numerous benefits to authors. Publishing in Materials Letters not only enhances the visibility and impact of research but also fosters interdisciplinary collaboration and promotes the advancement of materials science.。
Checklist for Manuscript SubmissionNumbers following entries refer to relevant section numbers in the Publication Manual.Format•Have you checked the journal’s website for instructions to authors regarding specific formatting requirements for submission (8.03)?•Is the entire manuscript—including quotations, references, author note, content footnotes, and figure captions—double-spaced (8.03)? Is the manuscript neatly prepared (8.03)?•Are the margins at least 1 in. (2.54 cm; 8.03)?•Are the title page, abstract, references, appendices, content footnotes, tables, and figures on separate pages (with only one table or figure per page)? Are the figure captions on the samepage as the figures? Are manuscript elements ordered in sequence, with the text pagesbetween the abstract and the references (8.03)?•Are all pages numbered in sequence, starting with the title page (8.03)?Title Page and Abstract•Is the title no more than 12 words (2.01)?•Does the byline reflect the institution or institutions where the work was conducted (2.02)?•Does the title page include the running head, article title, byline, date, and author note (8.03)?(Note, however, that some publishers prefer that you include author identification informationonly in the cover letter. Check with your publisher and follow the recommended format.) •Does the abstract range between 150 and 250 words (2.04)? (Note, however, that the abstract word limit changes periodically. Check APA Journals Manuscript Submission Instructions for All Authors for updates to the APA abstract word limit.)Paragraphs and Headings•Is each paragraph longer than a single sentence but not longer than one manuscript page(3.08)?•Do the levels of headings accurately reflect the organization of the paper (3.02–3.03)?•Do all headings of the same level appear in the same format (3.02–3.03)?Abbreviations•Are unnecessary abbreviations eliminated and necessary ones explained (4.22–4.23)?•Are abbreviations in tables and figures explained in the table notes and figure captions or legends (4.23)?Mathematics and Statistics•Are Greek letters and all but the most common mathematical symbols identified on the manuscript (4.45, 4.49)?•Are all non-Greek letters that are used as statistical symbols for algebraic variables in italics(4.45)?Units of Measurement•Are metric equivalents for all nonmetric units provided (except measurements of time, which have no metric equivalents; see 4.39)?•Are all metric and nonmetric units with numeric values (except some measurements of time) abbreviated (4.27, 4.40)?References•Are references cited both in text and in the reference list (6.11–6.21)?•Do the text citations and reference list entries agree both in spelling and in date (6.11–6.21)?•Are journal titles in the reference list spelled out fully (6.29)?•Are the references (both in the parenthetical text citations and in the reference list) ordered alphabetically by the authors’ surnames (6.16, 6.25)?•Are inclusive page numbers for all articles or chapters in books provided in the reference list(7.01, 7.02)?•Are references to studies included in your meta-analysis preceded by an asterisk (6.26)? Notes and Footnotes•Is the departmental affiliation given for each author in the author note (2.03)?•Does the author note include both the author’s current affiliation if it is different from the bylin e affiliation and a current address for correspondence (2.03)?•Does the author note disclose special circumstances about the article (portions presented at a meeting, student paper as basis for the article, report of a longitudinal study, relationship thatmay be perceived as a conflict of interest; 2.03)?•In the text, are all footnotes indicated, and are footnote numbers correctly located (2.12)? Tables and Figures•Does every table column, including the stub column, have a heading (5.13, 5.19)?•Have all vertical table rules been omitted (5.19)?•Are all tables referred to in text (5.19)?•Are the elements in the figures large enough to remain legible after the figure has been reduced to the width of a journal column or page (5.22, 5.25)?•Is lettering in a figure no smaller than 8 points and no larger than 14 points (5.25)?•Are the figures being submitted in a file format acceptable to the publisher (5.30)?•Has the figure been prepared at a resolution sufficient to produce a high-quality image (5.25)?•Are all figures numbered consecutively with Arabic numerals (5.30)?•Are all figures and tables mentioned in the text and numbered in the order in which they are mentioned (5.05)?Copyright and Quotations•Is written permission to use previously published text; test; or portions of tests, tables, or figures enclosed with the manuscript (6.10)? See Permissions Alert (PDF: 16KB) for more information.•Are page or paragraph numbers provided in text for all quotations (6.03, 6.05)?Submitting the Manuscript•Is the journal editor’s contact information current (8.03)?•Is a cover letter included with the manuscript? Does the lettera. include the author’s postal address, e-mail address, telephone number, and faxnumber for future correspondence?b. state that the manuscript is original, not previously published, and not underconcurrent consideration elsewhere?c. inform the journal editor of the existence of any similar published manuscripts writtenby the author (8.03, Figure 8.1)?d. mention any supplemental material you are submitting for the online version of yourarticle?。
稿件要求投稿方式录用奖励英语作文全文共3篇示例,供读者参考篇1Title: Submission Requirements, Submission Process, Acceptance, and Rewards for ManuscriptsIntroduction:Submitting manuscripts for publication in academic journals is a crucial step in the dissemination of research findings and scholarly contributions. In order to streamline the submission process, ensure the quality of submissions, and reward authors for their hard work, journals often have specific requirements for manuscript submission, a well-defined process for reviewing submissions, criteria for accepting manuscripts, and rewards for accepted publications.Submission Requirements:Authors must adhere to the submission requirements set forth by the journal in order for their manuscripts to be considered for publication. These requirements may include guidelines for formatting, word count, referencing style, and ethical considerations such as plagiarism and conflicts of interest.It is important for authors to carefully read and follow the submission requirements to increase their chances of acceptance.Submission Process:Once a manuscript is submitted to a journal, it undergoes a rigorous peer-review process to evaluate its quality, originality, and relevance to the journal's scope. The submission process typically involves multiple rounds of review by experts in the field, who provide feedback and recommendations for revisions. Authors are often required to respond to reviewers' comments and make necessary revisions to their manuscripts before a final decision is made.Acceptance:Manuscripts that meet the journal's standards for quality and originality are accepted for publication. Accepted manuscripts may undergo additional editing and formatting to ensure they meet the journal's publishing standards. Authors are then notified of the acceptance of their manuscripts and provided with information on the publication process and timeline.Rewards:Authors whose manuscripts are accepted for publication are often rewarded in various ways. Some journals offer financial incentives, such as publication fees or royalties, to authors whose manuscripts are accepted. Other rewards may include recognition in the form of awards, certificates, or prizes. Additionally, publication in a reputable journal can enhance authors' credibility and visibility in their field, leading to career advancement opportunities and increased impact of their research.Conclusion:In conclusion, submitting manuscripts for publication involves adhering to submission requirements, navigating the submission process, meeting acceptance criteria, and potentially reaping rewards for accepted publications. By understanding and following the guidelines set forth by journals, authors can increase their chances of success and contribute valuable research findings to the academic community.篇2Submission Requirements, Submission Methods, Acceptance, and RewardsSubmission Requirements:1. Submissions must be original and previously unpublished works.2. Submissions must be related to the specified theme or topic.3. Submissions must be written in English.4. Submissions must adhere to the specified word count and format guidelines.5. Submissions must be accompanied by a cover letter containing the author's contact information.Submission Methods:1. Submissions can be sent via email to the specified email address.2. Submissions can be uploaded to the specified online submission platform.3. Submissions can be mailed to the specified mailing address.Acceptance:1. Submissions will be reviewed by a panel of judges.2. Authors will be notified of the acceptance or rejection of their submissions.3. Accepted submissions will be published in the designated publication.Rewards:1. Authors of accepted submissions will receive a monetary reward.2. Authors of accepted submissions will receive a certificate of achievement.3. Authors of accepted submissions will have the opportunity to participate in special events or activities.In conclusion, authors are encouraged to carefully adhere to the submission requirements, choose the appropriate submission method, and await the acceptance notification and rewards for their hard work.篇3Submission Guidelines: Submission, Acceptance, RewardsSubmission Guidelines:To submit a manuscript for consideration, please follow these guidelines:************************************************* Word format.2. Include the title of your manuscript in the subject line.3. Include a cover letter with your contact information, a brief summary of your manuscript, and any relevant disclosures.4. Manuscripts must be original and not under consideration elsewhere.5. Ensure all co-author disclosures are included.6. Follow the journal's style guide for formatting and citation requirements.Acceptance Policy:Manuscripts are reviewed by our editorial team and external reviewers. Acceptance decisions are based on the quality, relevance, and originality of the manuscript. Authors will be notified of acceptance within 4-6 weeks of submission.Rewards:1. Publication: Accepted manuscripts will be published in the journal.2. Financial Reward: Authors of accepted manuscripts will receive a monetary reward based on the quality and impact of their work.3. Recognition: Authors will be recognized for their contributions in the journal and on the journal's website.4. Networking: Authors will have the opportunity to connect with other researchers, scholars, and professionals in their field.5. Career Advancement: Publication in a reputable journal can enhance an author's reputation and career prospects.Submit your manuscript today and be on your way to publication, rewards, and recognition!For any questions or further information, please contact******************.Thank you for considering submitting your work to our journal. We look forward to receiving your manuscript!。
LEOPOLD-FRANZENS UNIVERSITYChair of Engineering Mechanicso.Univ.-Prof.Dr.-Ing.habil.G.I.Schu¨e ller,Ph.D.G.I.Schueller@uibk.ac.at Technikerstrasse13,A-6020Innsbruck,Austria,EU Tel.:+435125076841Fax.:+435125072905 mechanik@uibk.ac.at,http://mechanik.uibk.ac.atIfM-Publication2-407G.I.Schu¨e ller.Developments in stochastic structural mechanics.Archive of Applied Mechanics,published online,2006.Archive of Applied Mechanics manuscript No.(will be inserted by the editor)Developments in Stochastic Structural MechanicsG.I.Schu¨e llerInstitute of Engineering Mechanics,Leopold-Franzens University,Innsbruck,Aus-tria,EUReceived:date/Revised version:dateAbstract Uncertainties are a central element in structural analysis and design.But even today they are frequently dealt with in an intuitive or qualitative way only.However,as already suggested80years ago,these uncertainties may be quantified by statistical and stochastic procedures. In this contribution it is attempted to shed light on some of the recent advances in the now establishedfield of stochastic structural mechanics and also solicit ideas on possible future developments.1IntroductionThe realistic modeling of structures and the expected loading conditions as well as the mechanisms of their possible deterioration with time are un-doubtedly one of the major goals of structural and engineering mechanics2G.I.Schu¨e ller respectively.It has been recognized that this should also include the quan-titative consideration of the statistical uncertainties of the models and the parameters involved[56].There is also a general agreement that probabilis-tic methods should be strongly rooted in the basic theories of structural en-gineering and engineering mechanics and hence represent the natural next step in the development of thesefields.It is well known that modern methods leading to a quantification of un-certainties of stochastic systems require computational procedures.The de-velopment of these procedures goes in line with the computational methods in current traditional(deterministic)analysis for the solution of problems required by the engineering practice,where certainly computational pro-cedures dominate.Hence,their further development within computational stochastic structural analysis is a most important requirement for dissemi-nation of stochastic concepts into engineering practice.Most naturally,pro-cedures to deal with stochastic systems are computationally considerably more involved than their deterministic counterparts,because the parameter set assumes a(finite or infinite)number of values in contrast to a single point in the parameter space.Hence,in order to be competitive and tractable in practical applications,the computational efficiency of procedures utilized is a crucial issue.Its significance should not be underestimated.Improvements on efficiency can be attributed to two main factors,i.e.by improved hard-ware in terms of ever faster computers and improved software,which means to improve the efficiency of computational algorithms,which also includesDevelopments in Stochastic Structural Mechanics3 utilizing parallel processing and computer farming respectively.For a con-tinuous increase of their efficiency by software developments,computational procedure of stochastic analysis should follow a similar way as it was gone in the seventieth and eighties developing the deterministic FE approach. One important aspect in this fast development was the focus on numerical methods adjusted to the strength and weakness of numerical computational algorithms.In other words,traditional ways of structural analysis devel-oped before the computer age have been dropped,redesigned and adjusted respectively to meet the new requirements posed by the computational fa-cilities.Two main streams of computational procedures in Stochastic Structural Analysis can be observed.Thefirst of this main class is the generation of sample functions by Monte Carlo simulation(MCS).These procedures might be categorized further according to their purpose:–Realizations of prescribed statistical information:samples must be com-patible with prescribed stochastic information such as spectral density, correlation,distribution,etc.,applications are:(1)Unconditional simula-tion of stochastic processes,fields and waves.(2)Conditional simulation compatible with observations and a priori statistical information.–Assessment of the stochastic response for a mathematical model with prescribed statistics(random loading/system parameters)of the param-eters,applications are:(1)Representative sample for the estimation of the overall distribution.4G.I.Schu¨e ller Indiscriminate(blind)generation of samples.Numerical integration of SDE’s.(2)Representative sample for the reliability assessment by gen-erating adverse rare events with positive probability,i.e.by:(a)variance reduction techniques controlling the realizations of RV’s,(b)controlling the evolution in time of sampling functions.The other main class provides numerical solutions to analytical proce-dures.Grouping again according to the respective purpose the following classification can be made:Numerical solutions of Kolmogorov equations(Galerkin’s method,Finite El-ement method,Path Integral method),Moment Closure Schemes,Compu-tation of the Evolution of Moments,Maximum Entropy Procedures,Asymp-totic Stability of Diffusion Processes.In the following,some of the outlined topics will be addressed stressing new developments.These topics are described within the next six subject areas,each focusing on a different issue,i.e.representation of stochastic processes andfields,structural response,stochastic FE methods and parallel processing,structural reliability and optimization,and stochastic dynamics. In this context it should be mentioned that aside from the MIT-Conference series the USNCCM,ECCM and WCCM’s do have a larger part of sessions addressing computational stochastic issues.Developments in Stochastic Structural Mechanics5 2Representation of Stochastic ProcessesMany quantities involving randomfluctuations in time and space might be adequately described by stochastic processes,fields and waves.Typical ex-amples of engineering interest are earthquake ground motion,sea waves, wind turbulence,road roughness,imperfection of shells,fluctuating prop-erties in random media,etc.For this setup,probabilistic characteristics of the process are known from various measurements and investigations in the past.In structural engineering,the available probabilistic characteristics of random quantities affecting the loading or the mechanical system can be often not utilized directly to account for the randomness of the structural response due to its complexity.For example,in the common case of strong earthquake motion,the structural response will be in general non-linear and it might be too difficult to compute the probabilistic characteristics of the response by other means than Monte Carlo simulation.For the purpose of Monte Carlo simulation sample functions of the involved stochastic pro-cess must be generated.These sample functions should represent accurately the characteristics of the underlying stochastic process orfields and might be stationary and non-stationary,homogeneous or non-homogeneous,one-dimensional or multi-dimensional,uni-variate or multi-variate,Gaussian or non-Gaussian,depending very much on the requirements of accuracy of re-alistic representation of the physical behavior and on the available statistical data.6G.I.Schu¨e ller The main requirement on the sample function is its accurate represen-tation of the available stochastic information of the process.The associ-ated mathematical model can be selected in any convenient manner as long it reproduces the required stochastic properties.Therefore,quite different representations have been developed and might be utilized for this purpose. The most common representations are e.g.:ARMA and AR models,Filtered White Noise(SDE),Shot Noise and Filtered Poisson White Noise,Covari-ance Decomposition,Karhunen-Lo`e ve and Polynomial Chaos Expansion, Spectral Representation,Wavelets Representation.Among the various methods listed above,the spectral representation methods appear to be most widely used(see e.g.[71,86]).According to this procedure,samples with specified power spectral density information are generated.For the stationary or homogeneous case the Fast Fourier Transform(FFT)techniques is utilized for a dramatic improvements of its computational efficiency(see e.g.[104,105]).Advances in thisfield provide efficient procedures for the generation of2D and3D homogeneous Gaus-sian stochasticfields using the FFT technique(see e.g.[87]).The spectral representation method generates ergodic sample functions of which each ful-fills exactly the requirements of a target power spectrum.These procedures can be extended to the non-stationary case,to the generation of stochastic waves and to incorporate non-Gaussian stochasticfields by a memoryless nonlinear transformation together with an iterative procedure to meet the target spectral density.Developments in Stochastic Structural Mechanics7 The above spectral representation procedures for an unconditional simula-tion of stochastic processes andfields can also be extended for Conditional simulations techniques for Gaussianfields(see e.g.[43,44])employing the conditional probability density method.The aim of this procedure is the generation of Gaussian random variates U n under the condition that(n−1) realizations u i of U i,i=1,2,...,(n−1)are specified and the a priori known covariances are satisfied.An alternative procedure is based on the so called Kriging method used in geostatistical application and applied also to con-ditional simulation problems in earthquake engineering(see e.g.[98]).The Kriging method has been improved significantly(see e.g.[36])that has made this method theoretically clearer and computationally more efficient.The differences and similarities of the conditional probability density methods and(modified)Kriging methods are discussed in[37]showing the equiva-lence of both procedures if the process is Gaussian with zero mean.A quite general spectral representation utilized for Gaussian random pro-cesses andfields is the Karhunen-Lo`e ve expansion of the covariance function (see e.g.[54,33]).This representation is applicable for stationary(homoge-neous)as well as for non-stationary(inhomogeneous)stochastic processes (fields).The expansion of a stochastic process(field)u(x,θ)takes the formu(x,θ)=¯u(x)+∞i=1ξ(θ) λiφi(x)(1)where the symbolθindicates the random nature of the corresponding quan-tity and where¯u(x)denotes the mean,φi(x)are the eigenfunctions andλi the eigenvalues of the covariance function.The set{ξi(θ)}forms a set of8G.I.Schu¨e ller orthogonal(uncorrelated)zero mean random variables with unit variance.The Karhunen-Lo`e ve expansion is mean square convergent irrespective of its probabilistic nature provided it possesses afinite variance.For the im-portant special case of a Gaussian process orfield the random variables{ξi(θ)}are independent standard normal random variables.In many prac-tical applications where the random quantities vary smoothly with respectto time or space,only few terms are necessary to capture the major part of the randomfluctuation of the process.Its major advantage is the reduction from a large number of correlated random variables to few most important uncorrelated ones.Hence this representation is especially suitable for band limited colored excitation and stochastic FE representation of random me-dia where random variables are usually strongly correlated.It might also be utilized to represent the correlated stochastic response of MDOF-systems by few most important variables and hence achieving a space reduction.A generalization of the above Karhunen-Lo`e ve expansion has been proposed for application where the covariance function is not known a priori(see[16, 33,32]).The stochastic process(field)u(x,θ)takes the formu(x,θ)=a0(x)Γ0+∞i1=1a i1(x)Γ1(ξi1(θ))+∞i1=1i1i2=1a i1i2(x)Γ2(ξi1(θ),ξi2(θ))+ (2)which is denoted as the Polynomial Chaos Expansion.Introducing a one-to-one mapping to a set with ordered indices{Ψi(θ)}and truncating eqn.2Developments in Stochastic Structural Mechanics9 after the p th term,the above representations reads,u(x,θ)=pj=ou j(x)Ψj(θ)(3)where the symbolΓn(ξi1,...,ξin)denotes the Polynomial Chaos of order nin the independent standard normal random variables.These polynomialsare orthogonal so that the expectation(or inner product)<ΨiΨj>=δij beingδij the Kronecker symbol.For the special case of a Gaussian random process the above representation coincides with the Karhunen-Lo`e ve expan-sion.The Polynomial Chaos expansion is adjustable in two ways:Increasingthe number of random variables{ξi}results in a refinement of the random fluctuations,while an increase of the maximum order of the polynomialcaptures non-linear(non-Gaussian)behavior of the process.However,the relation between accuracy and numerical efforts,still remains to be shown. The spectral representation by Fourier analysis is not well suited to describe local feature in the time or space domain.This disadvantage is overcome in wavelets analysis which provides an alternative of breaking a signal down into its constituent parts.For more details on this approach,it is referred to[24,60].In some cases of applications the physics or data might be inconsistent with the Gaussian distribution.For such cases,non-Gaussian models have been developed employing various concepts to meet the desired target dis-tribution as well as the target correlation structure(spectral density).Cer-tainly the most straight forward procedures is the above mentioned memo-ryless non-linear transformation of Gaussian processes utilizing the spectralrepresentation.An alternative approach utilizes linear and non-linearfil-ters to represent normal and non-Gaussian processes andfields excited by Gaussian white noise.Linearfilters excited by polynomial forms of Poisson white noise have been developed in[59]and[34].These procedures allow the evaluation of moments of arbitrary order without having to resort to closure techniques. Non-linearfilters are utilized to generate a stationary non-Gaussian stochas-tic process in agreement with a givenfirst-order probability density function and the spectral density[48,15].In the Kontorovich-Lyandres procedure as used in[48],the drift and diffusion coefficients are selected such that the solutionfits the target probability density,and the parameters in the solu-tion form are then adjusted to approximate the target spectral density.The approach by Cai and Lin[15]simplifies this procedure by matching the spec-tral density by adjusting only the drift coefficients,which is the followed by adjusting the diffusion coefficient to approximate the distribution of the pro-cess.The latter approach is especially suitable and computationally highly efficient for a long term simulation of stationary stochastic processes since the computational expense increases only linearly with the number n of dis-crete sample points while the spectral approach has a growth rate of n ln n when applying the efficient FFT technique.For generating samples of the non-linearfilter represented by a stochastic differential equations(SDE), well developed numerical procedures are available(see e.g.[47]).3Response of Stochastic SystemsThe assessment of the stochastic response is the main theme in stochastic mechanics.Contrary to the representation of of stochastic processes and fields designed tofit available statistical data and information,the output of the mathematical model is not prescribed and needs to be determined in some stochastic sense.Hence the mathematical model can not be selected freely but is specified a priori.The model involves for stochastic systems ei-ther random system parameters or/and random loading.Please note,due to space limitations,the question of model validation cannot be treated here. For the characterization of available numerical procedures some classifi-cations with regard to the structural model,loading and the description of the stochastic response is most instrumental.Concerning the structural model,a distinction between the properties,i.e.whether it is determinis-tic or stochastic,linear or non-linear,as well as the number of degrees of freedom(DOF)involved,is essential.As a criterion for the feasibility of a particular numerical procedure,the number of DOF’s of the structural system is one of the most crucial parameters.Therefore,a distinction be-tween dynamical-system-models and general FE-discretizations is suggested where dynamical systems are associated with a low state space dimension of the structural model.FE-discretization has no essential restriction re-garding its number of DOF’s.The stochastic loading can be grouped into static and dynamic loading.Stochastic dynamic loading might be charac-terized further by its distribution and correlation and its independence ordependence on the response,resulting in categorization such as Gaussian and non-Gaussian,stationary and non-stationary,white noise or colored, additive and multiplicative(parametric)excitation properties.Apart from the mathematical model,the required terms in which the stochastic re-sponse should be evaluated play an essential role ranging from assessing thefirst two moments of the response to reliability assessments and stabil-ity analysis.The large number of possibilities for evaluating the stochas-tic response as outlined above does not allow for a discussion of the en-tire subject.Therefore only some selected advances and new directions will be addressed.As already mentioned above,one could distinguish between two main categories of computational procedures treating the response of stochastic systems.Thefirst is based on Monte Carlo simulation and the second provides numerical solutions of analytical procedures for obtaining quantitative results.Regarding the numerical solutions of analytical proce-dures,a clear distinction between dynamical-system-models and FE-models should be made.Current research efforts in stochastic dynamics focus to a large extent on dynamical-system-models while there are few new numerical approaches concerning the evaluation of the stochastic dynamic response of e.g.FE-models.Numerical solutions of the Kolmogorov equations are typical examples of belonging to dynamical-system-models where available approaches are computationally feasible only for state space dimensions one to three and in exceptional cases for dimension four.Galerkin’s,Finite El-ement(FE)and Path Integral methods respectively are generally used tosolve numerically the forward(Fokker-Planck)and backward Kolmogorov equations.For example,in[8,92]the FE approach is employed for stationary and transient solutions respectively of the mentioned forward and backward equations for second order systems.First passage probabilities have been ob-tained employing a Petrov-Galerkin FE method to solve the backward and the related Pontryagin-Vitt equations.An instructive comparison between the computational efforts using Monte Carlo simulation and the FE-method is given e.g.in an earlier IASSAR report[85].The Path Integral method follows the evolution of the(transition)prob-ability function over short time intervals,exploiting the fact that short time transition probabilities for normal white noise excitations are locally Gaus-sian distributed.All existing path integration procedures utilize certain in-terpolation schemes where the probability density function(PDF)is rep-resented by values at discrete grid points.In a wider sense,cell mapping methods(see e.g.[38,39])can be regarded as special setups of the path integral procedure.As documented in[9],cumulant neglect closure described in section7.3 has been automated putational procedures for the automated generation and solutions of the closed set of moment equations have been developed.The method can be employed for an arbitrary number of states and closed at arbitrary levels.The approach,however,is limited by available computational resources,since the computational cost grows exponentially with respect to the number of states and the selected closurelevel.The above discussed developments of numerical procedures deal with low dimensional dynamical systems which are employed for investigating strong non-linear behavior subjected to(Gaussian)white noise excitation. Although dynamical system formulations are quite general and extendible to treat non-Gaussian and colored(filtered)excitation of larger systems,the computational expense is growing exponentially rendering most numerical approaches unfeasible for larger systems.This so called”curse of dimen-sionality”is not overcome yet and it is questionable whether it ever will be, despite the fast developing computational possibilities.For this reason,the alternative approach based on Monte Carlo simu-lation(MCS)gains importance.Several aspects favor procedures based on MCS in engineering applications:(1)Considerably smaller growth rate of the computational effort with dimensionality than analytical procedures.(2) Generally applicable,well suited for parallel processing(see section5.1)and computationally straight forward.(3)Non-linear complex behavior does not complicate the basic procedure.(4)Manageable for complex systems.Contrary to numerical solutions of analytical procedures,the employed structural model and the type of stochastic loading does for MCS not play a deceive role.For this reason,MCS procedures might be structured ac-cording to their purpose i.e.where sample functions are generated either for the estimation of the overall distribution or for generating rare adverse events for an efficient reliability assessment.In the former case,the prob-ability space is covered uniformly by an indiscriminate(blind)generationof sample functions representing the random quantities.Basically,at set of random variables will be generated by a pseudo random number generator followed by a deterministic structural analysis.Based on generated random numbers realizations of random processes,fields and waves addressed in section2,are constructed and utilized without any further modification in the following structural analysis.The situation may not be considered to be straight forward,however,in case of a discriminate MCS for the reliability estimation of structures,where rare events contributing considerably to the failure probability should be gener-ated.Since the effectiveness of direct indiscriminate MCS is not satisfactory for producing a statistically relevant number of low probability realizations in the failure domain,the generation of samples is restricted or guided in some way.The most important class are the variance reduction techniques which operate on the probability of realizations of random variables.The most widely used representative of this class in structural reliability assess-ment is Importance Sampling where a suitable sampling distribution con-trols the generation of realizations in the probability space.The challenge in Importance Sampling is the construction of a suitable sampling distribu-tion which depends in general on the specific structural system and on the failure domain(see e.g.[84]).Hence,the generation of sample functions is no longer independent from the structural system and failure criterion as for indiscriminate direct MCS.Due to these dependencies,computational procedures for an automated establishment of sampling distributions areurgently needed.Adaptive numerical strategies utilizing Importance Direc-tional sampling(e.g.[11])are steps in this direction.The effectiveness of the Importance sampling approach depends crucially on the complexity of the system response as well as an the number of random variables(see also section5.2).Static problems(linear and nonlinear)with few random vari-ables might be treated effectively by this approach.Linear systems where the randomness is represented by a large number of RVs can also be treated efficiently employingfirst order reliability methods(see e.g.[27]).This ap-proach,however,is questionable for the case of non-linear stochastic dynam-ics involving a large set of random variables,where the computational effort required for establishing a suitable sampling distribution might exceed the effort needed for indiscriminate direct MCS.Instead of controlling the realization of random variables,alternatively the evolution of the generated sampling can be controlled[68].This ap-proach is limited to stochastic processes andfields with Markovian prop-erties and utilizes an evolutionary programming technique for the genera-tion of more”important”realization in the low probability domain.This approach is especially suitable for white noise excitation and non-linear systems where Importance sampling is rather difficult to apply.Although the approach cannot deal with spectral representations of the stochastic processes,it is capable to make use of linearly and non-linearlyfiltered ex-citation.Again,this is just contrary to Importance sampling which can be applied to spectral representations but not to white noisefiltered excitation.4Stochastic Finite ElementsAs its name suggests,Stochastic Finite Elements are structural models rep-resented by Finite Elements the properties of which involve randomness.In static analysis,the stiffness matrix might be random due to unpredictable variation of some material properties,random coupling strength between structural components,uncertain boundary conditions,etc.For buckling analysis,shape imperfections of the structures have an additional impor-tant effect on the buckling load[76].Considering structural dynamics,in addition to the stiffness matrix,the damping properties and sometimes also the mass matrix might not be predictable with certainty.Discussing numerical Stochastic Finite Elements procedures,two cat-egories should be distinguished clearly.Thefirst is the representation of Stochastic Finite Elements and their global assemblage as random structural matrices.The second category addresses the evaluation of the stochastic re-sponse of the FE-model due to its randomness.Focusingfirst on the Stochastic FE representation,several representa-tions such as the midpoint method[35],the interpolation method[53],the local average method[97],as well as the Weighted-Integral-Method[94,25, 26]have been developed to describe spatial randomfluctuations within the element.As a tendency,the midpoint methods leads to an overestimation of the variance of the response,the local average method to an underestima-tion and the Weighted-Integral-Method leads to the most accurate results. Moreover,the so called mesh-size problem can be resolved utilizing thisrepresentation.After assembling all Finite Elements,the random structural stiffness matrix K,taken as representative example,assumes the form,K(α)=¯K+ni=1K Iiαi+ni=1nj=1K IIijαiαj+ (4)where¯K is the mean of the matrix,K I i and K II ij denote the determinis-ticfirst and second rate of change with respect to the zero mean random variablesαi andαj and n is the total number of random variables.For normally distributed sets of random variables{α},the correlated set can be represented advantageously by the Karhunen-Lo`e ve expansion[33]and for non-Gaussian distributed random variables by its Polynomial chaos ex-pansion[32],K(θ)=¯K+Mi=0ˆKiΨi(θ)(5)where M denotes the total number of chaos polynomials,ˆK i the associated deterministicfluctuation of the matrix andΨi(θ)a polynomial of standard normal random variablesξj(θ)whereθindicates the random nature of the associated variable.In a second step,the random response of the stochastic structural system is determined.The most widely used procedure for evaluating the stochastic response is the well established perturbation approach(see e.g.[53]).It is well adapted to the FE-formulation and capable to evaluatefirst and second moment properties of the response in an efficient manner.The approach, however,is justified only for small deviations from the center value.Since this assumption is satisfied in most practical applications,the obtainedfirst two moment properties are evaluated satisfactorily.However,the tails of the。
Manuscript After VerificationAfter the manuscript has been verified, it enters the next stage of the publishing process. This stage is crucial as it determines the overall quality and presentation of the final published work.During verification, the manuscript is checked for any errors or discrepancies. This includes grammar, spelling, punctuation, and formatting errors. The aim is to ensure that the manuscript is free from any mistakes that could undermine its credibility and readability.Once the manuscript has been verified, the publisher typically assigns a copy editor. The copy editor's role is to review the manuscript for any inconsistencies, redundancies, or unclear language. They also ensure that the manuscript follows the publisher's style guide and formatting requirements. In addition to copy editing, the manuscript may also undergo substantive editing. This involves restructuring the argument, improving the flow of the text, and ensuring that the content is as accurate and up-to-date as possible. The editor may also provide feedback on the overall quality and coherence of the work.After the editing process is complete, the manuscript is sent back to the author for review and approval. At this stage, the author has the opportunityto make any necessary changes or corrections. Once the author approves the edited manuscript, it is ready for publication.Publishing a manuscript is a time-consuming and meticulous process that requires attention to detail and quality control. Each stage of the process plays a crucial role in ensuring that the final published work is of the highest possible standard.。
中国电机工程学报英文稿The Chinese Journal of Electrical Engineering ManuscriptAbstract:The Chinese Journal of Electrical Engineering aims to provide a platform for researchers, scholars, and professionals in the field of electrical engineering to present their latest research findings and technological advancements. This article discusses the importance of the English manuscript submission for the journal and provides guidelines and format requirements for authors to follow.Introduction:In today's globalized world, scientific research and technological advancements have no borders. The Chinese Journal of Electrical Engineering recognizes the significance of international collaborations and knowledge exchange in enhancing the field of electrical engineering. Therefore, the journal has introduced the option for authors to submit their manuscripts in English.Benefits of English Manuscript Submission:1. Global Exposure: By submitting manuscripts in English, researchers can reach a broader international audience, allowing for a wider dissemination of their findings. This promotes cross-cultural collaboration and knowledge sharing.2. Increased Impact: English is the lingua franca of scientific communication. Publishing in English allows researchers to attract a largernumber of readers, which can lead to higher citation rates and increased impact for their work.3. Networking Opportunities: English manuscript submission facilitates connections with experts and scholars working in similar research areas around the world. This enables researchers to participate in international conferences, workshops, and collaborations, further advancing their own research and career opportunities.Guidelines for English Manuscript Submission:1. Abstract: Provide a concise summary of the research objectives, methods, key findings, and conclusions. The abstract should not exceed 250 words.2. Introduction: Clearly state the research background, objectives, and significance of the study. Introduce the research problem and outline the methodology.3. Literature Review: Provide a comprehensive analysis of the existing literature related to the research topic. Highlight the gap in knowledge that the study aims to address.4. Methodology: Describe the experimental design, data collection procedures, and statistical analysis methods used in the study. Provide sufficient detail for other researchers to replicate the experiments.5. Results and Discussion: Present the research findings in a logical and coherent manner. Use tables, figures, and graphs where appropriate to enhance clarity. Discuss the significance of the results and compare them with previous studies.6. Conclusion: Summarize the key findings of the study and their implications. Highlight the novelty and contributions of the research. Avoid the introduction of new information or research questions.7. References: Cite all relevant sources according to the journal's citation style. Ensure accuracy and consistency in formatting the references.8. Language and Formatting: Use clear and concise language. Proofread the manuscript carefully for grammar, spelling, and punctuation errors. Format the manuscript according to the journal's guidelines, including font size, line spacing, and margin requirements.Conclusion:The introduction of English manuscript submission in the Chinese Journal of Electrical Engineering represents a progressive step towards globalizing research in the field of electrical engineering. By adhering to the guidelines and format requirements mentioned above, authors can contribute to international scholarly exchange and improve the visibility and impact of their research findings. We encourage researchers to embrace this opportunity and contribute to the growing body of knowledge in their respective area of expertise.。
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.。
geroscience manuscript 格式The format of a manuscript for submission to a scientific journal in the field of geroscience (the study of aging and its related processes) typically follows the guidelines provided by the specific journal to which you are submitting. Different journals may have slightly different formatting requirements, and it's crucial to adhere to the specific guidelines provided by the target journal.However, there are general guidelines that are common across many scientific journals. Here is an example of a basic manuscript format:1. Title Page:• Title: Concise and informative.• Authors: Full names, affiliations, and email addresses of all authors.• Corresponding Author: Clearly indicate who will handle correspondence at all stages of review and publication.2. Abstract:• A brief summary of the study, including objectives, methods, results, and conclusions.3. Keywords:• Provide a list of keywords that capture the main topics of the manuscript.4. Introduction:• Clearly state the research question, objectives, and the background of the study.5. Methods:• Describe the study design, participants, procedures, and statistical methods.6. Results:• Present the findings with the help of tables, figures, and text.7. Discussion:• Interpret the results, discuss their implications, and relate them to existing literature.8. Conclusion:• Summarize the main findings and suggest potential implications and areas for future research.9. Acknowledgments:• Acknowledge individuals or organizations that contributed to the research.10. References:• Cite all sources used in the manuscript following a specific citation style (e.g., APA, MLA, Chicago).11. Figures and Tables:• Include any figures and tables with appropriate captions. Ensure they are cited in the text.12. Supplementary Material:• If applicable, include any supplementary material, data, or additional information.Always check the specific guidelines of the target journal for any additional requirements, such as preferred citation style, formatting of references, figure resolutions, and specific manuscript length restrictions.When in doubt, consult the author guidelines provided by the journal or contact the editorial office for clarification. Different journals may have different requirements, and adherence to these guidelines is crucial for successful manuscript submission and peer review.。
74Invitation for Manuscript Submission Confucian Academy (Chinese Thought and Culture Review)Offi cially launched in August 2014, the journal Confucian Academy (Chinese Th ought and Culture Review) [ISSN 2095–8536, CN 52–5035/C] is a leading Chinese–English bilingual scholarly journal dedicated to traditional Chinese thought and culture in prompting conversations among world civilizations.Confucian Academy cordially invites the submission of manuscripts for consideration for the next issue. Authors may submit manuscripts in Chinese or English while Chinese–English bilingual manuscripts are strongly preferred, in which case authors will receive a double payment upon publication. The corresponding author of an accepted manuscript will be notifi ed and receive credit for payment. Confucian Academy additionally provides the corresponding author with two complimentary copies of the print issue in which the article appears.1. Main SectionsAcademic Forum, Traditional Chinese Philosophy, Yangming Culture, Masters of Chinese Studies, Horizon of Sinology, and Translations of Chinese Th ought and Culture2. Manuscript Format and StyleTh e papers should meet the general criteria of signifi cance and academic merits with reliable reference. Chinese manuscripts should generally be 7,000 to 12,000 words in length; English manuscripts no more than 7,000 words. Title, abstract, keywords, biographical notes, text, and references are required in each manuscript.1) Abstract and KeywordsSubmissions must include an abstract of up to 200 words and three to six keywordsor phrases for indexing purposes.2) Biographical Notes, Affi liations, and Full Contact DetailsAll manuscripts are to be supplied with 200-word biographical notes, academicaffi liations, and full contact information for all authors including e-mail, mailingaddress, and telephone numbers.3) References and FootnotesAll references are included as footnotes. Manuscripts should indicate footnotesin text by a superscript number starting with “1” and number them consecutivelythroughout the entire manuscript. Detailed requirements are as follows:Book: Author(s), Title of book, Edition number (Place of publication: Publisher,Year of publication), Page(s).Chapter in Book: Author(s), “Title of chapter,” in ch. xx of Title of book (Placeof publication: Publisher, Year of Publication), Inclusive pages.Copyright©博看网. All Rights Reserved.Book in Series: Author(s), Title of book, in Title of book series, Editor(s) orCompiler(s), (Place of publication: Publisher, Year of publication), Page(s).Article in Journal: Author(s), “Title of article,” Name of the journal Volumenumber, Issue number (Year of publication): Inclusive pages.Translation: Translator(s), trans., Title of book (Place of publication: Publisher,Year of publication).Non-English Publication with Title Translation: Author(s), Original title ofbook [Title translation] (Place of publication: Publisher, Year of publication),Inclusive pages.Electronic/Online Sources: Author(s), Title of book, Web sites, Access time.3. Additional Requirements1) Manuscripts must be submitted electronically as Word documents to the editorat ***************. Submissions must not have been previously publishednor be under consideration by another publication. Time from submission topublication decision averages three months.2) All accepted manuscripts are subject to editorial revisions and copyediting forclarity, punctuation, grammar, syntax, and conformity to journal style. Theauthors bear sole responsibility for all statements made in the manuscript.3) Articles in Confucian Academy will be included in the China National KnowledgeInfrastructure (CNKI) database and will be reprinted by Replicated Journals ofthe Information Center for Social Sciences, Renmin University of China. Pleaseindicate if you disagree.Contact the Editorial Offi ce for further information372 Baoshan North Road, Yunyan District, Guiyang, Guizhou, China 550001Building No. 1, International Center for Chinese Culture Studies, Guiyang Confucius Academy, Huaxi District, Guiyang, Guizhou, China 550025E-mail: ***************Phone: +86-851-8698142775Copyright©博看网. All Rights Reserved.。
Submitted to???manuscript(Please,provide the mansucript number!)OR/MS Models for Supply Chain Disruptions:AReviewLawrence V.SnyderDept.of Industrial and Systems Engineering,Lehigh University,Bethlehem,PA,USA,larry.snyder@Z¨u mb¨u l AtanDept.of Industrial Engineering and Innovation Sciences,Eindhoven University of Technology,Eindhoven,The Netherlands,Z.Atan@tue.nlPeng PengDept.of Management Science,City University of Hong Kong,Hong Kong,adxypeng@.hkYing RongDepartment of Operations Management,Shanghai Jiao Tong University,Shanghai,China,rong@Amanda J.SchmittCenter for Transportation and Logistics,Massachusetts Institute of Technology,Cambridge,MA,USA,aschmitt@Burcu SinsoysalErnst&Young,Istanbul,Turkey,burcu.sinsoysal@We review the OR/MS literature on supply chain disruptions in order to take stock of the research to date and to provide an overview of the research questions that have been addressed.Wefirst place disruptions in the context of other forms of supply uncertainty and discuss common modeling approaches.We then discuss nearly150scholarly works on the topic,organized into six categories:evaluating supply disruptions;strategic decisions;sourcing decisions;contracts and incentives;inventory;and facility location.We conclude with a discussion of future research directions.Key words:supply chain disruptions,literature review,inventory management,facility location,sourcingdecisionsHistory:September20,20101.IntroductionIn the past decade,academics and practitioners have become increasingly interested in supply chain disruptions,which are caused by both natural disasters(floods,earthquakes,etc.)and intentional or unintentional human actions(industrial accidents,terrorist strikes,etc.).Academic journals and supply chain trade magazines have published numerous articles on the topic;universities have held workshops to discuss it;and OR/MS Today published a cover story about it(Clausen et al.2001).1Snyder et al.:Supply Chain Disruptions:A Review 2Article submitted to ???;manuscript no.(Please,provide the mansucript number!)Figure 1Histogram of dates of disruption-related works (journal articles,working papers,books,etc.)cited inthis review.64356551024354705101520253035404550<19901991-921993-941995-961997-981999-002001-022003-042005-062007-082009-10P a p e r C o u n t Figure 2Breakdown of journals in which disruption-related papers cited in this review were published.Workingpapers,books,and journals with fewer than three cited articles are excluded.International Journal of Production Economics, 11Naval Research Logistics, 10Management Science, 9Operations Research, 9European Journal of Operational Research, 8Computers & Operations Research, 7M&SOM, 5Operations Research Letters, 4Journal of Operations Management, 3Omega, 3Production and Operations Management, 3The academic literature on supply chain disruptions has increased sharply during this time;see Figure 1for a histogram of the dates of disruption-related works cited in this review.These papers have been published in the top journals in the field;see Figure 2.Supply chain disruptions are not new,of course;they have existed as long as supply chains have.So why the recent explosion of interest?We believe there are four main reasons.First,several high-Snyder et al.:Supply Chain Disruptions:A ReviewArticle submitted to???;manuscript no.(Please,provide the mansucript number!)3 profile events,including the terrorist attacks of September11,2001,the west-coast port lockout in2002,and Hurricane Katrina in2005,brought disruptions into the forefront of public attention. Second,some practitioners and researchers have concluded that the just-in-time(JIT)philosophy popular in recent decades increases supply chains’vulnerability to disruptions,since a tightly optimized,lean design,which performs well under normal situations,leaves little room for error when circumstances change drastically.Third,firms are much less vertically integrated than in the past,and their supply chains are increasingly global;suppliers are located throughout the world, some in regions that are politically or economically unstable.Finally,the topic has simply gained a critical momentum;like any maturing research area,scholars study the topic because their interest is sparked by emerging research and by increased attention to the topic in industry.It is tempting to think of supply chain disruptions as rare events.However,while a given type of disruption(earthquake,fire,strike)may occur very infrequently,the large number of possible disruption causes,coupled with the vast scale of modern supply chains,makes the likelihood that some disruption will strike a given supply chain in a given year quite high.(Some supply chains face disruptions nearly every day;Wal-Mart even has an emergency operations center dedicated to preparing for and mitigating the effects of man-made and natural disasters.)Even a small disruption can have a devastating impact as it cascades through a supply chain.For example,in1998,strikes at two General Motors parts plants led to the shutdown of100other parts plants,then26assembly plants,leaving dealer lots vacant for months(Simison1998).The economic impact of disruptions can be enormous.In a series of empirical studies,Hendricks and Singhal (2003,2005b,2005a)examine several hundred supply chain“glitches”reported in the Wall Street Journal and the Dow Jones News Service in the1990s.Theyfind that companies that experienced even minor disruptions faced significant declines in sales growth,stock returns,and shareholder wealth,and that these effects tended to linger for at least two years after the disruption.The purpose of this review article is to take stock of the literature that has appeared to date and to provide an overview of the research questions that have been addressed.Our focus is onSnyder et al.:Supply Chain Disruptions:A Review 4Article submitted to???;manuscript no.(Please,provide the mansucript number!)papers that use operations research/management science(OR/MS)methods to address supply chain disruptions.(We define the scope of our review more precisely in Section1.2.)In the subsections that remain in Section1,we place disruptions in the context of other forms of supply uncertainty,delineate the scope of our review,discuss the ways in which disruptions are typically modeled,and summarize the mitigation strategies that have been studied most commonly. Sections2–7discuss the literature,organized into six categories:strategic decisions;evaluating supply disruptions;sourcing decisions;contracts and incentives;inventory;and facility location. Finally,we summarize in Section8and suggest directions for future research.1.1.Forms of Supply UncertaintySeveral forms of supply uncertainty have been discussed in the literature.Disruptions are random events that cause a supplier or other element of the supply chain to stop functioning,either com-pletely or partially,for a(typically random)amount of time.In most models,disruptions affect a firm’s supplier;during a disruption,the supplier cannot provide any goods.Under yield uncertainty, the quantity delivered by a supplier or produced by a manufacturing process is a random variable that depends on the order quantity.A closely related concept is capacity uncertainty,in which the supplier’s delivery capacity or thefirm’s manufacturing capacity is a random variable that is typically independent of the order quantity.Lead-time uncertainty represents stochasticity in the order or processing lead time.Input cost uncertainty represents stochasticity in the procurement prices incurred by thefirm.The boundaries among these forms of supply uncertainty are often blurry.In fact,disruptions can often be viewed as a special case of yield uncertainty in which the yield is a Bernoulli random variable.However,yield uncertainty generally implies a continuous form of uncertainty,whereas disruptions are discrete,and therefore the two are often quite different in terms of both the approach toward modeling them and the managerial insights gained from them.The same is true for capacity uncertainty and lead-time uncertainty.Snyder et al.:Supply Chain Disruptions:A ReviewArticle submitted to???;manuscript no.(Please,provide the mansucript number!)5 1.2.Scope of ReviewWe have attempted to provide as complete a review as possible on the topic of supply chain disruptions.Undoubtedly,we have inadvertently omitted some relevant papers,and for that we apologize both to our readers and to the authors of the overlooked papers.In order to limit this article to a manageable scope,we have intentionally omitted several important,related topics: 1.Other Forms of Supply Uncertainty.Although disruptions are sometimes viewed as a special case of yield,capacity,or lead-time uncertainty,because of the modeling and managerial differences between them(see Section1.1),we have opted to omit the literature on these forms of supply uncertainty,except papers that deal with both disruptions and another form of supply uncertainty, and a few others.We refer the interested reader to the reviews on yield uncertainty by Grosfeld-Nir and Gerchak(2004)and Yano and Lee(1995);for a textbook treatment of lead-time uncertainty, see Zipkin(2000).2.Supply Chain Risk Management.Risk management is a broad topic that encompasses not only disruptions but also other forms of supply chain risk,includingfinancial and operational risks. In this paper,we consider only disruption risks,in the form of supplier unavailability,inaccessible facilities,production interruptions,lost capacity,and so on.See Tang(2006a)for a review of supply chain risk management more broadly.3.Disaster Relief and Homeland Security.Like the literature on supply disruptions,research on OR models for disaster relief and homeland security has grown steadily in the past several years, especially since9/11.Although these bodies of literature share a similar goal—get supplies where it is needed after a massively disruptive event—the modeling approaches are somewhat different: Disaster relief and homeland security models are generally concerned with large,unanticipated spikes in demand(e.g.,for food(Ekici2009),generators(Lodree and Taskin2009),etc.)or uncer-tainty in transportation links,whereas the models discussed in this review are concerned more with unanticipated disruptions to supply.For more on this topic,see Ergun et al.(2010)or Boin et al. (2010)and the references therein.Snyder et al.:Supply Chain Disruptions:A Review 6Article submitted to???;manuscript no.(Please,provide the mansucript number!)work Reliability.The facility location problems discussed in Section7are related to the literature on network reliability,which attempts to calculate the probability that a network remains connected after disruptions,or to optimize the design of a network with a connectivity objective in work reliability models sometimes consider the cost of constructing a network but, unlike the models in Section7,usually ignore the increased routing cost that results from a dis-ruption;that is,they focus more on connectivity than on cost since they are usually applied to power or telecommunications networks rather than transportation networks.We refer the reader to the review by Kerivin and Mahjoub(2005)and the textbooks by Colbourn(1987),Shier(1991), and Shooman(2002).5.Machine Breakdowns.Machine breakdowns are a type of disruption and,like other disruptions, can have an impact throughout the supply chain.There is an extensive literature on machine breakdowns in the context of both scheduling and queuing problems.We omit these papers from our review since they are generally concerned with evaluating the performance measures of such systems,rather than optimizing their policy parameters,and since they usually consider frequent, and often planned,disruptions such as routine maintenance.6.Facility Congestion.Congestion refers to the unavailability of a facility(e.g.,an ambulance orfire crew)while it is serving another demand.Facility location models with congestion account for this risk when making location decisions.Although congestion may be viewed as a type of disruption,congestion-related disruptions are derived from demand,rather than supply,and there-fore they fall somewhat outside the scope of this review.For reviews of the literature on facility congestion problems,see Daskin et al.(1988)or Berman and Krass(2002).7.Qualitative Papers.This review is concerned with quantitative,OR/MS-based modeling approaches for supply chain disruptions.Therefore,we do not review the many papers and books that are interested in qualitative descriptions of supply chain vulnerability and strategies for dis-ruption mitigation and that have appeared in the popular press(e.g.,Lynn2005,Sheffi2005), in business trade magazines(Elkins et al.2005,Simchi-Levi et al.2002),and in management journals(Knemeyer et al.2009,Lee and Whang2005,Sheffi2001,Stauffer2003).Snyder et al.:Supply Chain Disruptions:A ReviewArticle submitted to???;manuscript no.(Please,provide the mansucript number!)7 Other reviews and surveys of supply chain disruptions exist.Vakharia and Yenipazarli(2008) review the OR/MS and qualitative literature on supply chain disruptions.Natarajarathinam et al. (2009)review current practices and some quantitative research on managing disruptions.Schmitt and Tomlin(2010)review models for sourcing mitigation(see Section4below),while Atan and Snyder(2010)review models for inventory mitigation(see Section6below).Snyder et al.(2006) and Snyder and Daskin(2007)review models for facility location and network design with dis-ruptions(see Section7below).Vanany et al.(2009)review and classify literature on supply chain risk management,focusing primarily on management journals.Tang(2006a)also reviews supply chain risk management more broadly,including some papers on disruptions in particular.The textbook by Yu and Qi(2004)discusses mathematical programming models for disruption man-agement strategies in scheduling and supply chain contexts.The book by Murray and Grubesic (2006)discusses critical infrastructure reliability from a geographical modeling perspective.To our knowledge,ours is the most comprehensive review to date of OR/MS models for coping with supply chain disruptions.1.3.Modeling DisruptionsMost of the papers discussed in this review model disruptions in an abstract way and are applicable to a wide range of disruption types and characteristics.The most common way that disruptions are modeled is to assume that the supply process has two states,one in which it functions normally and one in which it is disrupted.We will refer to the former state as the“up”state and the latter as the “down”state.1Typically the supply capacity is infinite during up periods and is zero during down periods,though some papers consider in-between cases in which disruptions do not completely eliminate the capacity,or in which the supplier hasfinite capacity even during up periods. Typically,the system remains in the up state for a random amount of time,and then in the down state for a random amount of time.The most common assumption is that the duration of both the up period and the down period are exponentially distributed(in the continuous-time case)or geometrically distributed(for discrete-time models).Under this assumption,the supply processSnyder et al.:Supply Chain Disruptions:A Review 8Article submitted to???;manuscript no.(Please,provide the mansucript number!)forms a two-state Markov chain whose parameters are generally referred to as the disruption and recovery rates(for continuous-time models)or the disruption and recovery probabilities(for discrete-time models).This simple supply model isflexible enough to accommodate a spectrum of disruption profiles ranging from infrequent-but-long to frequent-but-short.(Two disruption processes may have the same steady-state probability of being disrupted but may have very different disruption profiles.)Some papers use a simpler supply model in which,for example,the disruption length is deter-ministic or the supply process is Bernoulli(a special case of the two-state Markov model in which the probability of disruption in the next period is the same whether the current period is disrupted or not).Other papers use more general distributions such as Erlang-k or even allow the distribution to remain unspecified.The vast majority of the papers discussed in this review use some variation of this supply model,although exceptions exist.For example,Snyder and Tomlin(2008)allow the disruption probabilities themselves to change in a Markovian manner over time,and Song and Zipkin(1996)assume that orders progress through the supply process randomly over time using a Markov model that is general enough to accommodate disruptions,random lead times,and so on. All of these modeling approaches require estimates of the disruption parameters(disruption and recovery probabilities,etc.).For some disruptions,such as those caused by poor weather, reliable historical data may be available for estimating these parameters.On the other hand,these parameters must be estimated subjectively for disruptions that have occurred infrequently in the past,such as those caused by aflu pandemic.Most of the OR/MS literature on supply disruptions assumes that these parameters are known with certainty and ignores the difficulties inherent in estimating them.The literature uses a wide range of assumptions about what part of the supply/replenishment process is disrupted.Can thefirm place orders during a disruption?Can it receive orders?Can orders be shipped from a disrupted supplier if it has sufficient inventory?Does a disruption affect items that are already in transit?These questions are answered differently in each paper;no common convention has yet emerged.Some papers treat disruptions as though they disable theSnyder et al.:Supply Chain Disruptions:A ReviewArticle submitted to???;manuscript no.(Please,provide the mansucript number!)9 supplier:no orders can be placed,but orders that have been shipped to thefirm but not yet received are unaffected.Others treat disruptions as though they occur in the transportation process:orders can be placed but not shipped,and items in transit are“paused”until the disruption ends.Still others assume that disruptions occur at thefirm itself,effectively pausing all inbound and outbound replenishment activities.1.4.Mitigation StrategiesFirms have a range of strategies available to them for mitigating the impact of disruptions.Many of them are similar to the strategies thatfirms use to buffer against demand uncertainty,though they are often deployed in different ways depending on the type of uncertainty.At leastfive mitigation strategies have been discussed in the literature on supply disruptions:21.Inventory.Extra inventory may be held in order to protect against possible future disruptions (either to the supplier,in which case the inventory is of raw materials,or to thefirm itself,in which case the inventory is offinished goods).The term“stockpiling”is used in common discourse to refer to large inventories held in reserve for future disruptions(or demand spikes);examples include the U.S.strategic petroleum reserve or the strategic national stockpile of medicines and medical supplies.OR/MS papers on supply disruptions tend not to use this term since,from a modeling perspective,there is not much difference between a stockpile and a typical inventory buffer.Inventory is usually a strategy that must be deployed proactively since most models assume that replenishment orders cannot be placed during a disruption.2.Routine Sourcing.Under this strategy,firms regularly source raw materials from more than one supplier.The idea is that,if one supplier is disrupted,thefirm is not left completely without raw materials since the other supplier(s)may still be operational.Under routine sourcing,order quantities to the non-disrupted suppliers do not change after the disruption(however,see contin-gent rerouting,below);rather,the routine orders from those suppliers serve to reduce the impact of the disruption.3.Contingent Rerouting.Like routine sourcing,this strategy assumes thefirm has multiple suppliers.In the case of contingent rerouting,however,when one supplier is disrupted,thefirmSnyder et al.:Supply Chain Disruptions:A Review 10Article submitted to???;manuscript no.(Please,provide the mansucript number!)changes its order quantities with the non-disrupted suppliers from their pre-disruption levels.This assumes that the suppliers have someflexibility so that they can ramp up production quickly. When this strategy is used in conjunction with routine sourcing,the suppliers often have more flexibility since contracts,product specifications,etc.are already in place.4.Demand Substitution.If one product is out of stock due to a disruption,thefirm may attempt to shift demand to another product that is available.Typically,this involves either upgrading to a superior product(usually at no additional cost to the customer)or providing an inferior product and providing monetary compensation to the customer.5.Financial Mitigation.Firms may purchase insurance policies to protect them against disrup-tions,or they may providefinancial subsidies to their suppliers in order to stabilize the supply base.6.Acceptance.In some cases,the cost of mitigation strategies outweighs the potential benefits from them.In these cases,thefirm may choose simply to accept the risk of disruptions(and the financial consequences that result from them).Note that these strategies are meant to mitigate the consequences of disruptions;most are not able to reduce the risk of disruptions occurring.In most cases,this risk is outside of the supply chain planner’s control.However,in some casesfirms may be able to reduce or eliminate the risk of disruption at certain locations(e.g.,by improving transportation infrastructure to reduce the risk of weather-related disruptions,or by negotiating contracts with workers threatening to strike).In the OR/MS literature,this has been discussed primarily in the context of facility location problems, where it is referred to as“fortification”;see Section7.2.2.Evaluating DisruptionsIn this section,we discuss papers whose aim is primarily to evaluate disruptions and their effects, rather than to optimize the supply chain.These models generally aim to provide planners with tools to evaluate a given supply chain configuration(locations,capacities,etc.)under the risk of disruptions;some also consider one or more mitigation strategies.Simulation is a natural tool for evaluating the impact of disruptions in complex supply chains. Deleris and Erhun(2005)introduce a simulation model of a multi-product,multi-echelon supply chain.Disruptions are modeled by scenarios,each with a different probability and severity.The model uses Monte Carlo simulation to determine the probability distribution of the loss of volume (compared to a no-disruption scenario)through the network.The motivation is to use the model as a strategic planning tool to evaluate different facility configurations,capacity levels,etc.Wilson (2007)simulates afive-echelon supply chain subject to transportation disruptions,whose impact is measured by stockout levels,inventoryfluctuations,and behavior of goods in transit.The author simulates both a traditional supply chain and a vendor-managed inventory(VMI)system in which more demand information is shared upstream.Shefinds that disruptions have the greatest impact when they occur near the middle echelons of the supply chain,and that VMI dampens some,but not all,of the effects of disruptions.Schmitt and Singh(2009b)describe a simulation model for a three-echelon supply chain subject to disruptions,motivated by a study performed for a consumer packaged goods(CPG)company. They use their model to derive a number of qualitative insights.For example,the reaction speed of a backup resource is more important than its capacity;upstream disruptions have a longer impact on customers than downstream ones,and the impact on customers may last significantly longer than the disruption itself;and,demand spikes can have an even greater impact on the system than disruptions.Schmitt and Singh(2009a)present a similar model that uses Monte Carlo simulation to estimate the risk profiles throughout the system and discrete-event simulation to model disruptions and materialflow.The objective is to evaluate the impact of disruptions on service levels and the efficacy of various mitigation strategies.One insight that emerges from the analysis is that the service level is highly dependent on the inventory level at the onset of a disruption,and therefore the overall risk level changes constantly over time.Li et al.(2006)model a supply chain as a directed acyclic supply network and consider disruptions on subgraphs of the network.The objective is to evaluate the impact of upstream disruptions on downstream stages in terms of time(when do they feel the disruption?)and cost(how severe isthe impact?).The time question is evaluated by solving shortest-path problems,while the cost question is evaluated using formulas derived in the paper.The authors present an algorithm for answering both questions simultaneously using a single pass through the network,whereas a brute force approach may require many more iterations.The impact of supply disruptions is not limited to the immediate downstream party.Rong et al. (2009b,a,c)postulate the existence of the“reverse bullwhip effect”(RBWE),which describes an increase in the order variance as one moves downstream from the disruption.(The RBWE is the opposite of the classical bullwhip effect(BWE),in which order variability increases in the oppo-site direction.)By using both a live“beer game”experiment and a simulation study,with supply uncertainty occurring at the manufacturer end of the supply chain,Rong et al.(2009a)show that the RBWE may result from either a player’s reaction to supply disruptions(e.g.,over-or under-ordering)or an over-emphasis on in-transit inventory in the player’s order-quantity decision.(See also Ellis et al.(2010)for a behavioral study of purchasing decisions under the risk of disruptions.) Rong et al.(2009b,c)analyze operational causes of the RBWE under supply uncertainty,namely, competition among retailers for scarce supply and pricing during disruptions with limited infor-mation about strategic customers(respectively).Rong et al.(2009c)prove that the BWE occurs between retailers and customers and that the RBWE occurs between suppliers and retailers in the well known“rationing game”when there is limited or uncertain capacity at the supplier’s end. Rong et al.(2009b)show that when customers react not only to the price itself but also to changes in price,a pricing mechanism implemented by the supplier that does not capture the underlying customer behavior may lead to the RBWE.These studies highlight the importance of treating the supply chain as an integrated system,since both supply and demand uncertainty can be magnified for the remaining parties.The papers discussed so far,and in fact most papers on supply disruptions,assume that thefirm knows the disruption process exactly.But it is often difficult to estimate disruption parameters accurately because of their rare occurrence and lack of historical data,and because suppliers are often unwilling to share disruption information with their customers.This is true when disruptionsare modeled using the simple two-state Markov chain described in Section1.3,but the problem is even more acute for disruption processes that have more complex forms(Song and Zipkin1996,Li et al.2004,Lewis et al.2005).Several studies(e.g.,Ross et al.2008,Saghafian and Van Oyen2008, Snyder and Tomlin2008,all discussed below)demonstrate the value of having accurate informa-tion about supply disruptions.Therefore,it is necessary to investigate good estimation methods; otherwise the benefit of a model that assumes accurate information is undermined.Two ways to deal with this problem have been suggested in the literature.One is to design a forecast method; the other is to design a mechanism that induces the supplier to reveal its disruption characteristics. Tomlin(2009b)takes the former approach,using a Bayesian model to update thefirm’s forecast of the reliability of its supplier and deriving the optimal policy when the forecast is incorporated into sourcing and inventory decisions.The latter approach is taken by Yang et al.(2008),who assume that the supplier has private information about its reliability.The manufacturer offers the supplier a menu of contracts,consisting of a transfer payment,an order quantity,and a penalty cost,and the supplier chooses the contract that maximizes its profit.By applying mechanism theory,the authors show that the manufacturer can induce the supplier to report its reliability level truthfully.3.Strategic DecisionsDisruption planning is often most effective when begun at the strategic level.Strategic decisions have a large impact on the functioning of the supply chain as a whole,as well as on individual locations,especially under the threat of disruptions.In this section,we review papers that discuss strategic decisions that can help protect supply chains against disruptions.The papers in Section3.1 classify strategies for protecting against disruptions and offer guidance tofirms seeking to choose among them.In Section3.2we discuss papers that examine what types of supply chain topologies are most resilient to disruptions.Section3.3discusses papers that consider the use or value of advanced information.(Another important strategic decision—facility location—has been studied extensively in the disruption literature and is discussed in its own section,Section7.)。
Manuscript:TOOLS/TOOLS99/USAPM.T E X Existing OO Process-Focussed Methods:A Critique of RUP and OPEN from a PM perspectiveB.Henderson-Sellers1,R.Du¶e2and I.Graham31School of Computing SciencesUniversity of Technology,SydneyBroadway,NSW,Australia2Thomsen Du¶e and AssociatesEdmonton,Alberta,Canada3Ian Graham and AssociatesLondon,UKPrinted:July25,1999(for presentation at TOOLS Workshop on\Project Management of Object-Oriented Developed Systems")Address for CorrespondenceProfessor B.Henderson-SellersDirector,Centre for Object Technology Applications and ResearchSchool of Computing SciencesUniversity of Technology,SydneyP.O.Box123BroadwayNSW2007AUSTRALIAfax:+61295141807email:brian@.auAbstractSecond generation OO methods,with a few exceptions,contained no elements address-ing process or project management.Third generation methods have been de¯ned as those collaborative developments which also have a signi¯cant process element.The two main candidates are Rational Uni¯ed Process(RUP)and Object-oriented Process, Environment and Notation(OPEN).In this paper,we critique RUP and OPEN froma project management viewpoint and evaluate whether either or both would meet ac-ceptable standards in process support,project management guidelines and full lifecycle description for OO software development.1.RUP and OPEN:A ComparisonWhile RUP(also UP)and OPEN have many similarities,particularly at the metalevel, there are clear distinctions.The most obvious are that:²RUP is a proprietary product and OPEN is in the public domain²RUP has limited tailorability and OPEN is fully tailorable(Figure1)²RUP(or at least the Uni¯ed Process)can only use UML since\UML is an integral part of the Uni¯ed Process'(Jacobson et al.,1999,p4),whereas OPEN can support any current(and future)notation of appropriate quality²RUP must be use-case-driven.Everything relies on the use cases|even the work°ows are derived from use cases(Jacobson et al.,1999,p5)[although how is not stated!] and each iteration deals with a discrete set of use cases(Jacobson et al.,1999,p7).In contrast,OPEN supports use-case-driven,responsibility-driven,data-driven etc.approaches to OO software development²While both can be said to be waterfall(or rather serial)at the macro(or business level)1,RUP uses an embedded waterfall for its iterative structure while OPEN uses an embedded fountain or(objecti¯ed)contract-driven software engineering process.2.TerminologiesRUP chooses terminology purposefully di®erent from standard project management (PM)practice.It is therefore necessary to seek a mapping between these RUP terms and OPEN's more standard terminology.This can be accomplished by comparison of de¯nitions and consideration of the two metamodels.From the de¯nitions it is clear that the term Producer in OPEN is the same as Worker in RUP(Table1).Similarly,the1Neither RUP nor OPEN(as published)are explicit about the di®erence between the product lifecycle and the process lifecycle(Figure2),as described by Henderson-Sellers and Edwards(1994),although this is discussed in Graham et al.(1997,pp21,26). Certainly Version2of OPEN will make some minor modi¯cations to accommodate this upgrade).1Table1Approximate mappings between OPEN and RUP termsOPEN Terms RUP TermsActivity Phase or Stage or Work°ow detailor Iteration work°owTask Activitydetails of Task Step or Activity Step(not given name in OPEN)Technique Guideline+template+mentor)in RUP tool Assertion TriggerDeliverable(V1)ArtifactWork Product(V2)ArtifactProducer Workernotion of Deliverable in OPEN(renamed Work Product in Version2)is the same as the RUP notion of Artifact.In OPEN,a Task is de¯ned as the smallest unit of work that can be project managed (Goldberg and Rubin,1995,p144;Henderson-Sellers,1999)and this is essentially the same as the de¯nition given by Jacobson(1998)in which the RUP Activity is de¯ned as\a unit of work a worker may be asked to perform".This gives an equivalence between the OPEN Task and RUP's Activity2(Table1).In RUP,Activities are explicitly broken down into a set of sequential Activity Steps|the equivalent in OPEN's Tasks is not given a separate name.OPEN Techniques(answering the question\how?")are equivalent to RUP Guidelines, supported only in the proprietary part of the process and also by templates and mentors. Sequencing is done by Assertions(in OPEN)and by Triggers(again explained only the proprietary,unpublished part of RUP)(Kruchten,1999b)The only signi¯cant di±culty in mapping between OPEN and RUP occurs in the use of the terms Activity(and Subactivity)in OPEN and the use of terms like Phase and Work°ow(both core work°ow and iteration work°ow)in RUP.Henderson-Sellers and Mellor(1999)suggest that the concept of the RUP Phase seems to correspond to the concept of Activity in the OPEN metamodel(Table2(a))since the Phases in RUP are described as giving the management perspective(Kruchten,1999b). Thus the RUP Inception Phase would map to the Project Initiation Activity of OPEN (Figure3);the RUP Elaboration Phase subsumes Requirements engineering;model re-¯nement and project planning Activities(not all shown explicitly in this diagram).Con-struction is equivalent to the Build Activity and Transition to Implementation Planning. There is no equivalent to the Evaluation Activity of OPEN nor to any activities in the Programme part of OPEN.Kruchten(1999b),however,recommends a mapping of the OPEN Activity to either Work°ow detail or Iteration Work°ow in RUP.The problem 2Although we should note that in Booch et al.(1999)the RUP Activity is de¯ned to be an aggregate of Tasks and Techniques.2Table2a Possible mapping between OPEN's Activities and RUP's PhasesOPEN RUPTerms Examples Terms ExamplesActivity Project initiation Phase InceptionRequirements ElaborationEngineeringBuild ConstructionImplementation TransitionPlanningTable2b Alternative mapping between OPEN's Stages and RUP's PhasesOPEN Version2RUPTerms Examples Terms ExamplesStage Business Planning Phase InceptionBuild Elaboration+ConstructionDelivery/TransitionDeploymenthere,simply,is that there is one concept in OPEN(Activity)yet two alternatives(with respect to mappings)concepts in RUP(Phase and Work°ow).A key consideration here is whether the RUP Inception phase assumes a software solution(i.e.whether it ignores business issues of the\product lifecycle")or whether these aspects of the business|seeking sponsorship,getting project approval etc.|are partof Inception.The implication that RUP is software focussed is strong in UP/RUP(e.g. Jacobson et al.,1999,p342;Kruchten,1999a,p109)and this viewpoint is also supportedin Cantor's(1998)controlled iteration lifecycle model which is strongly identi¯ed withUP/RUP.He states(p167)that the inception phase\starts after the software develop-ment plan:::has been written and approved.Management is fully committed:::and you have permission to proceed".This clearly identi¯es Inception as the start of the software focussed\process lifecycle"of Figure2.This is con¯rmed(p177)by the recommended creation of top-level class diagrams in Inception,again a component only of the software,not the business,domain.An alternative mapping results if we take into account the OPEN Version2proposalsfor discriminating between the\product"and\process"lifecycles as illustrated in Figure2.Now we might consider and evaluate a possible equivalence mapping between the three3\Stages"in MOSES/OPEN and the four RUP Phases(Table2b).This has appeal because of(1)the solidly sequential nature of the Phases in RUP and Stages in OPEN Version2together with(2)the strong emphasis on strictly>1core work°ows that take place in Elaboration+Construction in comparison with the almost mono-core work°ow situation in the Inception Phase(only Requirements work°ow)and in Transition(dominated by Deployment core work°ow plus some small amount of User testing3).While we might recommend this as a way forward for RUP,this appealing idea is quashed in the current version since it is made clear(Jacobson et al.,1999,p105; Kruchten,1999a,p64)that RUP concentrates on IT issues and neglects the importance of business decisions(as seen in the MOSES Business Planning Stage in Figure2)and starts with the assumption that a software solution has already been selected.Indeed,Jacobson et al.(1999,p342)discuss some of the(business decision-making)events that have to take place before the commencement of the Inception Phase.However,there are some hints(Jacobson et al.,1999,p319and p341;Kruchten,1999a,p64)that it is intended that Inception should include business decision-making processes.At present,however, the activities in this Phase seem to blur any distinction between business decision-making and the IT solution space by including aspects of both(see,for example,the four bullet points on page85of Jacobson et al.,1999,three of which are IT focussed and only one on business issues).Indeed,it is clear that some items,clearly relevant to business issues, are precluded from RUP|for instance,the construction of the phase plan(Kruchten, 1999a,p109)is outside(before)the Inception Phase of RUP.This con¯rms a de¯ciency of RUP in terms of its inadequate coverage of the business issues in software development (as it also ignores reuse and cross-project or programme issues such as domain analysis, as supported by OPEN).If this interpretation is correct,i.e.that the RUP Phases correspond to OPEN Stages of the product lifecycle(dealing with business issues)and the Elaboration+Construction Phases in RUP permit detailed description of all the tasks and techniques of the technical IT area,then the strong suggestion in Figure4(used as a prime explanation of the RUP) that all core work°ows occur in all phases is somewhat misleading.What is needed is for the elements currently in the Inception and Transition Phases contributing to the non-zero e®ort curve in this¯gure to be folded into the Elaboration+Construction Phase,leaving a product-with-embedded-process lifecycle as shown in Figure5|essentially equivalent to Figure2.In this case,Work°ows in RUP truly map to OPEN's Activities|although the level of granularity and detailed descriptors are(currently)a little di®erent.Table1is thus revised|as shown in Table3.3.Project management elementsProject management in an OO software development environment can be de¯ned as: 3The non-zero e®ort in requirements engineering is at odds with the emphatic statement by Cantor(1998,p283)to\Resist all attempts to add functionality during the transition phase."4Table3Revised mappings between OPEN Version2and RUP termsOPEN Terms RUP TermsStage PhaseActivity Work°ow(detail)Task ActivitySubtask Activitydetails of Task Step(a.k.a.Activity Step)(not given name in OPEN)Technique Guideline+template+mentor)in RUP tool Assertion TriggerWork Product ArtifactProducer Worker²the management of people and other resources by a leader in order to plan,analyze, design,construct,test,deploy and maintain an OO information systemIn order to ful¯l this,a project manager needs some support in the form of a project management methodology,either overlain on the technical development(as in RUP)or fully integrated(as in OPEN).In OO developments,as in traditional software developments and on non-software projects,the reponsibilities,variables and tasks of a project manager remain the same:²Responsibilities of Organizing,Directing,Sta±ng,Planning,Control²Variables of Scope,Time,People,Money,Tools&Techniques,Quality²Tasks of Scheduling,Estimating,Monitoring,Contingency Planning,Risk Manage-mentWhile the responsibilities,variables and tasks are unaltered,the context in which they operate has been modi¯ed.Cognizance needs to be taken of di®erent team structures for OO development to meet the expectations of an iterative,incremental and parallel(IIP) delivery anizational reuse also requires a di®erent perspective,particularly as we move to a component-oriented development environment.Finally,the use of metrics may have di®erent repercussions,for example,code size growth rates may be negative when refactoring occurs.OPEN also suggests that you de¯ne your own Project Charter which contains an agreed statement on(i)Business Statement,(ii)Description,(iii)Context Model,(iv) Methodology,(v)Project Resource Estimates and Schedules,(vi)Quality Assurance,(vii) Post-Implementation Review and(viii)Risk Analysis and Contingency Planning(Du¶e and Henderson-Sellers,1995).This Charter is an encapsulated agreed statement on the constraints and resources available.It is a source of reference should disputes arise later.The structure of OPEN means that project management elements exist both in its Activities(and associated Tasks)and in the speci¯cation of particular PM techniques5(e.g.approval gaining;cost estimation;library management;project planning;risk anal-ysis;team building:Henderson-Sellers et al.,1998).Certainly there is extensive support. Rather than a single Work°ow(OPEN Activity)as in RUP,project management tasks and techniques are fully integrated in OPEN.A number of the Activities re°ect PM per-spectives.The important detail comes in the two major and one minor tasks(Task: Develop software development context plans and strategies;Task:Develop and Implement Resource Allocation Plan;and Undertake Feasibility Study,respectively).There are also a number of quality focussed tasks which might also reasonably be grouped into this set of PM-focussed tasks.Within the two major PM Tasks in OPEN,there are many subtasks which deal with speci¯c aspects of either\planning"or\resource management".These include items such as choice of project teams,as well as r^o les and responsibilities within those teams;choice of hardware and software;speci¯cation of goals;development of iteration plan and so on.(Details are to be found in Graham et al.,1997).Each of these Tasks is supported by numerous¯ne-grain Techniques|these are collected together in OPEN's toolbox (Henderson-Sellers et al.,1998).The key element in OPEN is that the linkages between Activities and Tasks and,secondly,between Tasks and Techniques are accomplished,as throughout OPEN,by the use of possibility(or deontic)matrices which assist the method engineering in tailoring the most e±cacious pairings and thus accomplishing a high quality software development int he most e±cient manner.In RUP,in contrast,all of the PM elements are grouped together as a separate project management core supporting work°ow which operates in parallel to the other core work-°ows and across each iteration work°ow.In addition,the actual depth of support for project management is limited.And use of non-standard PM terminology obfuscates the RUP model further|for instance the use of the word activity to mean task i.e.the smallest unit of work.Although derived in large part from the work of Royce(1998),there are many areas in RUP which show de¯ciencies from a project management viewpoint.Ambler(1999) identi¯es a number of weaknesses in RUP's support for project management:²the neglect of several aspects of the larger scale management issues,especially main-tenance and support²the omission of any support for reuse and cross-project capability²the over-dependence on existing tools(of the vendor)leads to neglect of areas that cannot be automated²weakness in areas such as metrics management,reuse management,people manage-ment and testingwhile applauding²the use of sound SE principles focussing on iterative,incremental and architecture based development approaches²the linking of prototypes linked to ends of iterations providing the ability to make go/no go decisions²the serious investment in software tool support(RUP is after all a tool/product itself) Cost estimation is discussed in detail by Cantor(1998)although his emphasis is on what needs to be done rather than how it is to be achieved.He outlines elements of budget6tracking techniques and recommends the use of the COCOMO family of models for sizing OO projects.Nevertheless,this is still signi¯cantly more support than that described by Kruchten(1999a).In RUP's Project Management Work°ow,there are three key purposes: the provision of a framework for managing software-intensive projects(in other words, only relevant to the process lifecycle of software development);provision of guidelines for planning,sta±ng,executing and monitoring projects;and provision of a risk management framework.Speci¯cally,RUP is said not to cover management issues such as managing people,managing budgets,and managing contracts.This Work°ow concentrates on issues such as planning the details of an iterative project,both at the phase level and at the iteration level,the latter built on traditional techniques such as Gantt charts.Risk management is also an important key feature al-though there is little detail in Kruchten(1999a,p112/113)about how to go about avoiding, transferring or accepting risk(either by mitigation or by de¯ning a contingency plan).Met-rics are also discussed in passing with little detail|there is,for instance,no mention of the Goal{Question{Metric paradigm of Basili and Rombach(1988)or,at the other extreme, of detailed complexity metrics such as those described in,for example,Henderson-Sellers (1996).In contrast,OPEN has a large number of tasks and techniques devoted to quality,cost estimation,design and code metrics.There is signi¯cant research backing to the metrics, primarily from the work of Henderson-Sellers(1995,1996),Graham(1995),Haynes and Henderson-Sellers(1996)and Henderson-Sellers et al.(1996).OPEN also o®ers support for projects that are not\green¯eld"projects(a restriction apparent in RUP)by its support for enhancements to existing software in the form of repeated applications of the product lifecycle,its support of programmes of projects which span several software developments including tasks and techniques focussing on reuse, domain analysis and programme-level resource allocation,as well as on people issues such as team building and organizational r^o les.Reuse is supported not only\with reuse"but also,importantly,\for reuse".Here, strategies to inculcate reuse as a mindset and part of the organizational culture are im-portant.Consequently,as component-oriented development emerges into the mainstream, OPEN will o®er full support4for component reuse by aggregative\plug-and-play"tech-niques,including cost estimation techniques of the value of reuse.OPEN has a metamodel focus on interfaces as distinct from implementations,critical for component design and,at the design level,fully supports the use of patterns and frameworks.Finally,as noted above,the degree of tailorability in these two processes is vastly di®erent.In particular,should new demands be placed on project management such that a new work°ow(in RUP terminology)or a new Activity(in OPEN and standard PM terminology)be required,then this would be virtually impossible in RUP(because of the tight constraints to the toolset etc.)and extremely easy in OPEN(this eventuality was always considered throughout the gestation period of OPEN).Furthermore,the insistence 4The existing strong support for component development will be strengthened by the results from a project to incorporate component development ideas from Catalysis into OPEN:Wills and Graham,1999.7by Jacobson that an OO process must be use-case-driven,creates some di±culties in integrating ideas of Royce(1998)and others who contemplate a rise in the interest(and necessity for)architecture-driven thinking.4.Summary and ConclusionsCurrently both RUP and OPEN need further development to be able to o®er clean sup-port for a di®erentiation between the business-focussed product lifecycle and the software-focussed process lifecycle.Indeed,the extent to which RUP o®ers any support for business issues has been demonstrated to be arguable.RUP's project management support occurs in an independent work°ow that is inad-equately described in the published description of RUP.Fuller,associated project man-agement support,although not part of RUP,can be found in the book by Royce(1998). In OPEN,project management tasks and techniques are extensive and fully described in publications.Furthermore,the degree to which these tasks and techniques can be selected and con¯gurated within OPEN o®ers a more°exible and extensible framework which the project manager can readily tailor to suit his/her individual project management strategies and/or style.5.AcknowledgementsThis is Contribution no99/14of the Centre for Object Technology Applications and Research(COTAR).ReferencesAmbler,S.,1999,Completing the Uni¯ed Process with process patterns,white paper available at /uni¯edProcess.htmlBasili,V.R.and Rombach,H.D.,1988,The TAME project:towards improvement-orientated software environments,IEEE Trans.Software Eng.,14(6),758{773Booch,G.,Rumbaugh,J.and Jacobson,I.,1999,The Uni¯ed Modeling Language User Guide,Addison-Wesley,Reading,MA,USA,482ppCantor,M.,1998,Object-Oriented Project Management with UML,John Wiley&Sons, Inc.,New York,343ppDu¶e,R.T.and Henderson-Sellers,B.,1995,The changing paradigm for object project management,Object Magazine,5(4),54{60,78Goldberg,A.and Rubin,K.S.,1995,Succeeding with Objects.Decision Frameworks for Project Management,Addison-Wesley,Reading,MA,542ppGraham,I.M.,1995,Migrating to Object Technology,Addison{Wesley,Wokingham Graham,I.,Henderson-Sellers,B.and Younessi,H.,1997,The OPEN Process Speci¯cation, Addison Wesley Longman Ltd.,London,UK,314ppHaynes,P.and Henderson-Sellers,B.,1996,Cost estimation of OO projects:empirical observations,practical applications,American Programmer,9(7),35{418Henderson-Sellers,B.,1995,The goals of an OO metrics programme,Object Magazine, 5(6),72{79,95Henderson-Sellers,B.,1996,Object-Oriented Metrics.Measures of Complexity Prentice Hall,NJ,234ppHenderson-Sellers, B.,1999,A methodological metamodel of process,JOOP/ROAD, 11(9),56{58,63Henderson-Sellers,B.and Edwards,J.M.,1994,BOOKTWO of Object-Oriented Knowl-edge:The Working Object,Prentice-Hall,Sydney,594ppHenderson-Sellers, B.and Mellor,S.,1999,Tailoring process-focussed OO methods, JOOP/ROAD,12(4),40{44,59Henderson-Sellers,B.,Constantine,L.L.and Graham,I.M.,1996,Coupling and cohesion (towards a valid metrics suite for object-oriented analysis and design),Object-Oriented Systems,3,143{158Henderson-Sellers,B.,Simons,A.J.H.and Younessi,H.,1998,The OPEN Toolbox of Techniques,Addison Wesley Longman,Ltd.,UK,426pp+CD Jacobson,I.,1998,The uni¯ed process,keynote presentation at EDOC'98Jacobson,I.,Booch,G.and Rumbaugh,J.,1999,The Uni¯ed Software Development Pro-cess,Addison Wesley Longman Inc.,Reading,MA,USA,463pp Kruchten,Ph.,1999a,The Rational Uni¯ed Process.An Introduction,Addison Wesley Longman Inc.,Reading,MA,USA,255ppKruchten,Ph.,1999b,personal communicationRoyce,W.,1998,Software Project Management.A Uni¯ed Framework,Addison-Wesley, Reading,MA,USA,406ppWills,A.C.and Graham,I.,1999,paper in preparation9Figure LegendsFigure1The tailorability axis showing fully pre-tailored methods at the right hand side and fully tailorable methods at the left hand side(after Henderson-Sellersand Mellor,1999)c°SIGSFigure2Product and process lifecycle with embedded fountain model,derived from the MOSES lifecycle architectureFigure3OPEN's contract-driven lifecycle instantiated from the OPEN metamodel/framework for MIS applications(Graham et al.,1997,p46)with RUP Phases superim-posedFigure4Work°ows within the RUP process(after Kruchten,1999a)c°AWLFigure5RUP's lifecycle model with OPEN's Stages superimposed10。
Table of Contents:I.General Editorial, Ethical and Legal Issues一般编辑、伦理、法律问题A.AuthorshipB.Group Authorship团体作者C.Group Collaborators合作者D.Copyright 版权E.Duplicate, Prior or Divided Publications重复的、优先的、分开的出版物F.Scientific Misconduct科学不端行为G.Human Studies: IRB Approval and Consent人体研究H.Animal Studies: Animal Care Approval动物研究:动物伦理批准I.Conflicts of Interest利益冲突pliance with NIH and Other Research Funding AgencyAccessibility Requirements符合美国国立卫生研究院和其他研究资助机构的可达性要求K.Study Design Issues实验设计1.PreClinical Trials2.Surveys调查3.Observational Studies观察性研究4.Clinical Trials临床试验II.Types of Papers论文类型A.Original Investigations原始调查B.Clinical Concepts and Commentary (CCC) Articles临床概念和评论文章C.Review Articles review文章D.Special Articles特殊文章E.Correspondence对应F.Mind to MindG.Clinical Practice Guidelines 临床指南H.Images in Anesthesiology (IiA) 图像I.Other Items其他项目III.Manuscript PreparationA.General Arrangement Information on electronic documents电子文件一般资料整理B.Title Page标题页C.Abstract (when required) 摘要D.Body Text正文E.References参考文献F.Tables表G.Appendices附录H.Figure Legends图I.Figures图1.Color Images彩图2.Preparation of Electronic Figures3.Journal Cover Figures杂志封面彩图J.Manuscripts "In Press"K.Supplemental Digital Content补充数字内容L.Additional Information附加信息1.Units of Measurement测量单位2.Abbreviations缩写3.Drug Names and Equipment药品名称和设备4.Data Reporting and Statistics数据报告和统计5.Patient Identification患者识别M.Permissions权限nguage Editing Services语言编辑服务IV.Submission of Electronic Documents提交电子文件A.File Formats, Text文件格式,B.File Formats, Fonts文本文件格式,字体C.File Formats, Graphics and Images图像和图形D.File Sizes文件大小I.General Editorial, Legal and Ethical IssuesA.AuthorshipEach manuscript must have one "Corresponding Author." Anesthesiology follows the ICMJERecommendations for the Conduct, Reporting, Editing and Publication of Scholarly Work inMedical Journals to define the criteria required for authorship. All authors must have participated in the design, execution, and/or analysis of the work presented, and attest to the accuracy andvalidity of the contents. All persons or organizations involved in the work must be listed asauthors or acknowledged. Manuscripts are received with the understanding that they have beenwritten by the authors; ghostwritten papers are unacceptable. See Cullen D: Ghostwriting inscientific anesthesia journals. Anesthesiology 1997; 87: 195-6..每个手稿都必须有相应的作者。
Engineering Failure Analysis (EFA) is a peer-reviewedEngineering Failure Analysis (EFA) is a peer-reviewed journal that publishes original research articles, reviews, and case studies related to the analysis of failures in engineering systems, components, and materials. The submission process for EFA typically involves the following steps: 1. Preparing your manuscript: Before submitting your manuscript, ensure that it meets the journal's requirements for formatting, structure, and content. This may include preparing an abstract, introduction, methods, results, discussion, and conclusion sections.2. Registering your manuscript: Once you have prepared your manuscript, you will need to register it with the journal's online submission system. This typically involves creating an account, logging in, and uploading your manuscript as a PDF file.3. Manuscript review: After registering your manuscript, it will be reviewed by the journal's editorial team and/or external experts in the field. The review process may involve a single or double-blind peer review, where the identity of the authors is concealed from the reviewers.4. Reviewer feedback: If your manuscript is accepted for publication, the reviewers will provide feedback on the strengths and weaknesses of your work. You will then have the opportunity to revise and resubmit your manuscript based on this feedback.5. Revisions and resubmission: After receiving reviewer feedback, you will need to revise your manuscript and address any issues or concerns raised by the reviewers. Once you have made these revisions, you can resubmit your manuscript for further review.6. Final decision: After you have made any necessary revisions and resubmitted your manuscript, the editorial team will make a final decision on whether to accept or reject your work for publication. If your manuscript is accepted, it will be scheduled for publication in an upcoming issue of the journal.Overall, the submission process for Engineering Failure Analysis typically takes several months from registration to final decision. It is important to carefully follow the journal's guidelines and respond promptly to any requests for additional information or revisions during the review process.工程失效分析(EFA)是一个同行评审的期刊,它出版与工程系统、组件和材料的失效分析相关的原创研究文章、评论和案例研究。
Requirements Engineering manuscript No.(will be inserted by the editor)Specifying and Analyzing Early Requirements in TroposAriel Fuxman,Lin Liu,John Mylopoulos,Marco Pistore,Marco Roveri,Paolo Traverso Department of Computer Science,University of Toronto,40St.George St.M5S2E4,Toronto,CanadaDepartment of Information and Communication Technology,University of Trento,Via Sommarive14,I-38050,Trento,Italy ITC-irst,Via Sommarive18,I-38050,Trento,Italyafuxman,liu,jm@ pistore@dit.unitn.it roveri,traverso@irst.itc.itReceived:/Revised version:Abstract.We present a framework that supports the formal verification of early requirements specifications.The frame-work is based on Formal Tropos,a specification language that adopts primitive concepts for modeling early requirements (such as actor,goal,and strategic dependency),along with a rich temporal specification language.We show how existing formal analysis techniques,and in particular model checking, can be adapted for the automatic verification of Formal Tro-pos specifications.These techniques have been implemented in a tool,called the T-Tool,that maps Formal Tropos specifi-cations into a language that can be handled by the N U SMV model checker.Finally,we evaluate our methodology on a course-exam management case study.Our experiments show that formal analysis reveals gaps and inconsistencies in early requirements specifications that are by no means trivial to dis-cover without the help of formal analysis tools. Keywords:Early Requirements Specifications,Formal Methods,Model Checking.Correspondence and offprint requests to:Marco Roveri,ITC-irst,Via Som-marive18,I-38050Trento,Italy.E-mail:roveri@irst.itc.it.at all).In this work,we present a formal framework that adapts results from the Requirements Engineering and For-mal Methods communities to facilitate the precise modeling and analysis of early requirements.Formal methods have been successfully applied to the verification and certification of software systems.In several industrialfields,formal methods are becoming integral com-ponents of standards[5].However,the application of formal methods to early requirements is by no means trivial.Most formal techniques have been designed to work(and have been mainly applied)in later phases of software development, e.g.,at the architectural and design level.As a result,there is a mismatch between the concepts used for early require-ments specifications(such as actors,goals,needs...)and the constructs of formal specification languages such as Z[24], SCR[17],TRIO[15,22].Our framework supports the automatic verification of early requirements specified in a formal modeling language. This framework is part of a wider on-going project called Tro-pos,whose aim is to develop an agent-oriented software engi-neering methodology,starting from early requirements.The methodology is to be supported by a variety of analysis tools based on formal methods.In this paper,we focus on the ap-plication of model checking techniques to early requirements specifications.To allow for formal analysis,we have introduced a for-mal specification language called Formal Tropos(hereafter FT).The language offers all the primitive concepts of i*[25] (such as actors,goals,and dependencies among actors),but supplements them with a rich temporal specification language inspired by KAOS[10,11].The i*notations allow for the de-scription of the“structural”aspects of the early requirements model,for instance in terms of the network of relationships and dependencies among actors.FT permits to represent also the“dynamic”aspects of the model,describing for instance how the network of relationships evolves over time.In FT one can define the circumstances under which a given de-pendency among two actors arises,as well as the conditions2Ariel Fuxman et al.that permit to consider the dependency fulfilled.In our ex-perience,representing and analyzing these dynamic aspects allows for a more precise understanding of the early require-ments model,and reveals gaps and inconsistencies that are by no means trivial to discover without the help of formal analysis tools.In order to support the automated analysis of FT spec-ifications,we have extended an existing formal verification technique,model checking[9].We have also implemented this extension in a tool,called the T-Tool,which is based on the state-of-the-art symbolic model checker N U SMV[8]. The T-Tool translates automatically an FT specification into an Intermediate Language(hereafter IL)specification that could potentially link FT with different verification engines. The IL representation is then automatically translated into N U SMV,which can then perform different kinds of formal analysis,such as consistency checking,animation of the spec-ification,and property verification.On the methodological side,we have defined some heuristic techniques for rewriting an i*diagram into a cor-responding FT specification.The methodology also offers guidelines on how to use the T-Tool effectively for formal analysis,e.g.,by suggesting what model checking technique to use when a particular formal property is to be validated.Preliminary reports on the FT language already appeared in[14]and[13].This paper includes and integrates the con-tents of the previous two papers.The paper is structured as follows.Section2introduces a case study and shows how to build an FT specification from an i*model.Section3uses the case study to illustrate how FT can be used for the incremental refinement of a specification. Section4describes the T-Tool,focusing on its functionalities, architecture,and usage guidelines.In Section5we report the results of a series of experiments that we conducted in order to evaluate the scope and scalability of the approach.Finally, Section6discusses related work,and Section7draws con-clusions and outlines future work.2From i*to Formal TroposIn this section we use a course-exam management case study to describe how an FT specification can be obtained.We use i*models as starting point for our methodology,since they provide an informal graphical description of the organiza-tional setting.This graphical description is then translated into a formal language that is more suitable for the analysis of the dynamic aspects of the operational setting.2.1Strategic modeling with i*The i*modeling language[25]has been designed for the de-scription of early requirements.It is founded on the premise that during this phase it is important to understand and model the strategic aspects underlying the organizational setting within which the software system will eventually function.By understanding these strategic aspects one can better iden-tify the motivations for the software system and the role that it will play inside the organizational setting.For instance,in order to develop a software system that supports the teacher in running and marking an exam,we need to understand those aspects of the interdependencies among teacher and students that define the process of giving exams.The i*framework offers three categories of concepts, drawn from goal-and agent-oriented languages:actors,inten-tional elements,and intentional links.An actor is an active entity that carries out actions to achieve its goals.Figure1 depicts a high-level i*diagram for the course-exam manage-ment case study,with its two main actors:the Student and the T eacher.1Intentional elements in i*include goals,softgoals,tasks, and resources,and can either be internal to an actor,or define dependency relationships between actors.A goal(rounded rectangle)is a condition or state of affairs in the world that the actor would like to achieve.For example,a student’s objective to pass a course is modeled as goal Pass[Course] in Figure1.A softgoal(irregular curvilinear shape)is typi-cally a non-functional condition,with no clear-cut criteria as to when it is achieved.For instance,the fact that a teacher expects the students to be honest is modeled with the soft-goal Honesty.Also the goal AttractStudents of the teacher is a softgoal,since there is not a precise number of students to be“attracted”in order to consider the goal fulfilled.A task (hexagon)specifies a particular course of action that produces a desired effect.In our example,the element Give[Exam]is represented as a task.A resource(rectangle)is a physical or information entity.For instance,the student waits for the lec-tures of the course(Lectures[Course])and for a mark for an exam(Mark[Exam]),while the teacher waits for an answer to an exam(Answer[Exam]).In Figure1a boundary delimits in-tentional elements that are internal to each actor.Intentional elements outside the boundaries correspond to goals,soft-goals,tasks,and resources whose responsibility is delegated from one actor to another.For instance,the student depends on the teacher for the marking of the exams,so the resource Mark[Exam]is modeled as a dependency from the student to the teacher.In the diagrams,dependency links()are used to represent these inter-actor relationships.Figure2zooms into one of the actors of this domain,the student.Thefigure shows how the high-level intentional ele-ments of the student are refined and operationalized.In i*, these refinements and relationships among intentional ele-ments are represented with intentional links,which include means-ends,decomposition,and contribution links.Each el-ement connected to a goal by a means-ends link(is an alternative way to achieve the goal.For instance,in or-der to pass a course(Pass[Course]),a student can pass all the exams of the course(Pass[Exam]),or can do a research project for the course(DoResearchProject[Course]).Decompo-Specifying and Analyzing Early Requirements in Tropos3Fig.1.High-level i*model of the course-exam management case study.Fig.2.High-level i*model focusing on the Student.sition links()define a refinement for a task.For in-stance,if a student wants to pass an exam(Pass[Exam]),she needs to attend the exam(T ake[Exam])and get a passing mark (GetPassingMark[Exam]).A contribution link()describes the impact that an element has on another.This can be neg-ative(-)or positive(+).For instance,FairMarking[Exam]has a positive impact on Pass[Exam],since a fair marking makes it easier for the student to judge when she is ready to take the exam.In Figure2we use some elements that are not present in the original i*definition,but turn out to be useful in sub-sequent phases of our methodology.Prior-to links()de-scribe the temporal order of intentional elements.For exam-ple,a student can only write a report after studying for the course,and can only get a passing mark after she actually takes the exam.We also use cardinality constraints(the num-bers labeling the links)to define the number of instances of a certain element that can exist in the system.For instance,for each Pass[Course]goal there must be at least one Pass[Exam] subgoal.Links without a number suggest one-to-one connec-tions.Figure3completes Figure2with the inner description of the teacher.One can observe that new dependencies between the teacher and the student have been added with respect to the high-level diagram of Figure1.2.2Dynamic modeling with Formal TroposThe i*model of Figure3provides a static description of the course-exam management domain.In order to fully under-stand the domain,one needs to describe and analyze also the strategic aspects of its dynamics.For instance,the expecta-tions and dependencies of a student that wants to pass an exam change over time,depending on whether she has still to take the exam,is waiting for the marking,or wants to dis-cuss the marking with the teacher.Moreover,if a student has still to take the exam,she may possibly decide to write a re-port instead,but this is very unlikely to happen if the student has already got a passing mark.The prior-to links and cardinality constraints shown in Figure3permit to describe some aspects of the dynamics of the course-exam management case study,but their expressive power is very limited.In general,informal notations like the ones provided by i*are inadequate to carry out an accurate dynamic analysis.Formal specification languages are more suited for this purpose.FT has been designed to supplement i*models with a precise description of their dynamic aspects.In FT,we fo-cus not only on the intentional elements themselves,but also on the circumstances in which they arise,and on the condi-tions that lead to their fulfillment.In this way,the dynamic aspects of a requirements specification are introduced at the strategic level,without requiring an operationalization of the specification.With an FT specification,one can ask questions such as:Can we construct valid dynamic scenarios based on the model?Is it possible to fulfill the goals of the actors?Do the decomposition links and the prior-to constraints induce a meaningful temporal order?Do the dependencies represent a valid synergy or synchronization between actors?A precise definition of FT and of its semantics can he found in[12,1].Here we present the most relevant aspects of4Ariel Fuxman et al.Fig.3.Annotated i*model of the course-exam management case study.exam to be passed,and attribute passthe language.The grammar of FT is given in Figure4.An FTspecification describes the relevant objects of a domain andthe relationships among them.The description of each objectis structured in two layers.The outer layer is similar to a classdeclaration and defines the structure of the instances togetherwith their attributes.The inner layer expresses constraints onthe lifetime of the objects,given in a typedfirst-order linear-time temporal logic.An FT specification is completed by aset of global properties that express properties on the domainas a whole.2.2.1The outer layerFigure5is an excerpt of the outer layer of the FT specificationof the course-exam management case study.In the transfor-mation of an i*diagram into an FT specification,actors andintentional elements are mapped into corresponding declara-tions in the outer layer of FT.Moreover,entities(e.g.,Courseand Exam)are added to represent the non-intentional elementsof the domain.Many instances of each element may exist during theevolution of the system.For example,different Pass[Course]goals may exist for different Student instances,or for differentcourses taken by the same student.For this reason,we referto the different elements that compose an FT declarations as“classes”.Each class has an associated list of attributes.Each at-tribute has a sort(i.e.,its type)and one or more optionalfacets.Sorts can be either primitive(boolean,integer...)orclasses.Attributes of primitive sorts usually define the rel-evant state of an instance.For example,boolean attributepassed of resource dependency Mark determines whether themark is passing or not.Attributes of non-primitive sorts de-fine references to other instances in the domain.For example,attribute exam of goal Pass[Exam]is a reference to the specificSpecifying and Analyzing Early Requirements in Tropos5/*The outer layer*/specification:=(entity actor int-element dependency global-properties)entity:=Entity name[attributes][creation-properties][invar-properties]actor:=Actor name[attributes][creation-properties][invar-properties]int-element:=type name mode Actor name[attributes][creation-properties][invar-properties][fulfill-properties]dependency:=type Dependency name mode Depender name Dependee name[attributes][creation-properties][invar-properties] [fulfill-properties]type:=(Goal Softgoal Task Resource)mode:=Mode(achieve maintain achieve&maintain avoid)/*Attributes*/attributes:=Attribute attributeattribute:=facets name:sortfacets:=[constant][optional]...sort:=name integer boolean.../*The inner layer*/creation-properties:=Creation creation-propertycreation-property:=property-category event-category temporal-formulainvar-properties:=Invariant invar-propertyinvar-property:=property-category temporal-formulafulfill-properties:=Fulfillment fulfill-propertyfulfill-property:=property-category event-category temporal-formulaproperty-category:=[constraint assertion possibility]event-category:=trigger condition definition/*Global properties*/global-properties:=Global global-propertyglobal-property:=property-category temporal-formulaFig.4.The Formal Tropos grammar.tinuously maintained.There are other modalities,such as achieve&maintain,which is a combination of the previ-ous two modes and requires the fulfillment condition to be achieved and then to be continuously maintained;and avoid, which means that the fulfillment conditions should be pre-vented.2.2.2The inner layerThe inner layer of an FT class declaration consists of con-straints that describe the dynamic aspects of entities,actors, goals,and dependencies.Figure6presents an excerpt of con-straints on the lifetime of dependency Mark of the course-exam management case study.The actual constraints are de-scribed with formulas given in a typedfirst-order linear-time temporal logic(see Section2.2.3).In FT we distinguish dif-ferent kinds of constraints(namely,Invariant,Creation,and Fulfillment constraints),depending on their scope.Invariant constraints of a class define conditions that should hold throughout the lifetime of all class instances.Typically,invariants define relations on the possible values of attributes,or cardinality constraints on the instances of a given class.For instance,thefirst invariant of Figure6states a relationship between attributes of the instances of the Mark class.The second invariant imposes a cardinality constraint for Mark instances,namely,there can be at most one Mark for a given GetPassingMark goal.Creation and Fulfillment constraints define conditions on the two critical moments in the lifetime of intentional el-ements and dependencies,namely their creation and fulfill-ment.The creation of a goal is interpreted as the moment when an actor(the one associated to an intentional element, or the depender of a dependency)begins to desire a goal. The fulfillment of a goal occurs when the goal is actually achieved.Creation and fulfillment constraints can be used to define conditions on those two time instants.Creation con-straints can be associated with any class,including actors and entities.Such constraints should be satisfied whenever an in-stance of the class is created.Fulfillment constraints can be associated only with intentional elements and with dependen-6Ariel Fuxman et al.Entity CourseEntity ExamAttributeconstant course:CourseActor StudentActor T eacherGoal PassCourseActor StudentMode achieveAttributeconstant course:CourseGoal PassExamActor StudentMode achieveAttributeconstant exam:Examconstant passexam:PassExamSoftgoal IntegrityActor StudentMode maintainTask GiveExamActor T eacherMode achieveAttributeconstant exam:ExamResource Dependency MarkDepender StudentDependee T eacherMode achieveAttributeconstant exam:Examconstant gpm:GetPassingMarkpassed:booleanFig.5.Excerpt of outer layer of an FT class declaration. cies.These constraints should hold whenever a goal or soft-goal is achieved,a task is completed,or a resource is made available.Creation and fulfillment constraints are further dis-tinguished as sufficient conditions(keyword trigger),neces-sary conditions(keyword condition),and necessary and suf-ficient conditions(keyword definition).In an FT specification,primary intentional elements (e.g.,Pass[Course]and Integrity)typically have fulfillment con-straints,but no creation constraints.We are not interested inmodeling the reasons why a student wants to pass a course, or maintain her integrity,since these are taken for granted. Subordinate intentional elements(e.g.,Pass[Exam],GetPass-ingMark[Exam])typically have constraints that relate their cre-ation with the state of their parent elements.For instance,ac-cording to Figure6,a creation condition for an instance of dependency Mark is that the parent goal GetPassingMark has not been fulfilled so far.In other words,if the student has re-Resource Dependency MarkDepender StudentDependee T eacherMode achieveAttributeconstant exam:Examconstant gpm:GetPassingMarkpassed:booleanInvariantgpm.exam exam gpm.actor dependerInvariantm:Mark((m self)(m.gpm gpm))Creation conditionFulfilled(gpm)Fulfillment conditionim:InitialMarking(im.exam examim.actor dependee Fulfilled(im))Fulfillment triggerG(Changed(passed)r:ReEvaluation((r.mark self)JustFulfilled(self)))Fig.6.Example of FT constraints.ceived a passing mark,there is no need to ask for another mark.We note that the creation condition of dependency Mark together with the fulfillment condition of task GetPass-ingMark[Exam]elaborate the delegation relationship between Student and T eacher in the corresponding i*diagram.Goal de-composition relationships can be specified in a similar fash-ion.2.2.3The FT temporal logicIn FT,constraints are described with formulas in a typed first-order linear-time temporal logic.Linear-time temporal logic is quite common in formal specification and verifica-tion frameworks.The temporal operators provided by this logic have shown to capture the relevant temporal properties of dynamic systems.In FT the temporal operators are com-plemented with quantifiers that take into account the other aspect of the dynamics of FT models,namely,the presence of multiple instances of classes.It is hence possible to repre-sent in FT most,if not all,dynamic aspects of a model that one may want to express.The FT temporal logic is described by the following syn-tax:(boolean op.)(relational op.) sort sort(quantifier) X F G U(future op.)Y O H S(past op.)JustCreated ChangedFulfilled JustFulfilled(special pred.)(const.and var.) self actor depender dependee(special term) Besides the standard boolean and relational operators,the logic provides the quantifiers and,which range over allSpecifying and Analyzing Early Requirements in Tropos7the instances of a given class,and a set of future and pasttemporal operators.These allow for expressing propertiesthat are not limited to the current state,but may refer also to its past and future history.For instance,formula X(next)expresses the fact that formula should hold in the next state reached by the model,while formula Y(previous)requires condition to hold in the previous state.FormulaF(eventually)requires that formula is either true now or that it becomes eventually true in some future state;for-mula O(once)expresses the same requirement,but onthe past states.Formula G(always in the future)expresses the fact that formula should hold in the current state and inall future states of the evolution of the model,while formula H(always in the past)holds if is true in the current state and in all past state of the model.Formula U(until)holds if there is some future state where holds and formula holds until that state;finally,formula S(since)holds if there is some past state where holds and formulaholds since that state.Special predicates can appear in temporal logic formu-las.Predicate JustCreated t holds if element t exists in this state but not in the previous one.Predicate Changed t holds in a state if the value of term t has changed with respect to the previous state.Predicate Fulfilled t holds if t has been fulfilled,while predicate JustFulfilled t holds if Fulfilled t holds in this state,but not in the previous one.The two lat-ter predicates are defined only for intentional elements and dependencies.The terms on which the formulas are defined may be in-teger and boolean constants(),variables(),or may refer to the attribute’s values of the class instances(,where can either be a standard attribute,or a special attribute like actor or depender).Also,instances may express properties about themselves using the keyword self(see the second invariant of dependency Mark in Figure6).While the temporal logic incorporated in FT is quite ex-pressive,only simple formulas are typically used in a spec-ification.The possibility of anchoring temporal formulas to critical events in the lifetime of an object,together with the possibility of expressing modalities for goals and dependen-cies,provide implicitly an easy-to-understand subset of the language of temporal logics.Consider,e.g.,the creation con-dition and the fulfillment condition of dependency Mark in Figure6.No temporal operators are needed is these con-straints,since the kinds of the constraints already define the lifetime instants the conditions refer to.Only when the life-time events and the modalities are not sufficient for captur-ing all the temporal aspects of a conditions,temporal opera-tors need to appear explicitly in the formulas.For instance, the temporal operator that appears explicitly in the Fulfill-ment trigger of dependency Mark is needed since we want to bind the fulfillment of the dependency with a condition that should hold from that moment on(namely,the fact that at-tribute passed should change only because of a re-evaluation).2.2.4Assertions and possibilitiesThe constraints represented in Figure6express conditions that are required to hold for all possible scenarios.In an FT specification,we can also specify properties that are desired to hold in the domain,so that they can be verified with respect to the model.Figure7presents such properties for the course-exam management case study.We distinguish between As-sertion properties(A1-4)which are desired to hold for all valid evolutions of the FT specification,and Possibility prop-erties(P1-4)which should hold for at least one valid scenario. Properties A1,A2,A3,and P3are“anchored”to some impor-tant event in the lifetime of a class instance.For example,as-sertion A2requires that,whenever an instance of Pass[Exam] is created,no other instance of Pass[Exam]exists correspond-ing to the same exam and the same student.Properties A4, P1,P2,and P4are examples of“global properties”,i.e.,they express conditions on the entire model,and are not attached to any particular event.2.3From i*to FT:Translation guidelinesDeveloping a satisfactory formal specification for a software system can be hard,even when one starts from a good infor-mal model.According to our experience,the difficulties in developing an FT specification can be substantially reduced if one extracts as much information as possible from the i* model to produce a“reasonable”initial FT model.In fact, most of the constraints of an FT specification already appear implicitly in the i*model.We have identified a set of translation rules that permit to systematically derive these constraints.These rules cap-ture the intuitive semantics that we use when designing an i*model.For instance,decomposition and means-ends links describe possible ways to achieving a parent goal in terms of lower-level sub-goals.Therefore,sub-goals are created only with the purpose of fulfilling the parent goal.This leads to the following two translation rules for the creation and fulfill-ment conditions of the sub-goals:–The default creation condition of a sub-goal of a decom-position or means-ends link is that the parent goal exists, but has not been fulfilled yet.–The fulfillment condition of a parent goal depends on the fulfillment of the sub-goals.If the sub-goals are con-nected to the parent goal with means-ends links,then the fulfillment of at least one of the subgoals is necessary for the fulfillment of the parent goal.If they are connected with decomposition links then the fulfillment of all the subgoals is necessary.Parent goals and sub-goals typically share the same entity and owner.For instance,Pass[Exam]and T ake[Exam]refer to the same exam,and the Student that wants to pass the exam is the same that has to take it.This leads to the following translation rule:–An invariant condition is added to the sub-goal in order to force the binding between the owners of the two goals and between those attributes that are present in both goals.。