Identify the effective documentation method for representing the functional software architecture


  • Ibriwesh Iyas
  • Sin-Ban Ho
  • Ian Chai





Software Architecture, Requirements Documentation, Controlled Experiment, Requirements Engineering Context, Functional Perspective.


Software architecture mainly focuses on the high-level structures of the proposed software, and how to document these structures. A documentation method that represents an incomplete picture is one reason for inadequate requirements. This leads to requirements engineers wasting their time arguing over what to do and how to do it. Four documentation methods are frequently used in order to document stakeholders' statements, particularly for representing the functional perspective, namely, Natural Language (NL), Data Flow Diagram (DFD), Use Case Diagram (UCD), and Activity Diagram (AD). This research was carried out using the electronic market application domain as a test context. A controlled experiment was conducted among 158 participants, comparing among NL, DFD, UCD, and AD methods, which aimed to find out which requirements documentation method is more effective, helpful, and easier to comprehend. The results from this empirical study reveal that the AD method is more effective, understandable, and easier to document the software requirements in the functional perspective. Furthermore, AD had better performance in representing the requirements engineering context, system context, and development context than the other functional documentation methods. These empirical results would help software companies and associated experts enhance the quality of their software products, as well as increase the chance of success of software projects.


[1] K. Pohl and C. Rupp, Requirements Engineering Fundamentals: a study guide for the certified professional for requirements engineering exam-foundation level – IREB compliant, 2nd ed., USA: Rocky Nook Inc, 2015.

[2] H. S. Jabbar and T. V. Gopal, “Qualitative analysis model for software requirements driven by interviews,†J. Eng. Appl. Sci., vol. 2, no. 1, pp. 1–9, 2007.

[3] C. S. Murugan and S. Prakasam, “Stakeratreet: a new approach to requirement elicitation based on stakeholder recommendation and collaborative filtering,†Res. J. Appl. Sci., vol. 10, no. 10, pp. 574–586, 2015.

[4] K. A. Michael and K. A. Boniface, “Inadequate requirements engineering process: a key factor for poor software development in developing nations: a case study,†Int. J. Comput. Electr. Autom. Control Inf. Eng., vol. 8, no. 9, pp. 1462–1465, 2014.

[5] S-B. Ho, “Framework documentation with patterns: an empirical study,†PhD thesis, Multimedia University, Cyberjaya, Malaysia, Feb. 2008.

[6] N. Ibrahim, W. Kadir, and S. Deris, “Documenting requirements specifications using natural language requirements boilerplates,†in Proc. MySEC’14, 2014, p. 19–24.

[7] T. Bures, P. Hnetynka, P. Kroha, and V. Simko, “Requirement specifications using natural languages,†Charles Univ., Prague, Czech Republic, Tech. Rep. D3S-TR, 2012.

[8] J. Barros and L. Gomes. (2000) From activity diagrams to class diagrams. [Online]. Available:

[9] M. Dumas and A. H. M. Hofstede, Ed., The Unified Modeling Language. Modeling Languages, Concepts, and Tools: UML Activity Diagrams as a Workflow Specification Language, ser. Lecture Notes in Computer Science. Toronto, Canada: Springer, 2001, vol. 2185.

[10] D. Kundu and D. Samanta, “A novel approach to generate test cases from UML activity diagrams,†J. Object Technol., vol. 8, no. 3, pp. 65–83, 2009.

[11] B. Hnatkowska and M. Grzegorczyn, “Empirical comparison of comprehensibility of requirement specification techniques based on natural languages and activity diagrams,†in Proc. MSVVEIS'12, 2012, p. 27-36.

[12] R. Boudour and M. T. Kimour, “Model transformation for requirements verification in embedded systems,†Asian J. Inf. Technol., vol. 4, no. 11, pp. 1012–1019, 2005.

View Full Article: