Wymagania projektu – Collect Requirements Process

Aby skutecznie zdefiniować zakres projektu, kluczowe jest zebranie wymagań od wszystkich zaangażowanych interesariuszy. Jest to istotne, ponieważ pominięcie wymagania interesariusza może prowadzić do poważnych wyzwań, gdy projekt już się rozpocznie. Jeśli wymaganie zostanie przeoczone i projekt ruszy bez jego uwzględnienia, możemy zostać zmuszeni do powtarzania pracy lub, w niektórych przypadkach, do wstrzymania projektu.

Na przykład, rozważmy projekt tworzenia strony internetowej, gdzie klient określa, że strona główna musi ładować się w mniej niż dwie sekundy. Jeśli rozpoczniemy projekt, nie biorąc pod uwagę tego wymagania, możemy napotkać problemy w późniejszym etapie, co może prowadzić do dodatkowej pracy, opóźnień czasowych i przekroczenia budżetu.

Głównym celem procesu Collect Requirements  jest zgromadzenie potrzeb i oczekiwań wszystkich interesariuszy projektu. Ważne jest podkreślenie, że nie obejmuje to tylko wymagań klienta, ale również sponsora, organizacji i innych stron związanych z projektem. Wymagania te mogą wynikać z potrzeb jakościowych, wymogów zgodności z procedurami biura zarządzania projektami lub innych wymagań organizacyjnych.

Jak już omawialiśmy wcześniej, wymagania ogólne są zawarte w karcie projektu. W tym procesie uszczegóławiamy te wymagania, obejmując zarówno produkty końcowe, jak i dostarczane wyniki projektu.

Oprócz identyfikowania wymagań, dokumentujemy je i zarządzamy nimi na wszystkich etapach procesu. W skrócie, nasze główne działania polegają na określaniu, dokumentowaniu i zarządzaniu wymaganiami interesariuszy.

Możesz się zastanawiać, czy musimy uwzględniać wszystkie wymagania. Które z wymagań powinny zostać odrzucone? Ważne jest, aby ocenić, czy wymagania są zgodne z celami projektu i uzasadnieniem biznesowym zdefiniowanym w karcie projektu.

Odpowiedź jest prosta: nie powinniśmy uwzględniać wymagań, które nie wspierają celów projektu ani nie są zgodne z uzasadnieniem biznesowym.

Wymagania muszą być sformułowane w sposób jasny, aby wszyscy zaangażowani rozumieli je w ten sam sposób. Dlatego musimy stosować zwięzłe, ale skuteczne opisy, upewniając się, że są one mierzalne, aby umożliwić ich śledzenie i walidację.

Ponadto wymagania powinny być logiczne i spójne, nie mogą być sprzeczne z innymi wymaganiami projektowymi. Wymagania muszą również odnosić się bezpośrednio do produktu końcowego i celów projektu — nieistotne wymagania mogą wprowadzać zamieszanie i marnować zasoby.

Jasno zdefiniowane wymagania ułatwiają zarządzanie, co jest kluczowe dla sukcesu projektu. Jeśli nie będziemy skutecznie zarządzać wymaganiami, ryzykujemy dostarczenie wyników, które nie spełniają oczekiwań, co może prowadzić do opóźnień i wzrostu kosztów. Może to również skutkować niezadowoleniem klienta.

Aby zapewnić skuteczne zarządzanie wymaganiami, zazwyczaj wyznaczamy jedną osobę odpowiedzialną za ten aspekt — może to być właściciel produktu, inżynier wartości lub inna rola. Jako kierownicy projektów musimy również upewnić się, że cele projektu są spełnione.

W wyniku tego procesu tworzymy dwa kluczowe dokumenty: dokument wymagań oraz matrycę śledzenia wymagań.

Zacznijmy od dokumentu wymagań. Po zebraniu wszystkich wymagań, kluczowe jest ich dokładne udokumentowanie, aby zapobiec przeoczeniu jakiegokolwiek z nich, szczególnie w przypadku dużych projektów.

Nawet w mniejszych projektach dokumentacja jest niezbędna. Bez względu na wielkość projektu, tworzymy dokument wymagań, aby zapewnić jasność i wspólne zrozumienie.

Opisy wymagań muszą być wystarczająco szczegółowe, aby były zrozumiałe dla wszystkich. W trakcie projektu będziemy weryfikować wykonane prace w odniesieniu do tych wymagań, aby potwierdzić, że potrzeby interesariuszy są spełniane.

Wymagania muszą być również mierzalne, aby można było ocenić, czy zostały spełnione. Jeśli wymaganie nie jest mierzalne, jak możemy stwierdzić, że zostało spełnione?

Aby to ułatwić, każde wymaganie musi mieć zdefiniowane kryteria akceptacji. Zrozumienie, w jaki sposób te wymagania będą walidowane, jest kluczem do sukcesu projektu. Jeśli wyniki projektu spełnią te wymagania, wzrasta prawdopodobieństwo sukcesu całego projektu.

