Since many of you have selected a project by now, you are required to submit your first document in next 30-35 days probably. Its very very important to be in time. The project deliverables are different than the assignments. Its important to get your document “ACCEPTED” and not just submitted, within due date. When you submit the document in last few days, it takes the supervisor time to check it, reply you, if there is a mistake you have to correct it & then re-submit. So at least two weeks before the due date you must submit the document.
The first deliverable is the SRS document. You may find the template in your CS619’s assignments’ section. Stick to the template its very important.
SRS means Software Requirements Specifications. Whatever you write in this document will set your plan for your coding phase. What are the functions & features of your system. Getting this document clear to yourself is more important than getting it accepted by the supervisor. I will try to explain everything step by step, however if I miss anything, please let me know in comments section:
1. The Title is the title of your project.
2. Version number will be 1.0 if this is your first submission. If you submit, & supervisor mentions something needs to be corrected or improved, then the second time you submit your document will be Version 1.1 & then 1.2 & so on. If you do not change the version number the second time, chances are you will end up with Version 1.3 instead of 1.2 because you will have to submit next version just because you did not update the version number (been there, done that!)
3. Group ID is the group ID given at your LMS CS619 course’ assignments section top right side.
4. Supervisor name is also mentioned in same place on LMS
5. Revision History is mainly to keep a track of the changes you made from version 1.0 to whatever your current version is. e.g you submit Version 1.0 & in description you write a bit about whatever your document includes. In version 1.1 you made a change in Use Case diagrams, so mention, changes made in use case diagrams etc.
6. Start with Scope of Project. This section tells what is included in project, e,g a web application which has administration panel, a user control panel, a registration system to register users. Just a brief overview of the system. When you are doing this section, ask yourself, what things are included in my system? or fill in the blank “My system has____________”
7. Functional Requirements are what the system does, or what it can be used for. e.g a website used for exchange of links, a system for scanning MCQs, a system that navigates the satellites in space. What would be included in your project, take hints from scope & just elaborate the main features, in points. If there is an administration panel, what will it do, if there is login/logout facility, what is that for & what will it do for users.Take out your Project Description File & break the requirements in steps. Now explain these steps. These are your Functional requirements.
8. Non-Functional requirements are just the cream on top, what we need as support for functional requirements. Divide in two section. Hardware requirements which can be:
- A complete physical system capable of hosting a web-based application
- Development system is required for development and maintenance of the application.
- Database server is required for persistence of the data.
Software Requirements can be reliability, robustness, security, ease of use, authentication etc.
9. Use case diagrams can easily be understood if you have done Software Engineering-I course. Its great advantage for MIT students since they study this course in 2nd semester, before project but MCS students have this in 3rd semester. So bit of problem. Anyway, Use Case diagrams tell us what are the major players in this field, or what are the main types of users that use a system e.g Library is a system, what are users that directly use the system? Librarian & students right? so these are our two major actors. In a web site, what are two major users? Administrator, & user. So look at your description file, & your functional requirements & find out your users.
Once you have defined your actors (there won’t be more than two-three) next you define what actions they perform on this system? e.g User on a website, browses, registers,logs in, logs out, searches for something, writes a post. These are all actions of that user which go in the oval shaped thing. Here is my use case for actor Administrator:
Use case Diagram for Administrator
10. Usage Scenarios are just an expansion of the Use case diagrams. You take each use case actor, each use case inside that oval thing (e.g there are 7 usage scenarios in above picture) & put them in the given template box. Please remember the total number of usage scenarios MUST be equal to total number of oval use cases you are given for all your actors. If one is missing, you will have to re-do it.
Here is mine for example:
Login:
| Use Case ID: | 4.1 |
| Use case Title: | Log In |
| Actions: |
|
| Description: | By logging in to the account, the Administrator can:
|
| Alternative Paths: | N/A |
| Pre-conditions: | The user has not already been logged in |
| Post-Conditions: | The user can perform actions provided in description. |
| Authors: | Administrator and Registered User |
| Exceptions: | A message shows the error “invalid ID or password” |
And you are done with the SRS. If you pay attention it will not take longer than 3 days to complete it all. Read the description file again & again & yet again, take pen & paper, write down points what you are making, what it wants, what should be there in the system & just form your SRS. VU’s system is great they take you step by step. Make sure you submit your document at least two weeks before due date.
For anything you did not understand or want me to elaborate, please mention incomments.Thank you
Success & light
