You are on page 1of 59

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

1

0. Contents

TOPIC Introduction…………………………………………………3 • Purpose……………………………………………….3 • Scope………………………………………………….3 • Definitions……………………………………………4 • 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 CRC……………………………26 • Sequence diagram…………………………………..30 • Activity diagram……………………………………32 • Use cases…………………………………………….43 - Description……………………………………48 Appendix …………………………………………………55 • Analysis model…………………………………….55 • Elicitation techniques ……………………………57 • Validation criteria ………………………………..58

CMPS 282

Software Engineering/SRS

Alias

2

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. That’s 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

4

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

5

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. delete drivers. 2.II. and given also to the buyer). along with personal information about the buyer once vehicle is bought. Inspection is NOT paid online.1. Then registration comes. needs to fulfill functions such as: update. notice drivers for inspection success or failure… • Insurance company: This is omnipresent in the website. the system has exactly 3 possible users: • Driver (Car owner) • Mecanique Administrator: Can access all parts of the website. NB: Registration is necessary before all later steps. In a sense. his ID# and the chassis# of the vehicle (primary key among all other vehicles). maintain. The next step is to give the user the ability to fill his personal information and some important information about his vehicle. The user is supposed to pay online. General Overview As stated in other documents. register on the web. it will tell the requirements in plain English for customer expenditure while the next section will contain specifications written for the developers. the general layout for the system is the following: In summary. An automatic checking crosses the information to determine whether the user actually bought the vehicle. What happens actually is that the user can view the dates the inspection of his vehicle is supposed to take place in. If everything works well. 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. and the administrator notices him whether the transaction succeeded. add drivers. The user then takes his car for     CMPS 282 Software Engineering/SRS Alias 6 . the user is now signed in.

time also plays a pivotal role when it comes to delays. Mecanique happens every year. when the user connects. as well as the time factor which is responsible of automatic updates. Insurance is also NOT paid online. Insured car 4. NB: Inspection is necessary before all later steps. the system must be responsible to consider the users of this situation some special cases. the time factor also has to act in order to add a penalty payment that increases for a period of 3 years maximum. Registered car 2. The last step is the mecanique. concretely 3 elements: the RIN. and the inspection company which has an access to the web. Input Generally. The input is abstractly an unregistered but bought car. The number of car plate numbers is divided by 12 in order to produce the timeline of car inspection each month. The following are the possible outputs: 1. Mecanique paid for car Time Time is extremely important in the system. Output The output of the system however fluctuates according to the time span and/or requirements completion. 2.  inspection. if mecanique deadline is over. NB: Insurance is necessary before all other steps. Input. 2. posts whether the vehicle has succeeded or failed. External Interfaces CMPS 282 Software Engineering/SRS Alias 7 . it is just a form that the user prints and then goes to submit to a particular separate insurance company. the id# and the chassis # of the car.3. Other than the other case stated above. 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. The administrator will then be responsible of telling the user whether insurance went ok or not. Inspected car 3. his aim is to do an online registration for his car.2. Also. Output. Time The following describes very briefly the input and the output of the system. If the inspection is NOT done and the limit dates for inspection are over. and the system must automatically allocate days for inspection according to car plate numbers. and produce other dates for inspection.

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

and delete actions. CMPS 282 Software Engineering/SRS Alias 9 . The admin can do actions such as privileges granting. but the administrator don’t really have to do more than monitoring the system. create new accounts… The administrator’s storyboard is a bit more simplified than the user’s storyboard. update actions.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 administrator’s storyboard is similar to the user’s storyboard (in terms of designs).

