Practical experience of eliciting classes from use case descriptions

https://doi.org/10.1016/j.jss.2006.12.485Get rights and content

Abstract

In moving from requirements analysis to design, use cases are often recommended as the starting point for the derivation of classes. However, exactly how classes are to be found within the use case is not entirely obvious. Typical approaches suggest a simple noun/verb search or brainstorming. Recent work is moving towards an interrogation of the use case diagram as a means of validation and of the description (and scenario) to elicit objects in the problem domain. This paper presents a set of Elicitation Questions that enables the interrogation of descriptions from the perspectives of specification, software architecture and design. This qualitative ‘interrogation’ teases out design issues. The Elicitation Questions were trialled through application to a real industrial project at a financial services company. Feedback from practitioners shows that the Elicitation Questions are important in raising design and testing issues from the use case descriptions but the organisational culture in how software is developed would impact its uptake.

Section snippets

Motivation

Requirements engineering is about eliciting and describing a problem and/or opportunity for a software solution, typically before you deploy that solution. In order to understand where a software system will be used, it is important to understand the problem domain of that system. Use cases are a recommended means of establishing a model of the problem domain and then as a driver to enable the first steps into the structural design of the system (Jacobson et al., 1992, Rosenberg and Scott, 1999

Elicitation questions and use cases

The notion of questioning use cases and scenarios to find classes, objects and their components is not new. Rubin and Goldberg (1992) explore scripts (a form of use case) to find initiator and participants (behaviours) of objects, asking, “Which roles and responsibilities are needed to accomplish the required task? Furthermore, we must answer why a particular object exists, why it is linked to another object, why a particular service is provided by an object, and how the object participates in

The elicitation questions

These questions and heuristics were originally devised to consider how examination of dependencies among events aided the discovery and derivation of classes (Cox and Phalp, 2003). This approach was subsequently expanded to consider other design issues important to modern software systems, such as interfaces to other machines and a consideration of the internal machinations of the system itself. Note that the questions and heuristics (though interspersed with our commentary) are phrased in a

The case study

The industrial study was undertaken at a financial services company, based in the UK. The chief business of the company is the building and supporting of complex applications for online buying and selling of shares, stocks and investments, such as government bonds. The high quality of the online application, with its potential for the US market, led to a global financial services organisation acquiring the company just prior to the study.

IT plays a central role in delivery of the company’s

Feedback and discussion

Feedback was gained both by formal interview and comments raised in presenting the authors’ work to the stakeholders. (Stakeholders were members of the company’s IT Development team: Systems Analyst, Software Developer, Quality Assurance Manager, Software Development Manager, all with from two to 10 years practical software development experience.) Interviewees were asked the strengths and weaknesses of the Elicitation Questions. In general the feedback was positive. Some ‘hopefully

Conclusions

This paper has presented an elicitation approach to aiding the design formulation process by interrogating events in use case descriptions; in terms of dependencies (pre- and post-conditions), interfaces, actors, system processes and then an identification of potential classes. Two research questions were posed at the start of the paper:

  • RQ1. What is an appropriate technique to elicit classes from use cases?

In working on the reported project as contractors rather than academics, much

References (46)

  • J. Bosch

    Design and Use of Software Architectures

    (2000)
  • I. Bray

    An Introduction to Requirements Engineering

    (2002)
  • P. Coad et al.

    Object-Oriented Analysis

    (1991)
  • A. Cockburn

    Writing Effective Use Cases

    (2001)
  • Cox, K., Phalp, K., 2003. Exploiting use case descriptions for specification and design – an empirical study. In: 7th...
  • Cox, K., Phalp, K., Shepperd, M., 2001. Comparing use case writing guidelines. In: Achour-Salinesi, C., Opdahl, A.,...
  • A. Davis

    Just Enough Requirements Management

    (2005)
  • A. Davis et al.

    Requirements researchers: do we practice what we preach?

    Requirements Engineering Journal

    (2002)
  • A. Dennis et al.

    Systems Analysis and Design – An Applied Approach

    (2000)
  • J. Fernandes et al.

    From use cases to objects: an industrial information systems case study analysis

  • Gause, D., Weinberg, G., 1989. Exploring Requirements: Quality Before Design. Dorset...
  • I. Graham

    Requirements Engineering and Rapid Development

    (1998)
  • Hurlbut, R., 1997. A survey of approaches for describing and formalizing use cases. Technical Report XPT-TR-97-03,...
  • Cited by (14)

    View all citing articles on Scopus
    View full text