Skip to content

System specifications in detail

Writing "high quality" system specifications is essential to the success of a design project1. Inconsistencies and ambiguities in system specifications may cause costly and lengthy design iterations. Much has been written on structuring and managing system specifications by academia and industry alike23.

This page dives into the context of writing system specifications in general and why a formal language such as the Elephant Specification Language (ESL) is a valuable addition in the Systems Engineering landscape. It starts with a dissection of typical system specification concepts and concludes with a review of available methods tools to capture these. From this, we conclude with the concepts that ESL aimed to capture at its inception.

Tip

ESL is an evolving language. With each additional enhancement, it's expressive capability grows, making it easier to capture detailed requirements of your system. You can keep track of the evolution on the Governance page.

Needs, requirements, and constraints

A design project starts with capturing the Voice-of-the-Customer in a series of statements usually referred to as needs4. Needs describe what is wanted by the customer. Needs are typically qualitative, imprecise, and ambiguous due to their linguistic origins5.

In the literature, the term requirement is often used interchangeably with the term need, though several scholars define requirements to be structured and formalized needs 67. Similarly, some describe a process of gathering customer needs and subsequent elicitation, analysis, and specification of formalized requirements5. What is more, the term constraint is often used interchangeably with the term requirement8. In the Oxford dictionary9, a requirement is defined as a thing demanded, whereas a constraint is defined as a limitation or restriction. These definitions are consistent with definitions by Koelsch10. Constraints may, for instance, be imposed by the laws of nature, material properties, and the environment in which the system is ought to function.

In ESL, we consider needs to be informal (qualitative) statements on what is desired; requirements to be formal (quantitative) statements on what is desired; and constraints to be formal statements that impose limits on what is desired.

