CMPS 282 SOFTWARE ENGINEERING Software Requirements Specifications

LEBANESE SYSTEM VEHICLE INSPECTION AND REGISTRATION

Team: ALIAS Members: Yasmine Ghazzaoui Emile Saad Elsa Dagher Elie Bassil

Software Requirements Specification

CMPS 282

Software Engineering/SRS

Alias

0. Contents

TOPIC Introduction3 Purpose.3 Scope.3 Definitions4 Analysis models ..5 BriefOverview ...............6 General overview 6 External interfaces..7 Storyboard for user ....8 Storyboard for administrator 9 Functional requirements 10 Non Functional requirements 22 System models...26 DFD..26 Class diagram and CRC26 Sequence diagram..30 Activity diagram32 Use cases.43 - Description48 Appendix 55 Analysis model.55 Elicitation techniques 57 Validation criteria ..58

CMPS 282

Software Engineering/SRS

Alias

I. Introduction
This part of the SRS will lever its purpose and scope, along with some acronyms, references and overviews. 1.1. Purpose The SRS specifies the requirements for a Computer Software and the methods to be used to guarantee that each requirement has been met (WHAT is to be done). It will also be used later as the root for design and qualification testing of computer software. (A small premature idea on HOW things will get done). 1.2. Scope Lebanese car registration and mecanique is a web-based driven application which features provide an online system to smooth the progress of not only registration and mecanique, but also inspection and insurance, including online payment facilities. Its limitations, however, or what it will NOT do are the following: The product is NOT to be linked to governmental agencies databases or insurance databases. Assumptions such as stolen car or stolen driver information; license card for example; are not to be pointed to here, until further notice by the client (Prof. Karam). So in summary, the scope of the detailed analysis project phase specifies that this document will include: Classification of requirements according to their functional areas A description of each function, or process (functional and non functional requirements) A data model including an ER diagram with attribute/element descriptions, use cases, sequence diagrams, DFDs, a class diagram and an activity diagram.

The target audience for this product is fictively governmental and social officials, such as bureaucrats and executives in the transportation system decision-makers club in Lebanon and especially the development team, the team manager and all the other stakeholders in the system. All other readers are assumed to have knowledge about the basic theory and CMPS 282 Software Engineering/SRS Alias 3

operation of a regular web application, and have some idea about the terminology used in the document.

1.3. Definitions, acronyms and abbreviations: Acronyms: ER DFD SRS CRC Definitions: Web based Administrator

Entity Relationship Data Flow Diagram Software Requirements Specification. Class-responsibility-collaboration

A program that can be run through a typical internet browser such as Netscape or Explorer. an individual or group of individuals that upgrade, edit and maintain the functionality of a server or application

1.4. Analysis Models: The convolution of the system can be better paced when using a tough and exhaustive analysis model. Thats the reason why more than one model was espoused in order to emphasize on different perceptions and areas of the whole subject: It is necessary to represent in an SRS what is to be done in the system in terms of requirements, but still this is not sufficient. An SRS document is also a preamble of the design phase which leads to the conclusion that what is interesting to adopt is a coalition between these various techniques:

CMPS 282

Software Engineering/SRS

Alias

Name
Categories

Scenario-based Flow-oriented modeling modeling

Use cases Activity diagram DFD

Class-based modeling
Class diagram CRC

Behavior modeling
Sequence diagram State diagram

More explanation on the role of each model and the order we built those models in will figure later in the document, in the Appendix part. 1.5. Document overview: This document describes the software requirements for the car registration and inspection system. There will be first a complete synopsis of functional and non functional requirements, then an overview of the analysis model. Those include also the following: A general description of the user characteristics, the administrator scope, the product perspective and general constraints, assumptions, and dependencies. Finally, a complete explanation of validation procedures will be made in order to demonstrate how appropriate our quest for information in terms of requirements and needs was.

1.6. References 1. Books: Software Engineering, Roger S. Pressman, Mc.GrawHill international edition, 2005 2. Internet websites:
http://www.zoo.co.uk/~z0001039/PracGuides/toc.htm http://www.sdmagazine.com/documents/s=737/sdm0012c/0012c.htm http://www.donaldfiresmith.com/Components/WorkProducts/RequirementsSet/S ystemRequirementsSpecification/SystemRequirementsSpecificationInspectionCh ecklist.html http://www2.ics.hawaii.edu/~johnson/413/lectures/5.2.html http://www.agilemodeling.com/artifacts/uiFlowDiagram.htm

3. Other QSEE documentation

CMPS 282

Software Engineering/SRS

Alias

II. Brief Overview

This small section in the document aims at providing a useful background for functional and non functional requirements visited in details later in order to make them easier to understand. In a sense, it will tell the requirements in plain English for customer expenditure while the next section will contain specifications written for the developers. 2.1. General Overview As stated in other documents, the general layout for the system is the following:

In summary, the system has exactly 3 possible users: Driver (Car owner) Mecanique Administrator: Can access all parts of the website, needs to fulfill functions such as: update, maintain, delete drivers, add drivers, register on the web, notice drivers for inspection success or failure Insurance company: This is omnipresent in the website.

The system functions as follow: The user enters a special number called RIN (sent by BOX OFFICE say from the seller to the
website administrator, along with personal information about the buyer once vehicle is bought; and given also to the buyer), his ID# and the chassis# of the vehicle (primary key among all other vehicles). An automatic checking crosses the information to determine whether the user actually bought the vehicle. If everything works well, the user is now signed in. The next step is to give the user the ability to fill his personal information and some important information about his vehicle. Then registration comes. The user is supposed to pay online, and the administrator notices him whether the transaction succeeded. NB: Registration is necessary before all later steps. Inspection is NOT paid online. What happens actually is that the user can view the dates the inspection of his vehicle is supposed to take place in. The user then takes his car for

CMPS 282

Software Engineering/SRS

Alias

inspection, and the inspection company which has an access to the web, posts whether the vehicle has succeeded or failed. NB: Inspection is necessary before all later steps. Insurance is also NOT paid online, it is just a form that the user prints and then goes to submit to a particular separate insurance company. The administrator will then be responsible of telling the user whether insurance went ok or not. NB: Insurance is necessary before all other steps. The last step is the mecanique. It is an annually updated value to be paid under a certain time limit. The price varies according to the year model and the make of the car.

