Writing Use Cases in XML

Writing use cases is the most important step for modeling user requirements. Use cases focus on describing scenarios of using the system and are usually written in a textual form. To assist use case writing, various templates have been proposed, mainly differing in their visual representation. XML is a platform independent language for describing data and their structure without referring to their visual presentation. Here, we will propose the writing of use cases in XML. Using XML, we achieve the clear separation of the semantic part of use case descriptions from their visual representations. Hence, the same description can be visualized in many different ways. Furthermore, our encoding allows the integration of tools for Writing and validating use cases. We introduce an appropriate structure for use case descriptions and we model this structure using DTD (Document Type Definition).

Use cases constitute the basic way of modelling user requirements during software development. Nevertheless, there exist no standard rules for writing them. During the last years, many templates have been proposed for writing use cases. Some examples are the fully-dressed, the table, and the two-column format. Essentially, all these formats contain the same information presented in a different way. Also, different levels of detail are needed in different phases of software development. This need presupposes that the information is not degraded during its transformation in more detailed forms. XML (eXtensible Markup Language)is a language for data description, which has the potential of representing information in different forms, as well as, in different levels of detail. Compared to other documents, such as HTML and PDF, an XML document is not bound to an explicit output format. With the description written in XML, it is possible to produce any of the desired formats without rewriting the contents.

Our aim is to define a technique that will assist developers in writing use cases, without bothering about its visual representation, while at the same time respecting the logical structure of a use case. For visualization purposes, we provide several XSLT transformations that can be applied and result different visual formats in different levels of detail.

Use Cases:

Use cases are a technique for documenting functional requirements of a system under development. User requirements are modeled twofold: writing use cases descriptions and constructing a use case diagram. A use case diagram is composed of use cases and represents the global system’s behavior. Each use case corresponds to an exact behavior of the system that satisfies a user goal. Formally, a use case is defined as a sequence of events that illustrates the behavior of a system and its components when a service is invoked this behavior is described in several ways but the most common one is the textual description.

Structure for writing Software Requirements Specification (SRS)

Software Requirements Specification (SRS) is a requirements specification for a software system, in other words it is a complete description of the behavior of a system to be developed. It is includes a set of use cases that describes the interactions between system actors (System Users) with the Software system. Also SRS contains list of functional and non-functional software requirements.

This document lists all necessary requirements for application development, so it is written after a meeting or detailed communication between project manager and customer. A general structure of an SRS will be as follows:

1. Introduction:
   This part provide an overview of the SRS document, and it should contain all information needed by a software engineer to design and implement the software product described by the requirements listed in this document.
1. Purpose:
   What is the purpose of this SRS and the (intended) audience for which it is written.
    
2. Scope:
   Here we will identify software product by its name, and explain what the software product(s) will, and, if necessary, will not do. Then we can describe the application of the software being specified. As a portion of this, it should be consistent with similar statements in higher-level specifications, and describe all relevant benefits, objectives, and goals as precisely as possible.
    
3. Definitions and Abbreviations:
   Provide the definitions of all terms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendixes in the SRS or by reference to other documents.
    
4. References:
   This subsection should provide a complete list of all documents referenced elsewhere in the SRS, or in a separate, specified document. Identify each document by title, report number, and publishing organization. And specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.