[alg] Requirement identification and storage

[Verwijderd]

Ik vroeg me af hoe iedereen hier concreet zijn lijsten met requirements opslaat?

Maken jullie gewoon een lange lijst met nummertjes voor elke requirement, maken jullie een document aan met secties en subsecties en delen daar telkens elke requirement in onder, of doen jullie het in een DB met per requirements een aantal attributen zoals omschrijving, datum ingevoerd, datum veranderd, motivatie, onderdeel, subonderdeel, persoon, etc etc..

Zijn er eigenlijk mensen die speciale requirements management software gebruiken zoals bv Rational RequisitePro?

[Icheb]

Hier wordt er gebruik gemaakt van een PHP script met database module, dit is vanuit de interface uit te breiden met extra kolommen etc. Daarnaast worden er complete logs bijgehouden.
Als laatste is er ook een pdf export (fpdf lib), welke een index geeft en daarna eis voor eis alles laat zien (met 1 eis per pagina).

Ik ken RequisitePro niet, maar ik moet zeggen dat het PHP script voor de meeste dingen voldoende is hier.

[Verwijderd]

Ik denk dat er weinig mensen zijn die echt aan requirements engineering doen.

Gewoon een beetje de todo's afspreken en dan meteen gaan designen of programmeren, dat is toch wat de meeste hier doen denk ik.

Afspraken met de klant worden natuurlijk wel goed vastgelegd (zie verschillende andere threads hier), maar dat is dan meteen ook het punt: veel mensen zien requirements alleen als afspraken met de klant goed vastleggen. Echte requirements engineering is een nogal professioneel proces, waar je veelal een gespecialiseerde persoon voor hebt in een groter team.

Denk dat aan dingen als categoriseren van requirements. Dit klinkt makkelijk, maar is redelijk pittig. Denk alleen maar aan het bedenken van een set goede en sluitende categorieen voor een produkt. Dan heb je nog dingen als change tracking, maar ook de analyse van de requirements, etc etc...

[MSalters]

hangt van het project af. Voor een GUI tooltje van een paar K is een .txt file genoeg. Bij een opdracht vanaf zeg een ton gaan we zeker formeel met requirements om, en bij een miljoen of zo ( minder voor kritische projecten) gaan we nadenken over RequisitePro. In die laatste categorie zitten natuurlijk niet veel opdrachten, maar toch best wel veel omzet.

[Verwijderd]

In mijn geval gaat het om een on-line applicatie die de core business van het bedrijf is. We schatten er ongeveer een jaar mee bezig te zijn. Een deel van de requirements kunnen we meenemen omdat we al een applicatie hebben draaien voor onze core business, alleen deze is slecht gestructureerd en destijds zonder design opgezet (zodat het nu op een aantal punten een dood spoor is geworden kwa uitbreidbaarheid).

Anyway, we willen het nu goed doen, maar kwa opstellen en indelen van requirements is er hier ook niet super veel ervaring. Ik heb zelf wel WO informatica gedaan, maar niet echt de specialisatie van software engineering gedaan. Ik heb de SE onderwerpen dus licht aangeraakt, maar nooit echt in vediept.

Waar we nu het meest mee zitten is het indelen van de requirements. We hebben nu een hoofdcatergorie "general" met subcategorieen als "subscribe" ,"login", "user profile", "rights", etc... en dan nog een aantal andere hoofdcategorieen die voornamelijk per soort user zijn: "anonymous user", "system admin" etc. Of dit de beste categorieen zijn, en of andere het ook zo doen weten we eigenlijk niet.

Per requirement zetten we nu eigenlijk weinig neer, alleen de tekst (+-2 zinnen). Ik vroeg me af of het niet beter kan, met meer velden per requirement.

Het opslaan van de requirements gebeurd nu in een document (LaTeX).

[Orphix]

Zelf schrijf ik altijd, ook voor relatief kleine projecten, een document met daarin de requirements. Inderdaad niet altijd even formeel met pre-condition, post-conditions, etc. Dit soort formaliteit komt de productiviteit niet echt ten goede vind ik. Ik probeer in een enkel document de requirements vanuit de klant en de technische requirements samen te vatten. Die documenten zijn nooit zeer groot, het belangrijkste is dat je overal een keer aan gedacht hebt. Dat je mentaal de hele applicatie afloopt. Ook al lijkt het soms veel werk, het moet toch een keer gebeuren, en anders gebeurt het wel halverwege je coding proces.

