Engineering Requirements for Socio-Technical Systems

需求工程(Requirements Engineering，RE)关注利益相关者需求的引出、建模和分析，以便为将来的系统派生规范，并传递给设计者。Re被广泛认为是软件开发中最关键的阶段，从字面上看是决定项目成败的阶段。鉴于软件项目的失败率居高不下，我们建议通过为使软件工程成为工程学科奠定基础来努力推进软件工程的研究状况。*这些基础基于三个原则：(A)需求代表利益相关者的需求，并被建模为目标，由未来的系统来实现；(B)这些目标--无论多么非正式、相互冲突、含糊不清等--的转变将以一套细化运算符的应用为基础，其中每个应用都将一个目标转变为一个更具体的目标，这很符合Hoare、Abrial等人的细化演算的精神；(C)转变过程得到细化工具的支持，这些工具将一个或多个目标转变为一个或几个更具体的目标；(D)为特定目标模型选择最佳规格应得到推理工具的支持，该工具可进行健全、完整和可扩展的推理，即使是具有数千个要素(节点和链接)的目标模型。我们建议在这样的基础上工作，考虑到社会技术系统(包括软件的系统，但也包括业务流程和人类行为者)以及涉及软件和物理组件(例如机器人设备)的网络物理系统，因为这些都是软件工程的重要应用领域。除了这些基础之外，我们建议重新审查需求规范语言，使它们更具表现力，以便它们能够表达软件工程实践中使用的安全性、性能和其他机制，在我们看来，这些都不能被当前的规范技术所考虑，无论是正式的还是其他的。*我们感兴趣的是研究特定的需求类别，目的是(A)将它们形式化；(B)在文献的基础上，研究将其付诸实施的替代办法。其中一类是验收要求类。这些都是“X%的社区Y将使用该系统”形式的要求。它们是社交软件的关键需求。毕竟，如果一个系统没有被使用，它就是一个失败！另一类涉及在提供(基于计算机的)服务时将官僚开销降至最低。对于任何使用过政府服务的人来说，这些要求都是可以理解的，他们被长时间的等待、漫长的周转、被要求的太多信息以及(在一些国家)甚至需要行贿才能获得所需的东西所困扰。在这里，我们希望通过参考文献来描述这种“最大限度地减少官僚作风”的要求，并研究可以满足这些要求的替代方法。

Requirements Engineering (RE) is concerned with the elicitation, modelling and analysis of stakeholder requirements in order to derive a specification for a system-to-be, to be passed on to designers. RE is widely considered the most critical stage in software development, literally the one that makes or breaks projects. Given persisting high failure rates for software projects, we propose to work towards advancing the state-of-research in RE by laying the foundations for making RE an engineering discipline.******These foundations are based on three principles: (a) Requirements represent stakeholder needs and are modelled as goals, to be fulfilled by the system-to-be; (b) The transformation of these goals -- however informal, conflicting, vague, etc. is to be based on the application of a set of refinement operators, where each application transforms a goal into a more concrete one, much in the spirit of the Refinement Calculus of Hoare, Abrial, et al; (c ) The transformation process is be supported by refinement tools that transform one or more goals into one or several more concrete ones; (d) The selection of optimal specifications for a given goal model should be supported by a reasoning tool that carried out sound, complete and scalable reasoning, even for goal models with thousands of elements (nodes and links). We are proposing to work on such foundations having in mind socio-technical systems (systems that consist of software, but also business processes and human actors) as well as cyber-physical systems that involve both software and physical components, e.g., robotic devices, because these are important application areas for software engineering.******In addition to these foundations, we propose to revisit requirements specification languages with an eye towards making them more expressive so that they can express security, performance and other mechanisms used in software engineering practice, which in our view cannot be accounted by current specification techniques, formal or otherwise.******Finally, we are interested in studying specific classes of requirements, aiming to (a) formalize them; (b) study alternatives ways of operationalizing them, based on the literature. One such class is the class of acceptance requirements. These are requirements of the form “X% of community Y will use the system”. They are critical requirements for social software. After all, if a system isn't used, it is a failure! Another class concerns minimizing bureaucratic overhead in offering a (computer-based) service. Such requirements are understandable to anyone who has used a government service and was bothered by long waits, long turn-arounds, too much information being requested, and (in some countries) even the need to bribe in order to get what you need. Here, we want to characterize such “minimize bureaucracy” requirements and study alternative ways they can be fulfilled by referring to the literature.