either the car owner is a first time user. Outputs: Case input is correct and confirmed by database. ID and chassis number.    User has to enter RIN and password (password is discussed below). Inputs: User enters RIN. 3. in other words. 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. Software Engineering/SRS Alias 10 CMPS 282 . III. or he’s an old user. user is sent a confirmation page allowing him to move on. ID number and car chassis number to be able to enter the page. authenticating RIN. the employment of an encryption system or some password is crucial. however this is still under discussion and would need some security approaches to deal with the situation. he gets an RIN from seller.1 Login page: First-time user: Case study: When user buys car. but this option is still in mind. To consider functional requirements here. Functional Requirements Functional requirements describe the possible effects of a software system. Such information is sent and saved in database. we might consider two cases. For high security reasons. what the system must accomplish. The server sends the query to the database.Now there is a possibility of creating new storyboard for people who do data entries. Again no more than 3 attempts. Else. User cannot attempt more than 3 inputs for security reasons. he’s requested to input another time.

User is then required to enter a password. 3. color.2 User Registration: Inputs: User is then required to input some personal information: Name. Address. The manual registration is obvious. date of birth. type. The server will send info to the database and the administrator The administrator will confirm this info manually. 2nd case: Automated Registration:       The user would like to register online. he is required to fill a form in the car registration page. CMPS 282 Software Engineering/SRS Alias 11 . In this case. He can also get these papers manually of course. He will be able to see all information regarding his car. he will receive later a confirmation message and can access the page. Some form sends this info to database and is responded by a confirmation message. The database will receive this info from the user and send a value confirming the pay. This information will be sent to database in order to be processed and saved. In this form. 3.  Upon reply. if everything worked successfully. at the DMV. Here money can be paid in two options: manually or online.3 Car registration: Two options: manual or automated registration 1st case: Manual Registration: User registers the car manually in place. year of make. Outputs: User will get confirmation concerning his personal information. Online Payment: The user will first get the amount under “fees” link. email address. and the user will be replied to in few days The user is required to pay a certain amount of money to ensure registration. Phone Number. profession. which he has to confirm. the user will receive his car plate number and car registration papers later by mail. He will enter specific information in order to be able to pay. Below the online registration is discussed. marital status. In this case. the info asked for are: Car model. in order to get access later to the site. registration type… The user will enter this info and submits.

5 Insurance: CMPS 282 Software Engineering/SRS Alias 12 . 3rd case: User doesn’t take test at all. 3. No need of re-registering. The server will automatically display info concerning this. and he will get info about test dates. and the things the user’s car failed in. 2nd case: User takes test but fails Server will display information regarding next dates. which are retrieved from test table in database containing information about test requirements. fees. User will be informed of inspection dates on this page inspection dates.4 Inspection:      Each year cars must pass inspection test for safety purposes. the user will be requested to fill an online form. 3. User will be issued warning concerning this. 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. penalty fees. Inspection dates are related to car plate numbers.3rd case: car owner who wishes to become an online user of database:    In this case.  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. 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. 4th case: User’s car is not older than 3 years In this case user doesn’t need to pass inspection. so the server connects to a separate database of dates and car plate numbers span.

NB: Another requirement possibility is to make user pay online. or credit cards. manually or the system. and places regarding mecanique. Here. tickets: These add up to the total mecanique fee. The server here displays information about: 1. What companies’ can the user insure with. The server connects to a separate database containing mecanique information and retrieves information regarding mecanique. Which company is the user insured with 3. when’s the deadline for insurance 4. information about these companies. The user is given the choice of paying either online or personally. 3. server will update information in database to ensure payment. 2nd case: The user doesn’t pay or is late in payment The user will be issued warning and penalty fees. the server displays to the user dates. What fees have to be paid for insurance 5. 1st case: The user pays mecanique successfully.6 Mecanique:      The Lebanese government requires each year that cars renew registration through mecanique. fees. CMPS 282 Software Engineering/SRS Alias 13 . Whether user is insured or not 2. Cases: penalties. In this case server will update the page and confirm payment. When user pays. automatically. In case he’s not insured. Online payment is done through prepaid cards. Who will warn the user? Either the administrator.The Lebanese government requires each car to be insured against personal accident. links… 6.

