[ALG] Definitie van Eisen: indeling van het document

[Verwijderd]

Ik werk momenteel aan een document, Definitie van Eisen voor webapp X. Ik heb een ruwe schets klaar, in natuurlijke taal en onderverdeeld naar taak en/of weergave. Voorbeeld is een kop inloggen met daaronder een beschrijving van het proces. Andere voorbeelden zijn kopjes Overzichtsweergave en Detailweergave, bestellen en bijbehorende omschrijving.

Ik wil het nu reviseren naar een betere structuur omdat ik het gevoel heb dat dit niet de ideale indeling is. Ik vraag me af: Geef je elke eis een naam en nummer en een korte beschrijving? Hoe verdeel je ze logisch? Welke informatie is nog meer relevant, ik denk aan must/should/would/could have en zou dat dan ook een mogelijke hoofd-indeling zijn, of eerder een 'attribuut' van een eis?

Ik ben bijvoorbeeld wel eens iets op het spoor gekomen van een ISO standaardvoor dergelijke documenten, maar die kosten geld

[toost]

dit ligt ook aan de methode die je gebruikt voor je productontwikkeling, vaak zijn er per methode (zoals DSDM, RAD enz,) vaak vaste documentatie ontwikkelt. Een Definitie van eisen worden over het algemeen ingedeeld in functionele en niet functionele eisen.

Je moet wel goed het verschil houden tussen eisen en functionaliteiten!!!

Functionaliteiten onstaat uit de eisen en eisen kan je niet beschrijven als functionaliteiten, dus UML schema's, zoals voor de inlogfunctie waar je hebt over hebt, horen niet thuis in een definitie van eisen, maar wel in de definitie van functionaliteiten.

Deze eisen kunnen na dat ze beschreven zijn (en goedgekeurd door de opdrachtgever) uit gesplits worden in functionaliteiten en daarna ingepland worden, vaak gebeurd dit aan de hand van prioriteit, dus zoals jij al beschreef must,should,could,would oftwel MoSCoW methode. Hier aanvast gekoppeld zijn ook vaak timeboxen, wbs, gannt ed.

Maar als ik jou was zou ik eens gaan googlen op ontwikkel methode's, daar is genoeg informatie te vinden over documentatie


ps. Volgens mij zit je niet in de goeie topic, maar dat is iets voor de modjes.

[Verwijderd]

toost schreef op maandag 22 mei 2006 @ 14:21: Een Definitie van eisen worden over het algemeen ingedeeld in functionele en niet functionele eisen.

Ja dat heb ik ook gedaan, maar onder functionele eisen kan ook een onderverdeling, maar hoe weet ik dus niet. Vandaar dat ik daar tips over zoek.
Dit voorbeeld kwam ik tegen: https://docushare.gmu.edu...Document-19838/html#bmk32, dat is dus echt heel kort en bondig.

ps. Volgens mij zit je niet in de goeie topic, maar dat is iets voor de modjes.

Excuses, hoorde in Software Engineering & Architecture denk ik.

[ Voor 13% gewijzigd door Verwijderd op 22-05-2006 18:05 ]

[whoami]

Ik geloof ook dat dit eerder in SE&A thuishoort

-> SE&A

[toost]

Kan je nog eens vertellen wat jij onder "definitie van eisen" verstaat?

Als dit een document is waar de eisen gedefinieerd worden en niet meer dan zal dit geen groot document zijn.

Als je hier ook functie uitwerkingen gaat maken dan kan je dus gaan denken aan:

functie specificatie (doel, type functie, inhoud, verbanden, ed.)
MoSCoW (prioriteit)
Planning (timebox, wbs, gannt, ed.)
UML (usecases, class diagrams, dataflow ed.)
Schermen (schetsen, eerste ontwerp schermen)

Ik denk dat je hier wel een aardig eindje op weg kan.

Suc6

ps. je url voorbeeld is een class beschrijving een onderdeel van een UML class diagram

[ Voor 9% gewijzigd door toost op 22-05-2006 22:19 ]

[Verwijderd]

De link die ik gaf is een "Requirements Specification", ik linkte naar een kopje onder hoofdstuk 3.1.2 "Functional Requirements". Van de door jou genoemde zaken die ik op zou kunnen nemen, als ik dat allemaal deed zou het een document worden met planning, uml, GUI en functionele eisen, dat lijkt me toch niet de bedoeling?

--Edit--
Ik ga nu trouwens met use cases trachten het systeem te omschrijven. Door alle mogelijke use cases te documenteren verwacht ik dat ik tot een volledige definitie van eisen kom, alhoewel de eisen dan 'verstopt' zitten in use cases.

[ Voor 30% gewijzigd door Verwijderd op 23-05-2006 09:43 ]

[toost]

zoals ik al zei, je moet onderscheid maken tussen eisen en functionaliteiten.

Een beschrijving van eisen is heel kort en bondig, en een beschrijving van functionaliteiten kan complex zijn

edit;

in jouw gegeven voorbeeld spreken ze niet over eisen van de klant, maar over eisen aan functionaliteiten, ofwel "voorwaarden".

code:

Description : Official student enrollment information calculated based on official census data. 

Columns : Level, Headcount, Student FTE, Level, Credit hours, load, status, gender, ethnicity, domicile 

Calculations: count of all students by level, count of FTE students by level, count of credit hours by level, count of full time/ part time by level, count by status by level, count by gender by level, count by ethnicity by level, count by domicile by level, totals of each level and totals for the university. 

Parameters: Type of credit hours (all reportable hours, revenue hours, contract hours), college (unit), campus, department 

Drill down: By load type, status, gender, ethnicity, domicile 

Security Level:  

Special Instruction: When drilling down, for example drill down by gender – female, should give numbers related to females only

zoals je ziet spreken ze al over parameters, columns ed. Dit betreft dus de variabelen ed. in de functies.

Dus nog 1 keer voor de duidelijkheid, maak onderscheid in klant eisen en functionaliteiten (maar dat heb ik ondertussen al wel 20 keer gezegd)

[ Voor 78% gewijzigd door toost op 23-05-2006 10:56 ]