Software Requirements Specification (SRS) - Wymagania software vs testy jednostkowe

Witam,

Chciałem zadać kilka pytań doświadczonym developerom/inżynierom odnośnie wymagań software oraz unit testów.
Obecnie pracuję w międzynarodowym projekcie. Cały team składa się z 6 mniejszych teamów zlokalizowanych na różnych kontynentach.
Z doświadczenia zauważyłem, że co kraj(team) to inne podejście. W związku z tym chciałbym od was usłyszeć kilka odpowiedzi. Oto one:

1. Jak dokładne muszą być wymagania software zlokalizowane w SRS?
2. Kto jest winny za niski współczynnik pokrycia kodu? Developer czy tester?
3. Jakie wartości progowe z reguły przyjmuje się za odpowiednie? Wiem, że to zależy od klienta ale jak sami wiemy, 100% pokrycie nie odzwierciedla bezbłędnego kodu. Czasem jest wręcz nieosiągalne 100%, gdy mamy uniwersalny kod dla kilku projektów.
4. Czy SRS powinien opisywać wszystkie zewnętrzne interfejsy modułu?
5. Czy SRS powinien opisywać wszystkie funkcje lokalne dla modułu (wejścia, wyjścia dla 100% pokrycia)?

Ostatnie dwa pytania są dla mnie ważne. Czytając różne książki i fora internetowe odnoszę wrażenie, że opis powinien być ogólny.
Problem tkwi w tym, że testerzy proszą o nowe wymagania, które pokryją braki (pokrycie funkcji, decyzji, rozgałęzień). W takim wypadku, idąc ich tokiem myślenia, SRS powinien być bez mała jak design (opisany w funkcji każdy if, else, switch case, etc - mam na myśli wszystkie ścieżki). Czy tak faktycznie ma to wyglądać? Jeżeli SRS ma nie zawierać opisu od deski do deski każdej funkcji w module, to jak nazywa się dokument który do robi?

1. Tak dokładnie żeby nie było wątpliwości.
2. Dev bo przecież to on pisze testy jednostkowe.
3. Nie ma reguły ale im więcej tym lepiej. Nie dlatego że oznacza bezbłędny soft tylko dlatego że trudno pisać testy dla słabego kodu.
4. Jeśli wymaganiem jest komunikacja z zewnętrznym interfejsem to tak. Ale SRS nie opisuje JAK tylko CO system ma robić więc pojęcie modułu wydaje mi się tu zupełnie bez sensu.
5. Jw, SRS opisuje wymagania więc co system ma robić.

Dokument opisujący jak weryfikować spełnienie wymagań to Software Verification Test Specification a dokument opisujący zewnętrzne interfejsy to Interface Design Document.
Rzuć okiem na: ECSS-E-ST-40c wwwis.win.tue.nl/2R690/doc/ECSS-E-ST-40C(6March2009).pdf

W naszym projekcie testy jednostkowe przeprowadzane są na module stąd padło słowo moduł. Każdy moduł ma swój SRS, więc pisząc "powinien opisywać co robi system" raczej ma tutaj odzwierciedlenie "co robi moduł". Zaznaczam raz jeszcze to nie są testy integracyjne tylko modułowe.

Co do progu, ciężko pisać wymagania SRS do skomplikowanej funkcji, gdzie mamy do czynienia z dużą ilością If-else, switch-case etc. Jak to wtedy pogodzić? Odpuścić czy pocić się z tym dalej...

Odpowiedź na to pytanie nie jest jednoznaczna. W różnych gałęziach są różne specyfikacje. Przykładowo ISO26262 i/lub Automotive SPICE w motoryzacji, DO-178 w lotnictwie itp. itd.
Można spotkać prawdziwe piramidki samych typów wymagań (jedne ogólne, inne bardziej szczegółowe, polinkowane między sobą). Projekt powinien posiadać dokument, który opisuje właśnie to, co powinno się w danym typie requirementu znajdować i w jakim zakresie. Różne podejścia w ramach 1 projektu są niedopuszczalne.

Pisałem generalnie o softwarze "high reliable". Tam, gdzie nie wymagana się certyfikacji mogą być dowolne, a nawet w ogóle może ich nie być.

"Niskie pokrycie kodu" - to jest bolączka. Przynajmniej programistów, którzy muszą spełniać aspiracje managmentu, aby mieć jak największy słupek (kompleksy? :) ).
Pisanie unit testów, aby mieć wysoki "code coverage" jest bezsensowne, ponieważ współczynnik wykrycia błędu przy takim podejsciu jest bardzo niski. Dlatego według mnie uteki powinny być głównie pisane pod wymaganie a nie pod funkcje. Oczywiście można tu znowu wyróżnić utki testujące funkcjonalność i takie które testują tylko czy funkcja przewiduje wszysktie możliwości.