![](bga.png)
cases when reasonable should be replaced with activity diagrams. Being more pre-
cise, in our opinion SRS should consists of following artifacts:
(a) business glossary – defining main terms from the problem domain,
(b) use-case diagram – presenting the system boundary,
(c) activity diagrams for selected (not trivial) use-cases accompanied by at least short
descriptions presenting the aim of the use-case and business rules (not directly ex-
pressed on the activity diagram),
(d) textual specification for trivial use-cases (e.g. CRUD), mainly presenting in-
put/output together with business rules to be satisfied.
In future work we plan to perform more experiments checking the validity of the
recommendations given above, especially in the context of incremental software
development. In such a case an analyst/developer needs to have a general picture of
the whole but does not need to remember all details at once.
References
1. Attempto Project, http://attempto.ifi.uzh.ch/site/
2. Booch G., Rumbaugh J., Jacobson I.: The Unified Software Development Process, Addison
Wesley (1999).
3. Cockburn A.: Writing effective use-cases. Addison-Wesley (2001)
4. Condori-Fernández, N., Daneva, M., Sikkel, K., & Herrmann, A.: Practical Relevance of
Experiments in Comprehensibility of Requirements Specifications. International Workshop
on Empirical Requirements Engineer. Trento: IEEE Computer Society (2011) 21–28.
5. Gross, A., & Doerr, J.: EPC vs. UML Activity Diagram – Two Experiments Examining
their Usefulness for Requirements Engineering. In: Proceedings of the 2009 17
th
IEEE
International Requirements Engineering Conference. IEEE Computer Society, Washington,
DE, USA (2009)
6. Gursimran, S. W., & Carver, J.: A systematic literature review to identify and classify
software requirement errors. Information and Software Technology, Vol. 51, Iss. 7,
(2009)1087–1109.
7. IEEE Recommended practice for software requirements specification. IEEE Standard 830–
1998
8. Kabeli, J., & Shoval, P.: Comprehension and quality of analysis specifications – a
comparison of FOOM and OPM methodologies. Information and Software Technology.
(2005) 271–290
9. Kamsties, E., Knethen, A. V., & Reussner, R.: A controlled experiment to evaluate how
styles affect the understandability of requirements specifications. Information and Software
Technology Vol. 45, (2003) 955–965
10. Lauesen S.: Software requirements, London, Addison-Wasley (2002)
11. Machado, R., Ramos, I., & Fernandes, J. (brak daty). Specification of Requirements
Models. In: Aybüke Aurum, Claes Wohlim (Eds.), Engineering and Managing Software
Requirements, chap. 3, Springer-Verlag, Berlin Heidelberg, Germany (2005) 47–68
12. OMG Unified Modeling Language (OMG UML), Superstructure Version 2.3, (2010),
http://www.omg.org/spec/
13. OpenUP, http://epf.eclipse.org/wikis/openup/
14. Phalp, K., Adlem, A., Jeary, S., Vincent, J., & Kanyaru, J.: The role of comprehension in
requirements and implications for use case descriptions. Software Quality Journal, (2011)
461–486.
36