The user fills RIN. The server validates 3. Possible outputs: validation error messages. else restart process.7. authentication error messages. If valid. the server authenticates. User enters a field incorrectly more than three times. server sends user to next page. 5. else restart process.1 User Functions 1) Requirement name Priority Path User login Essential 1. chassis #. 4.3. Server authenticates and sends user to next page If server down while redirecting. server bans user. ID# 2.7 Table Requirements Hereafter. all functional requirements will be tabled and explained specifically. If authenticated. The work will distinguish THREE types of functional requirements: • User requirements • Administrator requirements • Other additional requirements 3. issue error statement Other paths Post conditions Exceptions CMPS 282 Software Engineering/SRS Alias 14 .

User submits entry. server redirects to payment page. wrong formats… 4. server continues. then update confirmation information about payment. it will be saved in an appropriate format in the database notifying that the payment has been done. If valid. Other paths Post conditions 3) Requirement name Priority Path Other paths Post conditions Exceptions Payment processing summary New car registration Critical 1. Server validates input 7. All info ok. The data will have to be first verified for correctness by being validated. server continues. Server validates information 3. after it cancels process. If user connection or server down while payment processing. server waits for a while. 3. 2. confirmation messages. User fills in payment info: credit card #. If valid. Server updates database with information. Server validates for empty fields. The user fills personal information. confirmation messages. 2. Possible outputs: validation error messages. Once the data has been entered. else re-enter erroneous fields. immediate blocking of operation.2) Requirement name Priority Path User registration Important 1. else reenter erroneous fields. Possible outputs: validation error messages. If user connection down while processing. User fills in car registration information. Alias 15 CMPS 282 Software Engineering/SRS . 4. None Server updates database with information. 5. Server authenticates input 8. prepaid card number#… 6. None. 5. If empty credit card. immediate blocking of information.

4. 5. If user did test and failed. the format for credit card number and the total amount should always be numeric. server redirects to admin page. Server updates database with information. 4. after it cancels process. user is done.For example. server Alias 16 CMPS 282 Software Engineering/SRS . 4) Requirement name Priority Path Other paths Post conditions Exceptions Already registered car IF TIME PERMITS 1. everything ok. User enters page. the system shall ask him to reenter the corresponding data. else reenter erroneous fields. All info ok. Server validates information 3. 6. If valid. 2. If the user entered incorrect information. None. If user connection down while processing. Admin sends confirmation to user and adds his car. can move on. Server displays information 3. server waits for a while. If user did test and passed. then update confirmation information about payment. User fills in request to enter his car in database. 5) Requirement name Priority Path Car inspection Essential 1. 2. User can continue. server continues.

displays new test dates. confirmation messages. If user didn’t take test. None. N/A If server down while redirecting. User sees insurance info. server displays fees. dates. None. server waits for a while. If user connection or server down while payment processing. user is sent info requiring insurance. place. user is sent info requiring insurance. if not. If not. UNTIL NOW NOT FEASIBLE 1. issue error statement 6) Requirement name Priority Path Other paths Post conditions Exceptions Car insurance Important 1. User is given option to pay online. fees… 5. If insurance is already paid. display information. 2. N/A If user connection down while processing. None. after it cancels process. NOT IMPORTANT. immediate Alias 17 CMPS 282 Software Engineering/SRS . 2. issue error statement 7) Requirement name Priority Path Other paths Post conditions Exceptions Car insurance payment IF TIME PERMITS. Possible outputs: validation error messages. Server moves user to insurance If server down while redirecting. Server confirms and updates… 3. user is sent info about company… 3.Other paths Post conditions Exceptions displays fields in which user failed. 6.

