ProCiv Project

Here you will find all the information to the Software Requirements project. The main idea is to support Civil Protection with a mobile application that can provide both push and pull functionalities related to the domain, the task for the teams will be to model the requirements for such project (please do not share the provided material).
 

Project Context

You will find all information related to the domain: what the goals of the Civil Protection are, how it operates, the needs in general. In the last part, you find some ideas and needs for implementation of a new system (slides 35-42): take into account that the needs for the mobile application are in slides 39-40. [download]

Initial Elicitation

There is an initial document that collects requirements collected from the customer. However, it is mixing several aspects into requirements (mixing features with functional / non-functional requirements, constraints, design decisions, etc...) plus ambiguous parts (e.g. "constantly"). You can use this document as a starting point for requirements analysis by extracting relevant information and better structuring it. [download]


Step 1 (by 19.03.2018):

• restructure the initial elicitation document by identifying and writing down different types of requirements as seen on lecture 2 (business requirements, functional requirements, non-functional, business rules, etc...)
• Create a context diagram (or ecosystem map) for the project

Step 2 (by 16.04.2018)

• add an initial statement about the project business vision
• structure the requirements in the IEEE Std 29148-2011 suggested form (note: you might mix with agile, more details during lecture)
• prioritized list of requirements: pick one method seen during lecture (AHP or planning poker) and provide the list of prioritized requirements

Step 3 (by 23.04.2018)

• Add Non-Functional Requirements

Step 4 (by 30.04.2018)

• add a use case for the project
• CRC Analysis

Step 5 (by 07.05.2018)

• Architectural representation (just add to document all the considerations about the way you would structure the system, according to non-functional (and functional) requirements. You can use the ADD method document as an example, but it does not need to be so detailed, the important is that you have NFRs, and indication how NFRs will be reflected in the architectural choices.

Step 6 (for final presentation on 14.05.2018)

• Mock-ups / UI prototypes - can be useful to show how the application will look like.
• Revise the whole requirements specification, so that it follows indications from different standards we have seen during lecture.