myUserNameIsThis

5.Sotware Requirements Specification

Apr 20th, 2016
395
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 2.89 KB | None | 0 0
  1. Software Requirements Specification
  2.  
  3. Software requirements specification (SRS) is a description of a software system to be developed, laying out functional and non-functional requirements, and may include a set of use cases that describe interactions the user will have with the software
  4.  
  5. Waterfall проект – спецификациите се променят рядко; прави се по-дълго време и обикновено резултира в доставяне на продукта наведнъж
  6. Agile проект – спецификациите се променят често; продукта се доставя на „хапки“; работния процес е итеративен
  7.  
  8. QA-ите трябва да направят така, че изискванията, описани в SRS-ите, да бъдат максимално разбираеми, за да не стават недоразумения и затруднения за тези, които ги четат (developer-ите)
  9. Много често изискванията се променят (например след срещи с клиентите)
  10.  
  11. Много често се случва клиентите да не знаят какво искат
  12.  
  13. Спецификацията трябва да е написана така, че да не създава двусмилици, за да не се получава, различни хора да интерпретират прочетеното по различни начини
  14.  
  15. Дефинират се различни роли (например администратор, клиент, editor и др.) и на базата на тези роли се съставят use case-ове
  16. Use cases:
  17. - List of interaction steps
  18. - Define relation between an actor and a system
  19. - Usually satisfying a goal
  20. - Actors are able to take decisions
  21. - Can be:
  22. o modeled via UML
  23. o flat text documents
  24.  
  25. Един SRS трябва:
  26. - това какво обхваща документа да е описано по достатъчно разбираем начин за всички
  27. - да има съдържание, чрез което да навигираме по документа
  28. - лесно да може да се разграничават първите по важност случаи, от вторите, третите и т.н. по важност случаи
  29. - да съдържа link-ове, които сочат към различните feature-и
  30.  
  31. SRS review is going through the document and trying to understand what the target application is going to be like
  32.  
  33. The review results in:
  34. - test scenarios list
  35. - found errors by statically going through the document
  36. - questions for better understanding
  37. - preliminary idea of the test environment
  38. - test scope identification
  39. - how many test cases will end up having
Add Comment
Please, Sign In to add comment