Server validates information. 7. immediate blocking of operation. Everything ok: server displays confirmation info. 5. Server updates database with information. after it cancels process. 8) Requirement name Priority Path Other paths Post conditions Exceptions Mecanique payment Essential 1. If valid. server redirects user to online payment page. immediate blocking of information. 6. 9) Requirement name Priority User Update Essential CMPS 282 Software Engineering/SRS Alias 18 . If user chooses option. If user connection down while processing. None. User sees mecanique info. server waits for a while. immediate blocking of information.blocking of operation. 2. 3. server authenticates user critical information such as credit card number or prepaid card number. User can choose online payment option. User fills in payment information. If empty credit card. If user connection or server down while payment processing. If empty credit card. 4.

Update permits the user to modify some specific information (address. server redirected to update page. Other paths Post conditions Exceptions 2’)Requirement name Priority Path Other paths Post conditions Exceptions Inspection update Essential 1. Database is updated. 4. If server down while processing. issue error statement. delete and give privileges to information entering people. User has updated personal information If server down while redirecting. If information entered is valid. Admin updates registration data manually. 2.2 Administrator Functions Administrator is given privileges such as update databases.7. issue error statement. Server sends information to database None.Path Other paths Post conditions Exceptions 1. Admin updates inspection data manually. issue error statement. 1’)Requirement name Priority Path Registration update Essential 1. case registration is not done online 2. If information is not valid. Server sends information to database None. phone number. If server down while processing. If user chooses this option. 2. then a link with the database will imply an update operation. Alias CMPS 282 Software Engineering/SRS 19 . 3. Database is updated. issue error statement. …) 3. None.

If server down while processing. Database is updated. Mecanique update Essential 1. Server sends information to database None. 3. Database is updated. Admin can update critical information. 2. 2.3’)Requirement name Priority Path Other paths Post conditions Exceptions 4’)Requirement name Priority Path Insurance update Essential 1. Admin updates mecanique data manually. Other paths Post conditions Exceptions 5’)Requirement name Priority Path Other paths Post conditions Exceptions CMPS 282 Software Engineering/SRS Alias 20 . If server down while processing. If server down while processing. In all cases. 2. issue error statement. Database is updated. issue error statement. Server sends information to database None. server interacts with DB. Admin updates insurance data. None. issue error statement. Admin can grant privileges. Admin responsibilities IF TIME PERMITS 1.

If server down while redirecting. If browser doesn’t support languages. None. None. issue error statement. Page is translated.3 Other functions 1’’)Requirement name Priority Path Other paths Post conditions Exceptions Language IF TIME PERMITS 1. If server down while processing. User is directed to sitemap process. User selects sitemap function 2.7. issue error statement. 2’’)Requirement name Priority Path Other paths Post conditions Exceptions Site map IF TIME PERMITS 1. 2. CMPS 282 Software Engineering/SRS Alias 21 . User chooses language in pages. Server translates pages. issue error statement. Server help user in site functions.3.

4. 4. to face big requests in short periods of time. Later on. At least 2 GB of memory. in case a lot more cars becomes online.2 Software: Server: • • • The web server will run on Windows NT or Windows XP professional. User: The user can run the application on Windows platforms: 95. The database server is Microsoft SQL server 2000. NT. 2. a concurrent server. 4.1 Hardware: Required: 1. Compliant server. 3. 2000 and XP.IV. 98. or window server 2003. 1000 GB of storage space. It is important that these requirements be specifies so that their achievement be objectively verified later. NON Functional Requirements (Software System Attributes) Software attributes also DO serve as requirements. CMPS 282 Software Engineering/SRS Alias 22 .

