Jaka jest różnica między wymogiem niefunkcjonalnym a atrybutem jakości?

Próbuję zrozumieć różnicę między niefunkcjonalnymi wymaganiami a atrybutami jakości. Czy to to samo?

Zestaw atrybutów jakości można znaleźć w standardzie ISO9126.

Wiem, że każdy system jest zdefiniowany przez zestaw wymagań funkcjonalnych i każde z tych wymagań ma jeden lub więcej atrybutów jakości. Załóżmy na przykład, że masz wymaganie opisujące funkcję logowania do systemu. Z tym wymogiem można powiązać atrybuty bezpieczeństwa i wydajności.

Jeśli powiem, że system nie może odpowiedzieć dłużej niż 1 sekundę, mówię o ograniczeniu.

Gdzie zatem pojawia się koncepcja wymagań niefunkcjonalnych? Czy są zdefiniowane przez użytkowników? Jak mogę je zidentyfikować?

Myślę, że myślisz o tym trochę za mocno. Wymagania funkcjonalne i niefunkcjonalne nie są tak rozdzielne, jak sugerujesz, Weźmy na przykład przypadek logowania.

Użytkownik MUSI mieć możliwość zalogowania się przez interfejs sieciowy. Technicznie jest to wymóg funkcjonalny.

System MUSI odpowiedzieć na żądania logowania w ciągu 1 sekundy. Technicznie jest to wymóg niefunkcjonalny.

Tak czy inaczej, oba są równie ważne niezależnie od konkretnej klasyfikacji.

Wymagania mogą pochodzić z dowolnej liczby miejsc. Możesz chcieć mieć lepszą wydajność niż konkurent. Klient może mieć określone potrzeby. Może wystąpić prośba od marketingu lub sprzedaży. Nie ma jednego miejsca, z którego pochodzą. Chociaż prawdopodobnie możesz wyodrębnić wszystkie różne źródła i nazwać je klientami. Ostatecznie tacy są.

Różnicę można zidentyfikować, korzystając z następujących danych. Wymagania funkcjonalne opisują, co zrobi system. Wymaganie niefunkcjonalne określa, jak to robi.

Zasada jest prosta i jasna.

Wymagania funkcjonalne są tym, co robi system .

Wymagania niefunkcjonalne to atrybuty jakości lub aspekty projektowania, budowy i wdrażania systemu.

• Wydajność (1 sekunda)
• Konserwowalność
• Zdolność adaptacji
• Koszt
• bezpieczeństwo
• użyteczność (która jest własnością całego systemu)
• testowalność
• skalowalność

Przeczytaj to. To bardzo jasne. http://en.wikipedia.org/wiki/Non-functional_requirement

Wymagania niefunkcjonalne pokazują się w taki sam sposób, jak wymagania funkcjonalne. Użytkownicy Kontekst, w którym system zostanie wdrożony. Wiele miejsc. Zarządzanie. Inne organizacje. Administratorzy sieci, administratorzy systemów, administratorzy baz danych. Każdy, kto jest interesariuszem lub tylko osobą postronną, wniesie niefunkcjonalne wymagania.

Patrząc na „dokumenty wymagań” w ciągu ostatnich 30 lat, mogę to powiedzieć. Wiele dokumentów wymagań napisanych przez duże, wewnętrzne organizacje IT są deklaracjami politycznymi z około 80% wymagań niefunkcjonalnych i mniej niż 20% wymagań funkcjonalnych.

Przeczytałem taki, który miał jedno zdanie, które było wymogiem funkcjonalnym. Pozostała część 30-stronicowego dokumentu mówiła o platformie, wsparciu, kopiach zapasowych i przywracaniu, systemach operacyjnych i bazach danych, standardach i operacjach oraz wielu innych rzeczach, których system nie zrobił .

Wymagania niefunkcjonalne i atrybuty jakości są takie same

Idea zmiany nazwy w ostatnim czasie polega na tym, że tak zwane wymagania niefunkcjonalne to tak naprawdę funkcjonalność systemu (lub zestaw funkcji systemu), która ma przekrojowy wpływ na system. Oznacza to, że wpływ przekrojowy, jaki tego rodzaju „specjalna funkcjonalność” ma w systemie, czyni go atrybutem jakości tego systemu. Jako przykład:

System z 5 komponentami musi przetworzyć żądanie w 10ms. Jeśli jeden element ma defekt zajmujący 5 ms, aby wziąć udział w przetwarzaniu, wpłynie to na wydajność systemu jako całości.

Podobnie jak bezpieczeństwo nie polega wyłącznie na logowaniu, a jego wpływ wpływa na cały system.

Podsumowując, atrybuty jakości (tj. Wymagania niefunkcjonalne) dotyczą funkcjonalności, sposobu implementacji oraz wpływu tej implementacji na systemy. Zazwyczaj różnica w stosunku do „normalnych wymagań” polega na wpływie, zasięgu i widoczności.

Oto interesujący link do ich identyfikacji w uporządkowany sposób:

• „Quality Attribute Workshop”, SEI, 2003

I książka o tym, jak je udokumentować i poprawnie zdefiniować:

• „Architektoniczne oprogramowanie Intensywne systemy: przewodnik dla praktyków”, Anthony J. Lattanze, 2008