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
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. Priority: High Notes: The reference number will be assigned automatically, making the registration unambiguously identifiable. Open questions: None Integration and survey: Administering registration Preconditions: All documents required are available in electronic form. Trigger: The applicant wants to submit an application for the registration of his/her trademark. Postconditions: Applicant and examiner receive a notification including the reference number. Normal flow of events:
Alternative flow of events:
... |
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 User-friendliness
Reliability and Protection
System Creation Requirements Technical Requirements
Logistic Requirements
... |
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.