Wymagania programowe

Wymagania programowe są opisem cech i funkcjonalności systemu docelowego. Wymagania przekazują oczekiwania użytkowników wobec produktu programowego. Wymagania mogą być oczywiste lub ukryte, znane lub nieznane, oczekiwane lub nieoczekiwane z punktu widzenia klienta.

Inżynieria Wymagań

Proces zbierania wymagań na oprogramowanie od klienta, analizowania i dokumentowania ich jest znany jako inżynieria wymagań.

Celem inżynierii wymagań jest opracowanie i utrzymanie wyrafinowanego i opisowego dokumentu 'Specyfikacja Wymagań Systemowych’.

Proces Inżynierii Wymagań

Jest to czteroetapowy proces,

• Studium wykonalności
• Zbieranie wymagań
• Specyfikacja wymagań programowych
• Walidacja wymagań programowych

Zobaczmy pokrótce ten proces –

Studium wykonalności

Kiedy klient zwraca się do organizacji w celu uzyskania pożądanego produktu, pojawia się z grubsza pomysł, jakie wszystkie funkcje musi spełniać oprogramowanie i jakich cech oczekuje się od niego.

Referencing do tych informacji, analitycy robi szczegółowe badania na temat tego, czy pożądany system i jego funkcjonalność są wykonalne do opracowania.

To studium wykonalności jest ukierunkowane na cel organizacji. Badanie to analizuje, czy produkt oprogramowania może być praktycznie zmaterializowane w zakresie realizacji, wkład projektu do organizacji, ograniczenia kosztów i jak na wartości i cele organizacji. Bada techniczne aspekty projektu i produktu, takie jak użyteczność, łatwość utrzymania, produktywność i zdolność integracji.

Wynikiem tej fazy powinien być raport studium wykonalności, który powinien zawierać odpowiednie komentarze i zalecenia dla kierownictwa, czy projekt powinien być podjęty, czy nie.

Gromadzenie wymagań

Jeśli raport wykonalności jest pozytywny w kierunku podjęcia projektu, następna faza zaczyna się od zbierania wymagań od użytkownika. Analitycy i inżynierowie komunikują się z klientem i użytkownikami końcowymi, aby poznać ich pomysły na to, co oprogramowanie powinno zapewniać i jakie funkcje chcą, aby zawierało.

Specyfikacja Wymagań Oprogramowania

SRS jest dokumentem tworzonym przez analityka systemowego po zebraniu wymagań od różnych interesariuszy.

Specyfikacja wymagań definiuje, w jaki sposób zamierzone oprogramowanie będzie współdziałać ze sprzętem, interfejsami zewnętrznymi, szybkością działania, czasem odpowiedzi systemu, przenośnością oprogramowania na różne platformy, łatwością utrzymania, szybkością odzyskiwania danych po awarii, bezpieczeństwem, jakością, ograniczeniami itd.

Wymagania otrzymane od klienta są napisane w języku naturalnym. Obowiązkiem analityka systemowego jest udokumentowanie wymagań w języku technicznym tak, aby mogły być zrozumiane i użyteczne przez zespół programistów.

SRS powinien posiadać następujące cechy:

• Wymagania użytkownika są wyrażone w języku naturalnym.
• Wymagania techniczne są wyrażone w języku strukturalnym, który jest używany wewnątrz organizacji.
• Opis projektu powinien być napisany w Pseudokodzie.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions –

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

• Zbieranie wymagań – Programiści rozmawiają z klientem i użytkownikami końcowymi, aby poznać ich oczekiwania względem oprogramowania.
• Organizowanie wymagań – Deweloperzy priorytetyzują i układają wymagania w kolejności ważności, pilności i wygody.

• Negocjacje & dyskusja – Jeśli wymagania są niejednoznaczne lub istnieją pewne konflikty w wymaganiach różnych interesariuszy, jeśli są, jest to następnie negocjowane i dyskutowane z interesariuszami. Wymagania mogą być wtedy uszeregowane pod względem ważności i rozsądnie skompromitowane.

  Wymagania pochodzą od różnych interesariuszy. Aby usunąć niejednoznaczność i konflikty, są one dyskutowane pod kątem jasności i poprawności. Nierealistyczne wymagania są rozsądnie kompromisowe.

