Journal of Computer Science and Technology

, Volume 21, Issue 1, pp 32–40 | Cite as

Revisiting the Meaning of Requirements



Understanding the meaning of requirements can help elicit the real world requirements and refine their specifications. But what do the requirements of a desired software mean is not a well-explained question yet though there are many software development methods available. This paper suggests that the meaning of requirements could be depicted by the will-to-be environments of the desired software, and the optative interactions of the software with its environments as well as the causal relationships among these interactions. This paper also emphasizes the necessity of distinguishing the external manifestation from the internal structure of each system component during the process of requirements decomposition and refinement. Several decomposition strategies have been given to support the continuous decomposition. The external manifestation and the internal structure of the system component have been defined. The roles of the knowledge about the environments have been explicitly described. A simple but meaningful example embedded in the paper illustrates the main ideas as well as how to conduct the requirements decomposition and refinement by using these proposed strategies.


problem decomposition requirements analysis requirements refinement 


  1. 1.
    Jackson M. The meaning of requirements. Annals of Software Engineering, 1997, 3: 5–21.CrossRefGoogle Scholar
  2. 2.
    Zave P, Jackson M. Four dark corners of requirements engineering. ACM Trans. Software Engineering and Methodology, January 1997, 6(1): 1–30.Google Scholar
  3. 3.
    Harnad S. The symbol grounding problem. Physica D, 1990, 42: 335–346.CrossRefGoogle Scholar
  4. 4.
    Xu G, Gu J, Che H (eds.). Systems Science. Shanghai Scientific and Technological Education Publishing House, 2000.Google Scholar
  5. 5.
    Leszek A Maciaszek. Requirements Analysis and System Design: Developing Information Systems with UML. Pearson Education Limited, 2001.Google Scholar
  6. 6.
    Jackson M. Problem Frames: Analyzing and Structuring Software Development Problems. Addison-Welsley, 2001.Google Scholar
  7. 7.
    Buschmann F, Meunier R, Rohnert H, Sommerlad P, Stahl M (eds.). Pattern-Oriented Software Architecture: A System of Patterns. John Wiley, 1996.Google Scholar
  8. 8.
    Jackson M, Zave P. Deriving specifications from requirements: An example. In Proc. the 17th Int. Conf. Software Engineering, ACM and IEEE Computer Society Press, Los Alamiton, CA, 1995, pp.15–24.Google Scholar
  9. 9.
    Chandrasekaran B, Josephson J R, Benjamins V R. Ontology of tasks and methods. In Proc. the Workshop on Knowledge Acquisition, Modeling and Management (KAW'98), Banff, Canada, 1998, pp.1–13.Google Scholar
  10. 10.
    Leveson N G, Heimdahl M P E, Hildreth H, Reese J D. Requirements specification for process-control systems. IEEE Trans. Software Engineering, 1994, 20(9): 684–707.Google Scholar
  11. 11.
    Axel van Lamsweerde. Formal refinement patterns for goal-driven requirements elaboration. In Proc. the 4th ACM Symposium on the Foundations of Software Engineering (FSE4), San Francisco, USA, 1996, pp.179–190.Google Scholar
  12. 12.
    Mylopoulos J, Chung L, Yu E. From object-oriented to goal-oriented requirements analysis. Communication of ACM, 1999, 42(1): 31–37.Google Scholar
  13. 13.
    Letier E, Axel van Lamsweerde. Deriving operational software specification from system goals. In Proc. 10th ACM SIGSOFT Symposium on the Foundations of Software Engineering, Charleston, South Carolina, USA, 2002, pp.119–128.Google Scholar
  14. 14.
    Parnas D L, Madey J. Functional documentation for computer systems. Science of Computer Programming, 1995, 25(1): 41–61.CrossRefGoogle Scholar
  15. 15.
    Heitmeyer C L, Jeffords R D, Labaw B G. Automated consistency checking of requirements specification. ACM Trans. Software Engineering and Methodology, July 1996, 5(3): 231–261.Google Scholar
  16. 16.
    Gunter C A, Gunter E L, Jackson M, Zave P. A reference model for requirements and specification. IEEE Software, May/June 2000, 17(3): 37–43.Google Scholar
  17. 17.
    Jon G Hall, Lucia Rapanotti, Michael Jackson. Problem frames semantics for software development. Journal of Software and System Modeling, 2005, 40(2): 189–198.Google Scholar

Copyright information

© Springer Science + Business Media, Inc. 2006

Authors and Affiliations

  1. 1.Academy of Mathematics and System ScienceChinese Academy of SciencesBeijingP.R. China
  2. 2.Institute of Computing TechnologyChinese Academy of SciencesBeijingP.R. China

Personalised recommendations