2.2. Input, Output, Time The following describes very briefly the input and the output of the system, as well as the time factor which is responsible of automatic updates. Input Generally, when the user connects, his aim is to do an online registration for his car. The input is abstractly an unregistered but bought car, concretely 3 elements: the RIN, the id# and the chassis # of the car. Output The output of the system however fluctuates according to the time span and/or requirements completion. The following are the possible outputs: 1. Registered car 2. Inspected car 3. Insured car 4. Mecanique paid for car Time Time is extremely important in the system. Mecanique happens every year, and the system must automatically allocate days for inspection according to car plate numbers. The number of car plate numbers is divided by 12 in order to produce the timeline of car inspection each month. Other than the other case stated above, time also plays a pivotal role when it comes to delays. If the inspection is NOT done and the limit dates for inspection are over, the system must be responsible to consider the users of this situation some special cases, and produce other dates for inspection. Also, if mecanique deadline is over, the time factor also has to act in order to add a penalty payment that increases for a period of 3 years maximum. 2.3. External Interfaces

CMPS 282

Software Engineering/SRS

Alias

The external interfaces are those user directly interacts with. The following illustrates a storyboard for the system. Explanation follows

Some things to specify: ----------- : These red dotted lines specify the interaction of a database with a component. Those arrows correspond to a link between two pages. A page with an arrow pointing to itself means this page is re-entering itself, maybe because of some erroneous input. Storyboard for Users: First, we have pages, and databases. There are two databases drawn, but they both represent one single database, there are two because of spacing purposes and neatness of designs. First is the login page, which interacts with the database to authenticate input. Then it leads to a user registration page, which interacts with database to update input, with validation of input of course. Then when everything is fine, the user can start actions. Now the user can access any page, but he cant do specific actions in a page without having done some other stuff in other pages. Each page basically represents a requirement. Also not all input variables are represented in each page because of the big amount of data, and the storyboard was put just to give an idea of how would external interfaces look like, the design document will specify all details. Now as we can see, the online registration payment is given as a choice, and leads to another page. The inspection process is just information processing, as well as insurance. The mecanique process has an online payment option, similar to the registration. Almost all pages interact with database. User can check any information on any of the pages. User can do data inputs (in terms of payments) only when its the period to do so. Now some things arent put yet like ad spaces, but some small components on storyboard makes the fact that these things will be put, but later because they dont affect functionality of system.

CMPS 282

Software Engineering/SRS

Alias

Storyboard for Administration:

Lo in system g U d te o e tio s p a p ra n

L ogin
A dmin ID P assw ord Data update processing D atabases F ields to change

S b it um

S b it ch ng s um a e

Mn o itoring
D atabas e

grant access rights G rants priv ieges S election of possibilities

su m b it

The administrators storyboard is similar to the users storyboard (in terms of designs). The admin can do actions such as privileges granting, update actions, and delete actions, create new accounts The administrators storyboard is a bit more simplified than the users storyboard, but the administrator dont really have to do more than monitoring the system.

CMPS 282

Software Engineering/SRS

Alias

Now there is a possibility of creating new storyboard for people who do data entries, however this is still under discussion and would need some security approaches to deal with the situation, but this option is still in mind.

III. Functional Requirements

Functional requirements describe the possible effects of a software system, in other words, what the system must accomplish. To consider functional requirements here, we might consider two cases, either the car owner is a first time user, or hes an old user. 3.1 Login page: First-time user: Case study: When user buys car, he gets an RIN from seller. Inputs: User enters RIN, ID number and car chassis number to be able to enter the page. The server sends the query to the database, authenticating RIN, ID and chassis number. Such information is sent and saved in database. Outputs: Case input is correct and confirmed by database; user is sent a confirmation page allowing him to move on. Else, hes requested to input another time. User cannot attempt more than 3 inputs for security reasons. Regular user: Regular user here means that the user is NOT using this website for the first time as is probably a member in it already. User has to enter RIN and password (password is discussed below). Again no more than 3 attempts. For high security reasons, the employment of an encryption system or some password is crucial. Software Engineering/SRS Alias 10

CMPS 282

Some form sends this info to database and is responded by a confirmation message. 3.2 User Registration:

Inputs: User is then required to input some personal information: Name, Address, Phone Number, email address, profession, date of birth, marital status. This information will be sent to database in order to be processed and saved. User is then required to enter a password, which he has to confirm, in order to get access later to the site. Outputs: User will get confirmation concerning his personal information. 3.3 Car registration: Two options: manual or automated registration 1st case: Manual Registration: User registers the car manually in place, at the DMV. In this case, he will receive later a confirmation message and can access the page. He will be able to see all information regarding his car. 2nd case: Automated Registration: The user would like to register online. In this case, he is required to fill a form in the car registration page. In this form, the info asked for are: Car model, color, year of make, type, registration type The user will enter this info and submits. The server will send info to the database and the administrator The administrator will confirm this info manually, and the user will be replied to in few days The user is required to pay a certain amount of money to ensure registration. Here money can be paid in two options: manually or online. Below the online registration is discussed. The manual registration is obvious. Online Payment: The user will first get the amount under fees link. He will enter specific information in order to be able to pay. The database will receive this info from the user and send a value confirming the pay.

Upon reply, if everything worked successfully, the user will receive his car plate number and car registration papers later by mail. He can also get these papers manually of course.

CMPS 282

Software Engineering/SRS

Alias

11

3rd case: car owner who wishes to become an online user of database: In this case, the user will be requested to fill an online form, specifying some information. The DMV server will send request to the administrator The administrator will send confirmation to user stating that his process worked successfully. No need of re-registering.

3.4 Inspection: Each year cars must pass inspection test for safety purposes. User will be informed of inspection dates on this page inspection dates. Inspection dates are related to car plate numbers, so the server connects to a separate database of dates and car plate numbers span. The server will get the date the user must pass his inspection The server will also display inspection fees and places as well as dates and finally whether the inspection was passed or not.

Server will be in connection with database to retrieve information about the user and the test: 1st case: User successfully passes test. Here the user will only get confirmation to move on. 2nd case: User takes test but fails Server will display information regarding next dates, fees, and the things the users car failed in, which are retrieved from test table in database containing information about test requirements. 3rd case: User doesnt take test at all. User will be issued warning concerning this, and he will get info about test dates, penalty fees. . 4th case: Users car is not older than 3 years In this case user doesnt need to pass inspection. The server will automatically display info concerning this. 3.5 Insurance: CMPS 282 Software Engineering/SRS Alias 12

