topic 5 results of the „analysis and definition“...
TRANSCRIPT
1
Humboldt University Berlin, University of Novi Sad, University of Plovdiv,University of Skopje, University of Belgrade, University of Niš, University of Kragujevac
Version: Feb. 06, 2004 (D Feb. 06, 2004)
DAAD Project“Joint Course on Software Engineering”
Topic 5Results of the „Analysis and Definition“
phase
Parts of this topic use material from the textbook H. Balzert, “Software-Technik”, Vol. 1, 2nd ed., Spektrum Akademischer Verlag, 2001
2
2DAAD project „Joint Course on Software Engineering“ ©
5. Results of the „Analysis and Definition“ phase
a) Overview of results: feasibility study, product definition
b) Activities of the planning phase
c) The contents of requirements specification -standardization
d) An example of a requirements specification
3
3DAAD project „Joint Course on Software Engineering“ ©
Analysisand
Definition
Analysisand
Definition
The classical waterfall model:analysis and definition
DesignDesign
ImplementationImplementation
TestTest
Usage and MaintenanceUsage and
Maintenance
4
4DAAD project „Joint Course on Software Engineering“ ©
Goals of the phase ‘analysis and definition’
Analysis of the problem to be solvedDefinition of the requirements of the software product
Description of external behavior of the software system
5
5DAAD project „Joint Course on Software Engineering“ ©
Product definition• requirements
specification• product model• user interface• user manual
Definition phase
Analysis andDefinition
Analysis andDefinition
Splitting of the phase ‘analysis and definition’
DesignDesign
ImplementationImplementation
TestTest
Usage and MaintenanceUsage and
Maintenance
Feasibility study• glossary• preliminary require-
ments specification • cost estimation• project plan
Planning phase
Balzert(2001)
Reason for splitting ?
6
6DAAD project „Joint Course on Software Engineering“ ©
Documents of the phase analysis and definition
Feasibility study• glossary• preliminary requirements
specification• cost estimation• project plan
Product definition• requirements specification
(verbal description)• product model
(suitable basis methods, non-verbal, formalized description)
• user interface (concept or/and prototype)
• user manual(preliminary)
Definition phasePlanning phase
2 subphases, 8 single documents
Topic 6
Topic 27
Topic 10, 13
Topic 25
Topic 26
7
7DAAD project „Joint Course on Software Engineering“ ©
Remarks
Result of this phase:• not only one document• but: a set of documents (4 + 4)
Feasibility study can lead to an interruption of the projectFeasibility study: basis of contractProduct definition: basis of designno unified concept of documentsdifferent notations:
product definition = requirements definition= system specification
dependent on project and companyhere: Balzert 2001
8
8DAAD project „Joint Course on Software Engineering“ ©
5. Results of the „Analysis and Definition“ phase
a) Overview of results: feasibility study, product definition
b) Activities of the planning phase
c) The contents of requirements specification -standardization
d) An example of a requirements specification
9
9DAAD project „Joint Course on Software Engineering“ ©
Planning phase: activities, roles, products
preliminary requirements specification
glossary
cost estimation
project plan
Source: Balzert, vol. 1, p. 60
Templatepreliminary requirements specificationglossary
RepositoryText editor
guidelines of the customer
planning of the product
project leader
customer application specialist
Feasibility study
legend:activity role document (artifact) tool
10
10DAAD project „Joint Course on Software Engineering“ ©
Roles: responsibility and cooperation (1)
crcproject plancrccost estimationrccglossaryrccprelim. requirements spec.
Application specialist
Project leader
CustomerActivities
11
11DAAD project „Joint Course on Software Engineering“ ©
Example: customer‘s request „Seminar Organization“
A company for advanced training (on-the-job training) needs a computer-based system for the management of its lectures. In particular, it should be possible to administrate seminars and participants, to issue invoices, to answer queries and to create statistics.
fundamental case study of this course
12
12DAAD project „Joint Course on Software Engineering“ ©
Glossary
Defines notions to assure a unified terminologyThe glossary will be reused for the user interface, the online help and the user manual.Examples:• Seminar organization: 12 notions• XCTL (control program in physics): 110 notions
13
13DAAD project „Joint Course on Software Engineering“ ©
Example of a glossary (excerpt)Glossary
Seminar organizationVersion 1.0
Version Author Date Status Comment——————————————————————————————————————1.0 Balzert 31.07.2000 accepted
ClientAssociate of a company or a private person, who is interested in services, or have booked and participated the seminar.
Client managerResponsible for communication with clients and companies, together with booking and information providing.
CompanyAssociate of a company (contact person) who is responsible for education and further education of company employees and who is informed about services or who sends associates on public presentations, or who books for closed presentations.
14
14DAAD project „Joint Course on Software Engineering“ ©
Additional case study: XCTL
Application field: technical application(control program in experimental physics)Real customer: Institute of Physics, HUXCTL: Xray Control• Analysis of crystal structures of semiconductors by
X-rays• Software controls experiments: movement of
samples by motors, supervision of experimantalsequences, recording (logging) and interpretation of measurments (e.g. pictures)
Use in SE lectures: examples of a requirements specification,use case diagram, metrics, reverseengineering
15
15DAAD project „Joint Course on Software Engineering“ ©
XCTL –working environment
working place
X-ray topographycamera
16
16DAAD project „Joint Course on Software Engineering“ ©
5. Results of the „Analysis and Definition“ phase
a) Overview of results: feasibility studies, product definition
b) Activities of the planning phase
c) The contents of requirements specification -standardization
d) An example of a requirements specification
17
17DAAD project „Joint Course on Software Engineering“ ©
Definition phase: activities, roles, products
glossary
defining the product
customer application specialist
projectleader
systemanalyst
preliminary requirements specification
Templaterequirements specification
Product definition
glossary
requirements specification
productmodel
user interface prototype
user manual
Source: Balzert, vol. 1, p. 98
legend :
role
activity model (artifact)
document (artifact)
18
18DAAD project „Joint Course on Software Engineering“ ©
Roles: responsibility and cooperation (2)
r
r
c
r
r
Application specialist
c
c
r
c
c
Systemanalyst
ccUser manual
ccGlossary
ccUser-interface prototype
ccProduct model
ccRequirements specifications
Project leader
CustomerActivities
19
19DAAD project „Joint Course on Software Engineering“ ©
Example: customer‘s request „Seminar Organization“
A company for advanced training (on-the-job training) needs a computer-based system for the management of its classes. In particular, it should be possible to administrate seminars and participants, to issue invoices, to answer inquiries and to create statistics.
What should be more precisely specified in this example requirements specification before starting the product development?
20
20DAAD project „Joint Course on Software Engineering“ ©
Contents of a requirements specification:verbal description of product requirements
(due to Balzert, Pagel/Six, IEEE Standard)
functional (operational) requirements:functionality, data (logical view), user interfacerequirements of application environment:application situation, user profiletechnical requirements:implementation language, operating system, hardwareperformance requirements:efficiency, volume of datavalidity requirements:preparation of tests, in particular of test casesquality requirements:user-friendly, reliable, ...realization requirements:process model, documentation, regulations, deadlines, costs
21
21DAAD project „Joint Course on Software Engineering“ ©
requirements specificationfunctional (operative) requirements:functionality, data (logical view), user interfacerequirements of application environment:application situation, user profiletechnical requirements:implementation language, operating system, hardwareperformance requirements:efficiency, volume of datavalidity requirements:preparation of tests, in particular of test casesquality requirements:user-friendly, reliable, ...realization requirements:process model, documentation, regulations, deadlines, costs
Preliminary requirements specification: contents due to Balzert
Preliminary requirements specification
Specification of preliminary requirements:• main functions• main data• general performance• important aspects of the user interface• important quality criteria
22
22DAAD project „Joint Course on Software Engineering“ ©
IEEE:template
23
23DAAD project „Joint Course on Software Engineering“ ©
24
24DAAD project „Joint Course on Software Engineering“ ©
Table of Contents: IEEE SRS (1)(Software Requirements Specification)
1 Introduction1.1 Purpose1.2 Scope1.3 Definitions, acronyms and abbreviations1.4 References1.5 Overview
2 Overall description2.1 Product perspective2.2 Product functions2.3 User characteristics2.4 Constraints2.5 Assumptions and dependencies
25
25DAAD project „Joint Course on Software Engineering“ ©
Table of Contents : IEEE SRS (2)(Software Requirements Specification)
3 Specific requirements• There are several different organizations of this section
depending on the application area • Independent of the chosen organization this section
should contain the following information:- external interface requirements- functional requirements- performance requirements- design restrictions- quality criteria- other requirements
26
26DAAD project „Joint Course on Software Engineering“ ©
5. Results of the „Analysis and Definition“ phase
a) Overview of results: feasibility studies, product definition
b) Activities of the planning phase
c) The contents of requirements specification -standardization
d) An example of a requirements specification
27
27DAAD project „Joint Course on Software Engineering“ ©
Example of a requirements specification (excerpt)Requirements specification
Seminar organizationversion 3.0
Version Author Date State Comment—————————————————————————————————————————2.1 Balzert 03/91 accepted2.2 Balzert 10/91 accepted /F115/ added2.3 Balzert 10/95 accepted /F15/, /F125/, /F185/, /D65/ removed,
/F130/, /D10/, /D20/ added,/D30/, /D70/ changed
3.0 Balzert 31.08.00 accepted Extension on the Web
oTRIs Software AG Landgrafenstr. 153 44139 Dortmund
Tel. +49 (0)231 106 15 40 Fax +49 (0)231 106 15 44
EMail [email protected]
starting from version 3.0 new organization: based on use cases
document name
project name
contact information
actual version
28
28DAAD project „Joint Course on Software Engineering“ ©
1 Goals The seminars presented by "Teachware" company should be supported by
computers.
1.1 Compulsory criteria • managing seminars.• managing presentations.• managing clients (participants/interested parties).• managing client companies.• managing lecturers.• queries like:
• When will the next X seminar take place?• Which associates participated the seminar X?
1.2 Optional criteria• all compulsory functions (the compulsory criteria) should be accessible through
Internet (Web browser) • hotel and contact person management • statistic evaluation • data security support 1.3 Exclusion criteria• No accounting (book keeping) integrated (the accounting has a copy of invoice
and keeps track of payment and notifies of the paying delay).
functionality in overview: 3 levels
29
29DAAD project „Joint Course on Software Engineering“ ©
2 Product UsageThe product is used by client-, company-, lecturer-, seminar- and presentation management of "Teachware" company. Besides that, various queries should be answered.
2.1 Application areaSalesman/administrative application area.
2.2 Target GroupsAssociates 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.
Actors
30
30DAAD project „Joint Course on Software Engineering“ ©
3 Product Overview
Business process of SemOrg product (overview diagram)
(simple) business process diagram (use-case diagram):
• Naming basicfunctions
• Defining access rights for actors
(simple) business process diagram (use-case diagram):
• Naming basicfunctions
• Defining access rights for actors
Company
Client
Lecturer
SemOrg
Seminar manager
Seminar custodian
from registering to booking acompny’s internal seminar
from question to information
from registration to booking
from canceling to credit note
from canceling to cancel notification
from participation to evaluation
from idea to a new seminar
from choosing to engaging
from scheduling to reservation
Client manager
Informing
Booking
Checking out
Canceling
Booking company
Presenting seminar
Designing seminar
Acquiring lecturer
Planning seminar
31
31DAAD project „Joint Course on Software Engineering“ ©
4 Product functions
4.1 Use cases
F10 (PF10)Use case: informing: from question to information Goal: client gets required information or the information material is sent to her/himCategory: primaryPrecondition: -Post condition success: client gets required informationPost condition failure: the required information can not be issuedActors: 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
structuring schema for the textual description of use cases
use case = sequence of actions
32
32DAAD project „Joint Course on Software Engineering“ ©
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 the seminar is overbooked, or
does not exist, or a booking for the client is already madeActor: client manager, client, companyTriggering event: client registration is availableDescription: 1. client data retrieval 2. seminar verification 3. booking undertaking4. registration notification and sending invoice 5. sending invoice copy to the accounts department Extension:1. A client data actualisation1. B when client is associate of the company, associated company data are
updated and accessed1. C invoice verification Alternatives:1. A inclusion of a new client 2. A when the seminar is over booked, to point out the alternative one 2. B notification of "false seminar", if the seminar does not exist
33
33DAAD project „Joint Course on Software Engineering“ ©
4.2 Lists F70 (PF70)
Participant list: a) per seminar with following data: seminar title, starting date, finishing date, presentation place, lecturers. b) per participant: first name, family name, company, town.
F80 (PF80)
Participant certificate: for every seminar participant with following data: address, title, first name, family name, staring 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?
producing lists: special product functions
34
34DAAD project „Joint Course on Software Engineering“ ©
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
D21 If a company is in a paying delay, then the following data should be saved:Date of still unpaid invoice, as well as amount
structure of data
size of data
35
35DAAD project „Joint Course on Software Engineering“ ©
5.2 Seminar Data
D30 (PD30) seminar data (max. 100 000):seminar number, duration (in days), from, to, daily period split-beginning, daily period split-end, beginning of the first day, end of the last day, seminar 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…
6. Performance concerning time and amount of data
36
36DAAD project „Joint Course on Software Engineering“ ©
7 Quality requirements
XXX
XXXX
XXXXX
XX
XX
X
FunctionalitySuitabilityAccuratenessInteroperabilityComplianceSecurityReliabilityMaturityFault toleranceRecoverabilityUsabilityUnderstandability Learn-abilityOperabilityEfficiencyTime behaviorResource behaviorMaintainabilityAnalyzabilityChangeabilityStability TestabilityPortability…
not importantnormalgoodvery goodProduct quality
ISO 9126
37
37DAAD project „Joint Course on Software Engineering“ ©
8 User InterfaceU10 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.
U30 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 To distinguish the following roles:
F10, F20, F21 (only through Internet) Client, company
F70, F80 (for some presentations only through Internet)
Lecturer
F30, F70, F80 seminar custodian
F22, F23, F40, F50, F60, F90Seminar manager
RightsF10, F20, F21, F90
RoleClient manager
38
38DAAD project „Joint Course on Software Engineering“ ©
9 Non-functional requirementsIf 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, seminar custodian.
10 Technical Product EnvironmentProduct is client/server and Internet-abled.
10.1 SoftwareServer-operating system: Windows NT/98. Client-operating system: Windows NT/98 or Browser.
10.2 HardwareServer: PC. Client: Browser enabled machine with graphic monitor.
39
39DAAD project „Joint Course on Software Engineering“ ©
12 Structure of Project Parts
There are three parts planned. First version covers core functionality without Internet, second one covers core functionality expanded with some Internet functionality like booking and booking the company's internal seminar. The third version supports hotel and terminal management.
(without Internet)(without Internet) (without Internet) (without Internet) (without Internet) (without Internet) (without Hotel-management)(without Internet) (without Internet) (without Internet)(without Internet) (without Internet)
Informing: from question to information.Booking: from registration to booking.Presenting seminar: from participation to realization. Designing seminar: from idea to a new seminar. Acquiring lecturer: from choosing to engaging. Planning presentation: from scheduling to reservation.
Participant list Participant certificateQueries Canceling: from canceling to cancel notification.Checking out: from canceling to a credit note.
F10F20F30
F40F50F60
F70F80F90F22F21
SemOrg V1.0 (Core)
40
40DAAD project „Joint Course on Software Engineering“ ©
13 SupplementsAccording experience, 5% of all clients are in paying delay.
(with Internet) (with Internet)(with Internet)
(with Internet)(with Internet)(with Internet)(with Internet)(with Internet)(with Internet)
Informing: from question to information.Booking: from registering to booking. Presenting seminar: from participation to realization. Designing seminar: from idea to a new seminar. Participant listParticipant certificateQueriesCanceling: from canceling to cancel notification.Checking out: from canceling to a credit note.Booking company: from registering to booking a
company's internal presentation.
F10F20F30F40F70F80F90F22F21F23
SemOrg V2.0
(with Hotel management)
Booking company: from registering to booking acompany's internal presentation.
F23SemOrg V3.0
41
41DAAD project „Joint Course on Software Engineering“ ©
„People always get what they ask for; the only trouble is that they never know, until they get it,what it actually is what they have asked for“
(A. Huxley, in: Leestma, Nyhoff: Modula-2)
42
42DAAD project „Joint Course on Software Engineering“ ©
Review
Background:arbitrary SW documents (e. g. requirements specification) have to be equally precise as programs Method (Review):Inspection of the documents by a group of evaluators by static reading the document(remark: 2 – 5 evaluators + author of the document)Process:1. Preparation of the participants2. Review meeting of the group:
sequentially or by points of emphasis
3. Produce a protocol
IEEE Std 1028-1988, Standard for Software Reviews and Audits
43
43DAAD project „Joint Course on Software Engineering“ ©
Review Protocol(contents scheme)
Document:Participants:Leader:Protocol:Date, time of the meeting:———————————————————————1. Summary2. Problems of the document
2.1 inaccuracies2.2 errors2.3 missing information
3. Remarks concerning the structure of the document4. Remarks concerning the review meeting
(preparation of the participants, length of the meeting, points of emphasis)
44
44DAAD project „Joint Course on Software Engineering“ ©
Requirements specification v3.0 compared with predecessor v2.3
Requirements specification often change because of:Errors, inaccuracies, misunderstandings, …and needs to correct thoseRequirements change (during the project lifetime) Different document structure is needed
Our case study - requirements specification v3.0 introduced:New functionality (web accessibility)Different document structure
45
45DAAD project „Joint Course on Software Engineering“ ©
Requirement specification version 2.34. Product functions4.1 Client Management/F 10/ Client registration, editing and deletion (client = participant/interested party) /PF 10//F 15/ Registration, editing and deletion of companies which send their associates to seminars./F 20/ Registration of a client with verification:/F 30/ - if she/he is already registered/F 40/ - if the desired seminar is possible/F 50/ - if the seminar is still free/F 55/ - what is the kind of payment./F 60/ Forwarding of registration notification /PF 20/./F 70/ Client checking out (canceling) with verification /PF 20/:/F 80/ - if she/he was registered at all./F 90/ - if canceling happened more than 4 weeks before seminar.
(−> 100 EUR cancellation fee or substitute participant)./F 100/ - if canceling happened less than 4 weeks before seminar.
(−> charge 100% of charge fee or substitute participant)./F 110/ - if “Teachware” canceled seminar (→ no invoice) /PF 20/./F 115/ Informing the participant in case “Teachware” canceled the seminar./F 120/ Registering, change and deletion of seminar booking /PF 50/./F 125/ A company can book another company’s internal presentation./F 130/ Making address labels for sending advertisements to all clients and companies./F 135/ A circular letter can be send to all clients and companies./F 140/ Accounting department inputs all the delayed payments using a provided function.
v2.3: linear sequence of 40 single functions
v3.0: 9 use cases
46
46DAAD project „Joint Course on Software Engineering“ ©
v. 2.3 vs. v. 3.0 (1) 1.1 Compulsory Criteria • managing seminars.• managing presentations.• managing clients
(participants/interested parties).• managing client companies.• managing lecturers.• queries like:
• When will the next X seminar take place?
• Which associates participated the seminar X?
1.2 Optional Criteria• all compulsory functions (the
compulsory criteria) should be accessible through Internet (Web browser)
• hotel and contact person management
• statistic evaluation • data security support
1.1 Compulsory Criteria• Managing seminars• Managing clients
(participants/interested parties)• Issuing and sending invoices• Queries like:
• When will the next X seminar take place?
• Which associates of Y company participated the seminar X?
1.2 Optional Criteria
• Advanced query possibility• Statistics• Support of data backup• Reuse of seminar and client
management
Why not desired anymore?
47
47DAAD project „Joint Course on Software Engineering“ ©
v. 2.3 vs. v. 3.0 (2)
F10 (PF10)Use case: informing: from question to
information Goal: client gets required information or the
information material is sent to her/himCategory: primaryPrecondition: -Post condition success: client gets
required informationPost 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
/F 10/Client registration, editing and deletion
(client = participant/interested party)/PF 10/
48
48DAAD project „Joint Course on Software Engineering“ ©
v. 2.3 vs. v. 3.0 (3)
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 of 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 undertaking4. registration notification and sending invoice 5. sending invoice copy to the accounts department Extension:1. A client data actualisation1. 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
/F 20/ Registration of a client with verification:
/F 30/ - if she/he is already registered/F 40/ - if the desired seminar is possible/F 50/ - if the seminar is still free/F 55/ - what is the kind of payment.
49
49DAAD project „Joint Course on Software Engineering“ ©
v. 2.3 vs. v. 3.0 (4)
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
D21 If a company is in a paying delay, then the following data should be saved:Date of still unpaid invoice, as well as amount
/D 10/ Save the following information about client (interested party/participant): /PD 10/ personal number, name (address, title, first and second name), address (street, house number, land code, postal code, place, phone, fax), date of birth, function, revenue, memo, notes, info-material, client since.
/D 20/ If a client is associate of a company, then save the following information about it: /PD 20/ Company short name, company name, address, phone, fax, name, address, department, date of birth, associate’s position in company, memo, notes, revenue, client since.
/D 30/ If a client or a company is late with payment, then save the following data: date of invoice, which is not yet paid for, and amount of invoice.
50
50DAAD project „Joint Course on Software Engineering“ ©
v. 2.3 vs. v. 3.0 (5)
Test casesFollowing function sequences are to be
checked: /T 10/ Participants login,
registration, checking out, new login, invoice, payment delay.
/T 20/ Canceling, change./T 30/ Canceling, issuing invoice./T 40/ Entering a seminar
realization, and issuing invoices.
Following data consistencies are to be kept:
/T 50/ The booking is possible to be made only if there is a client entry as well as a seminar presentation entry, and if the seminar presentation is not yet overbooked.
/T 60/ A new seminar presentation can be entered only if the corresponding seminar type is available.
51
51DAAD project „Joint Course on Software Engineering“ ©
XCTL: Requirements specification of theuse case „Manual adjustment“
Task:
Movement of motors to change the position of the sample.
Speciality:
An existing system is being described.
(Reverse engineering)
Requirements specification