• Dokumentacja – Wszystkie formalne & nieformalne, funkcjonalne i niefunkcjonalne wymagania są dokumentowane i udostępniane do przetwarzania w następnej fazie.

Techniki pozyskiwania wymagań

Elicytacja wymagań jest procesem mającym na celu poznanie wymagań dla zamierzonego systemu oprogramowania poprzez komunikację z klientem, użytkownikami końcowymi, użytkownikami systemu i innymi, którzy mają udział w rozwoju systemu oprogramowania.

Istnieją różne sposoby odkrywania wymagań

Wywiady

Wywiady są silnym medium do zbierania wymagań. Organizacja może przeprowadzić kilka rodzajów wywiadów, takich jak:

• Wywiady ustrukturyzowane (zamknięte), gdzie każda pojedyncza informacja do zebrania jest ustalona z góry, mocno trzymają się schematu i materii dyskusji.
• Wywiady nieustrukturyzowane (otwarte), gdzie informacja do zebrania nie jest ustalona z góry, bardziej elastyczne i mniej stronnicze.
• Wywiady ustne
• Wywiady pisemne
• Wywiady jeden-na-jeden, które odbywają się między dwiema osobami po drugiej stronie stołu.
• Wywiady grupowe, które odbywają się między grupami uczestników. Pomagają one odkryć wszelkie brakujące wymagania, ponieważ zaangażowanych jest wiele osób.

Badania

Organizacja może przeprowadzić badania wśród różnych interesariuszy, pytając o ich oczekiwania i wymagania od nadchodzącego systemu.

Kwestionariusze

Dokument z predefiniowanym zestawem obiektywnych pytań i odpowiednich opcji jest przekazywany wszystkim interesariuszom do udzielenia odpowiedzi, które są zbierane i kompilowane.

Wadą tej techniki jest to, że jeśli opcja dla jakiejś kwestii nie jest wymieniona w kwestionariuszu, kwestia ta może pozostać bez uwagi.

Analiza zadań

Zespół inżynierów i programistów może przeanalizować operację, do której wymagany jest nowy system. Jeśli klient posiada już jakieś oprogramowanie do wykonania określonej operacji, jest ono badane i zbierane są wymagania dla proponowanego systemu.

Analiza domeny

Każde oprogramowanie należy do jakiejś kategorii domenowej. Osoby będące ekspertami w danej dziedzinie mogą być bardzo pomocne w analizie ogólnych i specyficznych wymagań.

Burza mózgów

Nieformalna debata odbywa się wśród różnych interesariuszy, a wszystkie ich wkłady są rejestrowane w celu dalszej analizy wymagań.

Prototypowanie

Prototypowanie to budowanie interfejsu użytkownika bez dodawania szczegółowych funkcjonalności dla użytkownika w celu interpretacji cech zamierzonego produktu oprogramowania. Pozwala to na lepsze zrozumienie wymagań. Jeśli u klienta nie ma zainstalowanego oprogramowania, do którego mógłby się odwołać programista, a klient nie zna swoich wymagań, programista tworzy prototyp na podstawie wstępnie wymienionych wymagań. Prototyp jest pokazywany klientowi, a informacja zwrotna jest odnotowywana. Informacje zwrotne od klienta służą jako dane wejściowe do zbierania wymagań.

Obserwacja

Zespół ekspertów odwiedza organizację lub miejsce pracy klienta. Obserwują rzeczywiste działanie istniejących, zainstalowanych systemów. Obserwują przepływ pracy po stronie klienta i sposób rozwiązywania problemów wykonawczych. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

Powszechnie wymagania programowe powinny być skategoryzowane w dwóch kategoriach:

Wymagania funkcjonalne

Wymagania, które są związane z funkcjonalnym aspektem oprogramowania należą do tej kategorii.