Hull et al.11 point out the benefits of using consistent language in specifying needs, requirements, and constraints. These benefits have been recognized by many authors. For example, Cohen12 defined linguistic equivalents for mathematical inequality operators, Hooks2 debates the usage of the word 'shall' in requirements, and Van Vliet13 introduced the MoSCoW method (Must-o-Should-Could-o-Won't) to create subtle priority differences in requirements. For example, to distinguish between requirements and preferences. Furthermore, several engineers advocate the usage of boilerplates, i.e., a fixed layout in which requirements must be written1415.

Function, behavior, and design

Needs, requirements, and constraints, in the following referred to as specifications, can be divided into two groups: functional specifications and non-functional specifications10. Functional specifications are descriptions of what a system must do16. Non-functional specifications describe what a system must comply to.

Eisenbart et al.17 reviewed twelve different definitions of system functions and partitioned them into two groups. The first group are functions that describe a goal of a system. The second group are functions that describe a transformation of flow, such as electrical energy or information. In Automated generation of a function-component-parameter Multi-Domain Matrix from textual function specifications18, we defined a specific grammar for function specifications in both groups to reduce ambiguity. That is, a specific grammar for writing goal-functions to describe the goal of components with respect to other components in the system, and a specific grammar for writing transformation-functions to describe transformations of flow within components. To reduce ambiguity even further, we made use of the functional basis, developed by Stone et al.19 and Hirtz et al.20, to restrict the usage of verb synonyms.

Modern engineering systems are usually dynamic in nature. That is, they change behavior and/or state in response to stimuli such as operator input or changes in their environment. As such, there is a strong need to be able to specify when a system should exhibit what behavior and fulfil which functions. In other words, there is a strong need to be able to specify dynamic bounds on flows. Therefore, system behavior is often modelled in conjunction with system functions and system states. See, for example, the Function-Behavior-State model21, the Structure-Behavior-Function model2223 and the requirements engineering book of Hull11.

The literature has less consensus on non-functional specifications which are referred to by a variety of terms such as performance, quality, and safety specifications10. This motivates the increasing popularity of ontology-driven requirement engineering2425. That is, prior to writing a specification one defines the classes of requirements that may occur within a specification.

We interpret non-functional specifications as descriptions of the conceptual, embodiment, and detailed design of a system or derivative properties thereof such as capacity, reliability, availability, and cost of components. The conceptual, embodiment, and detailed design denote different stages of maturity of a design26. Hence, we refer to non-functional specifications as design specifications in the remainder of this article.

Hull et al.11 note that function and design specifications are often combined in single sentences. For example, the sentence 'The power source must provide power with a reliability of 98%' contains the sub-clause 'with a reliability of 98%' that is subordinate to the main clause 'The power source must provide power'. In this case, the main clause describes the function, whereas the subclause describes a performance bound on the function.

Dependencies

In engineering design, systems are usually decomposed into more manageable components26. It is important to specify and actively manage dependencies between components to ensure that the components eventually will fit and function together27.

Component dependencies may relate to a wide variety of engineering disciplines such as mechanical, electrical, thermal, and software engineering28, making it impossible for a single person to oversee all dependencies29. Therefore, dependencies between components are often visualized and analyzed using graphical models. A major challenge in this process is to ensure and maintain the consistency between the written specifications and the graphical models as the design process progresses. This motivated the development of graphical specification methods such as SysML30.

Written documents, however, remain the primary means of documentation and communication in engineering design31. This may be due to the limited scalability of graphical specification methods32. Therefore, we consider a direct relation between the written specification and the graphical models as a desirable feature in engineering design.

Hierarchies

In the literature one finds many design process models such as the waterfall model33, spiral-model34, V-model35, and the onion model36. All these models have in common that one starts with a high-level description of a system, its functions, and variables. Subsequently, one decomposes the system, its functions, and variables, until one obtains a specification (design) that is sufficiently detailed for manufacturing purposes.

Many scientists advocate the usage of separate decomposition trees for the system's components, functions, and variables373826, and the subsequent manual mapping of components to functions and variables. Obtaining such a mapping is far from trivial39. That is, components may have multiple functions and functions may be fulfilled by multiple components and involve multiple variables. For that reason, others introduced new function terminology such as the terms exogenous and endogenous functions39. These terms are similar in meaning to the terms goal-function and transformation function17 which are used by Wilschut et al.18. Exogenous functions describe the purpose of a component with respect to the components around it, while endogenous functions describe processes internal to the component.

The paper by Crilly39 shows that exogenous (goal) functions may propagate through nested systems. That is, a function may state that a power source provides power to a lamp. If one subsequently decomposes the power source into a battery and a holder, one may find out that it is actually the battery that provides power to the lamp. This means, the function provide power to the lamp is not decomposed into sub-functions but simply assigned to a sub-component of the power-source.

Endogenous (transformation) functions, however, do not propagate through nested systems but are decomposed into sub-transformations. For example, a petrol engine must convert gasoline (liquid material flow) into torque (mechanical energy flow) at a system level. Internally, the subcomponents of the engine transform gasoline into vapor which is burned to produce heat. The heat is transformed into pressure which in turn is transformed into torque. In other words, the top-level transformation is described by a series of sub-level transformations. In systems engineering research, the importance traceability of top-level functions to functions of sub-components is a frequently discussed topic. Traceability is required to ensure during the design process that the systems will meet all top-level functional requirements.

Existing system specification methods and tools

As discussed in in the previous sections, we argue that a system specification method or tool should enable a user to specify function specifications, design specifications, and combinations thereof in terms of needs, requirements, and constraints. Moreover, we consider it desirable to have a direct relation between written specifications and graphical models to display dependencies between components, functions, variables, and combinations thereof. Finally, one should be able to easily decrease the granularity level of the specification as the design process progresses and enable functions to propagate through the nested systems.

In the literature, a variety of requirement management tools are found, see the piece by De Gea et al.40 for an extensive overview and classification. As the name suggests, these tools mainly focus on the management of large volumes of requirements; they do not consider the conciseness and preciseness of the written specifications themselves. As a consequence, specifications may still be vague and ambiguous. What is more, in most available tooling users have to manually create the links between components, functions, and variables (and many other types of artifacts that one can create within these tools). Typically, no direct relation between the written specification and the dependency structure exists.

To improve the preciseness and conciseness of the written specifications, several authors advocate the use of boilerplates141511. Boilerplates predefine a fixed format in which the specifications should be written, though, do not constrain the actual content of the specifications. Ghosh et al.41 and Mustafa et al.42 develop tooling to automatically convert natural language specifications such that they are formatted following at set of predefined boilerplates. Manual checking is needed to verify the correctness of these conversions.

Other researchers aim at improving the quality of manually written specifications using controlled natural languages. Kuhn et al.43 provides an overview of more than a hundred controlled natural languages. Most controlled natural languages are used to simplify and to automate the translation of user and service manuals in a variety of languages. Only a few focus on system specifications.

Clark et al.44, for example, developed a controlled natural language for writing knowledge databases for artificial intelligence systems. They noticed that many engineers have difficulties with writing the logical expressions in mathematical form which are stored in such a database. They developed a language that enables engineers to write natural language rules and to automatically convert them into logical expressions. Fuchs et al.45 developed Attempto Constrained English (ACE) as a natural language specification tool. ACE supports automatic conversion to first-order-logic. To our knowledge ACE does not support the structured multi-level description of systems. Mavin et al.46 developed the Easy Approach to Requirements Syntax (EARS) which, as we understand them, are automated boilerplates. That is, the tool identifies keywords such as shall,if, where, and while, but the text between those keywords is not constrained to a predefined format. Fieler et al.47 developed the language ReqSpec which resembles a programming language and is specifically built for the construction industry to perform spatial analysis and design of buildings. Hence, ReqSpec does not support the concept of system functions. Similar to ReqSpec, the psi-language Tosserams et al.32 and the z-language Woodcock et al.48 are domain specific languages. The former is used for specifying the structure of multi-disciplinary optimization problems and the latter is used for formally describing computing systems.

Requirements for a formal system specification language

Based on the aforementioned reviews of literature on specification methods and tools, we postulate that the area of engineering design would benefit from a domain specific language that supports the following features:

  1. The specification of function specifications, behavior specifications, design specifications, and combinations thereof in terms of needs, requirements, and constraints of new and existing systems at multiple levels of granularity.
  2. The formal derivation of dependencies between components, function specifications, behavior specifications, design specifications, variables and combinations thereof.
  3. The propagation and traceability of function specifications through out the system decomposition tree.

Therefore, we present the Elephant Specification Language (ESL) which is a language specifically designed to support these features.

Where to from here?

  1. D. M. Buede. The engineering design of systems: models and methods. John Wiley & Sons, Hoboken, New Jersey, USA, 2nd edition, 2009. ↩

  2. I. Hooks. Writing good requirements. INCOSE International Symposium, 4(1):1247–1253, 1994. ↩↩

  3. J. O. Grady. System requirements analysis. Academic Press, San Diego, California, USA, 2014. ↩

  4. S. Eppinger and K. Ulrich. Product design and development. McGraw-Hill Higher Education, 2015. ↩

  5. J. Jiao and C.-H. Chen. Customer Requirement Management in Product Development: A Review of Research Issues. Concurrent Engineering, 14(3):173–185, 2006. ↩↩

  6. A. Ericson, P. Müller, T. C. Larsson, and R. Stark. Product-service systems from customer needs to requirements in early development phases. In Proceedings of the 1st CIRP Industrial Product-Service Systems Conference, 62––67. Cranfield, England, 2009. ↩

  7. G. Cascini, G. Fantoni, and F. Montagna. Situating needs and requirements in the FBS framework. Design Studies, 34(5):636–662, 2013. ↩

  8. M. Glinz. On non-functional requirements. In Proceedings of the 15th IEEE International Requirements Engineering Conference, 21–26. Delhi, India, 2007. ↩

  9. Oxford English Oxford. Oxford English Dictionary. Oxford University Press, Oxford, England, 2009. ↩

  10. G. Koelsch. Requirements Writing for System Engineering. Apress, New York, USA, 2016. ↩↩↩

  11. E. Hull, K. Jackson, and J. Dick. Requirements engineering. Springer, London, England, 2nd edition, 2017. ↩↩↩↩

  12. E. Cohen. Programming in the 1990s: An Introduction to the Calculation of Programs. Springer Science & Business Media, London, England, 1990. ↩

  13. H. van Vliet. Software Engineering: Principles and Practice. Wiley, Chichester, England, 2005. ↩

  14. C. Arora, M. Sabetzadeh, L. C. Briand, and F. Zimmer. Requirement boilerplates: transition from manually-enforced to automatically-verifiable natural language patterns. In Proceedings of the 4th IEEE International Workshop on Requirements Patterns, 1–8. Karlskrona, Sweden, 2014. ↩↩

  15. N. Mahmud, C. Seceleanu, and O. Ljungkrantz. Specification and semantic analysis of embedded systems requirements: from description logic to temporal logic. In Proceedings of the International Conference on Software Engineering and Formal Methods, 332–348. Trento, Italy, 2017. ↩↩

  16. J. M. Fernandes and R. J. Machado. Requirements in Engineering Projects. Lecture Notes in Management and Industrial Engineering. Springer International Publishing, London, England, 2016. ↩

  17. B. Eisenbart, L. Blessing, and K. Gericke. Functional modelling perspectives across disciplines: a literature review. In Proceedings of 12th international design conference, 847–858. Dubrovnik, Croatia, 2012. ↩↩

  18. T. Wilschut, L. F. P. Etman, J. E. Rooda, and J. A. Vogel. Automated generation of a function-component-parameter multi-domain matrix from textual function specifications. Research in Engineering Design, 29(4):531––546, 2018. ↩↩

  19. Robert B Stone and Kristin L Wood. Development of a functional basis for design. Journal of Mechanical design, 122(4):359–370, 2000. ↩

  20. J. Hirtz, R. B. Stone, D. A. McAdams, S. Szykman, and K. L. Wood. A functional basis for engineering design: reconciling and evolving previous efforts. Research in engineering Design, 13(2):65–82, 2002. ↩

  21. Y. Umeda, M. Ishii, M. Yoshioka, Y. Shimomura, and T. Tomiyama. Supporting conceptual design based on the function-behavior-state modeler. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 10(4):275–288, 1996. ↩

  22. A. K. Goel, S. R. Rugaber, and S. Vattam. Structure, behavior, and function of complex systems: The structure, behavior, and function modeling language. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 23(Special Issue 01):23–35, 2009. ↩

  23. H. Komoto and T. Tomiyama. A framework for computer-aided conceptual design and its application to system architecting of mechatronics products. Computer-Aided Design, 44(10):931–946, 2012. ↩

  24. X. Chen, C.-H. Chen, K. F. Leong, and X. Jiang. An ontology learning system for customer needs representation in product development. The International Journal of Advanced Manufacturing Technology, 67(1):441–453, 2013. ↩

  25. D. Dermeval, J. Vilela, I. I. Bittencourt, J. Castro, S. Isotani, P.k Brito, and A. Silva. Applications of ontologies in requirements engineering: a systematic review of the literature. Requirements engineering, 21(4):405–437, 2015. ↩

  26. G. Pahl and W. Beitz. Engineering design: a systematic approach. Springer Science and Business Media, London, England, 2007. ↩↩↩

  27. S. D. Eppinger, N. R. Joglekar, A. Olechowski, and T. Teo. Improving the systems engineering process with multilevel analysis of interactions. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 28(04):323–337, nov 2014. ↩

  28. A. H. Tilstra, C. C. Seepersad, and K. L. Wood. A high-definition design structure matrix (HDDSM) for the quantitative assessment of product architecture. Journal of Engineering Design, 23(10-11):767–789, 2012. ↩

  29. M. E. Sosa, S. D. Eppinger, and C. M. Rowles. Are your engineers talking to one another when they should? Harvard Business Review, 85(11):133–142, 2007. ↩

  30. S. Friedenthal, A. Moore, and R. Steiner. A practical guide to SysML: the systems modeling language. Morgan Kaufmann, Waltham, Massachusetts, USA, 2014. ↩

  31. T. Tomiyama, T. J. van Beek, A. A. C. Alvarez, H. Komoto, and V. D'Amelio. Making function modeling practically usable. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 27(Special Issue 03):301–309, 2013. ↩

  32. S. Tosserams, A. T. Hofkamp, L. F. P. Etman, and J. E. Rooda. A specification language for problem partitioning in decomposition-based design optimization. Structural and Multidisciplinary Optimization, 42(5):707–723, 2010. ↩↩

  33. W. W. Royce. Managing the development of large software systems: concepts and techniques. In Proceedings of the 9th international conference on Software Engineering, 328–338. Monterey, California, USA, 1987. ↩

  34. B. W. Boehm. A spiral model of software development and enhancement. Computer, 21(5):61–72, 1988. ↩

  35. K. Forsberg and H. Mooz. The relationship of system engineering to the project cycle. In Proceedings of the INCOSE International Symposium, 57–65. Wiley Online Library, 1991. ↩

  36. S. R. Childers and J. E. Long. A concurrent methodology for the system engineering design process. In Proceedings of the INCOSE International Symposium, 226–231. San Jose, California, USA, 1994. Wiley Online Library. ↩

  37. N.P. Suh. Axiomatic design theory for systems. Research in engineering design, 10(4):189–209, 1998. ↩

  38. C. L. Dym and D. C. Brown. Engineering Design: Representation and Reasoning. Cambridge University Press, Cambridge, England, 2nd edition, 2012. ↩

  39. N. Crilly. Function propagation through nested systems. Design Studies, 34(2):216–242, 2013. ↩↩↩

  40. J. M. C. De Gea, J. Nicolás, J. L. F. Alemán, A. Toval, C. Ebert, and A. Vizcaíno. Requirements engineering tools: Capabilities, survey and assessment. Information and Software Technology, 54(10):1142–1157, 2012. ↩

  41. S. Ghosh, D. Elenius, W. Li, P. Lincoln, N. Shankar, and W. Steiner. Arsenal: automatic requirements specification extraction from natural language. In NASA Formal Methods Symposium, 41–46. Minneapolis, Minnesota, USA, 2016. Springer. ↩

  42. A. Mustafa, W. M. N. Kadir, and N. Ibrahim. Automated Natural Language Requirements Analysis using General Architecture for Text Engineering (GATE) Framework. Journal of Telecommunication, Electronic and Computer Engineering (JTEC), 9(3-4):97–101, 2017. ↩

  43. T. Kuhn. A survey and classification of controlled natural languages. Computational Linguistics, 40(1):121–170, 2014. ↩

  44. P. Clark, P. Harrison, T. Jenkins, J. A/ Thompson, and R. H. Wojcik. Acquiring and using world knowledge using a restricted subset of english. In FLAIRS Conference, 506–511. Clearwater Beach, Florida, USA, 2005. ↩

  45. N. Fuchs, K. Kaljurand, and T. Kuhn. Attempto controlled English for knowledge representation. Reasoning Web. Lecture Notes in Computer Science, 5224:104–124, 2008. ↩

  46. A. Mavin, P. Wilkinson, A. Harwood, and M. Novak. Easy approach to requirements syntax (EARS). In Proceedings of the 17th IEEE International Requirements Engineering Conference, 317–322. Atlanta, Georgia, USA, 2009. ↩

  47. P. Feiler, J. Delange, and L. Wrage. A requirement specification language for AADL. Technical Report, Carnegie Mellon University, 2016. ↩

  48. J. Woodcock and J. Davies. Using Z: specification, refinement, and proof. Prentice Hall International, 1996. ↩