Należy jednak zauważyć, że w tym procesie nie przeprowadzamy weryfikacji — definiujemy jedynie kryteria akceptacji, które będą walidowane w późniejszych procesach.

Teraz omówmy matrycę śledzenia wymagań, która jest kluczowa dla zrozumienia i może pojawić się w pytaniach egzaminacyjnych. Matryca ta pomaga nam śledzić wymagania na każdym etapie cyklu życia projektu.

Matryca zawiera wszystkie wymagania i śledzi je aż do momentu spełnienia zdefiniowanych kryteriów akceptacji. Obejmuje takie elementy jak potrzeba biznesowa i strategia testowania, umożliwiając nam śledzenie wymagań, jednocześnie łącząc je z celami projektu.

Matryca ta również wskazuje, kto jest odpowiedzialny za każde wymaganie, jego źródło oraz aktualny status, dostarczając kontekstu, dlaczego każde wymaganie jest istotne.

Podsumowując, matryca śledzenia wymagań jest kluczowym narzędziem do śledzenia wymagań i łączenia ich z potrzebami projektu. Zawiera informacje na temat źródła, statusu i odpowiedzialności za każde wymaganie.

To effectively define the project scope, it’s essential to gather the requirements from all stakeholders involved. This is crucial because overlooking a stakeholder’s requirement can lead to significant challenges once the project is underway. If a requirement is missed and the project begins without addressing it, we may find ourselves needing to redo work or, in some cases, halt the project entirely.

For instance, consider a website development project where the client specifies that the homepage must load in under two seconds. If we initiate the project without factoring in this requirement, we might encounter problems later on. This could lead to additional work, resulting in both time and financial overruns.

The primary goal of the Collect Requirements Process is to compile the needs and expectations of all project stakeholders. It’s important to stress that this includes not just the customer’s requirements but also those of the sponsor, the organization, and any other relevant parties. These requirements might arise from quality considerations, compliance with project management office procedures, or other organizational mandates.

As we discussed previously, high-level requirements are outlined in the project charter. In this process, we will detail these requirements further, encompassing both the project’s deliverables and the final product.

Beyond simply identifying requirements, we also document and manage them throughout this process. To summarize, our main activities involve determining, documenting, and managing stakeholder requirements.

Now, you might wonder if we need to consider all requirements. Specifically, which requirements should be excluded? It’s important to evaluate whether the requirements align with the project’s objectives and business case as defined in the project charter.

The answer is clear: we should not consider requirements that do not support the project’s goals or do not meet the business case.

Requirements must be articulated clearly enough that everyone involved understands them in the same way. Therefore, we need concise yet effective descriptions, ensuring they are measurable to facilitate tracking and validation.

Furthermore, requirements should be logical and coherent, avoiding any contradictions with other project requirements. Finally, they must relate directly to the end product and overall project objectives; irrelevant requirements can create confusion and inefficiencies.

Clearly defined requirements simplify management, which is vital for project success. If we fail to manage requirements effectively, we risk delivering outcomes that do not meet expectations, potentially leading to project delays and increased costs. This could also result in customer dissatisfaction.

To ensure effective management of requirements, we typically designate one individual to oversee this aspect, whether it’s a product owner, value engineer, or another role. As project managers, we must also ensure that the project’s objectives are met.

As a result of this process, we produce two key documents: the requirements document and the requirements traceability matrix.

Let’s start with the requirements document. After collecting all requirements, it’s essential to document them thoroughly to prevent overlooking any amidst the numerous requirements, especially in large projects.

Even for smaller projects, documentation is crucial. Regardless of project size, we create a requirements document to ensure clarity and shared understanding.

All requirement descriptions must be detailed enough for clear comprehension. Throughout the project, we will validate the work against these requirements to confirm that stakeholder needs are being met.

Requirements should also be measurable, providing criteria for assessment. If a requirement isn’t measurable, how can we determine if it’s been satisfied?

To facilitate this, each requirement must have defined acceptance criteria. Understanding how these requirements will be validated is key to the project’s success. If the project outputs meet these requirements, the likelihood of overall project success increases.

It’s important to note that we do not conduct verification in this process; we merely define acceptance criteria, which will be validated in subsequent processes.

Now, let’s discuss the requirements traceability matrix, which is vital for your understanding and may appear in exam questions. This matrix helps us track requirements throughout the project lifecycle.

The matrix lists all requirements and follows them until they meet the defined acceptance criteria. It includes headings like business need and test strategy, allowing us to track requirements while linking them to project objectives.

This matrix also indicates who is responsible for each requirement, its source, and its current status, providing context for why each requirement is essential.

To summarize, the requirements traceability matrix is a crucial tool for tracking requirements and linking them to project needs. It includes information about the source, status, and responsibility for each requirement.