Tag: krav

Som verksamhetsanalytiker arbetar jag ofta med “fyrfältare” dvs jag grupperar saker utifrån två olika dimensioner. En klassisk fyrfältare vid kravarbetet är att kategorisera kraven utifrån realiseringsarbetet i enkelt-svårt, och utifrån verksamhetsnyttan i hög-låg nytta för verksamheten. När alla kraven är inplacerade i matrisen så är sedan det vanliga resonemanget att man bör börja med enkla saker […]

The post Prioritera utifrån verksamhetsnytta appeared first on Kravanalys.se.

Innehåll

Att skära ut en tårtbit ur ett epos Jag skrev tidigare om stora och små användarberättelser, eller epos (epics) och vad som utmärker bra användarberättelser. Det är ok med ett epos i produktens backlogg, men allt eftersom vi vi närmar oss utvecklingen så måste alla epos brytas ned till bra berättelser. Varför det kan […]

The post Att skära tårtbitar ur epos appeared first on Kravanalys.se.

Charles Babbage uppfann den första datorn i början på 1800-talet, men kanske dröjde det ända tills 1936 innan vi upptäckte svårigheten med att specificera krav. Då presenterade nämligen Konrad Zuse den första datorn som på allvar var programmerbar, Z1. Eller var det 1954 när Fortran, det första framgångsrika högnivåspråket lanserades? Hur som helst att speca […]

The post Är kravhantering verkligen svårt? appeared first on Kravanalys.se.

Jag lade just upp en kort presentation på slideshare om 10 vanliga missförstånd kring användningsfall. Kolla gärna in den!
I enterprise architect finns det stöd för att definiera ett kravs tillstånd. De fördefinierade tillstånden är; approved, implemented, mandatory, proposed och validated. Om man inte tycker dessa passar det egna arbetssättet så kan man enkelt ändra dessa till något eget. … Continue reading
Idag var vår första ”gör vad du vill förutom att arbeta -dag ”.  Konceptet var enkelt, alla skulle samlas på kontoret och vara där hela dagen, ingen ”fick” arbeta med sina uppdrag. Istället skulle man göra något roligt,  något som … Continue reading
Att arbeta agilt med krav har ingenting med vilken ”mall” man använder för att dokumentera kraven, utan beror på förhållningssättet man har till kraven. Oavsett om man arbetar med user stories eller användningsfall är nedanstående process att rekommendera. Ta reda … Continue reading
Vad betyder egentligen pilhuvudet på associationen mellan aktör och användningsfall i UMLs användningsfallsdiagram. Nedan är klippt från UML Superstructure 2.3, sid 18. 6.4.2 Diagram format The following conventions are adopted for all metamodel diagrams throughout this specification: • An association … Continue reading
En artikel om att knyta ihop user stories med mer tekniska systembeskrivningar.  En user story har formatet; Som X vill jag Y för att Z. Systembeskrivningen kan ha formatet; Komponent A gör åtgärd B.C.D genom att E.F När G inträffar. … Continue reading