such as flash player.4 Coding: • • • • Coding is done in ASP . Forms will be created via VB. Then we need about at least 1 terabyte for database storage system.net scripts. requires. like safari. But assuming that not more than 30 o 50 % of car owners have access to internet. depending on traffic. 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. say. and secondary requirements. are recommended but not required. equivalent to 1000 GB.net.5 Documents: Each page of the website will contain help information. 1 MB of space. even duplicated to handle many simultaneous requests. Database queries use standard SQL queries.• • The user is required to have Internet Explorer 5 and above. Let’s assume we have about 1. which should have strong attributes: large memory. Database queries are expected to run on average in less than 1 sec. but with time and technological development the server must better be updated.3 Connection: The user can use dial up connection and higher bandwidth connections. or at least know how to use it then storage space can be reduced significantly. each user.000 cars in Lebanon. 4. The user’s browser is also expected to have JavaScript enabled. however connections from 56. At first the server is not expected to handle many requests. 4. 4. CMPS 282 Software Engineering/SRS Alias 23 .6 Performance: The web application will on run on the DMV server. at least 2 GB. Performance will also vary depending on the traffic on the server. assuming all registered cars want to enter online. The web server will use an HTTP proxy. Server is expected to connect on a high bandwidth system. 4.6 kbps bandwidth are preferred.net. Netscape 6 and above or any Netscape compliant application. The website will also contain a general FAQ.net using VB .000. significant amounts of storage mechanisms are required to store large amounts of information in database. Forms will be processed using VB. or html tags. with his car. or support for Arabic or French (or both) encoding with leftto-right or right-to-left (or both).