Definiują one funkcje i funkcjonalność wewnątrz i z systemu oprogramowania.

Przykłady –

• Opcja wyszukiwania dana użytkownikowi do wyszukiwania spośród różnych faktur.
• Użytkownik powinien mieć możliwość wysłania dowolnego raportu do zarządu.
• Użytkownicy mogą być podzieleni na grupy, a grupy mogą mieć oddzielne prawa.
• Powinien być zgodny z regułami biznesowymi i funkcjami administracyjnymi.
• Oprogramowanie jest rozwijane z zachowaniem kompatybilności w dół.

Wymagania niefunkcjonalne

Wymagania, które nie są związane z funkcjonalnym aspektem oprogramowania, należą do tej kategorii. Są to domyślne lub oczekiwane cechy oprogramowania, które użytkownicy zakładają.

Wymagania niefunkcjonalne obejmują.

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, 'Must have’ must be implemented, 'Should have’ is a matter of debate with stakeholders and negation, whereas 'could have’ and 'wish list’ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is –

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below –

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Zapewnienie informacji pomocy
• Podejście skoncentrowane na użytkowniku
• Ustawienia widoku oparte na grupach.

Analityk systemowy

Analityk systemowy w organizacji IT jest osobą, która analizuje wymagania proponowanego systemu i zapewnia, że wymagania są opracowane i udokumentowane prawidłowo & prawidłowo. Rola analityka rozpoczyna się w fazie Analizy Oprogramowania w SDLC. Do obowiązków analityka należy upewnienie się, że tworzone oprogramowanie spełnia wymagania klienta.

Analitycy systemowi mają następujące obowiązki:

• Analiza i zrozumienie wymagań dotyczących planowanego oprogramowania
• Zrozumienie, w jaki sposób projekt przyczyni się do realizacji celów organizacji
• Identyfikacja źródeł wymagań
• Weryfikacja wymagań
• Opracowanie i wdrożenie planu zarządzania wymaganiami
• Dokumentacja wymagań biznesowych, technicznych, Koordynacja z klientami w celu nadania priorytetu wymaganiom i usunięcia niejednoznaczności
• Finalizacja kryteriów akceptacji z klientem i innymi interesariuszami

Mierniki i metryki oprogramowania

Mierniki oprogramowania mogą być rozumiane jako proces kwantyfikacji i symbolizacji różnych atrybutów i aspektów oprogramowania.

Mierniki oprogramowania dostarczają miar dla różnych aspektów procesu oprogramowania i produktu oprogramowania.

Mierniki oprogramowania są podstawowym wymogiem inżynierii oprogramowania. Nie tylko pomagają kontrolować proces tworzenia oprogramowania, ale także pomagają utrzymać jakość produktu końcowego na doskonałym poziomie.

Według Toma DeMarco, a (Software Engineer), „Nie możesz kontrolować tego, czego nie możesz zmierzyć.” Przez jego powiedzenie, jest bardzo jasne, jak ważne są miary oprogramowania.

Zobaczmy kilka metryk oprogramowania:

• Metryki wielkości – LOC (Lines of Code), najczęściej obliczane w tysiącach dostarczonych linii kodu źródłowego, oznaczane jako KLOC.

  Liczba punktów funkcyjnych jest miarą funkcjonalności dostarczanej przez oprogramowanie. Liczba punktów funkcyjnych definiuje wielkość funkcjonalnego aspektu oprogramowania.

• Metryka złożoności – Złożoność cyklomatyczna McCabe’a określa górną granicę liczby niezależnych ścieżek w programie, co jest postrzegane jako złożoność programu lub jego modułów. Jest ona reprezentowana w kategoriach teorii grafów przy użyciu grafu przepływu sterowania.

• Mierniki jakości – Defekty, ich rodzaje i przyczyny, konsekwencje, intensywność nasilenia i ich implikacje definiują jakość produktu.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics – In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics – Effort, time and various resources used, represents metrics for resource measurement.