Deriving specifications from requirements: an example
Proceedings of the 17th international conference on Software engineering
Four dark corners of requirements engineering
ACM Transactions on Software Engineering and Methodology (TOSEM)
Distributed Feature Composition: A Virtual Architecture for Telecommunications Services
IEEE Transactions on Software Engineering
| Hi-index | 0.00 |
Ten years ago, our paper described how a very small system might be developed to control a coin-operated turnstile in a zoo [1]. It arose out of our efforts to understand how requirements, domain knowledge and specifications fit together, and how specifications could be derived systematically. A particular goal was to understand requirements and specifications for telecommunication systems well enough to handle the feature interaction problem that plagues telecommunication software.A year later we published a more comprehensive version of our requirements framework [3], and began to develop the Distributed Feature Composition (DFC) architecture for telecommunication services [2]. We continued to work on it together until mid-2002. DFC has proven successful in practice, and is now being used in a commercial voice-over-IP service.Since publishing the requirements framework, we have worked on different kinds of system, and have been confronted with important differences in how its principles apply. It has taken all this time to achieve the goal of understanding requirements for telecommunication services and other connection services. In this domain, requirements are heavily influenced by the fact that services are assemblies of components added to a basic network infrastructure. Our work in another direction has led to a focus on system interaction with the human and physical world, recognising the varying roles of formalisation and formal reasoning in problems of different kinds, and the need for a stronger grip on the relationship between engineering of software and engineering in the world.The common lesson of these experiences is that the requirements framework of ten years ago is a good generalization, but specific domains and situations require their own specializations of it.