The Lebanese government requires each car to be insured against personal accident. The server here displays information about: 1. Whether user is insured or not 2. Which company is the user insured with 3. In case hes not insured, whens the deadline for insurance 4. What fees have to be paid for insurance 5. What companies can the user insure with, information about these companies, links 6. NB: Another requirement possibility is to make user pay online.

3.6 Mecanique: The Lebanese government requires each year that cars renew registration through mecanique. Here, the server displays to the user dates, fees, and places regarding mecanique. The server connects to a separate database containing mecanique information and retrieves information regarding mecanique. The user is given the choice of paying either online or personally. Online payment is done through prepaid cards, or credit cards. When user pays, server will update information in database to ensure payment.

Cases: penalties, tickets: These add up to the total mecanique fee. 1st case: The user pays mecanique successfully. In this case server will update the page and confirm payment. 2nd case: The user doesnt pay or is late in payment The user will be issued warning and penalty fees. Who will warn the user? Either the administrator; manually or the system; automatically.

CMPS 282

Software Engineering/SRS

Alias

13

3.7 Table Requirements

Hereafter, all functional requirements will be tabled and explained specifically. The work will distinguish THREE types of functional requirements: User requirements Administrator requirements Other additional requirements

3.7.1 User Functions 1) Requirement name Priority Path User login

Essential 1. The user fills RIN, chassis #, ID# 2. The server validates 3. If valid, the server authenticates, else restart process. 4. If authenticated, server sends user to next page, else restart process. 5. Possible outputs: validation error messages, authentication error messages. User enters a field incorrectly more than three times, server bans user. Server authenticates and sends user to next page If server down while redirecting, issue error statement

Other paths Post conditions Exceptions

CMPS 282

Software Engineering/SRS

Alias

14

2) Requirement name Priority Path

User registration
Important 1. The user fills personal information. 2. User submits entry. 3. Server validates for empty fields, wrong formats 4. If valid, server continues, else re-enter erroneous fields. 5. Possible outputs: validation error messages, confirmation messages. None Server updates database with information.

Other paths Post conditions

3) Requirement name Priority Path

Other paths Post conditions Exceptions

Payment processing summary

New car registration Critical 1. User fills in car registration information. 2. Server validates information 3. If valid, server continues, else reenter erroneous fields. 4. All info ok, server redirects to payment page. 5. User fills in payment info: credit card #, prepaid card number# 6. Server validates input 7. Server authenticates input 8. Possible outputs: validation error messages, confirmation messages. None. Server updates database with information, then update confirmation information about payment. If user connection down while processing, server waits for a while, after it cancels process. If user connection or server down while payment processing, immediate blocking of operation. If empty credit card, immediate blocking of information. Once the data has been entered, it will be saved in an appropriate format in the database notifying that the payment has been done. The data will have to be first verified for correctness by being validated. Alias 15

CMPS 282

Software Engineering/SRS

For example, the format for credit card number and the total amount should always be numeric. If the user entered incorrect information, the system shall ask him to reenter the corresponding data.

4) Requirement name Priority Path

Other paths Post conditions Exceptions

Already registered car IF TIME PERMITS 1. User fills in request to enter his car in database. 2. Server validates information 3. If valid, server continues, else reenter erroneous fields. 4. All info ok, server redirects to admin page. 5. Admin sends confirmation to user and adds his car. 6. User can continue. None. Server updates database with information, then update confirmation information about payment. If user connection down while processing, server waits for a while, after it cancels process.

5) Requirement name Priority Path

Car inspection Essential 1. User enters page. 2. Server displays information 3. If user did test and passed, everything ok, user is done, can move on. 4. If user did test and failed, server Alias 16

CMPS 282

Software Engineering/SRS

Other paths Post conditions Exceptions

displays fields in which user failed, displays new test dates, fees 5. If user didnt take test, server displays fees, dates, place. 6. Possible outputs: validation error messages, confirmation messages, display information. None. Server moves user to insurance If server down while redirecting, issue error statement

6) Requirement name Priority Path

Other paths Post conditions Exceptions

Car insurance Important 1. User sees insurance info. 2. If insurance is already paid, user is sent info about company 3. if not, user is sent info requiring insurance. None. N/A If server down while redirecting, issue error statement

7) Requirement name Priority Path

Other paths Post conditions Exceptions

Car insurance payment IF TIME PERMITS, NOT IMPORTANT, UNTIL NOW NOT FEASIBLE 1. User is given option to pay online. 2. Server confirms and updates 3. If not, user is sent info requiring insurance. None. N/A If user connection down while processing, server waits for a while, after it cancels process. If user connection or server down while payment processing, immediate Alias 17

CMPS 282

Software Engineering/SRS

blocking of operation. If empty credit card, immediate blocking of information.

8) Requirement name Priority Path

Other paths Post conditions Exceptions

Mecanique payment Essential 1. User sees mecanique info. 2. User can choose online payment option. 3. If user chooses option, server redirects user to online payment page. 4. User fills in payment information. 5. Server validates information. 6. If valid, server authenticates user critical information such as credit card number or prepaid card number. 7. Everything ok: server displays confirmation info. None. Server updates database with information. If user connection down while processing, server waits for a while, after it cancels process. If user connection or server down while payment processing, immediate blocking of operation. If empty credit card, immediate blocking of information.

9) Requirement name Priority

User Update Essential

CMPS 282

Software Engineering/SRS

Alias

18

Path

Other paths Post conditions Exceptions

1. If user chooses this option, server redirected to update page. 2. Update permits the user to modify some specific information (address, phone number, ) 3. If information entered is valid, then a link with the database will imply an update operation. 4. If information is not valid, issue error statement. None. User has updated personal information If server down while redirecting, issue error statement.

3.7.2 Administrator Functions Administrator is given privileges such as update databases, delete and give privileges to information entering people. 1)Requirement name Priority Path Registration update Essential 1. Admin updates registration data manually, case registration is not done online 2. Server sends information to database None. Database is updated. If server down while processing, issue error statement.

Other paths Post conditions Exceptions

2)Requirement name Priority Path

Other paths Post conditions Exceptions

Inspection update Essential 1. Admin updates inspection data manually. 2. Server sends information to database None. Database is updated. If server down while processing, issue error statement. Alias

CMPS 282

Software Engineering/SRS

19

3)Requirement name Priority Path Other paths Post conditions Exceptions 4)Requirement name Priority Path

