search

bnsn-dp / 4800-Grapevine

MIT License
2 stars 0 forks source link

SRS Final Draft #9

Closed bnsn-dp closed 3 weeks ago

bnsn-dp commented 1 month ago

As restrictive in terms of detail as possible.

Once everything is collated, move it into a doc

bnsn-dp commented 1 month ago

https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document https://en.wikipedia.org/wiki/Software_requirements_specification https://asana.com/resources/software-requirement-document-template

bnsn-dp commented 1 month ago

Final Doc

Note: Only filling this out once everything else is collected

https://docs.google.com/document/d/1XLF-1hUs6BSML5iDpdpdiqHy0mEphSTotvDJYA-WoPM/edit?usp=sharing

bnsn-dp commented 4 weeks ago

Notes

Perforce Blog

Including the scope of the product and the definitions of key terms removes ambiguity and there eliminates room for the client to add features. When writing requirements, consider how the product will interface with the user, necessary databases, and more.

Asana Blog

Functional Requirements should be more than enumeration, but should include the intended business logic to execute on said functional requirement. Nonfunctional Requirements clarify the details of how Functional Requirements are implemented and any security and capacity requirements.

Include diagrams and visuals in SRS's while maintaining as concise and unvague language as possible

Examples

https://www.cse.msu.edu/~cse435/Handouts/SRSExample-webapp.doc https://www.utdallas.edu/~chung/RE/Presentations07S/Team_1_Doc/Documents/SRS4.0.doc https://krazytech.com/projects/sample-software-requirements-specificationsrs-report-airline-database

bnsn-dp commented 4 weeks ago

Notes on Structure

  1. Headings are numbered hierarchically
  2. Requirements are noted through use cases, which are formatted in tables with the following fields:
    1. Use Case Name
    2. External Reference (XRef) to another heading in the SRS
    3. Trigger, or the action that the user takes to start the use case
    4. Precondition, or the state that the app must be in for the trigger to be possible or valid
    5. Basic Path, a step-by-step breakdown of the use case from the user's perspective
    6. Alternate Path to cover any deviations at any of the steps along the Basic Path including missing data
    7. Postcondition, what occurs or what is now true of the system after execution
    8. Exception Paths, ways for the user to abort the use case prematurely
    9. Other, for any useful information that's not covered above
  3. Databases should have their structure depicted
  4. Requirements can include sentences before the table described above