Skip to content
This repository was archived by the owner on May 3, 2022. It is now read-only.

Project Documents

Jump to bottom
Eduardo Riffo edited this page Dec 16, 2015 · 18 revisions

Project Documentation

Most project documents are stored as LaTex formatted text. You can find information about LaTex here.

Requirement documents

Identified use cases for the dragonfly project are described here.

Based on the use case scenarios at set of product requirements are created and defined. All product requirements for the dragonfly project are described here.

When the product requirement have been identified and created, then software requirements are created to meet the product requirements demands. Software requirements are done at system and sub-system level. The system is the whole Dragonly system with all its components and the sub-system is tied to the use case e.g. safety scenario creates the safety sub-system. All software requirements are described here.

The software requirements are then added by priority to a backlog file that contains all the requirements. The priority is then set by the project board and/or project members. The latest version backlog file can found here. All requirements listed i the backlog must be handled and executed by an agile team. An SRS item may be in the following states:

  • To be analyzed. This is the initial state, all added requirements must be set to this state.
  • Analyzing. The team analyzes the requirements from sprint point of view, outcome of this activity is:
    • User story document with a reference number. The story to sprint. Template of user story can be found here.
    • Test specification document, listing all the tests and test cases needed for this story.
    • Implementation design document. Describing the software design and interactions to enable this functionality.
  • Analyzed. When the above is done, then the team set this item to analyzed.
  • Ready to sprint is set by the project members/board when it is ready to be sprinted.
  • Sprinting. Marks an ongoing activity.
  • Done. The definition of done is set by the team, but it must at least have the following points met:
    • Well formatted and code.
    • Warning and error free code.
    • Tested code.
    • Test results of the specification.
    • Coverage of code.
    • SDD (Software Design Description) of implementations.

The team might add some more to the definition of "done".

Clone this wiki locally