Join GitHub today
Task 2 Write An SRS
For the project you have to create and maintain a Software requirements specification (SRS) document. Name your document "SRS" and put it inside the "documentation" directory in your repo. The goal of the first week is to make yourself familiar with the project domain, set up the SRS, and prepare the first customer meeting. Prepare questions, define goals of the meeting, and figure out what each team members task is during the meeting.
Note that requirements are likely to change. Your customer might change his mind or come up with new requirements. The SRS must be kept up-to-date and will be graded at the end of the project.
What is the SRS document?
This document contains an exhaustive description of the system that you will maintain. In this phase you need to focus on the needs expressed by your customer, ignoring any detail regarding how you will implement them. Read the requirement document provided by the customer and incorporate the requirements in the SRS. Note that the requirements are high level and vague. You need to talk to your customer and clarify things out. Get as much details as possible to remove any ambiguity.
There are many templates that you can use. You are free to choose your favorite one or to define your own. You are also free to choose any format (Word, LaTeX, ...) for your SRS document.
The document that you will write is meant to work as a contract between you and your customer. The customer must be able to read it and understand if your vision of the project is aligned with his. Agreement on the content of the document is fundamental to the success of the project.
This is a possible outline of an SRS document:
- System overview
- Overall description
- Use cases
- Actor characteristics
- Specific requirements
- Functional requirements
- Non-functional requirements (external, performance, etc.)
In section 1 you describe the system in general terms focusing on user goals, project stakeholders and terminology.
in section 2 you define the system from the user perspective. This is typically done by writing use cases and describing typical user scenarios. Try to characterize your user, understand his needs and specify his interactions with the application.
In section 3 you define all the functionalities that your application needs in order to fulfill the scenarios described in section 2. These are the features that your application must be able to provide in order to fulfill the expectations of your customer. In this section you also specify additional requirements (related to performance, interactions with other systems, etc..).
Use Case Scenarios
- J. Spolsky, Functional Specifications