Insurance update Essential 1. Admin updates insurance data. 2. Server sends information to database None. Database is updated. If server down while processing, issue error statement. Mecanique update Essential 1. Admin updates mecanique data manually. 2. Server sends information to database None. Database is updated. If server down while processing, issue error statement. Admin responsibilities IF TIME PERMITS 1. Admin can grant privileges. 2. Admin can update critical information. 3. In all cases, server interacts with DB. None. Database is updated. If server down while processing, issue error statement.

Other paths Post conditions Exceptions

5)Requirement name Priority Path

Other paths Post conditions Exceptions

CMPS 282

Software Engineering/SRS

Alias

20

3.7.3 Other functions

1)Requirement name Priority Path Other paths Post conditions Exceptions

Language IF TIME PERMITS 1. User chooses language in pages. 2. Server translates pages. None. Page is translated. If server down while redirecting, issue error statement. If browser doesnt support languages, issue error statement,

2)Requirement name Priority Path Other paths Post conditions Exceptions

Site map IF TIME PERMITS 1. User selects sitemap function 2. Server help user in site functions. None. User is directed to sitemap process. If server down while processing, issue error statement.

CMPS 282

Software Engineering/SRS

Alias

21

IV. NON Functional Requirements (Software System Attributes)

Software attributes also DO serve as requirements. It is important that these requirements be specifies so that their achievement be objectively verified later. 4.1 Hardware: Required: 1. At least 2 GB of memory. 2. 1000 GB of storage space. 3. Compliant server, to face big requests in short periods of time. 4. Later on, a concurrent server, in case a lot more cars becomes online.

4.2 Software: Server: The web server will run on Windows NT or Windows XP professional, or window server 2003. The database server is Microsoft SQL server 2000.

User: The user can run the application on Windows platforms: 95, 98, NT, 2000 and XP.

CMPS 282

Software Engineering/SRS

Alias

22

The user is required to have Internet Explorer 5 and above, Netscape 6 and above or any Netscape compliant application, like safari, and in all cases the user is required to have Unicode UTF-8 support in his browser if he wishes to see pages in Arabic or French, or support for Arabic or French (or both) encoding with leftto-right or right-to-left (or both). The users browser is also expected to have JavaScript enabled, and secondary requirements, such as flash player, are recommended but not required.

4.3 Connection: The user can use dial up connection and higher bandwidth connections, however connections from 56.6 kbps bandwidth are preferred. Server is expected to connect on a high bandwidth system. The web server will use an HTTP proxy. 4.4 Coding: Coding is done in ASP .net using VB .net. Forms will be created via VB.net scripts, or html tags. Forms will be processed using VB.net. Database queries use standard SQL queries.

4.5 Documents: Each page of the website will contain help information. The website will also contain a general FAQ. 4.6 Performance: The web application will on run on the DMV server, which should have strong attributes: large memory, at least 2 GB, significant amounts of storage mechanisms are required to store large amounts of information in database. Lets assume we have about 1,000,000 cars in Lebanon, each user, with his car, requires, say, 1 MB of space. Then we need about at least 1 terabyte for database storage system, equivalent to 1000 GB, assuming all registered cars want to enter online. But assuming that not more than 30 o 50 % of car owners have access to internet, or at least know how to use it then storage space can be reduced significantly. Database queries are expected to run on average in less than 1 sec, depending on traffic. Performance will also vary depending on the traffic on the server. At first the server is not expected to handle many requests, but with time and technological development the server must better be updated, even duplicated to handle many simultaneous requests. CMPS 282 Software Engineering/SRS Alias 23

Peak time running: Server performance is expected to slow down during peak times, for example during mecanique payment periods. Server during peak time is requested to handle between 1,000 and 5,000 requests per day in the first years of the projects, depending on number of users willing to become online users. 4.7 Availability: The system can be accessed 24 hours a day. However, transactions will not be allowed after the DMV closure time, and during holidays, weekends and important official events like elections. During this time, the user is only allowed to see information only.

4.8 Safety: Cases: 1. Server down or crashes for some reason: transactions occurring will be immediately cancelled. If the problem is not important and fixed automatically, user can continue his work. If the problem needs professional assistance, server will close during fixing time. 2. User connection is broke, or some problems stopping the user from continuing (PC shuts down, electricity) during session or user simply stops using page for some time. In this case server cancels session if user doesnt continue later. 4.9 Security: 3.10.1 1st time login: encryption for decoding and encoding RIN. Type to be specified later. (128 bit is an option) 3.10.2 User password: for 2nd time login: encryption for decoding/encoding password. Type will be specified later. (128 bit is an option) 3.10.3 Online payment: high security encryption software for processing credit card/prepaid card transactions. 3.10.4 Log files: every database transaction, every user action involving database transaction will be recorded in a log file, in case controversies happen. 3.10.5 User is not allowed to enter password or login information incorrectly more than 3 times during login process. 3.10.6 Cookies are an option. 3.10.7 Firewall is required in server. 4.10 Maintainability:

CMPS 282

Software Engineering/SRS

Alias

24

1. Software components are written in VB .net and HTML code, which should allow easy maintenance of code. 2. Updates to software components can be easily made since components functions arent directly attached. 4.11 Portability 1. The software can be run on windows platform XP professional or Windows Server edition, or Windows NT 2. Internet Information services is required on the platform to run the host 3. 50% of code is host-dependent. 4. 50% of components are host dependents. 5. HTML and VB .net are used, which allows easy interpretation.

4.12 Other Quality Requirements 1. Correctness: errors expected: technical errors, related to external influences, such as heat or electricity problems. Otherwise, everything is expected to run fine. 2. Efficiency: The program is expected to have about 3 % of CPU usage for each database transaction. 3. Flexibility: Modification of software can be easily done since components arent directly attached by functionality to each other. 4. Reliability: System transactions, requests are expected to run without many interruptions. 5. Reusability: Components can be used in other application specific to those components, i.e. mecanique can be used in a mecanique specific application. 6. Testability: Each component is tested separately, and then with each other, thus testing functionalities arent complicated. 7. Usability: Basic knowledge of DMV operations, with a basic knowledge of windows components, makes the learning of the usage of the application very fast. No professionalism is required except for admin.

CMPS 282

Software Engineering/SRS

Alias

25

V. System Models

5.1 DFD

For DFD, see Appendix II.

5.2 Class diagram and CRC

For Class Diagram see AppendixII. Class: CarRegistered Responsibility computeAmountMecanique computeAmountInsurance computeAmountInspection Collaborator CarRequirements(client)+ the apropriate class of the inheriting classes(server). CarRequirements(client) + the apropriate class of the inheriting classes(server). CarRequirements(client) + the apropriate class of the inheriting classes(server). Alias 26

