semorg requ spec.v3.0

Seminar Organization: Requ. Spec. v3.0

Seminar Organization

Requirements Specification v3.0

version author security quality date status comment2.1 Balzert 03/91 accepted 2.2 Balzert 10/91 accepted F115 added

2.3 Balzert 10/95 accepted

F15, F125, F185, D65 removed; F130, D10, D20 added; D30, D70 changed

3.0 07/00 accepted extension on Web

1. Goals

The seminars presented by "Teachware" company should be supported by computers.

1.1 Compulsory criteria

l managing seminars l managing presentations l managing clients (participants/interested parties) l managing client companies l managing lecturers l queries like: When will the next X seminar take place?

Which associates participated the seminar Y?

1.2 Optional criteria

l all compulsory functions (the compulsory criteria) should be accessible through Internet (Web browser)

l hotel and contact person management l statistic evaluation l data security support

1.3 Exclusion criteria

l no accounting (book keeping) integrated (the accounting has a copy of invoice and keeps track of payment and notifies the paying delay)

file:///C|/reqspec3_0.htm (1 von 13)20.02.2007 14:27:34


2. Product usage

The product is used by client-, company-, lecturer-, seminar- and presentation management of "Teachware" company. Besides, the various queries should be answered.

2.1 Application area

Salesman, administrative application area

2.2 Target groups

Associates of "Teachware" company should be divided into: client manager, seminar manager, presentation custodian.

"Teachware" clients: clients and companies can get the information about seminars and presentations on the Internet. They can book using Internet, as well.

2.3 Company conditions

Office environment.

3. Product overview

Overview diagram:



4. Product functions

4.1 Use cases

F10 (PF10)

Use case: informing: from question to informationGoal: client gets required information or the information material is sent to her/himCategory: primaryPreconditions: -Post condition success: client gets required information



Post condition failure: the required information can not be issuedActor: client manager, client, companyTriggering event: client writes (letter, fax, e-mail) or callsDescription:

1. client data retrieval 2. information issue

Extension:1. A client data actualization 2. A production of address label (for sending info-material)

Alternatives:1. An inclusion of a new client

F20 (PF20) Use case: booking: from registration to bookingGoal: the registration notification and sending invoice to the client Category: primaryPreconditions: -Post condition success: client is notifiedPost condition failure: notification to clients that presentation is overbooked, or does not exist, or a booking for the client is already made Actor: client manager, client, companyTriggering event: client registration is availableDescription:

1. client data retrieval 2. presentation verification 3. booking undertaking 4. registration notification and sending invoice 5. sending invoice copy to the accounts department

Extension:1. A client data actualization 1. B when client is associate of the company, associated company data are updated

and accessed 1. C invoice verification

Alternatives:1. A inclusion of a new client 2. A when the presentation is over booked, to point out the alternative one 2. B notification of "false presentation", if the presentation does not exist

F21 Use case: checking out: from canceling to credit noteGoal: the cancel notification and sending the client a credit noteCategory: primaryPreconditions: client is registered for a presentation Post condition success: client is canceled



Post condition failure: client was not registered Actor: client manager, client, companyTriggering event: client canceling is availableDescription:

1. client data retrieval2. presentation verification 3. cancel undertaking 4. cancel notification and credit note issue

Extension:1. A client data actualization 3. A 200 EUR fee for canceling, when canceled more than 4 week before presentation 3. B 100% fee for canceling, when canceled less than 4 week before presentation

Alternatives: - F22 Use case: canceling: from canceling to cancel notificationGoal: the cancel notification sent to all clients, lecturers and presentation custodians, sending the client a credit noteCategory: primaryPreconditions: client is notified about canceled presentation, lecturers stop presenting the canceled presentationPost condition success: clients, lecturers, presentation custodians and seminar managers are informed about Post condition failure: - Actor: client manager, seminar managerTriggering event: presentation must be canceled, because of, for instance, lecturer's illnessDescription:

1. concerned clients, lecturers and presentation custodian are contacted 2. presentation canceling 3. sending canceling of presentation notification

Extension:3. A credit note sending 3. B credit note copy to account department

Alternatives:1. A if a lecturer is not able to keep a presentation, verify alternative lecturer 3. A offering alternative presentation

F23 Use case: booking company: from registering to booking a company's internal presentationGoal: sending a registration proof to a company's contact personCategory: primaryPreconditions: -Post condition success: company got the invoice and the registration form



Post condition failure: sending notification to clients that internal company presentation is not possible Actor: seminar managerTriggering event: company notification is availableDescription:

1. company data retrieved2. presentation registration 3. booking undertaken 4. produce registration proof

Extension:1. A company data actualization 1. B invoice verification

Alternatives:1. A a new company inclusion 2. A to show an interest in company's wishes 2. B informing lecturers about company wishes

F30 (PF30) Use case: presenting seminar: from participation to evaluationGoal: lecturers are conducting the presentationCategory: primaryPreconditions: presentation has enough participants and is not canceledPost condition success: presentation is conductedPost condition failure: - Actor: presentation custodianTriggering event: presentation beginning dateDescription:

1. participants list and evaluations to participants and lecturers 2. certificates to participants3. evaluations collection 4. proof of 5. payment notification to account department

Extension: -Alternatives:- F40 (PF40) Use case: designing seminar: from idea to a new seminarGoal: new seminar conductionCategory: primaryPreconditions: ask for client's, company's, and lecturer's opinion, examine the marketPost condition success: new seminar realizationPost condition failure: - Actor: seminar managerTriggering event: start planning period



Description: 1. look at seminar and presentation statistics (participants figures and payments) 2. seminar realization

Extension:2. A order lecturers 2. B presentation scheduled (Use case: presentation planning)

Alternatives:1. A delete a seminar 1. B seminar modification

F50 (PF50) Use case: acquiring lecturer: from choosing to engagingGoal: new lecturers engagingCategory: secondaryPreconditions: market examinationPost condition success: new lecturer engaged, contract sentPost condition failure: - Actor: seminar managerTriggering event: start the planning period or sporadicDescription:

1. to see a new seminar and presentation2. lecturer registration

Extension:2. to assign seminars and presentations to lecturer

Alternatives:2. A delete lecturer 2. B actualize lecturer

F60 (PF60) Use case: planning presentation: from scheduling to reservationGoal: presentation scheduled, place fixed and reservedCategory: secondaryPreconditions: -Post condition success: planned presentation Post condition failure: planned presentation is not finished Actor: seminar managerTriggering event: start the planning period or sporadicDescription:

1. to see a new seminar 2. presentation registration

Extension:1. to see unfinished planned presentations

Alternatives:



2. to plan an incomplete presentation 4.2 Lists F70 (PF70) Participant list: a) per presentation with following data: seminar title, staring date, finishing date, presentation place, lecturers; b) per participant: first name, family name, company, town

F80 (PF80) Participant certificate: for every presentation participant with following data: address, title, first name, family name, starting date, finishing date, seminar title, place, overview, conductor F90 (PF90) Queries like the following should be allowed:When the next X seminar will be held?Which associates of company Y participated in seminar X? 5. Product data 5.1 Client data D10 (PD10) Client data (max. 50 000):Client number, name, address, communication data, date of birth, function, exchange, short information, notices, info material, client since. D20 (PD20) Company data (max. 10 000):When a client is an associate of a company:Company's short name, company name, address, communication data, contact person, section, date of birth, function of contact person, short information, notices, exchange, client since D21If a company is in a paying delay, then the following data should be saved:Date of still unpaid invoice, as well as amount 5.2 Seminar data D30 (PD30) Presentation data (max. 100 000):Presentation number, duration (in days), from, to, daily period split-beginning, daily period split-end, beginning of the first day, end of the last day, presentation place (hotel/company, address, room), cooperation partner, public (yes/no), net price, cancel fee, min. participant rate, max. participant rate, actual participant, carried out (yes/no) D40 (PD40) Seminar type data (max. 10 000):



