-
Notifications
You must be signed in to change notification settings - Fork 2
Task Requirements
For this assignment you are asked to write a Software requirements specification (SRS) document.
This document contains an exhaustive description of the system that you will build. In this phase you need to focus on the needs expressed by your customer, ignoring any detail regarding how you will implement them. Take all the information that you collected during your first customer meeting and write it down in a precise and easily understandable manner.
There are many templates that you can use. You are free to choose your favorite one or to define your own.
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.
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.
This is a possible outline of an SRS document:
-
- Introduction
- Purpose
- Stakeholders
- Definitions
- System overview
- References
-
- 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 to fulfil the scenarios described in section 2. These are the features that your application must be able to provide in order to fulfil the expectations of your customer. In this section you also specify additional requirements (related to performance, interactions with other systems, etc..).
We strongly encourage you to use our MS Word Template.
This template contains two sections:
- Diagram: contains a UML use case diagram providing an overview of all the use cases described in the document. This is useful to show the relationships existing between different use cases.
- Use cases: contains all defined use cases. Each use case is specified in 9 points (see example). All these points are optional and should be filled out according to your needs.
We recommend to start designing use cases starting from the user stories agreed with your customer. Start writing down a list containing the use cases you need. Use meaningful and active verbs to name the use cases.
Remember: You are not limited to the user stories we gave to you. Feel free to split and rearrange stories in order to obtain a more clear separation of the different actions that your user is allowed to execute. If a user story is complex, break it in more parts !
After writing the list, figure out the relationships drawing the UML diagram. As last step, write a detailed description of each use case using our example as a reference. An optional UML sequence diagram can be added for clarification if the use case is complicated.
The Final use case document must be saved in your repository at the following location: /Documentation/SRS
Accepted file types: doc/docx/odt/pdf
For more information on how to write good use cases:
- ch. 6 Use cases - Applying UML and patterns, Larman, 3rd. edition
- https://www.draw.io
- http://www.gatherspace.com/static/use_case_example.html
- http://www.readysetpro.com/whitepapers/usecasetut.html
- http://www.bredemeyer.com/pdf_files/functreq.pdf
- J. Spolsky, Functional Specifications