CMPS 282

Software Engineering/SRS

Class: TouristicBus (local) Responsibility computeAmountRegistration computeAmountInsurance computeAmountMecanique computeAmountInspection Class: TouristicBusA(continental ) Responsibility computeAmountRegistration computeAmountInsurance computeAmountMecanique computeAmountInspection

Collaborator

Collaborator

Class: HeavyWeightTransport Responsibility computeAmountRegistration computeAmountInsurance computeAmountMecanique computeAmountInspection

Collaborator

Class: Taxi Responsibility computeAmountRegistration computeAmountInsurance computeAmountMecanique computeAmountInspection

Collaborator

Class:PrivateCar Responsibility computeAmountRegistration computeAmountInsurance computeAmountMecanique CMPS 282

Collaborator

Software Engineering/SRS

Alias

27

computeAmountInspection Class: InternationalTransport Responsibility computeAmountRegistration computeAmountInsurance computeAmountMecanique computeAmountInspection

Collaborator

Class: CarRequirements Responsibility getAmount getDate check_If_car_has_requirements Class: InspectionCompany Responsibility payAmountDue? Class: InspectionForm Responsibility computeIfPassedOrFailed generateReport Class: InsuranceCompany Responsibility payAmountDue? Class:Seller Responsibility generateForm

Collaborator Signal + CarRegistered Signal + Dates Signal + databases

Collaborator AdminstratorMecanique+Inspection form

Collaborator Form filled by inspector+ Inspection

Collaborator AdminstratorMecanique+Insuranceform

Collaborator AdminstratorMecanique

Class: AdministratorMecanique Responsibility login CMPS 282

Collaborator

Software Engineering/SRS

Alias

28

update addRegistered doStatistics updateUserProfile mecaniqueInfo checkInspectionResult InspectionDone payForMecanique Class: Profile Responsibility updateAddress updatePhoneNumber Class: Account Responsibility updateAddress updatePhoneNumber StartSession Class: Client Responsibility userLogin userRegistration NewCarRegistration updateInfo PayForMecanique payForRegistration Class: Password Responsibility validate AddTrial

InspectionCompany+signal InspectionCompany+signal Client + signal Collaborator account account

Collaborator

client

Collaborator Password Account AdministratorMecanique AdministratorMecanique

Collaborator Client Client

Class: Dates Responsibility computeRegistrationDates computeInsuranceDates CMPS 282

Collaborator

Software Engineering/SRS

Alias

29

computeMecaniqueDates computeInspectionDates amountCoefficient

5.3 Sequence Diagrams We have decided to create sequence diagrams for some of the functional requirements discussed above.

CMPS 282

Software Engineering/SRS

Alias

30

udt UeIn Sqec p a s r fo e une e

sqec eune dgm ia r a fr o

ue : c n s r liet

ps wr : Ps Wd as o d as o r

ac ut : Ac ut c on c on

p fle P f r i : r ile o o

1:vlid t ( a a ) e 2:vlidt ( a ae )

3:Ad r l( dT ) ia

4:tu: v lidt ( re a a ) = e

6:ud t Ad s( pa dr s e e ) 5:S rSsio ( t t es n a ) 7:ud t Ad s( p a dr s e e )