Je kan ook denken om een set met use-cases op te stellen. Dit is effectief in de zin dat de meeste mensen dit goed kunnen lezen (ook de klant), je bij elke usecase makkelijk na kan gaan of de huidige functionaliteit dit biedt. En het geeft een indiciatie van de grenzen van je applicatie. Afhankelijk van je ontwikkel methode kan je veel usecases omzetten in (handmatige of automatische) tests.

Ik gebruikte vooral Word hiervoor. Maar ik ben toevallig nu ook op zoek naar goede alternatieven. Belangrijkste reden is dat Word niet goed meewerkt met SVN. Je requirements in DocBook of LaTeX is al een veel betere keus omdat dit text-based is. Je kan de (requirement) changes bij elke revisie dus ook in de gaten houden. Helaas vind ik het intypen van DocBook (LaTeX geen ervaring mee) nog niet altijd even productief.

[joopst]

Het is in de praktijk vaak gebleken dat 1x goed de requirements opstellen vaak niet werkt. Dit komt omdat projecten die wat groter zijn (jouwe is ook een jaar) nogal tijdrovend zijn om helemaal uit te denken. En vaak worden er de hele tijd ook nieuwe 'handige' dingen bedacht die ervoor zorgen dat je requirements een beetje out-dated zijn.
Een paar handvaten voor je project die je misschien kan gebruiken staan wel op deze site.

Wat wel handig is om op te letten is dat je requirements hebt die altijd hetzelfde zullen zijn en onafhankelijk van wat je aan het maken bent. Denk hierbij aan inloggen, rechten, contentbeheer, loggen, errorhandling, etc .. Oplossingen voor dit soort problemen kan je vaak wel 'downloaden' of afkijken.
En je hebt requirements die een stuk meer verander-gevoelig zijn. Deze hebben vaak te maken met het precieze onderwerp waar je mee bezig bent. Deze laatste requirements zijn vaak de enige waar de opdrachtgever altijd een mening over heeft en die voor hem belangrijk zijn. (veel afstemmen dus)

Om requirements af te stemmen met de opdrachtgever maak ik vaak gebruik van plaatjes van hoe het wordt , deze maak ik dan in photoshop, frontpage, powerpoint of excel . Op deze manier kan je redelijk snel de belangrijkste zaken kortsluiten met de opdrachtgever. Met deze informatie kan je als je in kleine stappen programmeert rekening houden met evt zaken die er iig nog aankomen.

hopelijk heb je er wat aan,

success met je project!

[Verwijderd]

Ik vraag me af of er ondertussen al mensen zijn die gebruik maken van requirements management software en dan niet meteen RequisitePro gebruiken.

Als je RequisitePro alleen voor projecten van miljoenen gebruikt, wat gebruik je dan daaronder? Ik wil graag een lijst van requirements hebben waarop ik kan zoeken via attributen en waar per requirement een revision controll op zit. Eigenlijk de combinatie van een simpele DB en CVS.

Het klinkt zo eigenlijk best simpel om zoiets te maken, maar ik kan weinig (open source) requirements software vinden, anders dan RequisitePro. Heeft er iemand een tip voor een alternatief?

[Verwijderd]

*bump*

maar om toch een reactie te geven op de vraag van De-henkman. Ten eerste is RequisitePro niet alleen voor projecten van Miljoenen. Daarnaast zal je de vraag moeten stellen: wil ik gebruik maken van RM-tools? Wanneer we één ontwerper hebben en twee bouwers kun je idd ook heel goed uit de voeten met een Excel-sheet en een database. Misschien dat de levensverwachting, #verwachte wijziging van het te bouwen ook mee te nemen is in de afweging.

maar goed. mocht de keuze vallen op tooling dan is er meer dan (dure)IBM-tooling alleen. Er is bijvoorbeeld (dure) Borland-tooling (Caliber) en er is goedkope tooling (waar ik persoonlijk erg enthousiast over ben) van Sparxsystems: Enterprise architect. Je kunt een 30 dagen trail versie downloaden om te spelen en een licentie kost iets van 200 euro.

opensource RM-tools ken ik niet.