weekends and important official events like elections. 2. During this time. the user is only allowed to see information only. and during holidays.10 Maintainability: CMPS 282 Software Engineering/SRS Alias 24 . Type will be specified later. Type to be specified later.7 Firewall is required in server. 4. (128 bit is an option) 3. 4. electricity…) during session or user simply stops using page for some time. In this case server cancels session if user doesn’t continue later.10.2 User password: for 2nd time login: encryption for decoding/encoding password. If the problem is not important and fixed automatically. server will close during fixing time.10. Server during peak time is requested to handle between 1.10.7 Availability: The system can be accessed 24 hours a day.000 requests per day in the first years of the projects.1 1st time login: encryption for decoding and encoding RIN. 3.Peak time running: Server performance is expected to slow down during peak times.3 Online payment: high security encryption software for processing credit card/prepaid card transactions.9 Security: 3.10. If the problem needs professional assistance.10.5 User is not allowed to enter password or login information incorrectly more than 3 times during login process. depending on number of users willing to become online users.6 Cookies are an option. or some problems stopping the user from continuing (PC shuts down. 3. for example during mecanique payment periods. 4.000 and 5.10. transactions will not be allowed after the DMV closure time. every user action involving database transaction will be recorded in a log file.10.4 Log files: every database transaction. 3. user can continue his work. However. in case controversies happen.8 Safety: Cases: 1. 4. User connection is broke. (128 bit is an option) 3. 3. Server down or crashes for some reason: transactions occurring will be immediately cancelled.

everything is expected to run fine. 3. Flexibility: Modification of software can be easily done since components aren’t directly attached by functionality to each other. i. 2. Testability: Each component is tested separately. The software can be run on windows platform XP professional or Windows Server edition. Reusability: Components can be used in other application specific to those components. No professionalism is required except for admin. makes the learning of the usage of the application very fast. 50% of code is host-dependent. which allows easy interpretation. Updates to software components can be easily made since components’ functions aren’t directly attached. 4. 50% of components are host dependents. 4. CMPS 282 Software Engineering/SRS Alias 25 . Software components are written in VB .net are used. HTML and VB .1. and then with each other.12 Other Quality Requirements 1. Usability: Basic knowledge of DMV operations. Efficiency: The program is expected to have about 3 % of CPU usage for each database transaction. related to external influences. or Windows NT 2. 6. which should allow easy maintenance of code. with a basic knowledge of windows components.e. 2. Reliability: System transactions. 4. such as heat or electricity problems. thus testing functionalities aren’t complicated. Otherwise. Internet Information services is required on the platform to run the host 3.net and HTML code.11 Portability 1. 7. requests are expected to run without many interruptions. mecanique can be used in a mecanique specific application. 4. 5. 5. Correctness: errors expected: technical errors.

Class: CarRegistered Responsibility computeAmountMecanique computeAmountInsurance computeAmountInspection Collaborator CarRequirements(client)+ the apropriate class of the inheriting classes(server).2 Class diagram and CRC For Class Diagram see AppendixII. see Appendix II. 5. Alias 26 CMPS 282 Software Engineering/SRS .V. CarRequirements(client) + the apropriate class of the inheriting classes(server).1 DFD For DFD. System Models 5. CarRequirements(client) + the apropriate class of the inheriting classes(server).

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 .

CMPS 282 Software Engineering/SRS Alias 30 .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 31 . Then account can invoke methods from class profile in case user triggers an event such as. a method from class account. updateAddress. for example. Once the user is in. invoke start session.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.

CMPS 282 Software Engineering/SRS Alias 32 . the process can be stopped here.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. Otherwise. car requirement invokes methods to find the date of mecanique payment (from Dates) and the amount to be paid (from car registered). In case the car has no requirement.

5. Every object of each instance invokes specific functions of other classes in order to accomplish tasks.4 Activity Diagrams CMPS 282 Software Engineering/SRS Alias 33 .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.

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 .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.

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 .

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 .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.

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 .

Use Cases UML Use Case Model + User + First-Time User + Member + Seller + Inspector + Insurance Administrator + Mecanique Administrator CMPS 282 Software Engineering/SRS Alias 44 .5.5.

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 .

5. The customer enters his ID number into the corresponding text field. The system validates the information the customer has entered. 3. • If the customer enters invalid information.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 system displays the main page specific for the customer as if they have just logged in. Count Trials Extends: None Entry Condition: The user should have legal input data that allow him to log in Flow of Events: 1. 3. The system displays a sign-up page. 4. The customer selects the login button CMPS 282 Software Engineering/SRS Alias 49 . the customer’s information is stored in a database of customer information so that they can login again at a different time. 2. the system displays an appropriate error message indicating which fields the customer must change. 6. Exit Condition: • If the customer selects the cancel button of the sign-up page. 5. Find Member. The customer enters his RIN into the corresponding text field. 4. The customer enters the site 2. The customer enters the information into the sign-up page. the page is exited and the customer is brought to the previous page. Administrator Includes: Check Password. • If the operation was successful. The user enters the site. The user selects the “sign-up” (first-time user) option. Use Case 2: Log in Use case: Login Participating Actor: Member. The customer enters his Chassis number into the corresponding text field.

Use Case 4: Check Login Data Use case: Check Login Data. Exit Condition: • If the Login fields are not found in the database. then error message is displayed telling that the member was not found. the system prompts the customer to re-enter the information. The system receives the login information 3. The user chosen action is resumed. • If everything was successful. The system receives this data 3. the user chosen action is resumed. The system checks in the database of the data is correct. 4. 7. • If the customer selects the cancel button. Entry Condition: Login data that the system must check Flow of Events: 1.6. Use Case 3: Find Member Use case: Find Member Participating Actor: System Includes: None Extends: Member Not Found. 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. or to register if not previously registered. The system checks in the database if this information exists and belongs to a member. The system displays the welcome page specific for the customer. Exit condition: • If the system doesn’t find the corresponding input login data in the database. Flow of events: 1. and belongs to a member CMPS 282 Software Engineering/SRS Alias 50 . Participating Actor: System Includes: none Extends: Wrong Login data Entry Condition: these exists a login data that the system needs to check. The user enters the login information 2. The user enters the login data 2. The system performs the find member use case and the check RIN use case simultaneously.

the user is blocked and does not have the right to log in again. 7. 2. If the Count Trials reaches 3. the user chosen action is resumed. The user is blocked and doesn’t have the right to login again. The user tries again to log in. The user chosen action is resumed. The user has logged in. it prints a message saying that this data is wrong. The user tries to log in. Error occurred: illegal login data. Use Case 6: Count Trials Use case: Check Login Data. 3. Use Case 8: Edit Content CMPS 282 Software Engineering/SRS Alias 51 . Count trial is incremented by one. 6. 8. it prints a message saying that this data is wrong 5. 4. Exit condition: • If password is legal. 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.4. 5. Each time the new log in trial fails the system increments the Count Trial by one. The user chosen action is resumed. the system applies the block use case. Exit condition: • If password is legal. 3. the user chosen action is resumed. Flow of events: 1. • If the system doesn’t find the password in the database. Participating Actor: System Includes: block Extends: none Entry Condition: the user tried to log in but there were errors. The User uses all his allowed login trials. • If the system doesn’t find the password in the database. 2. it prints a message saying that this data is wrong. If the system doesn’t find the password in the database. The Count Trials reached its maximum. Exit condition: • If the Count Trials reaches its maximum.

2. If the user leaves the page intact for a time. 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. Update Member Extends: none Entry Condition: administrator has logged in Flow of events: 1. or Administrator has chosen “Update Users Profile” action. The user chooses the “Customize Personal Profile” action on the terminal 2. Administrator chooses the “Manipulate Members” action on the terminal. Delete Members. 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. 3. User changes the information he wants to edit. Delete Member. User chooses the “Edit Content” action on the terminal. 2. He chooses one or more of the three use cases Add Members. the session expires and exit. Administrator Includes: none Extends: Session Expiry Entry Condition: member has chosen the “Customize Personal Profile”. 3. If the user leaves the page intact for a while. the session expires. “Delete Member”. Flow of events: 1. and exit. Exit condition: • Administrator can apply one or more of the 3 use cases: “Add Member”. Flow of events: 1. Exit condition: • If the session doesn’t expire the user content of the profile is edited Use Case 9: Manipulate Members Use case: Manipulate Members Participating Actor: Administrator Includes: Add Member. and Update Members. CMPS 282 Software Engineering/SRS Alias 52 .Use case: Edit Content Participating Actor: Member.

the system print a message asking the administrator to provide the missing information 6. Flow of events: 1. System checks if member exists. 4. If some information are missing. Incomplete Form Entry Condition: Administrator has chosen the “Manipulate Members” option. CMPS 282 Software Engineering/SRS Alias 53 . 2. Administrator chooses the “Add Members” action on the terminal. Flow of events: 1. if not. Administrator fills the form with the needed information 5. it is deleted from the database. System checks if a member with the same primary key exists by applying the Find Member use case. If the member already exists. 2. 3. the system informs the administrator. Incomplete Form Entry Condition: Administrator has chosen the “Manipulate Members” option. • If the member is not found. Administrator chooses the “Delete Members” action on the terminal. Incomplete Form Entry Condition: Administrator has chosen the “Manipulate Members” option. an error message is displayed Use Case 12: delete Member Use case: Delete Member Participating Actor: Administrator Includes: Find Member Extends: Member Not Found. 4. an error message is displayed Use Case 13: Update Member Use case: Update Member Participating Actor: Administrator Includes: Find Member Extends: Member Not Found. 3. the new member is added to the database • If the member is not found.Use Case 11: Add Member Use case: Add Member Participating Actor: Administrator Includes: Find Member Extends: Member Already Exists. The member is deleted from the database. Exit condition: • If all information is available. Exit condition: • If the member is found. the system informs the administrator. The new Member is added to the Database.

Flow of events: 1. The member information has been updated. 2. Edit Content Extends: none Entry Condition: Administrator has logged in. 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. administrator applies the “Edit Content” use case. 5. Administrator chooses the “Update Member” action on the terminal. System performs the “Find Member” use case. System checks if member exists 3. an error message is displayed Use Case 14: Update User Profiles Use case: Update User Profiles Participating Actor: Administrator Includes: Find Member. Exit condition: • If the member was found. Flow of events: 1. 2. 4. If some information is missing. the member information is updated. system informs the administrator. 3. Member enters all corresponding information: credit card number. Administrator chose the “Edit Content”. Administrator enters the username of the member he wants to update the profile. If not. Member chooses the “Pay registration” action on the terminal. 2. 3. 6. • If the member is not found. Exit condition: • If all information is provided. Information entered by the member concerning credit card and the format and other data is validated 4. Exit condition: CMPS 282 Software Engineering/SRS Alias 54 . Administrator chooses the “Update User Profiles” action on the terminal. The administrator updates user information by filling a form. the system informs the administrator and asks him to provide the missing information. 4. Member has finished payment. Flow of events: 1.

Member chooses the “Pay mecanique” action on the terminal. an error message will occur. 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. Appendix CMPS 282 Software Engineering/SRS Alias 55 . Member has finished payment. Exit condition: • If the payment was successful. • If not. Member enters all corresponding information: credit card number. 2. 3. If not. Flow of events: 1.• • If the payment was successful. VI. the member can proceed to the inspection. the member can proceed to the inspection. Information entered by the member concerning credit card and the format and other data is validated 4.

May be used later as a reference for software test and quality guarantee.Methodology analysis and elicitation techniques will be discussed in this part. Class-based modeling: CMPS 282 Software Engineering/SRS Alias 56 . 2. Plays a crucial role in the software design process.] Scenario-based modeling: • Use Cases: They define explicitly what the system does. Analysis Model As mentioned previously. The reasons why we chose to construct the DFD can be stipulated as follows: . The way the models are explained determines the order in which we built them: Flow-oriented diagram: • • • • First. This implied our choice to choose more than one analysis model. The purpose of a DFD is to provide a semantic link between systems and software developers. WHAT gets done).A DFD avoids user/developer misunderstanding of the system . It models WHAT the system does rather than HOW the system does it. 3. It is a logical representation of the system. • Activity diagram: It can be viewed as a completion to the use case diagram. the use cases build up all the aims and requirements of that system. but also must be an introduction and a resource to the design phase. an SRS document consists first of showing what to build. It grasps the functional requirements very clearly: Easy to read.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. It shows more specifically what the steps that the user must do are in order to attain a particular goal.A DFD avoids having to begin documentation from trash when the physical system fluctuates [since the logical system (that is. It is also a good indicator on HOW the system must be built. 1. Since it enlists the various approaches under which the system is used. easy to understand. and what happens when actors interact with the system. . The reasons this model was an inevitable choice for us are summarized thereafter: 1. we started with the classical DFD. often stays the same when technology alters.

is. 2. CMPS 282 Software Engineering/SRS Alias 57 . 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. and the order in which the invocation occurs is captured in a Sequence diagram.) Since the SRS is a pre-design introduction. Class diagram: Unlike use cases which embody users..1.. class diagrams are essential. the class diagram is intended to developers. It represents the responsibility of classes and the interaction between classes. The invocation of methods in each object. Behavioral modeling: Sequence Diagram: A Sequence diagram depicts the sequence of actions that occur in a system. CRC: The CRC is an extension to the class diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behavior of a system. So the reason the CRC was a choice as a model is because it organizes intrinsically the classes represented in the class diagram.

CMPS 282 Software Engineering/SRS Alias 58 . it requires a lot of common sense and social background. Interviews: Questionnaire interviews are one of the most successful elicitation techniques since they guide the client to choose requirements and design elements. Naturally. although requirements elicitation is one of the most pivotal procedures in software engineering. 2. that is. Indeed. It guides the clients to figure out how the system would function better and what is feasible and not feasible. Introspection: It is a technique that amounts to imagining what kind of system should we produce. This was mainly used in particular cases where the client himself (Prof. Discussion is a central point here. The techniques used were the following: • • • Introspection Interviews (more preferably. and speculate about how it would be better to represent it in the overall system. questionnaire interviews) Discussions 1. Elicitation techniques It is said that requirements elicitation is where “science stops and chaos begins”. trying to get part of the requirements from imagination and own speculation. Karam) gave us the right to choose some requirements out of the whole list.2. the extent at which we used this technique is very limited since it might not correspond with the client’s point of view.

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