8:udt Poe u br) pa hnNme e (

9:ud t Poe u br) p a hnNme e (

This sequence diagram starts by the user process which first invokes the Validate function from the password class. The password validates and adds trials then returns true to the client in case everything is validated. Once the user is in, invoke start session, a method from class account. Then account can invoke methods from class profile in case user triggers an event such as, for example, updateAddress.

CMPS 282

Software Engineering/SRS

Alias

31

C r m n e S en a eca iqu equ ce

S uenc eq e diag ram for C r a M anique ec Info

u r : clie t se n

M : A m istra rM ca iq e A d in to e n u

S :S n l M ig a

C : C rR q ire e R a e u m nts

d te : D te a s a s

ca e is : C rR g re rR g a e iste d

1: M ecan ueInfo() iq

2 : s nalM ig ecaniq ueInfo()

3: c heck _if_c ar_ha _req s uirem () ents

5 : c puterM om ecaniq ates ueD ()

6: c p om uteA o m untM ecanique()

7 : am ountC effic nt() o ie 9: s ignalM ecanique () Info 10 : M ecaniqueP t() os 8 : getA oun m t()

11 : P orM anique() ayF ec

12 : s nalM ig ecanique()

< d troy> < es >

This sequence diagram first starts by the user requesting to get the mecanique info from the administrator mecanique. The administrator mecanique then invokes the signal class in order to communicate with the car requirements. In case the car has no requirement, the process can be stopped here. Otherwise, car requirement invokes methods to find the date of mecanique payment (from Dates) and the amount to be paid (from car registered).

CMPS 282

Software Engineering/SRS

Alias

32

InspectionConfirmation

client : client

administrator : AdministratorMecanique

IM : Inspection

IC : InspectionForm

signalDone : Signal

1 : checkInspectionR esult()

2 : compute_if_pass ed_or_failed() 3 : generateR eport()

4 : payAmountD ue?() 5 : InspectionD one()

6:s ignalInspectionD one()

This sequence diagram represents the posting of information related to the inspection process. Same as above. Every object of each instance invokes specific functions of other classes in order to accomplish tasks.

5.4 Activity Diagrams CMPS 282 Software Engineering/SRS Alias 33

Login UML Activity Model

L o gin : Th is actio n ha s to be p e rfo rm ed s u cce s s fu lly b y e ve ry us e r eve ry tim e he w an ts to e n te r th e s ys tem

User starts client application

[in a ctive]/Ab o rt

Enters RIN, chassis# and userID #

Verify input data

[In va lid ] [Va lid ]/En te r App lica tio n

Invalid username and password / try again

Customizing personal information UML Activity Model

this action is to be performed by the user in case of updating information

Enter login information

Selects major function

[Valid input data]

Customize personal info

Edit textual content

/exit the function

CMPS 282

Software Engineering/SRS
Commit changes

Alias

34

Customizing personal information UML Activity Model

this action is to be performed by the user in case of updating information

Enter login information

Selects major function

[Valid input data]

Customize personal info

Edit textual content

/exit the function

Commit changes

CMPS 282

Software Engineering/SRS

Alias

35

Manipulate Members UML Activity Model

Enter Login information
This action is to b e perform ed by the adm inis trator in cas e he wants to add/delete/update m em bers [In valid]/Try ag ain

Select major function

[Valid Input]

[No in put]/Abort

Manipulate members
/Choos e operation

Add Member

/Add /Delete

/Update

Update Member

[If U pdate Action]

Delete Member
/Enter m em ber ID

[If Delete Actio n] /Enter m em ber ID

/Enter m em ber ID

Find Member

Find Member

Find Member

/Check which operation was called

/Check if m em ber exis ts

/Look for m em ber [Mem ber n ot found]

Prompt member doesn't exist

[Mem ber Found]

[Mem ber Found]

Prompt member already exists Add Member

[If Delete Actio n]

[If U pdate Action]

Delete Member

Update member

[Succes s ful Add]

[s ucces s ful delete] [Succes s ful Update]

Prompt operation successful

[Exit Function]

CMPS 282

Software Engineering/SRS

Alias

36

Manipulate User Profile UML Activity Model

Enter Login information

This action is to be performed by the administrator in case he wants to update users' profile [Invalid]/Try again

Select major function

[Valid Input]

[No input]/Abort

Change users' profile

/Enter member ID

Prompt Illegal User ID Find Member

[Member not found] /Look for member

[Member Found]

Member's Profile

/Exit

Edit Textual Content

/Save Changes

CMPS 282

Software Engineering/SRS Commit Changes

Alias

37

Registration UML Activity Model

This action is to be perform ed by firs t-tim e user in order to fill inform ation

Select Major Function

[Firs t-Tim e us er]/Select Register

Register
/Get Form

Fill the Form

Submit the form

[Invalid: Errors in the form ]/Try again /Validate Input

[Valid]/Succes s ful execution

CMPS 282

Software Engineering/SRS

Alias

38

Populate DB UML Activity Model

This action is to be performed by the administrator in case he wants to populate the check DBs filling in the corresponding RIN, ID# and chassis#

Enter Login information

[Invalid]/Try again

Select major function

[Valid Input]

[No input]/Abort

Populate DB

/Get Form

Fill a form

Submit the form

[Invalid: Form contains errors]/Try again

/Validate Input

[Valid]/Succes sful execution

CMPS 282

Software Engineering/SRS

Alias

39

Seller filling info UML Activity Model

This action is to be performed by the seller: he must fill an application form including his own info and the buyers's info and then he m ust submit it to the administrator

Enter Login information

[Invalid]/Try again

Select major function

[Valid Input]

[No input]/Abort

Sell car

/Get the form

Fill the form

Submit the form

[Invalid : Errors in the form]/Try again /Validate Input

[Valid]/Succes sful execution

CMPS 282

Software Engineering/SRS

Alias

40

Updating news UML Activity Model

Enter Login information
[Invalid]/Try again

Select major function

[Valid Input]

/Select Update news Publication

[No input]/Abort

Make Changes

Store news locally

[Error in filling news]/Try again

/Save the updates

CMPS 282

Software Engineering/SRS

Alias

41

Payment UML Activity Model

Enter Login information
[Invalid]/Try again

Select major function

[Valid Input]

[No input]/Abort

/Select Mecanique

[Select Registration]

Check Payment Information

Pay

/Get Form

Fill the form

[Invalid : Errors in the form]/Try again

Submit the form

/Validate Input

[Valid]/Successful execution

CMPS 282

Software Engineering/SRS

Alias

42

Publish news UML Activity Model

Enter Login information
[Invalid]/Try again

Select major function

/Select Publication

[Valid Input]

[No input]/Abort

Fill news

Store news locally

[Error in filling news]/Try again

/News published successfully

CMPS 282

Software Engineering/SRS

Alias

43

5.5. Use Cases

UML Use Case Model
+ User

+ First-Time User

+ Member

+ Seller

+ Inspector

+ Insurance Administrator

+ Mecanique Administrator

CMPS 282

Software Engineering/SRS

Alias

44

Mem Use Case Diagram ber

+ CountTrials

+ block
<<extend>>

<<extend>>

+ login
<<include>>

+ check login input

<<extend>>

+W rong login input

<<include>>

+ Fill Registration Form

<<include>>

+ Personal Info

+ client + Fill Insurance Form

<<include>>

<<include>>

+ Paym Info ent

<<include>>

+ Fill M ecanique Form

<<include>>

+ Store in Database
<<include>> <<include>>

+ Display M essage

+ Submit Form

+ Check Data + Reset Form + Incorrect Data

<<extend>> <<extend>> <<extend>> <<extend>> <<extend>>

+ Incom plete

+ Check Inspection Status

+ Check Credit Card N ber um + Check Account N ber um + Check Minim Account un

<<include>>

+ Find Car in Table + Print Insurance Form

<<extend>>

+ Car N Found ot

CMPS 282

Software Engineering/SRS

Alias

45

Administrator Use Case

+ block
<<extend>>

+ CountTrials

<<extend>>

+ login

<<include>>

+ check login input

<<extend>>

+ Wrong login input

+ payment + history + Administrator + fill forms

<<include>>

+ populate DBs + insurance requirements + register

+ inspection requirements + update

<<extend>>

+ mecanique requirements

+ manipulate members

+ incomplete form + add

<<extend>> <<extend>>

+ update all news(postings) + Give privileges

+ delete

<<include>> <<include>> <<include>>

+ finding members

<<extend>>

+ member not found

inspector Use Case

+ fill inspection form + Inspector

<<include>>

+ populate inspection form database

CMPS 282

Software Engineering/SRS

Alias

46

System Use Case Model

+ System Login

+ Register User + User + Update User Information + Fill Inpsection Information + Inspector

+ Register Car

+ Check Inspection Status

+ Apply for Insurance

+ Pay Mecanique + Administrator + Add Member

+ Manipulate Members + Delete Member

<<include>> <<include>>

+ Find Members

<<include>>

+ Update Member + Populate Database

+ Update Postings

CMPS 282

Software Engineering/SRS

Alias

47

New-User Use Case Model

+ Personal Inform ation + N -U ew ser + Fill M bership Form em + Store in U Database ser
<<include>>

<<include>>

+ Submit Form

<<include>>

+ Check Data
<<extend>> <<extend>>

+ Incorrect Data + Reset Form

+ Incom plete Form

Seller Use Case Model

+ Wrong login input

<<extend>> <<extend>>

+ Login + Seller
<<include>>

+ check login input + CountTrials

<<extend>>

+ block

+ Fill Seller's Form

<<include>>

+ Personal Information

+ Print Form

+ Reset Form

CMPS 282

Software Engineering/SRS

Alias

48

USE CASE EXPLANATIONS

Use Case 1: Sign up

Use case: Sign up Participating Actor: New user Includes: None Extends: Incomplete form Entry Condition: The user registers for a login to the system Flow of Events: 1. The user enters the site. 2. The user selects the sign-up (first-time user) option. 3. The system displays a sign-up page. 4. The customer enters the information into the sign-up page. 5. The system validates the information the customer has entered. 6. The system displays the main page specific for the customer as if they have just logged in. Exit Condition: If the customer selects the cancel button of the sign-up page, the page is exited and the customer is brought to the previous page. If the customer enters invalid information, the system displays an appropriate error message indicating which fields the customer must change. If the operation was successful, the customers information is stored in a database of customer information so that they can login again at a different time.

Use Case 2: Log in

Use case: Login Participating Actor: Member, Administrator Includes: Check Password, Find Member, Count Trials Extends: None Entry Condition: The user should have legal input data that allow him to log in Flow of Events: 1. The customer enters the site 2. The customer enters his ID number into the corresponding text field. 3. The customer enters his RIN into the corresponding text field. 4. The customer enters his Chassis number into the corresponding text field. 5. The customer selects the login button

CMPS 282

Software Engineering/SRS

Alias

49

6. The system performs the find member use case and the check RIN use case simultaneously. 7. The system displays the welcome page specific for the customer. Exit Condition: If the Login fields are not found in the database, the system prompts the customer to re-enter the information, or to register if not previously registered. If the customer selects the cancel button, the system blanks out the login and password fields without displaying a new window. The customer is logged in and the count trials use case increments by one.

Use Case 3: Find Member

Use case: Find Member Participating Actor: System Includes: None Extends: Member Not Found. Entry Condition: Login data that the system must check Flow of Events: 1. The user enters the login information 2. The system receives the login information 3. The system checks in the database if this information exists and belongs to a member. 4. The user chosen action is resumed. Exit condition: If the system doesnt find the corresponding input login data in the database, then error message is displayed telling that the member was not found. If everything was successful, the user chosen action is resumed.

Use Case 4: Check Login Data

Use case: Check Login Data. Participating Actor: System Includes: none Extends: Wrong Login data Entry Condition: these exists a login data that the system needs to check. Flow of events: 1. The user enters the login data 2. The system receives this data 3. The system checks in the database of the data is correct, and belongs to a member CMPS 282 Software Engineering/SRS Alias 50

4. If the system doesnt find the password in the database; it prints a message saying that this data is wrong 5. The user chosen action is resumed. Exit condition: If password is legal, the user chosen action is resumed. If the system doesnt find the password in the database; it prints a message saying that this data is wrong.

Use Case 6: Count Trials

Use case: Check Login Data. Participating Actor: System Includes: block Extends: none Entry Condition: the user tried to log in but there were errors. Flow of events: 1. The user tries to log in. 2. Error occurred: illegal login data. 3. Count trial is incremented by one. 4. The user tries again to log in. 5. Each time the new log in trial fails the system increments the Count Trial by one. 6. If the Count Trials reaches 3, the system applies the block use case. 7. The user has logged in. 8. The user chosen action is resumed. Exit condition: If password is legal, the user chosen action is resumed. If the system doesnt find the password in the database; it prints a message saying that this data is wrong.

Use Case 7: Block

Use case: Block Participating Actor: System Includes: none Extends: none Entry Condition: the Count Trials has reached his maximum limit Flow of events: 1. The User uses all his allowed login trials. 2. The Count Trials reached its maximum. 3. The user is blocked and doesnt have the right to login again. Exit condition: If the Count Trials reaches its maximum, the user is blocked and does not have the right to log in again.

Use Case 8: Edit Content

CMPS 282 Software Engineering/SRS Alias 51

Use case: Edit Content Participating Actor: Member, Administrator Includes: none Extends: Session Expiry Entry Condition: member has chosen the Customize Personal Profile, or Administrator has chosen Update Users Profile action. Flow of events: 1. User chooses the Edit Content action on the terminal. 2. If the user leaves the page intact for a while, the session expires and exit. 3. User changes the information he wants to edit. Exit condition: If the session doesnt expire the user content of the profile is edited

Use Case 9: Manipulate Members

Use case: Manipulate Members Participating Actor: Administrator Includes: Add Member, Delete Member, Update Member Extends: none Entry Condition: administrator has logged in Flow of events: 1. Administrator chooses the Manipulate Members action on the terminal. 2. He chooses one or more of the three use cases Add Members, Delete Members, and Update Members. Exit condition: Administrator can apply one or more of the 3 use cases: Add Member, Delete Member, and Update Member.

Use Case 10: Customize Personal Profile

Use case: Customize Personal Profile Participating Actor: Member Includes: Edit Content Extends: Session Expiry Entry Condition: Member is logged in. Flow of events: 1. The user chooses the Customize Personal Profile action on the terminal 2. If the user leaves the page intact for a time, the session expires, and exit. 3. The user chooses the Edit Text content Use Case Exit condition: If the user keeps working on the page he can choose to apply the Edit Content use case. CMPS 282 Software Engineering/SRS Alias 52

Use Case 11: Add Member

Use case: Add Member Participating Actor: Administrator Includes: Find Member Extends: Member Already Exists, Incomplete Form Entry Condition: Administrator has chosen the Manipulate Members option. Flow of events: 1. Administrator chooses the Add Members action on the terminal. 2. System checks if a member with the same primary key exists by applying the Find Member use case. 3. If the member already exists, the system informs the administrator. 4. Administrator fills the form with the needed information 5. If some information are missing, the system print a message asking the administrator to provide the missing information 6. The new Member is added to the Database. Exit condition: If all information is available, the new member is added to the database If the member is not found, an error message is displayed

Use Case 12: delete Member

Use case: Delete Member Participating Actor: Administrator Includes: Find Member Extends: Member Not Found, Incomplete Form Entry Condition: Administrator has chosen the Manipulate Members option. Flow of events: 1. Administrator chooses the Delete Members action on the terminal. 2. System checks if member exists. 3. if not, the system informs the administrator. 4. The member is deleted from the database. Exit condition: If the member is found, it is deleted from the database. If the member is not found, an error message is displayed

Use Case 13: Update Member

Use case: Update Member Participating Actor: Administrator Includes: Find Member Extends: Member Not Found, Incomplete Form Entry Condition: Administrator has chosen the Manipulate Members option. CMPS 282 Software Engineering/SRS Alias 53

Flow of events: 1. Administrator chooses the Update Member action on the terminal. 2. System checks if member exists 3. If not, system informs the administrator. 4. The administrator updates user information by filling a form. 5. If some information is missing, the system informs the administrator and asks him to provide the missing information. 6. The member information has been updated. Exit condition: If all information is provided, the member information is updated. If the member is not found, an error message is displayed

Use Case 14: Update User Profiles

Use case: Update User Profiles Participating Actor: Administrator Includes: Find Member, Edit Content Extends: none Entry Condition: Administrator has logged in. Flow of events: 1. Administrator chooses the Update User Profiles action on the terminal. 2. Administrator enters the username of the member he wants to update the profile. 3. System performs the Find Member use case. 4. Administrator chose the Edit Content. Exit condition: If the member was found, administrator applies the Edit Content use case.

Use Case 15: Pay Registration

Use case: Pay Registration Participating Actor: Member Includes: none Extends: Payment failure Entry Condition: Member has finished registration and wants to pay. Flow of events: 1. Member chooses the Pay registration action on the terminal. 2. Member enters all corresponding information: credit card number. 3. Information entered by the member concerning credit card and the format and other data is validated 4. Member has finished payment. Exit condition: CMPS 282 Software Engineering/SRS Alias 54

If the payment was successful, the member can proceed to the inspection. If not, an error message will occur.

Use Case 16: Pay Mecanique

Use case: Pay Mecanique Participating Actor: Member Includes: none Extends: Payment failure Entry Condition: Member wants to pay mecanique. Flow of events: 1. Member chooses the Pay mecanique action on the terminal. 2. Member enters all corresponding information: credit card number. 3. Information entered by the member concerning credit card and the format and other data is validated 4. Member has finished payment. Exit condition: If the payment was successful, the member can proceed to the inspection. If not, an error message will occur.

VI. Appendix
CMPS 282 Software Engineering/SRS Alias

55

Methodology analysis and elicitation techniques will be discussed in this part. 1. Analysis Model
As mentioned previously, an SRS document consists first of showing what to build, but also must be an introduction and a resource to the design phase. This implied our choice to choose more than one analysis model. The way the models are explained determines the order in which we built them:

Flow-oriented diagram:

First, we started with the classical DFD. The purpose of a DFD is to provide a semantic link between systems and software developers. It is a logical representation of the system. It models WHAT the system does rather than HOW the system does it. The reasons why we chose to construct the DFD can be stipulated as follows: - A DFD sets the requirements and keeps the abstraction level that hides HOW is the system configured to emphasize on WHAT is to be done. - A DFD avoids user/developer misunderstanding of the system - A DFD avoids having to begin documentation from trash when the physical system fluctuates [since the logical system (that is, WHAT gets done), often stays the same when technology alters.]

Scenario-based modeling:
Use Cases: They define explicitly what the system does, and what happens when actors interact with the system. Since it enlists the various approaches under which the system is used, the use cases build up all the aims and requirements of that system. The reasons this model was an inevitable choice for us are summarized thereafter: 1. It grasps the functional requirements very clearly: Easy to read, easy to understand. 2. May be used later as a reference for software test and quality guarantee. 3. Plays a crucial role in the software design process.

Activity diagram: It can be viewed as a completion to the use case diagram. It shows more specifically what the steps that the user must do are in order to attain a particular goal. It is also a good indicator on HOW the system must be built.

Class-based modeling: CMPS 282 Software Engineering/SRS Alias 56

1. Class diagram: Unlike use cases which embody users, the class diagram is intended to developers. The reasons why a class diagram is important are: It is the rigid root for a good design of the system It organizes information into abstraction of objects and encapsulation It starts going into details such as relationships between classes (hasa, is...) Since the SRS is a pre-design introduction, class diagrams are essential. 2. CRC: The CRC is an extension to the class diagram. It represents the responsibility of classes and the interaction between classes. So the reason the CRC was a choice as a model is because it organizes intrinsically the classes represented in the class diagram.

Behavioral modeling: Sequence Diagram: A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behavior of a system.

CMPS 282

Software Engineering/SRS

Alias

57

2. Elicitation techniques

It is said that requirements elicitation is where science stops and chaos begins. Indeed, although requirements elicitation is one of the most pivotal procedures in software engineering, it requires a lot of common sense and social background. The techniques used were the following: Introspection Interviews (more preferably, questionnaire interviews) Discussions

1. Introspection: It is a technique that amounts to imagining what kind of system should we produce; that is; trying to get part of the requirements from imagination and own speculation. Naturally, the extent at which we used this technique is very limited since it might not correspond with the clients point of view. This was mainly used in particular cases where the client himself (Prof. Karam) gave us the right to choose some requirements out of the whole list, and speculate about how it would be better to represent it in the overall system. 2. Interviews: Questionnaire interviews are one of the most successful elicitation techniques since they guide the client to choose requirements and design elements. It guides the clients to figure out how the system would function better and what is feasible and not feasible. Discussion is a central point here.

CMPS 282

Software Engineering/SRS

Alias

58

2. Validation of criteria Understanding the requirement leads to better management of software projects and improvements in the software engineering process. It was not easy to gather all requirements, as in every meeting we made, we realised there are additional question we should deal with. We decided it is very necessary to have: 1. User involvement 2. Executive management support 3. A clear statement of requirements But, for now, we believe that we have all what is needed, as throughout all our analysis, processes are consistent, predictable, and we have full control over requirements. What we mainly focused on, is that we understand the problem well, and make an estimation for time we will need, resources that will be used. Our goal is producing a high quality product within the time given to us,(thats why we divided functional requirements to different priority levels). Then we handled all different scenarios that can possibly happen, and considered all improvements that can be made concerning efficiency, practicality of usage , maintainability, and fast searching through the databases. We developed a DFD, a class diagram, CRC cards ,sequence diagrams, and use cases. The class diagram and the CRC cards identify the key responsibilities of each class, and the collaboration it might need to make with other objects to provide a specific service. Our design is object oriented, this will make it very easy to the developers to stay on the right track. Developers will have to make sure they gave each class the appropriate responsibilities according to the CRC cards, and any minor changes within a class will not have an effect on the system requirements.

CMPS 282

Software Engineering/SRS

Alias

59