Short title of seminar, seminar title, purpose, methodic, overview, daily procedure, duration, records, target group, requirements, fee without tax, min. participant rate, max. participant rate D50 (PD50) Lecturers data (max. 5 000):Lecturer number, name, address, communication data, date of birth, biography, daily allowance, short information, notices, lecturer since. D60 If a lecturer conducts a seminar, this information should be saved. 5.3 Booking data D70 For every seminar booking by company or client, following information should be saved: Registered when, validated when, biledl when, canceled when, notification when. 6. Product efficiency E10 (PE10) Function F90 must take less than 15 sec to answer.

E20 (PE20) All reaction times on user actions must take less than 2 sec (except function F90)

7. Quality requirements

Product quality excellent good normal not relevant

Functionality Suitability X

Accurateness X

Interoperability X

Compliance X

Security X

Reliability Maturity X

Fault tolerance X

Recoverability X

Usability



Understandability X

Learn-ability X

Operability X

Efficiency Time behavior X

Resource behavior X

Maintainability Analyzability X

Changeability X

Stability X

Testability X

Portability Adaptability X

Install-ability X

Conformance X

Replace-ability X

8. User interface

U10 Standard Windows-oriented environment.

U20 The web-browser handling is simplified. The available functions are executed in side-wise frames. In main frames are presented the lists and register masks.

UI30 Service interfaces are designed for mouse.

U40 ISO 9241-10: 1996 (Ergonomic requirements for office work with screen machines, part 10: dialog design fundamentals) to be taken into account.

U50 Distinguish the following roles:



Role RightsClient manager F10, F20, F21, F90

Seminar manager F22, F23, F40, F50, F60, F90Presentation custodian F30, F70, F80

LecturerF70, F80 (for some presentations only through Internet)

Client, Company F10, F20, F21 (only through the Internet)

9. Non-functional requirements

If a functionality would be used over the Internet, than a secure transmit has to be possible, after a client's wish, especially for roles of client manager, seminar manager, presentation custodian.

10. Technical product environment

Product is client/server and Internet-enabled.

10.1 Software

Server-operating system: Windows NT/98.

Client-operating system: Windows NT/98 or Browser.

10.2 Hardware

Server: PC.

Client: Browser enabled machine with graphic monitor.

10.3 Orgware

Network connection of servers to accounts department's computer.

10.4 Product interfaces

A copy of a produced invoice will be stored as a data. Account department has an access to this data through an available function. Paying delays will be entered by account department through an available function.



11. Special requirements for development environment

No variations of product environment.

12. Structure of product parts

The tree parts of product are planned: the first version includes kernel functionality without Internet functionality. The second version covers core functionality expanded with some Internet functionality like booking and booking the company's internal presentation. The third version supports hotel and terminal management.

Functions SemOrg v1.0 (Kernel)SemOrg v2.0 (Kernel)

SemOrg v3.0 (Kernel)

F10 informing X (without Internet) X (with Internet)

F20 booking X (without Internet) X (with Internet)

F21 checking out X (without Internet) X (with Internet)

F22 canceling X (without Internet) X (with Internet)

F23 company booking X

F30 presenting seminar

X (without Internet) X (with Internet)

F40 designing seminar


F50 acquiring lecturer


F60 planning presentation

X (without hotel management)

X (with hotel management)

F70 participant list X (without Internet) X (with Internet)

F80 participant certificate


F90 queries X (without Internet) X (with Internet)

13. Supplements



According experience, 5% of all clients are in paying delay.


Lokale FestplatteSeminar Organization: Requ. Spec. v3.0

semorg requ spec.v3.0

Documents