2 Part 2: A Tour through the V-Modell

2.5 Specification of Requirements

2.5.2 Requirements Specification

V- Model Description: »Requirements Specification

The product »Requirements Specification includes all requirements identified for the system to be developed. It is the basis for the request for proposal and the contract, and thus the most important specification for the preparation of an offer. The requirements specification is part of the contract between acquirer and supplier. The requirements specify the framework conditions for the development, which will be detailed by the supplier in the »Overall System Specification.

When preparing the »Requirements Specification the Requirements Analyst Mr.Sokrates considers the specifications of the »Project Proposal and of the previous »Project Progress Decision. He uses the finished chapter »Project Objectives and System Concepts of the »Project Proposal as basis and adapts it specifically to the project stage Trademark and Patent Information System I.

In the course of further research, Mr. Sokrates discovers that the Trademark and Patent Administration of the Technische Universität München has an information system called Trademark and Patent Forum, which is accessible via Internet. This system is used for presenting available files to the public. Thus the idea to establish an interface between the Trademark and Patent Information System I and the already existing Trademark and Patent Forum suggests itself.

Requirements Specification: Initial Situation and Objectives

The management and processing of the files of the Trademark and Patent Administration of the Technische Universität München is intended to be supported electronically by the Trademark and Patent Information System.


The first project stage, Trademark and Patent Information System I, will only support the application of trademarks.

In detail, the Trademark and Patent Information System I will support the following

  • the preparation of trademark applications,
  • the examination of trademark applications by the Trademark and Patent Administration of the Technische Universität München,
  • the rejection of trademark applications by the Trademark and Patent Administration of the Technische Universität München,
  • the submission of trademark applications to the German Patent and Trademark Office by the Trademark and Patent Application of the Technische Universität München
  • the publication of the existing files in the existing Trademark and Patent Forum.

For every trademark to be registered, a data file will be prepared, examined and submitted to the the German Patent and Trademark Office as required.

As a first step for preparing the chapter »Functional Requirements, the Requirement Analyst Mr. Sokrates defines the actors interacting with the Trademark and Patent Information System. By determining the individual tasks which should be fulfilled by the system for these actors, he can derive the requirements. He sketches these use cases in a survey diagram.



After completing the survey diagram, the Requirement Analyst Dr. Sokrates describes the exact profile of the use cases. For this purpose, he uses a uniform description method which is not specified by the V-Modell but has proven its worth in previous projects. All use cases will be described uniformly by this method (see Figure 5 ). This facilitates the preparation of unambiguous, repeatable, verifiable and complete requirements (Reference: »RD02).


Figure 5: Use Case Form

The following example shows the application of this template to the use case "Processing registration"

Requirements Specification (continued)

Use case 4.3: <<Processing registration>>

Point of contact:

Requirement Engineer, Mr. Sokrates, Trademark and Patent Administration, Technische Universität München

Brief description:

The system must enable the applicant to process his registration.




The reference number will be assigned automatically, making the registration unambiguously identifiable.

Open questions:


Integration and survey:

Administering registration


All documents required are available in electronic form.


The applicant wants to submit an application for the registration of his/her trademark.


Applicant and examiner receive a notification including the reference number.

Normal flow of events:

  • The applicant selects the functionality for preparing a new application
  • The system shows an input mask.
  • The applicant can enter his/her personal data (name, address, telephone, e-mail).
  • The applicant can add or delete files.
  • The applicant transmits the entry.
  • The system assigns a registration number.
  • The system stores the entry.
  • Use use case 6 <<Informing>> (<<Benachrichtigen>>)
  • The system indicates the registration number.

Alternative flow of events:

  • Before the entry is transmitted, the process can be aborted at any time. The entry will not be stored and the application case is terminated.
  • The applicant does not load a file. The system informs him/her that a trademark file must be attached to every application. A transmission is impossible unless this fault is corrected.
  • The applicant enters incomplete or wrong personal data. The system induces the applicant to correct the data; otherwise a transmission is impossible.



The Requirements Analyst Mr. Sokrates describes requirements regarding additional quality characteristics of the system - e.g. user-friendliness and reliability - or the system development process in the chapter »Non-Functional Requirements.

Requirements Specification: Non-Functional Requirements

The specified system shall correspond to the state of the art and fulfill the organizational and legal framework conditions of the Technische Universität München. It shall fit smoothly into the existing data processing environment. The following requirements were specified:

Quality Requirements


  • NF 1: Faults and wrong inputs shall be indicated in near real time (response time < 0,5s) to the user. The application shall be supported by a help mode.
  • NF 2: The graphical user interfaces shall be clear and robust, have a uniform structure and provide the required functionality. An intuitive operation must be possible, i.e., the user bust be able to operate the system without instruction, only using the help mode.
  • NF 3: The user input interface shall be adapted to the web-based surface of the German Patent and Trademark Office.

Reliability and Protection

  • NF 4: The system shall always respond reliably - even under high workloads. Uncontrolled system crashes and data losses shall be avoided. In case of a malfunction, it must be ensured that at least the data of the previous day can be used.
  • NF 5: Programs and data shall be protected against inadvertent modifications.

System Creation Requirements

Technical Requirements

  • NF 7: Java shall be used as implementation language.
  • NF 8: Windows XP is the target system.
  • NF 9: The system shall be based on components in order to facilitate maintainability and extendability.
  • NF 10: As far as possible, the system architecture shall be documented in the Unified Modeling Language (UML).

Logistic Requirements

  • NF 11: Suitable training and instruction documents for the system's end users are to be prepared.
  • ...


Together with a colleague, the »Requirements Engineer (Acquirer) Mr. Sokrates defines a rough architecture of the system in order to clarify the specified requirements and ensure that the requirements are technically feasible. He describes this architecture in the chapter »Outline of the Life Cycle and the Overall System Architecture.


The architecture of Trademark and Patent Information System I is intended to be designed as web-based client-server model comprising database, system core and a web-based user interface. Trademark and Patent Information System I transmits trademark applications via E-mail to the German Patent and Trademark Office.

The »Requirements Engineer (Acquirer) Mr. Sokrates submits this version of the requirements to a group of future users for evaluation.

In this text, we have followed the way of the project by means of the project results - i.e. the products - and their interconnections within the development process in order to illustrate the processing of a project in accordance with the V-Modell. The following procedural steps include request for proposal, commissioning and acceptance of the system. The processing of these project sections in a real project and the processing of a supplier project are left to the reader.