ontwikkeling (en niet alleen), praktische voorbereiding van technische specificaties. B O de meeste al klaar voor gebruik logische elementen Technische specificaties vindt u aan het einde van het artikel. Herziening gedateerd 20 juni 2018.

Hoe schrijf je een technische specificatie?!

Aangemaakt op 02/05/2005 11:41:19

Jouw wereld is leeg...

Wie zal jouw verdriet delen?

“Hoe schrijf je een technische specificatie?!” - uit de mond van de zogenaamde een beginnend “technisch schrijver”, hierna te noemen technisch schrijver. Hier is het: de verschrikkelijke prijs van de ineenstorting van de Unie en de overgang van het Russische hoger onderwijs naar een tweefasenonderwijssysteem.

Laten we terugkeren naar de vraag. Bij "lay-out" blijkt:

• de eerste vraag is “waarom is het nodig”;
• de tweede vraag is wat de structuur van de secties zou moeten zijn “ Technische taak»;
• derde vraag: op welke manieren kunnen teksten worden voorbereid voor de inhoud van delen van een technische specificatie?

De derde is de moeilijkste. Antwoorden op deze vragen verschijnen tijdens de presentatie.

Doelen en doelstellingen van het artikel

Het doel van het artikel is om het leven van compleet nieuwe technici gemakkelijker te maken.

Doelstellingen van het artikel:

• antwoorden geven op de gestelde vragen;
• de vereiste minimale praktische voorbereiding van technische specificatieteksten tonen;
• geef een beginnende techneut een kans:
  • verhoog uw eigen beoordeling;
  • of jezelf volledig verliezen in de ogen van de Grote Boss.

Verhaal

Alles wat ooit is geproduceerd, wordt geproduceerd en zal worden geproduceerd, is (uiteraard voorwaardelijk) verdeeld in:

Het eerste () product was misschien een stenen bijl. Of een (kunstmatige) kleischerf () waarmee je wat water in een beekje kunt opscheppen.

Het eerste stukje software dat op hardware werd geïmplementeerd, was waarschijnlijk een ‘jukebox’ met een roterende schijf bedekt met pinnen. De pinnen raakten op een bepaald moment een specifieke stemvork. Zo bleek de melodie geprogrammeerd, 'hardwired' op metaal - een echt softwareproduct, niet alleen dat, maar een zelfgemaakt product. Je kunt dit prachtige wonder zien in het Polytechnisch Museum van Moskou.

Het eerste geautomatiseerde systeem was waarschijnlijk de windmolen. Ik trok de stop eruit - de "messen" draaien, de molenstenen malen. “Een druk op de knop” - 100% automatisering.

Een huiveringwekkend verhaal

En toen beval de koning () - om een ​​molen te bouwen, en een die zou werken door de kracht van de wind, koeler dan die van de koning van Engeland (de “wensen” van de klant), en zodat het de afgunst van de hele bourgeoisie (overeenkomend met moderne ontwikkeling wetenschap en niet onderdoen voor vergelijkbare eisen voor de beste moderne binnenlandse en buitenlandse analogen).

De wachters sleepten de dienaar van de soeverein, een plaatselijke vakman (), en gooiden hem aan de voeten van de tsaarvader. De vakman sloeg met zijn voorhoofd op de stenen vloer - dus natuurlijk! Wij zullen alles doen, Majesteit, onvoorwaardelijk, nauwkeurig, op tijd en volledig!

Het is zover, de koning arriveert bij de molen (werken). Hij kijkt en is verbaasd - de vleugels draaien, de molenstenen malen, het meel stroomt vanzelf in zakken! (Volledige naleving van de vereisten voor functies (taken) die door het systeem worden uitgevoerd). Ja, neem het en steek je hand in de tas... (die niet werd meegeleverd, want zulke dingen bestonden niet).

De koning werd paars - nou, deze stinkende molen maalt onfatsoenlijk meel?! (Geproduceerd niet-naleving van de vereisten van GOST 7045-90 Roggebakmeel.). De wachters grepen de man vast en sloegen met een stenen bijl op zijn wilde hoofdje. En Lefty beëindigde zijn leven op de klanken van Mozarts ‘Requiem’ uit de jukebox...

conclusies

In de oudheid bestond er weinig gelijkheid in de relatie tussen de partijen, de klant en de opdrachtnemer (ontwikkelaar). Er was natuurlijk iets dat de relatie reguleerde. Misschien werden er berkenschorsdocumenten voorbereid - prototypes van moderne verdragen. Het is onwaarschijnlijk dat dergelijke overeenkomsten met alles rekening kunnen houden, zelfs met de kwaliteit van het malen. En nog niet in brede zin waren alle aspecten van de relatie tussen opdrachtgever en opdrachtnemer algemeen aanvaard.

Er werden decreten en bevelen uitgevaardigd - “aan de Universiteit van Moskou moeten studenten op stro zitten, hun neus in hun vuist snuiten en hun neus afvegen met een bosje stro. En degenen die deze regels overtreden, worden genadeloos verscheurd met roeden” (of iets dergelijks).

Zelfs nu bestaat er geen gelijkheid; wie betaalt, bepaalt de toon. En de klant betaalt.

Notitie van 05/10/2014 - Maar niet alles is zo verdrietig Als je verstandig handelt, kun je gemakkelijk elke klant omverwerpen, zie i.

Huidige toestand

En ze bedachten iets dat een tank maakte...

uit de serie “Legergrappen”

Moe van de wetteloosheid van de "klant", verzamelden de uitvoerders (ontwikkelaars) zich (in het laatste kwart van de twintigste eeuw), organiseerden "" en maakten een tank - gebaseerd op de structuur en (om preciezer te zijn) een document genaamd "technische specificaties ”. Opgemerkt moet worden dat de auteursteams in de regel bestonden uit mensen die technisch onderlegd en attent waren en naar de verre toekomst keken.

Misschien was alles anders, maar de tank is over het algemeen goed gebleken - wat wordt bevestigd door zowel vertegenwoordigers van GOSSTANDARD als beoordelingen van ervaren ontwikkelaars.

Technische specificaties en het doel ervan

Voor de Big Boss, die rechtstreeks met de klant communiceert, stelt de technische specificatie hem in staat het lot van de vakman te vermijden (dit is al meerdere keren eerder genoemd).

Voor een kleine technisch technicus werkzaam bij Big Boss is de ontwikkeling van technische specificaties:

• een middel om geld te verdienen voor “iets te eten”;
• een manier om te laten zien dat Techpis geen bevend wezen is, maar het recht heeft: een manier om te groeien in de ogen van Big Boss.

De extreme uitspraak is een driesnijdend zwaard. Oh, je bent slim, kun je het doen? Je hebt dus nog werk te doen. En we verhogen het salaris. Op een dag.

Hoe dan ook is het vermogen om op competente wijze technische specificaties te ontwikkelen (vooral vaardigheid) een indicator van de hoge kwalificaties van de ontwikkelaar.

Wij zijn van mening dat de eerste vraag (naar een eerste benadering) gesloten is.

GOST-normen voor technische specificaties

Een struik is een verzameling takken die vanuit één punt groeit.

Militaire wijsheid

Na hard werken (en lijden) werden minstens vier documenten vrijgegeven, die overeenkomen met een zeer conventionele verdeling van de producten van het menselijk leven:

Opmerkingen:

1. Er zijn andere binnenlandse GOST's die vereisten bevatten voor de inhoud en het formaat van het document "Technische specificaties". Dit feit is te wijten aan de specificiteit ervan. De vier genoemde waren en blijven voor de meeste vakgebieden;
2. Het mandaat was en blijft het fundamentele document, het “steunpunt” waaruit alles groeit.

Wat hebben de secties van de hierboven genoemde documenten met elkaar gemeen? Elke technische specificatie moet secties bevatten die informatie weerspiegelen:

• wat moet je doen;
• waarom, met welk doel moet dit gebeuren;
• waar, in welk toepassingsgebied, op welk object moet het zijn beslissen taken en vervullen zijn functies;
• welke eisen zullen hieraan worden gesteld;
• welke werkzaamheden hiervoor nodig zijn;
• wat is de procedure voor het uitvoeren en aanvaarden en overdragen van werkzaamheden aan de klant;
• hoe de werkzaamheden moeten worden uitgevoerd;
• en, ten slotte, op basis van welke regelgevende en technische documenten moeten de werkzaamheden worden uitgevoerd?

Dit is de algemene structuur van de secties van de technische specificaties. Wij beschouwen de tweede vraag als gesloten.

Het was noodzakelijk om een ​​technische specificatie voor het product te ontwikkelen - we gebruiken GOST 2.114-95, aangezien GOST 15.001 een levenscurve is en de secties van de technische specificaties (in het algemeen) overeenkomen met de secties van de technische specificatie. Open indien nodig GOST 34.602-89. Aan - GOST 19.201-78.

We zullen het noodzakelijke minimum aan praktische technieken laten zien waarmee zelfs de meest beginnende technicus onmiddellijk kan beginnen met het ontwikkelen van de inhoud van secties van de technische specificaties en aanvaardbare resultaten kan bereiken (afzonderlijke kant-en-klare structurele elementen van de technische specificaties in overeenstemming met GOST 34.602-89 vindt u in de “kelder” van dit artikel).

Praktische technieken

Praktische methoden voor het ontwikkelen van technische specificaties waren letterlijk zuurverdiende gebaseerd op de ervaring van interactie met de klant, zowel de auteur zelf als zijn senior kameraden, waarvoor ik voor hen buig, eer en respect (zowel nu als voor altijd, en voor altijd en altijd Amen).

De allereerste techniek is het maken van een document met een GOST-standaard sectiestructuur. Als de baas de taak heeft een technische specificatie te ontwikkelen, bijvoorbeeld voor een geautomatiseerd systeem, wordt GOST 34.602-89 gedownload als bestand en vervolgens eenvoudig geopend in Word en in puntformaat.

Elektronische versies van GOST's die zijn opgeslagen, komen over het algemeen overeen met de officiële versies. Twijfelachtige punten kunnen altijd door vergelijking worden gecontroleerd, als je natuurlijk niet lui bent.

Opmerking van 25 december 2011 - Rostekhregulirovaniya (protect.gost.ru) is onlangs begonnen met het publiceren van officiële versies van GOST's, hoewel niet in een bewerkbaar formaat...

Detaillering

Detaillering is een van de fundamentele technieken. Sommige mensen geven de voorkeur aan een wetenschappelijke term die is ontleend aan de bourgeoisie: ontbinding. We zullen het hebben over het detailleren van de structuur van GOST-secties voor technische specificaties.

Laten we het ouderlijke onthouden: "totdat je alles op orde hebt gebracht," zal niets voor jou (mama) lukken "of" niets zal voor jou lukken (papa)." Zowel mama als papa hadden en blijven uiteraard oneindig gelijk. Het is onmogelijk een eenvoudig natuurkundig probleem op te lossen totdat de krachtvectoren langs de assen verspreid zijn. Het is onmogelijk om een ​​drievoudige integraal te nemen totdat de integralen over dx, dy en dz om beurten zijn genomen. Behalve in het geval waarin “de integraal zo eenvoudig is dat je hem zelfs zonder dx kunt nemen.”

Willekeurig geselecteerd citaat uit GOST 34.602-89:

Voor het systeem gelden de eisen voor gebruik in het systeem, interactietalen en technische middelen systemen, evenals vereisten voor decodering, talen, beschrijvingsmiddelen (van het automatiseringsobject), organisatiemethoden [uit clausule 2.6.3.3 van GOST 34.602-89]

achterkant O Rovo, toch? We zullen deze puinhoop moeten opruimen. Dus, expliciet door fragmentatie worden aanvullende subparagrafen van de technische specificaties gecreëerd (dit kan en moet worden gedaan).

4.3.2.1 Vereisten voor taalkundige ondersteuning van het systeem

4.3.2.1.1 Vereisten voor gebruik in een programmeertaalsysteem op hoog niveau

(tekst van eis)

4.3.2.1.2 Vereisten voor talen voor interactie tussen gebruikers en technische middelen van het systeem

(tekst van eis)

4.3.2.1.3 Vereisten voor gegevenscodering

(tekst van eis)

4.3.2.1.4 Vereisten voor het decoderen van gegevens

(tekst van eis)

4.3.2.1.5 Vereisten voor talen voor gegevensinvoer/uitvoer

(tekst van eis)

4.3.2.1.6 Vereisten voor talen voor gegevensmanipulatie

(tekst van eis)

4.3.2.1.7 Vereisten voor beschrijvingstools gebied(automatiseringsobject)

(tekst van eis)

4.3.2.1.8 Vereisten voor methoden voor het organiseren van dialoog

(tekst van eis)

Is het volume aan technische specificaties toegenomen? Is het de moeite waard om papier te besparen? Er is nog een militaire wijsheid, hoe grof en dubbelzinnig het ook mag klinken: “meer papier - schoner z@@@@tsa.” Worden de vereisten voor taalkundige ondersteuning duidelijker?

Let op - De termen "begrijpelijkheid" en "begrijpelijkheid" verschijnen in verschillende GOST's tegelijk. Hier is de essentie: “de totaliteit van iets dat de uitgaven van menselijke inspanningen karakteriseert om het logische concept van dit iets te begrijpen.”

Na het transformeren van een doorlopende tekst in een opsomming (subsecties, alinea's) voor begrip (tenminste memoriseren) logische structuur de technische specificatie kostte de auteur minder tijd (en moeite), omdat de subparagrafen duidelijk “zichtbaar” werden.

Detail, detail en nog eens detail. Op een acceptabel (atomair) niveau.

Sjabloonconstructie van zinnen

Je moet er rekening mee houden dat elke vraag (goed gesteld) de helft van het antwoord bevat. Laten we zeggen dat het nodig is om de tekst van de subclausule "Vereisten voor gebruik in het systeem" te formuleren. Dus:

4.3.2.1 Vereisten voor gebruik in een programmeertaalsysteem op hoog niveau

In systeem moeten zijn (precies moeten- dat is alles!) De volgende programmeertalen op hoog niveau worden gebruikt:

• C++ taal;
• Pascal-taal;
• enz.

Voor degenen die niet hebben gevoeld hoe ze een zin moeten construeren, wordt aan de linkerkant een diagram van de constructie ervan weergegeven.

4.1.2 Eisen aan het aantal en de kwalificaties van systeempersoneel en hun werkwijze

(om meer gedetailleerd te zijn, creëren we subclausules 4.1.2.1, 4.1.2.2 en 4.1.2.3)

(we formuleren de tekst van de alinea correct - we beantwoorden de vraag aan welke eisen het aantal personeelsleden moet voldoen)

Aantal medewerkers moeten aan de eisen voldoen :

• voldoende zijn voor de implementatie van geautomatiseerde ()systemen in alle vormen van systeemwerking;

4.1.2.2 Eisen aan personeelskwalificaties

Kwalificaties van het personeel moeten voorzien efficiënt functioneren van technische en systeemsystemen in alle bedrijfsmodi van het systeem"

Bij beslissingen over de kwalificaties van het personeel zal het mogelijk zijn om aan te geven dat, op basis van de ervaring van meer dan honderd eerder ontwikkelde soortgelijke systemen, het personeel minimaal drie jaar onderwijs moet hebben genoten in een parochiale school. Deze verklaring zal de klant tevreden stellen. Het zal mogelijk zijn om te profiteren van ultragoedkope arbeid. Maar daarover meer in toekomstige artikelen.

4.1.2.3 Eisen aan de werkuren van het personeel

Het werkschema van het personeel bestaat uit drie ploegen, 24 uur per dag.

In het artikellid wordt tevens de procedure geregeld voor het opleiden van personeel en het monitoren van kennis en vaardigheden. Geen woord over de compositie. En het klopt. De samenstelling van het personeel, verdeeld in operationeel (), reparatie, etc., wordt bepaald bij het ontwerpen van het systeem. Hoewel niemand kan verbieden om vereisten voor de personeelssamenstelling aan de taakomschrijving toe te voegen. Waarschijnlijk niet de moeite waard.

Eenvoudig, maar smaakvol. Pure praktijk, zonder diepe onderdompeling in taalkundige subtiliteiten. Detaillering plus specifieke eisen van de technische specificaties.

Formalisering bij het opstellen van de tekst van de technische specificaties

Mogelijk tweehonderd opties

Een van de tweehonderd opties voor het ontcijferen van de afkorting “VDV”

Laten we terugkeren naar het voorbeeld uit de vorige subsectie van het artikel.

4.1.2.1 Personeelsvereisten

Het aantal personeelsleden moet voldoen aan de eisen:

• voldoende zijn om geautomatiseerde systemen in alle vormen van systeemwerking te implementeren;
• zorgen voor volledige inzet van personeel bij het implementeren van geautomatiseerde systeemfuncties, enz.

De noedels zijn compleet, maar formeel klopt alles. Het wordt aanbevolen voor gebruik als het onmogelijk is om enig onderdeel van de technische specificatie te specificeren. Als Big Boss er niet is, kunt u hem beleefd vragen om de wensen van de klant met betrekking tot dit artikel te verduidelijken, om meer te geven exacte informatie. Dit is het recht van een technisch specialist die niet in direct contact staat met de klant.

U kunt toevoegen: “het aantal personeelsleden is gespecificeerd voor het “Technische Project””. Big Boss zal versteld staan ​​van zoveel kennis van de technicus (ook al weet hij zelf helemaal niets) op het gebied van podia en geautomatiseerde systemen. En als je de baas mondeling voorstelt om (later) de zinsnede aan het project toe te voegen - "gebaseerd op de ervaring van meer dan honderd eerder ontwikkelde soortgelijke systemen, zou het aantal personeelsleden 10 fulltime-eenheden moeten zijn" - zal de baas dat doen. laat je ter plekke verrassen. U kunt veilig een Beschikking opstellen voor de aanstelling van een technisch specialist in de functie van systeemanalist (die ook afwezig is in volledig Russische classificatie). Of wacht tot ze je wat extra werk geven, omdat je zo slim bent.

Opmerking gedateerd 17-04-2018 - De OKPDTR heeft ook niet de functie van technisch griffier. En de positie van de tekststapelaar is van vroeger gebleven

Stempels en unificatie bij het opstellen van de tekst van technische specificaties

Jullie vrouwen zijn mooi

En ik - zonder verfraaiing

Maar toch, mannen

Ze laten je...

Yu Rybchinsky, ‘Twee zussen’

tekst van de technische specificaties wordt tot stand gebracht door middel van stempels. Allereerst moet u een eenvoudige waarheid leren kennen - nooit, in welk document dan ook Niet je moet een schop een schop noemen .

Laten we zeggen dat er een universele energieomzetter in de energie van de menselijke geest wordt ontwikkeld (het bestaan ​​van de menselijke geest is twijfelachtig. Is het redelijk om het werk van het creëren van zo'n omzetter aan je nek te hangen? Maar reflexen bestaan ​​objectief). U moet deze converter onmiddellijk, in het gedeelte 'Productnaam', een product noemen:

Productnaam - omzetter van zonnestralingsenergie in de energie van de menselijke geest ( Verder volgens de tekst - Product ).

En in de tekst - Product, Product, Product...

Hetzelfde geldt voor softwareproducten en geautomatiseerde systemen. Naam AS - geautomatiseerd systeem voor de distributie van ruwvoer voor rundvee ( Verder volgens de tekst - Systeem ).

En in de tekst - Systeem, Systeem, Systeem... Programma, Programma, Programma...

Het resultaat is dat we twee vliegen in één klap hebben gepakt en gedood. Het is niet nodig om een ​​hele reeks woorden te verbuigen en te vervoegen, en het zal gemakkelijker zijn om de op deze manier opgebouwde technische taak te lezen.

Opmerking gedateerd 5 februari 2010 - Bij geautomatiseerde ontwikkeling van technische documentatie met behulp van één bron zijn zowel de optie met allerlei verbuigingen en vervoegingen, als zonder deze, acceptabel. U kunt bijvoorbeeld eenmalig een variabele maken<ЗАО «Заказчик»>en invoegen in de vereiste onderwerpen van de documentbibliotheek - dit is soms handiger.

Hieronder vindt u typische lijsten met stempels die al lange tijd en met succes worden gebruikt bij de ontwikkeling van technische specificaties (per hoofdsecties, vetgedrukt):

• doel van het systeem - systeem bedoeld Voor het oplossen van de volgende problemen:
  • taken zo en zo (eerste);
  • taken zo-en-zo (tweede);
  • enzovoort.
• doelstellingen voor het creëren van het systeem - doelen systeemcreatie zijn :
  • toename snelheid...;
  • Promotie nauwkeurigheid...;
  • afname kosten...;
  • afwijzen consumptie...;
  • verbetering indicatoren...;
  • enzovoort.

Elk doel impliceert altijd positief dynamiek , verandering in indicatoren ten goede. Het doel is bijvoorbeeld om het welzijn van het hele Sovjetvolk te vergroten (maar niet het communisme: het communisme is het doelwit!). Het doel is het verhogen van de klanttevredenheid. De uitzonderingen zijn:

• winst maken (in de context van technische specificaties);
• ondertekening door de klant.

Er zijn ook trucs die niet zo zijn. Een voorbeeld uit de praktijk van een van de meest eerbiedwaardige techpis (hij gaf zelf, zonder enige dwang, een voorbeeld in een van de techpis-forums) - “ staat toe... programma presteert... programma doet...". Geachte heer, technisch schrijver! Er is nog geen programma, het is nog niet ontwikkeld, is niet, niet, niet overgedragen aan de klant, daarom staat, doet of doet het nog steeds niets. Wat is dit voor een onoverwinnelijke Sovjet-gewoonte van wensdenken?!

• vereisten voor functies (taken) die door het systeem worden uitgevoerd - systeem moeten hieronder opgesomd functies:
  • V binnenin Eerst taken- het uitvoeren van deze en die functie, die en die functie;
  • V binnenin seconde taken- het uitvoeren van deze en die functie, enz.

Als het een functie is (zoals een proces), dan precies voorzien mogelijkheid tot executie de opgegeven functie. De gebruiker kan de stop verwijderen - de molen begint bloem te malen. Maar de gebruiker mag de stop niet verwijderen. IN gespecificeerd In dit geval bevindt de molen (systeem) zich in de standby-modus (inactief).

Als het een functie is (zoals een proces), dan moet het systeem dat ook doen voorzien prestatie functies. De automatische functie wordt volgens een bepaald schema door de systeemsoftware gestart (zonder tussenkomst van personeel) en voegt de database samen.

Wat betreft de omvang van de taken. Taken er wordt besloten en de functies worden uitgevoerd. Naar beslissen taak, het is noodzakelijk uitvoeren een reeks functies, procedures of handelingen. Met andere woorden, de taak is groter structureel element in strijd met verzinsels.

In GOST 34.003-90 wordt het vooruitgezet, de taak maakt als het ware deel uit van de functie. En dit is vreemd: zelfs op school loste iedereen problemen op, door de waarden van verschillende functies daarin te berekenen... En stel je voor hoe wild de verklaring zou klinken: “Het doel van de partij en de regering is het verbeteren van het welzijn van het gehele Sovjet-volk. Om het doel te bereiken stelt de partij zichzelf functie elk gezin voorzien van een apart appartement tegen het jaar 2xxx”... (Trouwens, het zelf schoonmaken van huizen en appartementen is niet langer in de mode en er is geen tijd meer voor - daar zijn schoonmaakbedrijven voor). De functie is dus onderdeel van de taak, en niet andersom. Zelfs als dit in strijd is met de heilige GOST 34.003-90.

Een voorbeeld dus.

IN binnenin taken (of Voor probleemoplossing ) software systemen moeten afdwingen hieronder opgesomd functies:

• geautomatiseerd functies
• geautomatiseerde functie voor het sorteren van records in databasetabellen;
• functies automatisch back-up van de database.

En uit de vorige paragraaf:

• moeten zijn ...;
• moeten aan de eisen voldoen ..

Als gevolg van het gebruik van stempels wordt de tekst van de technische specificatie uniform en geformaliseerd. Geen versiering . En de klant man zal nergens heen gaan van jullie, beste meisjes-technische ingenieurs, aangezien de eisen van de technische specificaties voor hem zullen zijn transparant.

Lijsten en nummering van secties

Lijsten (opsommingen of genummerde lijsten) zijn zeer geschikt bij het opstellen van de tekst van een technische specificatie. Een normaal persoon kan drie tot negen elementen van de lijst waarnemen (onthouden en nauwkeurig reproduceren). Meer dan negen is een teken van genialiteit.

B, misschien moet het aantal elementen van de lijst worden verminderd. In de technische specificaties - optioneel. Er moet aan worden herinnerd dat het mandaat met veel andere documenten is ontwikkeld verschillende niveau's en stadia van het creëren van een systeem (of wat dan ook).

Geval één.

"IN binnenin taken (of Voor probleemoplossing moeten de mogelijkheid tot vervulling garanderen hieronder opgesomd functies:

• geautomatiseerd functies records toevoegen aan databasetabellen;
• geautomatiseerde functie voor het verwijderen van records uit databasetabellen;

Geval twee.

« 4.3.2.1 IN binnenin taken (of Voor probleemoplossing ) systeemsoftware voor databaseonderhoud moeten de mogelijkheid tot vervulling garanderen hieronder opgesomd functies:

1. geautomatiseerd functies records toevoegen aan databasetabellen;
2. geautomatiseerde functie voor het verwijderen van records uit databasetabellen;
3. geautomatiseerde functie voor het sorteren van records in databasetabellen...;"

De verschillen lijken klein. Maar!

In het eerste geval moet u in het document "Testprogramma en methodologie" schrijven "een methode voor het controleren van de implementatie door het systeem van de geautomatiseerde functie van het toevoegen van records aan databasetabellen."

In het tweede geval is het slechts een “methode om de implementatie van clausule 4.3.2.1(1) van de technische specificaties te controleren.”

In het eerste geval is “aan de vereisten van de technische specificatie voor de implementatie van de geautomatiseerde functie voor het toevoegen van records aan databasetabellen voldaan.” In het tweede geval wordt “aan de vereisten van clausule 4.3.2.1(1) van de technische specificaties voldaan.” Er is een verschil?

Wat betreft de nummering op meerdere niveaus van secties, subsecties, clausules en subclausules: in de praktijk zijn deze vereisten in de overgrote meerderheid van de gevallen verplicht.

De lijsten moeten niet met cijfers worden “genummerd”, maar met letters:

a) zo en zo functioneren;

Deze vraag is van fundamenteel belang, aangezien de technische specificaties van de kerncentrale (naast de technische specificaties) voordat ze ter goedkeuring worden voorgelegd, moeten worden gecontroleerd door de dienst van de organisatie die de technische specificaties heeft ontwikkeld en, indien nodig, onderworpen aan [ uit paragraaf 8 van de bijlage. 1 GOST 34.602-89]. Als de technische specificaties scheef zijn ontwikkeld (naar vorm en naar essentie), zullen de ontwerp- en operationele documenten immers scheef zijn.

Een beetje over. Als de technische specificatie een subsectie “Metrologische ondersteuning...” bevat, moet het metrologisch onderzoek worden uitgevoerd volgens volledig programma. Als de gespecificeerde subsectie ontbreekt, wordt het metrologisch onderzoek beperkt tot het controleren van afkortingen in overeenstemming met GOST 8.417. Maar alleen.

De link “algemene informatie, doel en samenstelling” in de technische specificaties

Koppeling " algemene informatie, doel en samenstelling” bleek niet alleen uitstekend te zijn bij de ontwikkeling van technische specificaties. De link is geschikt voor alle non-fictieteksten met een beschrijvend karakter.

Voorbeeld - Vereisten voor het aantal niveaus en de mate van centralisatie van het systeem. Dat is het O waar je naar kunt schrijven gespecificeerd onderafdeling van de technische specificaties?

Iedereen zal reflexmatig door de secties van GOST gaan kijken naar de technische specificaties, in een poging op zijn minst een aanwijzing te vinden. Een persoon met ervaring zal zich Fr.

2.1 Doel van het systeem

Een kameraad die daar direct iets aan het solderen of opzetten is, zal de technicus altijd kunnen vertellen waarom het systeem wordt gemaakt. Uiteraard binnen uw competentie. De systeemingenieur of baas vertelt u meer. Laten we zeggen

Het systeem moet een oplossing (het vermogen om op te lossen) bieden voor de volgende problemen:

1. taken voor het verzamelen van gegevens van bijvoorbeeld sensoren;
2. verwerkings-, opslag-, display-, etc. taken in het verzamelcentrum.

Dat is alles. Een beetje fantasie, en de sectie is klaar:

Het systeem moet hebben hiërarchische structuur en omvatten de volgende hiërarchieniveaus:

1. 1e niveau - niveau gegevensverzameling ;
2. 2e niveau - niveau gegevensconsolidatie (gecentraliseerde verwerking, opslag, enz.).

Nogmaals, beide hazen - en ter plaatse. En de hiërarchieniveaus worden vermeld, en de mate van centralisatie. Wat is het volgende?

2.1.1 Niveau van gegevensverzameling

2.1.1.1 Algemene informatie

Wat algemene informatie. Je kunt bijvoorbeeld schrijven dat het niveau wordt gekenmerkt door territoriale distributie - elk water zal het doen als het ongeveer overeenkomt.

2.1.2.2 Doel

Niveau van gegevensverzameling bedoeld(nog een stempel):

1. om gegevens van sommige sensoren over te dragen naar het consolidatieniveau op verzoek (initiatief) van de laatste;
2. voor het loggen van gegevensoverdracht in het gebeurtenislogboek (en indien volgens GOST, dan in);
3. voor iets anders.

2.1.2.3 Samenstelling

De gegevensverzamelingslaag moet het volgende omvatten:

1. sensoren zo en zo;
2. enkele andere sensoren.

Wat is het gemak van het gebruik van de link “algemene informatie, doel en samenstelling”? En je krijgt onwillekeurig een goed gestructureerde technische taak - boomachtig en hiërarchisch.

2.2.2.3.1 Sensoren zo en zo

2.2.2.3.1.1 Algemene informatie (over deze en die sensoren)

2.2.2.3.1.2 Doel (van deze en die sensoren)

2.2.2.3.1.3 Samenstelling (van deze en die sensoren)

Het belangrijkste is om op tijd te stoppen.

Waarschuwing

Tijdens de ontwikkeling en van het grootste belang zijn de volgende:

• Allereerst - . Want dat is;
• , bijvoorbeeld en;
• , Bijvoorbeeld;
• en bijvoorbeeld;
• een aantal anderen.

Je moet je niet te veel laten meeslepen door dergelijke "thematische" GOST's, die zeer specifieke vereisten bevatten. Een typische fout van beginners is "communicatiekanalen moeten voldoen aan de vereisten van GOST zo-en-zo." Dit is een fatale fout. Het is bekend dat de acceptatie en oplevering van werk om een ​​systeem, product of softwareproduct te creëren altijd wordt voorafgegaan door implementatie.

Laten we zeggen dat de Grote Baas, verbaasd door de diepgaande kennis van de technische specificatie, hem vertrouwde, niets las en een goedkeurende verklaring op de titelpagina van de technische specificatie krabbelde (onder GOEDGEKEURD, rechts). bovenste hoek titelpagina). De klant plaatste met een gemene grijns voorzichtig de zijne (onder GOEDGEKEURD, in de linkerbovenhoek). Alles kan de technische specificaties en worden daarin opgenomen, of het is alleen mogelijk na aanvullende overeenkomst met de klant. Hier kwam de technische informatie binnen.

Het is tijd om het systeem (programma, product) te testen op naleving van de eisen van de technische specificaties. De klant zal uiteraard moeten aantonen dat de communicatiekanalen voldoen aan de eisen van GOST zo en zo.

Wat moeten we doen? Het is niet zo erg als je met communicatiekanalen omgaat, klaar om deze aan de Grote Baas te verstrekken. De baas verontschuldigt zich bij de klant en de technische informatie leeft voort (tot de volgende lekke band). Maar de slechte smaak in de ziel van Big Boss zal voor altijd blijven bestaan. Je hoeft geen promotie te verwachten.

Het is een echte ramp als er geen certificaten zijn. De baas zal geld (niet voorzien in de begroting) aan de autoriteit moeten betalen om het felbegeerde certificaat te verkrijgen, dit aan de klant te presenteren en het werk af te ronden. Technici kunnen een dergelijke fout misschien niet vergeven.

Kortom, je moet zoiets als dit schrijven, in gewoon Engels:

“Het volgende kan worden gebruikt (gebruikt) als communicatiekanalen:

1. verbindingskanalen -;
2. kanalen van mobiele operators;
3. kanalen van satellietoperatoren;
4. geschakeld telefoonlijnen normaal gebruik;
5. faciliteit van de klant;
6. enzovoort"

U mag in geen geval de gegevensuitwisselingssnelheid van het communicatiekanaal specificeren, d.w.z. bijzonderheden. Als het communicatiekanaal op basis van Ethernet is geïmplementeerd en de technische specificaties duidelijk een wisselkoers van minimaal 1200 bps aangeven, heeft de klant elk recht de opdrachtnemer verplichten de tests volledig uit te voeren. Zelfs in zo'n duidelijk absurde situatie.

Conclusie

Laten we dus nogmaals de belangrijkste punten onthouden:

1. voorbereiding van technische specificaties door een elektronische versie van de vereiste GOST te importeren;
2. detaillering - het opsplitsen van grote delen van de technische specificaties in korte, eenvoudige subsecties;
3. sjabloonconstructie van zinnen in secties (subsecties, enz.) van de technische specificatie, zodat “het antwoord de helft van de vraag bevat”;
4. formalisering van de inhoud van die secties waar het onmogelijk (of) is om details te geven;
5. gebruik van postzegels;
6. gebruik van lijsten (lijsten met opsommingstekens of genummerde lijsten);
7. toepassing van de link “algemene informatie, doel en samenstelling”;
8. minimaal gebruik van "thematische" GOST's.

Concluderend kunnen we nog een aantal aanvullende tips geven:

• zoek de "vis" van de technische specificatie en leen, na deze kritisch te hebben begrepen, de inhoud van de juiste secties (maar niet van de bekende resource inkoop.gov.ru - daar staat complete onzin);
• gebruik documenten;
• aarzel niet om vragen te stellen.

U kunt Technical Documentation LLC per e-mail bestellen. e-mail admin@tdocs. su (zonder spaties), tel. 8-910-468-09-28 of in het formulier.

Copyright © Technical Documentation LLC 2018. Leen onze materialen met glans! Bij het reproduceren van portaalmaterialen is het noodzakelijk om een ​​actieve hyperlink naar de bron te installeren: de pagina met deze publicatie op de site.

Vaak wordt mij gevraagd: “Hoe ontwikkel je op de juiste manier technische specificaties voor een geautomatiseerd systeem?” Een soortgelijk onderwerp wordt voortdurend besproken op verschillende fora. Deze vraag is zo breed dat het onmogelijk is om deze in een notendop te beantwoorden. Daarom besloot ik een lang artikel over dit onderwerp te schrijven.

• In het eerste deel " Ontwikkeling van technische specificaties. Wat is het, waarom is het nodig, waar te beginnen en hoe het eruit moet zien? Ik zal proberen de vragen over het onderwerp in detail te beantwoorden, de structuur en het doel van de Terms of Reference te bekijken en enkele aanbevelingen te doen over het formuleren van vereisten.
• Tweede deel " Ontwikkeling van technische specificaties. Hoe eisen te formuleren? zal geheel gewijd zijn aan het identificeren en formuleren van eisen aan een informatiesysteem.

Eerst moet je uitzoeken welke vraag daadwerkelijk interessant is voor degenen die zich afvragen: “Hoe ontwikkel je een technische specificatie?” Feit is dat de aanpak bij het ontwikkelen van de technische specificaties sterk zal afhangen van de doeleinden waarvoor het wordt gedaan, en ook van wie het zal worden gebruikt. Over welke opties heb ik het:

• Een commerciële organisatie besloot een geautomatiseerd systeem te implementeren. Zij beschikt niet over een eigen IT-dienst en heeft besloten dit te doen: De belanghebbende moet een Technische Specificatie ontwikkelen en deze ter ontwikkeling aan een derde partij voorleggen;
• Een commerciële organisatie besloot een geautomatiseerd systeem te implementeren. Het beschikt over een eigen IT-dienst. We besloten dit te doen: een Technische Specificatie ontwikkelen, en daar vervolgens overeenstemming over bereiken tussen de IT-dienst en de IT-dienst geïnteresseerde partijen, en implementeren op ons zelf;
• De overheidsinstantie besloot een IT-project te starten. Alles is hier zo duister, veel formaliteiten, smeergeld, bezuinigingen, enz. Ik zal deze optie in dit artikel niet overwegen.

• Een IT-bedrijf levert diensten voor de ontwikkeling en/of implementatie van geautomatiseerde systemen. Dit is het moeilijkste geval, omdat je onder verschillende omstandigheden moet werken:

  • De opdrachtgever heeft eigen specialisten met een eigen visie en zij stellen specifieke eisen aan de Technische Specificaties;
  • De taakomschrijving is ontwikkeld voor interne ontwikkelaars (het maakt de klant niets uit);
  • De taakomschrijving is ontwikkeld voor overdracht aan de contractant (d.w.z. een groep programmeurs in dienst van het bedrijf, of een individuele specialist);
  • Er ontstaat een misverstand tussen het bedrijf en de klant over het behaalde resultaat, en het bedrijf stelt steeds opnieuw de vraag: “Hoe moeten de Technische Specificaties worden ontwikkeld?” Het laatste geval lijkt misschien een paradox, maar het is waar.
  • Andere, minder gebruikelijke opties zijn ook mogelijk;

Ik denk dat de lezer nu vragen zou moeten hebben:

• Waarom kunnen de Technische Specificaties niet altijd op dezelfde manier worden ontwikkeld?;
• Zijn er normen, methoden, aanbevelingen? Waar kan ik ze krijgen?
• Wie moet het referentiekader ontwikkelen? Moet deze persoon speciale kennis hebben?
• Hoe kunt u begrijpen of de Terms of Reference goed geschreven zijn of niet?
• Op wiens kosten moet het worden ontwikkeld, en is het überhaupt nodig?

Deze lijst kan eindeloos zijn. Ik zeg dit met vertrouwen omdat ik al 15 jaar bezig ben met professionele softwareontwikkeling en de kwestie van de technische specificaties ter sprake komt in elk ontwikkelteam waarmee ik werk. De redenen hiervoor zijn verschillend. Als ik het onderwerp van het ontwikkelen van de Terms of Reference aan de orde stel, ben ik me er terdege van bewust dat ik het niet 100% zal kunnen presenteren aan iedereen die geïnteresseerd is in het onderwerp. Maar ik zal proberen, zoals ze zeggen, “alles op een rijtje te zetten.” Degenen die al bekend zijn met mijn artikelen weten dat ik geen "copy-paste" van andermans werk gebruik, de boeken van anderen niet herdruk, geen standaarden van meerdere pagina's citeer en andere documenten die u zelf op internet kunt vinden, ze doorgeven als je eigen geniale gedachten. Typ gewoon in een zoekmachine “Hoe een technische specificatie te ontwikkelen” en je kunt veel interessante, maar helaas repetitieve dingen lezen. In de regel hebben degenen die graag slim zijn op forums (probeer maar eens te zoeken!) zelf nooit een goede technische specificatie gemaakt en voortdurend GOST-aanbevelingen aangehaald over deze kwestie. En degenen die de kwestie echt serieus nemen, hebben meestal geen tijd om op de forums te zitten. Trouwens, we zullen het ook hebben over GOST-normen. Door de jaren dat ik werk, heb ik veel opties gezien technische documentatie, samengesteld door zowel individuele specialisten als gerenommeerde teams en adviesbureaus. Soms doe ik ook aan deze activiteit: ik besteed tijd aan mezelf en zoek naar informatie over een interessant onderwerp uit ongebruikelijke bronnen (zoals een beetje intelligentie). Als gevolg hiervan moest ik documentatie zien over monsters als GazProm, Russian Railways en vele anderen interessante bedrijven. Uiteraard houd ik mij aan het vertrouwelijkheidsbeleid, ondanks het feit dat deze documenten tot mij komen via openbaar beschikbare bronnen of de onverantwoordelijkheid van adviseurs (het verspreiden van informatie op internet). Dus ik zeg meteen: vertrouwelijke informatie, dat eigendom is van andere bedrijven, deel ik niet, ongeacht de herkomst (beroepsethiek).

Wat is een technische specificatie?

Het eerste wat we nu gaan doen is uitzoeken wat voor soort beest deze “Technische Specificatie” is.

Ja, er zijn echt GOST's en standaarden die dit deel van de activiteit (softwareontwikkeling) proberen te reguleren. Er waren eens al deze GOST's relevant en actief gebruikt. Nu zijn er verschillende meningen over de relevantie van deze documenten. Sommigen beweren dat GOST's zijn ontwikkeld door zeer vooruitziende mensen en nog steeds relevant zijn. Anderen zeggen dat ze hopeloos achterhaald zijn. Misschien dacht iemand nu dat de waarheid ergens in het midden lag. Ik zou antwoorden met de woorden van Goethe: “Ze zeggen dat tussen twee tegengestelde meningen de waarheid ligt. In geen geval! Er is een probleem tussen hen." Er zit dus geen waarheid tussen deze meningen. Omdat GOST's de praktische problemen van de moderne ontwikkeling niet onthullen, en degenen die ze bekritiseren geen alternatieven bieden (specifiek en systemisch).

Merk op dat GOST duidelijk niet eens een definitie geeft, maar alleen zegt: “TK voor een kerncentrale is het hoofddocument dat de vereisten en procedure definieert voor het creëren (ontwikkeling of modernisering - en vervolgens creatie) van een geautomatiseerd systeem, in overeenstemming waarmee de ontwikkeling van een kerncentrale wordt uitgevoerd en de acceptatie ervan bij de inbedrijfstelling in werking."

Als iemand geïnteresseerd is in welke GOST's ik het heb, hier zijn ze:

• GOST 2.114-95 één systeem ontwerpdocumentatie. Technische specificaties;
• GOST 19.201-78 Uniform systeem programma documentatie. Technische taak. Eisen aan inhoud en vormgeving;
• GOST 34.602-89 Informatie Technologie. Set normen voor geautomatiseerde systemen. Referentievoorwaarden voor het creëren van een geautomatiseerd systeem.

Op Wikipedia wordt een veel betere definitie gepresenteerd (hoewel het gaat om technische specificaties in het algemeen, en niet alleen voor software): “ Technische taak– dit is het originele ontwerpdocument technisch voorwerp. Technische taak stelt het hoofddoel vast van het object dat wordt ontwikkeld, zowel technisch als tactisch specificaties, kwaliteitsindicatoren en technische en economische vereisten, instructies voor het uitvoeren van de noodzakelijke fasen van het maken van documentatie (ontwerp, technologie, software, enz.) en de samenstelling ervan, evenals speciale vereisten. Een taak als startdocument voor het creëren van iets nieuws bestaat op alle activiteitsgebieden, verschillend in naam, inhoud, volgorde van uitvoering, enz. (bijvoorbeeld een ontwerptaak ​​in de bouw, een gevechtstaak, huiswerk, een contract voor een literair werk, enz.). d.)"

En dus, zoals uit de definitie blijkt, is het hoofddoel van de Technische Specificatie het formuleren van de eisen voor het object dat wordt ontwikkeld, in ons geval voor een geautomatiseerd systeem.

Het is het belangrijkste, maar ook het enige. Het is tijd om tot het belangrijkste te komen: alles “in de schappen leggen”, zoals beloofd.

Wat moet je weten over de eisen? Het is noodzakelijk om duidelijk te begrijpen dat alle vereisten moeten worden onderverdeeld naar type en eigenschappen. Nu zullen we leren hoe we dit moeten doen. Om de vereisten per type te scheiden, zal GOST ons helpen. De lijst met soorten eisen die daar wordt gepresenteerd, is een goed voorbeeld van de soorten eisen waarmee rekening moet worden gehouden. Bijvoorbeeld:

• Functionaliteitseisen;
• Beveiligings- en toegangsrechtenvereisten;
• Vereisten voor personeelskwalificaties;
• …. Enz. Je kunt erover lezen in de genoemde GOST (en hieronder zal ik ze ook wat gedetailleerder bekijken).

Het lijkt mij voor u duidelijk dat de sleutelfactor voor een succesvolle Technische Specificatie juist goed geformuleerde functionaliteitseisen zijn. De meeste werken en methoden waarover ik sprak, zijn aan deze vereisten gewijd. Functionaliteitsvereisten vormen 90% van de complexiteit van het werk aan de ontwikkeling van het mandaat. Al het andere is vaak een ‘camouflage’ die aan deze eisen voldoet. Als de eisen slecht geformuleerd zijn, zal er, ongeacht welke mooie camouflage je erop aanbrengt, geen succesvol project uitkomen. Ja, formeel zal aan alle vereisten worden voldaan (volgens GOST J), de technische specificatie is ontwikkeld, goedgekeurd en ondertekend en er is geld voor ontvangen. En wat? En dan begint het meest interessante deel: wat te doen? Als dit een project is in het kader van het Staatsbesluit, dan zijn er geen problemen - de begroting daar is zodanig dat het in niemands zak past, en tijdens het implementatieproces (als die er is) zal alles worden verduidelijkt. Dit is precies hoe het merendeel van de projectbudgetten wordt besteed aan staatsbevelen (ze krabbelden “TZ”, verloren tientallen miljoenen, maar voerden het project niet uit. Alle formaliteiten werden in acht genomen, er waren geen schuldige partijen, een nieuwe auto staat vlakbij de huis. Schoonheid!). Maar we hebben het over commerciële organisaties waar geld wordt geteld en er een ander resultaat nodig is. Laten we daarom het belangrijkste begrijpen, hoe we ons kunnen ontwikkelen nuttig en werkend. Technische specificaties.

Ik zei over de soorten eisen, maar hoe zit het met eigenschappen? Als de soorten vereisten verschillend kunnen zijn (afhankelijk van de doelstellingen van het project), dan is met eigenschappen alles eenvoudiger, er zijn er 3:

1. De eis moet zijn begrijpelijk;
2. De eis moet zijn specifiek;
3. De eis moet zijn testers;

Bovendien is de laatste eigenschap onmogelijk zonder de twee voorgaande, d.w.z. is een soort ‘lakmoesproef’. Als het resultaat van een eis niet kan worden getoetst, betekent dit dat deze onduidelijk of niet specifiek is. Denk er over na. Het is in de beheersing van deze drie eigenschappen van eisen dat beheersing en professionaliteit schuilen. Het is eigenlijk heel eenvoudig. Wanneer je er achter komt.

Hiermee is het verhaal over wat een Technische Specificatie is afgerond en gaan we verder met het belangrijkste: hoe je eisen formuleert. Maar het is niet zo snel. Er is nog een extreem belangrijk punt:

• In welke taal (in termen van moeilijkheidsgraad) moet de technische specificatie worden geschreven?
• Moet het de specificaties van verschillende functies, algoritmen, datatypen en andere technische zaken beschrijven?
• Wat is technisch ontwerp, dat overigens ook wordt vermeld in GOST's, en hoe verhoudt dit zich tot de technische specificaties?

Er zit iets heel verraderlijks verborgen in de antwoorden op deze vragen. Daarom ontstaan ​​er vaak geschillen over de toereikendheid of het gebrek aan noodzakelijke detaillering van eisen, over de begrijpelijkheid van het document door de Klant en Opdrachtnemers, over redundantie, presentatieformaat, etc. Waar ligt de grens tussen het mandaat en het technische project?

Technische taak– dit is een document gebaseerd op eisen, geformuleerd in een taal die voor de Klant begrijpelijk (gewoon, vertrouwd) is. In dit geval kan en moet brancheterminologie worden gebruikt die voor de Klant begrijpelijk is. Er mogen geen verbanden bestaan ​​met de bijzonderheden van de technische implementatie. Die. in de technische specificatiefase maakt het in principe niet uit op welk platform deze eisen worden geïmplementeerd. Hoewel er uitzonderingen zijn. Als we praten over over de implementatie van een systeem op basis van een reeds bestaand softwareproduct, dan kan een dergelijke koppeling plaatsvinden, maar alleen op het niveau van schermformulieren, rapportageformulieren etc. Het verduidelijken en formuleren van eisen, evenals het ontwikkelen van voorwaarden van Referentie moet worden uitgevoerd bedrijfsanalist. En zeker geen programmeur (tenzij hij deze rollen combineert, gebeurt dit). Die. deze persoon moet de Klant te woord staan ​​in de taal van zijn bedrijf.

Technisch project– dit is een document dat bedoeld is voor de technische implementatie van de eisen geformuleerd in het Terms of Reference. Dit document beschrijft datastructuren, triggers en opgeslagen procedures, algoritmen en andere zaken die nodig zijn technische specialisten. De klant hoeft zich hier helemaal niet in te verdiepen (zelfs dergelijke voorwaarden zijn voor hem misschien niet duidelijk). Technisch project wel Systeemarchitect(de combinatie van deze rol met een programmeur is heel normaal). Of beter gezegd: een groep JSC-specialisten onder leiding van een architect. Hoe groter het project, hoe meer mensen aan de Terms of Reference werken.

Wat hebben we in de praktijk? Het is grappig om te zien wanneer de regisseur een technische specificatie ter goedkeuring voorgeschoteld krijgt, die vol staat met technische terminologie, beschrijvingen van gegevenstypen en hun waarden, databasestructuur, enz. Hij probeert het natuurlijk te begrijpen, aangezien hij goedkeuring moet geven , in een poging bekende woorden tussen de regels door te vinden en de zakelijke vereisten van de keten niet uit het oog te verliezen. Is dit een bekende situatie? En hoe eindigt het? In de regel worden dergelijke technische specificaties goedgekeurd en vervolgens geïmplementeerd, en in 80% van de gevallen komen ze helemaal niet overeen met het feit van het uitgevoerde werk, omdat ze besloten te veranderen, veel dingen opnieuw te doen, ze verkeerd te begrijpen, verkeerd te denken, enz. enzovoort. En dan begint de serie over het inleveren van werk. ‘Maar dit is niet wat we nodig hebben’, maar ‘dit werkt niet voor ons’, ‘dit is te ingewikkeld’, ‘dit is lastig’, enz. Klinkt bekend?!! Dat komt mij bekend voor, ik heb op tijd de hobbels moeten nemen.

Wat hebben we dan in de praktijk? Maar in de praktijk hebben we een vage grens tussen het mandaat en het technische project. Ze zweeft tussen TK en TP in verschillende verschijningsvormen. En dat is slecht. Dit gebeurt omdat de ontwikkelingscultuur zwak is geworden. Dit komt deels door de competenties van specialisten, deels door de wens om budgetten en deadlines te reduceren (documentatie kost immers veel tijd - dat is een feit). Er is er nog één belangrijke factor, wat van invloed is op het gebruik van het Technisch Ontwerp als afzonderlijk document: snelle ontwikkeling fondsen snelle ontwikkeling, evenals ontwikkelingsmethoden. Maar dit is een apart verhaal; ik zal er hieronder een paar woorden over zeggen.

Nog een klein maar belangrijk punt. Soms worden de Terms of Reference een klein stukje vereisten genoemd, eenvoudig en begrijpelijk. Verbeter bijvoorbeeld het zoeken naar een object volgens bepaalde voorwaarden, voeg een kolom toe aan het rapport, enz. Deze aanpak is volkomen gerechtvaardigd, waarom zou het het leven ingewikkelder worden? Maar het wordt niet gebruikt bij grote projecten, maar bij kleine verbeteringen. Ik zou zeggen dat dit dichter bij het onderhoud van softwareproducten ligt. In dit geval kan het mandaat ook een specifieke technische oplossing beschrijven voor het implementeren van de vereiste. Bijvoorbeeld: 'Breng die en die wijziging aan in het algoritme', wat een specifieke procedure aangeeft en specifieke verandering voor een programmeur. Dit is het geval wanneer de grens tussen het mandaat en de technische projecten volledig wordt gewist, omdat er is geen economische haalbaarheid om het papierwerk op te blazen waar het niet nodig is, maar er wordt wel een nuttig document gecreëerd. En het klopt.

Is technische specificatie überhaupt nodig? Hoe zit het met het technische project?

Ben ik oververhit? Is dit mogelijk zonder Technische specificaties? Stel je voor dat het mogelijk is (of beter gezegd, het is mogelijk), en deze aanpak heeft veel volgers, en hun aantal groeit. In de regel nadat jonge specialisten boeken hebben gelezen over Scrum, Agile en andere snelle ontwikkelingstechnologieën. In feite zijn dit prachtige technologieën, en ze werken, maar ze zeggen niet letterlijk ‘het is niet nodig om technische taken uit te voeren’. Ze zeggen ‘een minimum aan papierwerk’, vooral onnodig papierwerk, dichter bij de klant, meer details en snellere resultaten. Maar niemand heeft de registratie van eisen geannuleerd, en dit staat daar duidelijk vermeld. Het is daar dat de eisen worden vastgesteld op basis van de drie opmerkelijke eigenschappen die ik hierboven noemde. Het is gewoon zo dat de geest van sommige mensen zo is gestructureerd dat als iets kan worden vereenvoudigd, we het dan moeten vereenvoudigen tot het punt van volledige afwezigheid. Zoals Einstein zei: " Maak het zo eenvoudig mogelijk, maar niet eenvoudiger dan dat.” . Dit zijn gouden woorden die bij alles passen. Dus Technische taak nodig, anders zie je geen succesvol project. Een andere vraag is hoe je het moet samenstellen en wat je daarin moet opnemen. In het licht van de snelle ontwikkelingsmethodologieën hoeft u zich alleen op de vereisten te concentreren en kunt u alle ‘camouflage’ achterwege laten. In principe ben ik het hier mee eens.

Hoe zit het met het technische project? Dit document is zeer nuttig en heeft zijn relevantie niet verloren. Bovendien kun je vaak gewoon niet zonder. Vooral als het gaat om het uitbesteden van ontwikkelingswerk. op het principe van uitbesteding. Doe je dit niet, dan loop je het risico veel te leren over hoe het systeem dat jij voor ogen hebt er uit moet zien. Moet de klant ermee vertrouwd raken? Als hij wil, waarom niet, maar het is niet nodig om dit document aan te dringen en goed te keuren; het zal het werk alleen maar belemmeren en belemmeren. Het is bijna onmogelijk om een ​​systeem tot in het kleinste detail te ontwerpen. In dit geval zul je voortdurend wijzigingen moeten aanbrengen in het Technisch Ontwerp, wat veel tijd kost. En als de organisatie zwaar bureaucratisch is, laat je al je zenuwen daar achter. Het terugdringen van dit soort ontwerp is precies waar de moderne snelle ontwikkelingsmethodologieën, die ik hierboven noemde, over gaan. Ze zijn trouwens allemaal gebaseerd op de klassieke XP (extreme programmering) - een aanpak die al zo'n 20 jaar oud is. Maak daarom een ​​hoogwaardige Technische Specificatie die begrijpelijk is voor de Klant en gebruik het Technisch Ontwerp als intern document voor de relatie tussen systeemarchitect en programmeurs.

Interessant detail Wat betreft technisch ontwerp: sommige ontwikkelingstools die op een onderwerpgerichte basis zijn ontworpen (zoals 1C en dergelijke) gaan ervan uit dat ontwerp (dat wil zeggen het documentatieproces) alleen nodig is in echt complexe gebieden waar interactie tussen hele subsystemen vereist is. In het eenvoudigste geval, bijvoorbeeld het maken van een directory of document, zijn alleen correct geformuleerde bedrijfsvereisten voldoende. Dit blijkt ook uit de bedrijfsstrategie van dit platform op het gebied van het opleiden van specialisten. Als je naar de examenkaart van een specialist kijkt (zo wordt het genoemd, niet een ‘programmeur’), zul je zien dat er alleen zakelijke vereisten zijn, en hoe je deze kunt implementeren programmeertaal Dit is de taak van een specialist. Die. dat deel van het probleem dat het technisch project moet oplossen, moet de specialist ‘in zijn hoofd’ (we hebben het over taken van gemiddelde complexiteit) hier en nu oplossen, volgens bepaalde ontwikkelings- en ontwerpstandaarden, die opnieuw worden gevormd door het 1C-bedrijf voor zijn platform. Van twee specialisten waarvan de werkresultaten identiek lijken, kan de een wel slagen voor het examen, maar de ander niet, omdat op flagrante wijze de ontwikkelingsnormen geschonden. Dat wil zeggen dat er uiteraard van wordt uitgegaan dat specialisten over zodanige kwalificaties moeten beschikken dat zij zelfstandig typische taken kunnen ontwerpen, zonder tussenkomst van systeemarchitecten. En deze aanpak werkt.

Laten we de vraag blijven bestuderen: "Welke vereisten moeten in de Terms of Reference worden opgenomen?"

Formuleren van eisen aan het informatiesysteem. Structuur van het mandaat

Laten we meteen duidelijk zijn: we zullen het specifiek hebben over het formuleren van eisen aan een informatiesysteem, d.w.z. ervan uitgaande dat het werk aan het ontwikkelen van zakelijke vereisten, het formaliseren van bedrijfsprocessen en al het voorgaande advieswerk al is voltooid. Natuurlijk kunnen er in dit stadium enkele verduidelijkingen worden aangebracht, maar dat zijn slechts verduidelijkingen. Het automatiseringsproject zelf lost geen bedrijfsproblemen op - onthoud dit. Dit is een axioma. Om de een of andere reden proberen sommige managers dit te weerleggen, in de overtuiging dat als ze het programma kopen, er orde in een chaotische onderneming zal komen. Maar een axioma is een axioma omdat er geen bewijs voor nodig is.

Zoals bij elke activiteit kan (en moet) het formuleren van eisen in fasen worden verdeeld. Alles op zijn tijd. Dit is zwaar intellectueel werk. En als u het met onvoldoende aandacht behandelt, zal het resultaat passend zijn. Volgens schattingen van deskundigen kunnen de kosten voor het ontwikkelen van het mandaat 30-50% bedragen. Ik ben dezelfde mening toegedaan. Hoewel 50 misschien wel te veel is. De Technische Specificatie is er immers nog niet laatste document, die ontwikkeld moet worden. Er moet immers ook sprake zijn van technisch ontwerp. Deze spreiding is het gevolg verschillende platforms automatisering, benaderingen en technologieën die door projectteams worden gebruikt tijdens de ontwikkeling. Als we het bijvoorbeeld hebben over ontwikkeling in een klassieke taal als C++, dan is gedetailleerd technisch ontwerp onmisbaar. Als we het hebben over het implementeren van een systeem op het 1C-platform, dan is de situatie met het ontwerp enigszins anders, zoals we hierboven zagen (hoewel het bij het helemaal opnieuw ontwikkelen van een systeem wordt ontworpen volgens klassiek schema).

Hoewel de eisenverklaring het belangrijkste onderdeel is Technische specificaties, en in sommige gevallen wordt dit het enige deel van de technische specificaties, moet u erop letten dat dit een belangrijk document is en dat het dienovereenkomstig moet worden opgesteld. Waar te beginnen? Allereerst moet je beginnen met de inhoud. Schrijf de inhoud en begin deze vervolgens uit te breiden. Persoonlijk doe ik dit: eerst schets ik de inhoud, beschrijf de doelen, alle inleidende informatie en ga dan over op het belangrijkste deel: het formuleren van de vereisten. Waarom niet andersom? Ik weet het niet, het is handiger voor mij. Ten eerste is dit een veel kleiner deel van de tijd (vergeleken met de vereisten), en ten tweede stem je, terwijl je alle inleidende informatie beschrijft, af op het belangrijkste. Nou ja, wie het maar leuk vindt. Na verloop van tijd zult u uw eigen sjabloon voor technische specificaties ontwikkelen. Om te beginnen raad ik aan om precies de inhoud te nemen die wordt beschreven in GOST. Het is perfect voor de inhoud! Vervolgens nemen we elke sectie en beginnen we deze te beschrijven, waarbij we de aanbevelingen van de volgende drie eigenschappen niet vergeten: begrijpelijkheid, specificiteit en testbaarheid. Waarom blijf ik hier zo op hameren? Meer hierover in de volgende sectie. En nu stel ik voor om die punten van de technische specificaties door te nemen die worden aanbevolen in GOST.

1. algemene informatie;
2. doel en doelstellingen van de creatie (ontwikkeling) van het systeem;
3. kenmerken van automatiseringsobjecten;
4. systeem vereisten;
5. samenstelling en inhoud van het werk om het systeem te creëren;
6. procedure voor controle en acceptatie van het systeem;
7. vereisten voor de samenstelling en inhoud van het werk om het automatiseringsobject voor te bereiden voor de inbedrijfstelling van het systeem;
8. documentatie-eisen;
9. ontwikkelingsbronnen.

In totaal 9 secties, die elk ook weer zijn onderverdeeld in subsecties. Laten we ze in volgorde bekijken. Voor het gemak presenteer ik alles in de vorm van een tabel voor elk item.

Sectie 1. algemene informatie.

Aanbevelingen volgens GOST
volledige naam van het systeem en zijn symbool;	Alles is hier duidelijk: we schrijven hoe het systeem zal heten, de korte naam
onderwerpcode of code (nummer) van het contract;	Dit is niet relevant, maar u kunt dit desgewenst wel specificeren
de naam van de ondernemingen (verenigingen) van de ontwikkelaar en klant (gebruiker) van het systeem en hun gegevens;	geef aan wie (welke organisaties) aan het project gaan werken. Je kunt ook hun rollen specificeren, je kunt deze sectie zelfs verwijderen (redelijk formeel).
een lijst met documenten op basis waarvan het systeem tot stand is gekomen, door wie en wanneer deze documenten zijn goedgekeurd;	Hulpvolle informatie. Hier dient u de regelgevings- en referentiedocumentatie aan te geven die aan u is verstrekt om vertrouwd te raken met een bepaald deel van de vereisten
geplande start- en einddata voor de werkzaamheden aan het creëren van het systeem;	Verzoeken om timing. Soms schrijven ze hierover in de technische specificaties, maar vaker staan ​​dergelijke zaken beschreven in arbeidscontracten
informatie over de bronnen en procedure voor financiering van de werkzaamheden;	Hetzelfde als in de vorige paragraaf over deadlines. Relevanter voor bevelen van de overheid(voor staatspersoneel)
procedure voor registratie en presentatie aan de klant van de resultaten van het werk aan het creëren van het systeem (de onderdelen ervan), productie en inbedrijfstelling aparte fondsen(technische, software, informatie) en software en hardware (software en methodologische) complexen van het systeem.	Ik zie de noodzaak van dit punt niet, omdat... Documentatievereisten worden apart vastgelegd en daarnaast is er een heel apart hoofdstuk “Procedure voor controle en acceptatie” van het systeem.

Sectie 2. doel en doelstellingen van creatie (ontwikkeling) van het systeem.

Aanbevelingen volgens GOST	Wat je er in de praktijk aan kunt doen
Doel van het systeem	Aan de ene kant is het doel eenvoudig. Maar het is raadzaam om het specifiek te formuleren. Als je zoiets schrijft als ‘hoogwaardige automatisering van de magazijnboekhouding in bedrijf X’, dan kun je na voltooiing nog lang discussiëren over het resultaat, zelfs ongeacht de goede formulering van de eisen. Omdat De klant kan altijd zeggen dat hij met kwaliteit iets anders bedoelde. Over het algemeen kun je elkaars zenuwen flink bederven, maar waarom? Het is beter om meteen zoiets als dit te schrijven: "Het systeem is ontworpen om magazijngegevens in bedrijf X bij te houden in overeenstemming met de vereisten die zijn gespecificeerd in deze technische specificatie."
Doelstellingen van het creëren van het systeem	Doelen zijn zeker een belangrijk onderdeel. Als we het willen opnemen, moeten we deze doelen kunnen formuleren. Als u moeite heeft met het formuleren van doelen, kunt u dit onderdeel beter helemaal uitsluiten. Een voorbeeld van een niet succesvol doel: ‘Zorg ervoor dat de manager documenten snel invult.’ Wat is snel? Dit kan dan eindeloos bewezen worden. Als dit belangrijk is, is het beter om te herformuleren het doel zo: “De verkoopmanager zou in 10 minuten een document ‘Verkoop van goederen’ van 100 regels moeten kunnen opstellen.” Een dergelijk doel kan zich voordoen als een manager daar momenteel bijvoorbeeld ongeveer een uur aan besteedt, wat voor dat bedrijf te veel is en belangrijk voor hem. In deze formulering kruist het doel al de vereisten, wat heel natuurlijk is, omdat wanneer we de boom met doelen uitbreiden (d.w.z. ze opsplitsen in kleinere, samenhangende doelen), komen we al dichter bij de vereisten. Daarom moet u zich niet laten meeslepen.

Over het algemeen is het vermogen om doelen te identificeren, te formuleren en een boom van doelen op te bouwen een heel ander onderwerp. Onthoud het belangrijkste: als je weet hoe, schrijf, als je het niet zeker weet, schrijf dan helemaal niet. Wat gebeurt er als je geen doelen formuleert? Je gaat werken volgens de eisen, dit wordt vaak in de praktijk gebracht.

Sectie 3. Kenmerken van automatiseringsobjecten.

Sectie 4. Systeemvereisten

GOST ontcijfert de lijst met dergelijke vereisten:

• vereisten voor de structuur en het functioneren van het systeem;
• vereisten voor het aantal en de kwalificaties van systeempersoneel en hun werkwijze;
• bestemmingsindicatoren;
• betrouwbaarheidseisen;
• veiligheidseisen;
• vereisten voor ergonomie en technische esthetiek;
• transporteerbaarheidseisen voor mobiele luidsprekers;
• vereisten voor bediening, onderhoud, reparatie en opslag van systeemcomponenten;
• vereisten voor het beschermen van informatie tegen ongeoorloofde toegang;
• eisen voor de veiligheid van informatie bij ongevallen;
• vereisten voor bescherming tegen externe invloeden;
• vereisten voor de zuiverheid van patenten;
• vereisten voor standaardisatie en unificatie;

Ondanks het feit dat de belangrijkste uiteraard de sectie zal zijn met specifieke vereisten (functioneel), kan deze sectie dat ook hebben groot belang(en dat is in de meeste gevallen ook zo). Wat belangrijk en nuttig kan zijn:

• Kwalificatievereisten. Het is mogelijk dat het systeem dat wordt ontwikkeld een herscholing van specialisten vereist. Dit kunnen net als gebruikers zijn toekomstig systeem, evenals de IT-specialisten die nodig zullen zijn om dit te ondersteunen. Onvoldoende aandacht voor dit onderwerp leidt vaak tot problemen. Als de kwalificaties van het bestaande personeel duidelijk onvoldoende zijn, is het beter om eisen te stellen aan de organisatie van de training, het trainingsprogramma, de timing, enz.
• Vereisten voor het beschermen van informatie tegen ongeoorloofde toegang. Geen opmerkingen hier. Dit zijn precies de vereisten voor het afbakenen van de toegang tot gegevens. Als dergelijke eisen worden gepland, moeten ze afzonderlijk en zo gedetailleerd mogelijk worden geschreven, volgens dezelfde regels als functionele eisen (begrijpbaarheid, specificiteit, testbaarheid). Deze eisen kunnen daarom worden opgenomen in de paragraaf met functionele eisen
• Vereisten voor standaardisatie. Als er ontwerpnormen zijn die van toepassing zijn op het project, kunnen deze worden opgenomen in de eisen. In de regel worden dergelijke eisen geïnitieerd door de IT-dienst van de Klant. Het bedrijf 1C heeft bijvoorbeeld ontwerpvereisten programmacode, interfaceontwerp, enz.;
• Vereisten voor de structuur en het functioneren van het systeem. Hier kunnen de vereisten voor het met elkaar integreren van systemen worden beschreven, er wordt een beschrijving gegeven algemene architectuur. Vaker worden integratievereisten over het algemeen opgesplitst in een afzonderlijk hoofdstuk of zelfs in een afzonderlijke technische specificatie, omdat deze vereisten kunnen behoorlijk complex zijn.

Alle overige eisen zijn minder belangrijk en behoeven niet beschreven te worden. Naar mijn mening maken ze de documentatie alleen maar zwaarder en hebben ze weinig praktisch voordeel. En het is heel moeilijk om ergonomische eisen te beschrijven in de vorm van algemene eisen; het is beter om ze om te zetten in functionele eisen. Zo kan bijvoorbeeld de eis ‘Krijg informatie over de prijs van een product door op slechts één knop te drukken’ worden geformuleerd. Naar mijn mening ligt dit nog dichter bij specifieke functionele vereisten, hoewel het verband houdt met ergonomie Vereisten voor functies (taken) die door het systeem worden uitgevoerd Dit is het belangrijkste en belangrijkste punt dat het succes zal bepalen. Zelfs als al het andere perfect is gedaan en deze sectie "3" is, zal het resultaat van het project dat zijn in het gunstigste geval op “3”, anders zal het project zelfs helemaal mislukken. Hier gaan we dieper op in in het tweede artikel, dat in het vijfde nummer van de nieuwsbrief zal worden opgenomen. Het is op dit punt dat de ‘regel van drie eigenschappen van vereisten’ waar ik het over had, van toepassing is.

GOST identificeert de volgende typen:

• Wiskundig
• Informatief
• Taalkundig
• Software
• Technisch
• Metrologisch
• Organisatorisch
• Methodisch
• en anderen…

Op het eerste gezicht lijken deze vereisten misschien onbelangrijk. Bij de meeste projecten is dit het geval. Maar niet altijd. Wanneer moet u deze vereisten beschrijven:

• Er zijn geen beslissingen genomen over welke taal- (of platform-)ontwikkeling zal worden uitgevoerd;
• Het systeem vereist een meertalige interface (bijvoorbeeld Russisch/Engels)
• Om het systeem te laten functioneren, moet er een aparte eenheid worden gecreëerd of moeten er nieuwe medewerkers worden aangenomen;
• Om het systeem te laten functioneren moet de Klant veranderingen in de werkwijze ondergaan en deze veranderingen moeten gespecificeerd en gepland zijn;
• Integratie met welke apparatuur dan ook wordt verwacht en er worden eisen aan gesteld (bijvoorbeeld certificering, compatibiliteit, etc.)
• Andere situaties zijn mogelijk, het hangt allemaal af van de specifieke doelstellingen van het project.

Sectie 5. Samenstelling en inhoud van het werk om het systeem te creëren

Sectie 6. Procedure voor controle en acceptatie van het systeem

Algemene vereisten voor de acceptatie van werk in fasen (lijst van deelnemende bedrijven en organisaties, plaats en timing), procedure voor coördinatie en goedkeuring van acceptatiedocumentatie; Ik raad u ten zeerste aan om de verantwoordelijkheid te nemen voor de procedure voor het indienen van werk en het controleren van het systeem. Dit is precies de reden waarom er toetsbare eisen nodig zijn, maar zelfs de aanwezigheid van toetsbare eisen is mogelijk niet voldoende als het systeem wordt opgeleverd als de procedure voor acceptatie en overdracht van werk niet duidelijk is vastgelegd. Een veel voorkomende valkuil bijvoorbeeld: het systeem is gebouwd en volledig operationeel, maar de klant is om de een of andere reden nog niet klaar om erin te werken. Deze redenen kunnen allerlei zijn: geen tijd, doelen zijn veranderd, iemand is gestopt, enz. En hij zegt: “Aangezien we nog niet in het nieuwe systeem werken, kunnen we er niet zeker van zijn dat het werkt.” Leer dus de werkfasen correct te identificeren en hoe u de resultaten van deze fasen kunt controleren. Bovendien moeten dergelijke werkwijzen vanaf het begin duidelijk zijn voor de Klant. Als ze zijn vastgelegd op het niveau van de Technische Specificaties, dan kun je er indien nodig altijd terecht en de werkzaamheden afronden met de overdracht.

Paragraaf 7. Vereisten voor de samenstelling en inhoud van de werkzaamheden om het automatiseringsobject voor te bereiden op de inbedrijfstelling van het systeem

Er kunnen andere regels zijn voor het invoeren van informatie die door het bedrijf zijn aangenomen (of gepland). Informatie over een contract werd vroeger bijvoorbeeld als tekststring in welke vorm dan ook ingevoerd, maar nu is een apart nummer, een aparte datum, etc. vereist. Er kunnen veel van dergelijke omstandigheden zijn. Sommigen van hen kunnen met weerstand van het personeel worden ervaren, dus het is beter om al dergelijke gevallen te registreren op het niveau van vereisten voor de volgorde van gegevensinvoer.

Het creëren van voorwaarden voor het functioneren van het automatiseringsobject, waaronder de conformiteit van het gecreëerde systeem met de eisen opgenomen in de technische specificaties is gegarandeerd. Eventuele wijzigingen die nodig zijn. Dat heeft het bedrijf bijvoorbeeld niet het lokale netwerk, een verouderde vloot computers waarop het systeem niet zal werken.

Misschien is een aantal noodzakelijke informatie op papier verwerkt en moet deze nu in het systeem worden ingevoerd. Als u dit niet doet, zal een bepaalde module niet werken, enz.

Misschien is iets vereenvoudigd, maar nu moet er meer in detail rekening mee worden gehouden, dus iemand moet informatie verzamelen volgens bepaalde regels.

Deze lijst kan lang zijn, kijk naar het specifieke geval van uw project Oprichting van afdelingen en diensten die nodig zijn voor het functioneren van het systeem;

Timing en procedure voor personeelsbezetting en training We hebben hier al eerder over gesproken. Misschien wordt het systeem ontwikkeld voor een nieuwe structuur of soort activiteit die voorheen niet bestond. Als er geen geschikt personeel is, en zelfs niet opgeleid personeel, zal het systeem niet werken, hoe vakkundig het ook is gebouwd.

Sectie 8. Documentatievereisten

Bedenk hoe gebruikershandleidingen zullen worden gepresenteerd.

Misschien heeft de klant de bedrijfsnormen geaccepteerd, wat betekent dat we ernaar moeten verwijzen.

Het negeren van documentatievereisten leidt vaak tot de meest onverwachte gevolgen voor projecten. Alles is bijvoorbeeld gedaan en alles werkt. Gebruikers weten ook hoe ze moeten werken. Er was helemaal geen overeenstemming of gesprek over documentatie. En plotseling, bij de overdracht van het werk, vraagt ​​een van de topmanagers van de klant, die niet eens aan het project heeft deelgenomen, maar wel betrokken is bij de aanvaarding van het werk, u: “Waar zijn de gebruikershandleidingen?” En het begint je ervan te overtuigen dat het niet nodig was om het eens te worden over de beschikbaarheid van gebruikershandleidingen, dit wordt “natuurlijk” zogenaamd geïmpliceerd. En dat is het, hij wil je baan niet overnemen. Op wiens kosten gaat u de richtlijnen ontwikkelen? Veel teams zijn al voor deze haak gevallen.

Sectie 9. Ontwikkelingsbronnen

Daarom is het beter om eenvoudigweg te verwijzen naar het onderzoeksrapport en de behoeften van sleutelpersonen.

En dus hebben we alle secties overwogen die in de Terms of Reference kunnen worden opgenomen. ‘Kan’ en niet ‘moet’, juist omdat elk document moet worden ontwikkeld om een ​​resultaat te bereiken. Daarom, als het voor u duidelijk is dat een bepaald gedeelte u niet dichter bij het resultaat zal brengen, dan heeft u het niet nodig en hoeft u er geen tijd aan te verspillen.

Maar geen enkele competente technische specificatie kan zonder het belangrijkste: functionele eisen. Ik wil graag constateren dat dergelijke Technische Specificaties in de praktijk voorkomen, en hoe! Er zijn mensen die de wateren in alle secties kunnen scheiden, de algemene vereisten in algemene termen kunnen beschrijven, en het document blijkt erg zwaar te zijn, en er zitten veel slimme woorden in, en zelfs de klant vindt het misschien leuk (dat wil zeggen, hij zal het goedkeuren). Maar het kan zijn dat het niet volgens deze methode werkt, d.w.z. Het heeft weinig praktisch nut. In de meeste gevallen worden dergelijke documenten geboren als u specifiek voor de Terms of Reference veel geld nodig heeft, maar dit moet snel gebeuren en zonder in details te duiken. En vooral als bekend is dat de zaak niet verder zal gaan, of dat heel andere mensen het zullen doen. Over het algemeen alleen maar om de begroting te beheren, vooral de staatsbegroting.

In het tweede artikel zullen we het alleen hebben over paragraaf 4 “Systeemvereisten”, en specifiek zullen we eisen formuleren om redenen van duidelijkheid, specificiteit en testbaarheid.

Waarom eisen duidelijk, specifiek en toetsbaar moeten zijn.

Omdat de praktijk leert: in eerste instantie blijken de meeste technische specificaties die door specialisten zijn ontwikkeld niet in trek te zijn (komen niet overeen met de realiteit), of worden ze een probleem voor degene die ze moet implementeren, omdat De klant begint vage termen en eisen te manipuleren. Ik zal een paar voorbeelden geven van welke zinsneden we tegenkwamen, waar dit toe leidde, en daarna zal ik proberen aanbevelingen te doen over hoe dergelijke problemen kunnen worden vermeden.

Is deze eis toetsbaar? Het lijkt eenvoudig, maar hoe kun je het controleren als er geen bijzonderheden zijn?

Hoe kan dit opnieuw worden geformuleerd: “Het bedrag aan kosten dat in het document is gespecificeerd, moet worden verdeeld over alle goederen die zijn gespecificeerd in het document dit document in verhouding tot de waarde van deze goederen." Het bleek zowel duidelijk als specifiek. Hoe te controleren is ook niet moeilijk.

Ergonomie Het programma moet een gebruiksvriendelijke interface hebben, ik moet toegeven dat ik me ooit zelf op deze formulering heb moeten abonneren - later waren er talloze problemen. Dergelijke formuleringen zouden natuurlijk niet mogen bestaan. Er zijn hier geen bijzonderheden, noch de mogelijkheid om deze vereiste te verifiëren. Hoewel het natuurlijk begrijpelijk is (subjectief). Er is geen manier om het te herformuleren; elk element van “gemak” moet in detail worden beschreven, aangezien de Klant erop aandringt. Bijvoorbeeld:

• Lijnen moeten aan het document worden toegevoegd door op de knop "Toevoegen" te klikken en door op de toets "Invoegen" te drukken, en door de gebruiker een deel van de naam in te voeren;
• Bij het bekijken van een lijst met producten moet het mogelijk zijn om te zoeken op naam, barcode en artikel;
• Enz.

Differentiatie van toegangsrechtenToegang tot winstgegevens zou alleen beschikbaar moeten zijn voor de financieel directeur, is dat duidelijk? Bijna. Het is waar dat de winsten variëren, we moeten dit verduidelijken. Natuurlijk niet. Hoe ziet dit er in de uitvoering uit? Als we het hebben over de brutowinst, dan is het noodzakelijk om de toegang tot gegevens over de aankoopkosten te beperken, omdat anders zal de brutowinst niet moeilijk te berekenen zijn, aangezien gegevens over de verkoopkosten bij een groot aantal mensen bekend zijn. Wat de toegangsrechten betreft, moet zeer zorgvuldig worden omgegaan. En als de motivatie van verkoopmanagers gebaseerd is op de brutowinst, dan spreken deze eisen elkaar ook tegen, omdat managers zullen dit nooit kunnen verifiëren. Als we een dergelijke eis willen opnemen, moeten we specifieke rapporten en systeemobjecten specificeren die aangeven welk deel van de gegevens beschikbaar moet zijn voor bepaalde categorieën personen. En beschouw elk van deze gevallen afzonderlijk. Productiviteit Het verkooprapport zou binnen 1 minuut moeten worden gegenereerd. Ja, ik begrijp het. En er is zelfs een specifieke tijdslimiet: 1 minuut. Maar als het niet bekend is wat voor detaillering er verwacht wordt: per product, productgroep, klant of iets anders, dan kan het ongeveer zo geformuleerd worden: “Een verkooprapport per klant met details per productitem (zie voorbeeld) moet mag niet langer dan 1 minuut worden weergegeven, op voorwaarde dat het aantal producten in het monster niet groter is dan 5000 regels.”

Ik hoop dat het idee duidelijk is. Als je specifieke vragen hebt, schrijf dan, ik zal proberen te helpen.

Naar Referentievoorwaarden er waren meer details, er zijn veel aanbevelingen. Er is zelfs een lijst met woorden die niet worden aanbevolen in de technische specificaties. K. Wiegers schrijft hierover interessant in zijn boek ‘Ontwikkeling van Softwarevereisten’. Ik zal naar mijn mening de meest interessante en eenvoudige aanbevelingen geven:

• Gebruik geen woorden die veel synoniemen hebben. Als dit nodig is, is het beter om een ​​duidelijke definitie van de term te geven in het onderdeel ‘Termen en definities’ van de Terms of Reference.
• Probeer geen lange zinnen te gebruiken;
• Als een vereiste u te algemeen lijkt, moet deze worden uitgewerkt in kleinere maar specifieke vereisten;
• Gebruik meer schema's, grafieken, tabellen, tekeningen - op deze manier wordt informatie veel gemakkelijker waargenomen;
• Te vermijden woorden zijn: “effectief”, “adequaat”, “eenvoudig”, “duidelijk”, “snel”, “flexibel”, “verbeterd”, “optimaal”, “transparant”, “duurzaam”, “voldoende”, “ vriendelijk”, “gemakkelijk”, enz. De lijst kan worden voortgezet, maar ik denk dat het idee duidelijk is (probeer het zelf voort te zetten).

Alles wat hierboven is geschreven, is belangrijke informatie, maar niet het belangrijkste. Zoals je je herinnert, noemde ik dit aan het begin van het artikel de term ‘camouflage’, omdat. het belangrijkste dat minstens 90% van de tijd en complexiteit van het werken aan een document zal uitmaken, is het identificeren en formuleren van vereisten. En je moet nog steeds informatie over eisen kunnen verzamelen, structureren en formuleren. Dit heeft overigens veel gemeen tussen een overzicht van bedrijfsactiviteiten en een daaropvolgende beschrijving van bedrijfsprocessen. Maar er zijn ook belangrijke verschillen. Een van deze belangrijkste verschillen is de aanwezigheid van de fase waarin een prototype van het toekomstige systeem wordt gebouwd, of zoals het ook wel het “informatiesysteemmodel” wordt genoemd.

In het volgende artikel zullen we alleen praten over methoden voor het identificeren van vereisten, en ook overwegen wat gemeenschappelijk is tussen het verzamelen van vereisten voor een informatiesysteem en het verzamelen van informatie om bedrijfsprocessen te beschrijven.

Soorten werk bij het verzamelen van vereisten voor een boekhoudsysteem en informatie om bedrijfsprocessen te beschrijven. Deel 2

In dit deel zullen we bespreken hoe we de fase van het verzamelen van eisen kunnen organiseren, waaruit deze moet bestaan ​​en welke hulpmiddelen kunnen worden gebruikt. Ik herhaal dat dit werk, vanuit het oogpunt van fasen, sterk lijkt op een onderzoek van een onderneming om bedrijfsprocessen te beschrijven.

Zoals meestal gebeurt in het leven:

Zo gaat dat bij de meeste projecten.
	Hoe gebeurde dit
	Het is duidelijk dat er reden tot vreugde is, vooral als het project groot is, daar is niets mis mee! Het belangrijkste is om je niet te lang te verheugen, het uitstellen van de start van het daadwerkelijke werk, vanaf nu zal de tijd anders verlopen.
	Meestal beperkt dit proces zich tot meerdere gesprekken met het management en vervolgens met afdelingshoofden. Nadat bepaalde “drangen” van de kant van de Klant zijn vastgelegd, worden deze vastgelegd in de vorm van algemene formuleringen. Soms wordt hieraan bestaande documentatie toegevoegd (iemand heeft ooit geprobeerd een onderzoek uit te voeren, documenten volgens bestaande regelgeving, gebruikte rapportageformulieren). Verrassend genoeg roept de meerderheid van de implementeerders van automatiseringssystemen hierna vrolijk uit: “Ja, ons systeem heeft dit allemaal ! Nou, pas het een beetje aan en alles zal werken. Op de vraag of we met eindgebruikers moeten bespreken hoe iets zou moeten werken (of hoe een bepaald proces wordt uitgevoerd), is het antwoord meestal nee. De mening wordt geuit dat de leider alles weet voor zijn ondergeschikten. Maar tevergeefs... Daarachter schuilen veel valkuilen en obstakels, en het inleveren van werk kan uitmonden in een marathon langs een hindernisbaan. Zoals je weet is het gebruikelijk om een ​​marathon op een vlakke weg te lopen, en rennen met obstakels is alleen mogelijk over korte afstanden (het kan zijn dat je niet eens finisht).
Documenteren van werkresultaten	Hierna begint de documentatie van de resultaten, afhankelijk van de doelstellingen van het werk: als het nodig is om een ​​technische specificatie te ontwikkelen, begint de consultant de ontvangen informatie in een voorbereid documentsjabloon te plaatsen, zodat het er mooi uitziet en aan de belangrijkste vereisten wordt voldaan. opgenomen (die door het management zijn ingesproken, anders keuren ze het misschien niet goed). Omdat hij begrijpt dat dergelijke Terms of Reference in de praktijk niet bijzonder worden gebruikt en dat alles ‘onderweg’ moet worden uitgezocht, stelt hij het belangrijkste doel van de Terms of Reference vast als de minimale tijd voor coördinatie en goedkeuring. En, indien mogelijk, informatie voor een ruwe schatting van de kosten van toekomstig werk (trouwens ook belangrijk). Als u bedrijfsprocessen moet beschrijven. Vreemd genoeg, maar vaak lijken alle voorgaande acties op elkaar, zoals het geval is bij de ontwikkeling van Technische Specificaties. Het enige verschil zit in de documentatie. Hier zijn opties: consultants beschrijven het proces in willekeurige woorden of gebruiken regels voor het beschrijven van bedrijfsprocessen (notaties). In het eerste geval blijkt zo’n document verrassend veel op de Technische Specificaties te lijken. Het komt zelfs voor dat als je de titelpagina vervangt, je geen verschil ziet.In dit laatste geval ligt de nadruk vaak niet op het voldoen aan de werkelijkheid, maar op de ‘juistheid van de beschrijving’, dat wil zeggen: formele naleving van de beschrijvingsregels Helaas zijn beide opties niet de meest beste oefening, omdat zijn meer een formaliteit en leveren niet veel voordeel op.

Waarom ontwikkelde de praktijk zich zoals hierboven beschreven? Eerlijk gezegd weet ik het niet. Vraag het aan iemand, niemand weet het. Tegelijkertijd verandert de situatie niet erg snel, hoewel mensen dit onderwerp voortdurend bespreken, ervaringen uitwisselen, boeken schrijven... Het lijkt mij dat een van de redenen is lage kwaliteit passend onderwijs. Het kan ook komen doordat veel specialisten uit andere bedrijven komen en alles in de praktijk leren. hun ervaring wordt gevormd in de omgeving waarin zij zich bevinden. De houding van universiteiten en hun gebrek aan verlangen om dichter bij de werkelijkheid te staan ​​is ook een bekend feit, maar soms ben ik verrast door hun standpunt. Ik had bijvoorbeeld een geval waarin een afgestudeerde student, een getalenteerde specialist, een scriptie wilde schrijven over het 1C-platform (een goede sectorontwikkeling), maar de afdeling vertelde haar dat ze, ongeacht het onderwerp, niet kon rekenen op een “ uitstekend” cijfer, omdat 1C is geen serieus systeem. Het punt hier is niet de ernst en objectiviteit van deze mening, maar het feit dat een primitieve taak in een klassieke programmeertaal onmiddellijk een "uitstekende" beoordeling waardig werd geacht.

Laten we proberen het hierboven besproken proces verder uit te werken systeem benadering. Hoe zou hij er dan uit kunnen zien?

Zoals je ziet eindigt het proces met een vraag, omdat Op dit punt is het werk nog lang niet klaar, en dan zal het moeilijkste en meest praktische beginnen - precies wat de toepasbaarheid van het verkregen resultaat zal bepalen in echte leven. Dit is precies wat het lot van het vorige werk zal bepalen: óf het gaat naar de kast (op een plank of ergens anders), óf het zal een waardevolle bron van informatie vormen. En nog beter als het een model wordt voor volgende projecten.

Ik zou vooral willen opmerken dat tot de laatste stap in het diagram (waar de vraag is) het algemene principe van het verzamelen van informatie over de activiteiten van het bedrijf er hetzelfde uitziet, ongeacht wat u in de toekomst van plan bent te doen, bedrijfsprocessen te beschrijven of implementeren van een geautomatiseerd systeem. Ja, de volgorde van de stappen zelf is hetzelfde, maar de hulpmiddelen die bij sommige stappen worden gebruikt, kunnen verschillen. We zullen dit punt zeker overwegen als we de methoden en hulpmiddelen van individuele fasen bestuderen. We zullen dit in afzonderlijke artikelen in detail doen, maar nu zullen we alleen de belangrijkste dingen bespreken. Verdere stappen zullen verschillen en zullen worden bepaald door wat er van het project wordt verlangd: bedrijfsprocessen beschrijven of een boekhoudsysteem implementeren.

Laten we eens kijken hoe we de aanpak van het verzamelen van informatie over de activiteiten van een bedrijf kunnen reorganiseren.

Hoe dit kan gebeuren met een competentere werkorganisatie
	Hoe gebeurde dit
De beslissing is genomen, het project gaat van start!	Hier verandert niets ten opzichte van de eerste optie, emoties zijn niet geannuleerd
We hebben een bijeenkomst gehad met de managers en informatie verzameld over hun visie op het resultaat.	Ook deze stap blijft bestaan ​​en is van groot belang. Maar het voornaamste doel van de eerste bijeenkomst (of meerdere bijeenkomsten) met managers en eigenaren is om elkaar te leren kennen. Eerst de mensen en het bedrijf leren kennen. De doelen en wensen die op zulke algemene vergaderingen worden geformuleerd, kunnen heel verschillend zijn, zelfs fantastisch. Er zal uiteraard naar ze allemaal worden geluisterd, maar het is geen feit dat ze ten uitvoer zullen worden gelegd. Met meer diepe duik In de bedrijfsvoering van het bedrijf zullen andere doelen verschijnen en eerdere doelen worden afgewezen. Wat ik bedoel is dat het onmogelijk is om duidelijke doelen te formuleren op basis van voorbereidende bijeenkomsten; dit alles zal een zorgvuldige studie vereisen. Bij dergelijke bijeenkomsten is het noodzakelijk om aantekeningen te maken van alle berichten van de eigenaren en topfunctionarissen, zodat je later kunt terugkeren en bespreek ze zodra er voldoende informatie is verzameld. Zelfs een ogenschijnlijk eenvoudige eis kan onmogelijk te implementeren blijken of zeer arbeidsintensief zijn.
Vorming van een werkgroep van Klant en Opdrachtnemer, rolverdeling	Er moet worden besloten wie er aan het project gaat werken, zowel aan de kant van de opdrachtgever als aan de kant van de opdrachtnemer. Ondanks de ogenschijnlijke eenvoud dit stadium, hij heeft een heel grote rol. Als u niet duidelijk vastlegt wie waarvoor verantwoordelijk is, riskeert u verwarring tijdens de uitvoering van de werkzaamheden. Als u van uw kant altijd de rollen in uw team kunt specificeren, kan de klant hier problemen mee hebben. Waar u op moet letten: in de werkgroep van de Klant moeten de mensen zitten die in de toekomst op zijn minst op een of andere manier invloed zullen hebben op de acceptatie van het resultaat. Als we uitgaan van de situatie dat bij de overdracht van het werk medewerkers van de Klant betrokken worden die niet hebben deelgenomen aan het werk om doelen te formuleren en eisen te identificeren, dan zijn problemen gegarandeerd. Zelfs zo'n absurde situatie is mogelijk dat niet alles naar wens blijkt te zijn. In mijn praktijk ben ik een dergelijke situatie meer dan eens tegengekomen. Je kunt jezelf daarom beschermen als je bespreekt en documenteert dat niemand anders dan de klant werkt. groep kan deelnemen aan de acceptatie en oplevering van werk. En je kunt dit het beste vastleggen in de contractvoorwaarden (in het contract of projectcharter). Ik herinner me dat er zo'n geval was: in één enorm project de oprichter besloot mee te doen aan het proces (ik weet niet waarom, het leek saai) en woonde een van de werkvergaderingen bij waar de kwestie van het genereren van facturen voor klanten werd besproken. Hij was verrast toen hij hoorde dat de verkoopmanager de factuur aan de klant uitreikt. Volgens hem moet de accountant de factuur uitreiken, en niets anders. Maar in feite had de accountant geen idee waar hij het over had, en de manager kon zich niet voorstellen hoe hij zo te werk moest gaan als hij voor elke factuur naar de accountant moest rennen. Hierdoor verloren we veel tijd, maar er veranderde niets, de manager bleef de factuur uitreiken. En de oprichter bleef niet overtuigd, maar bemoeide zich niet meer met het proces. In dezelfde fase is het raadzaam om een ​​Project Charter te ontwikkelen, waarin de rollen van de deelnemers, de procedure voor communicatie, regelgeving en rapportage worden vastgelegd, evenals al het andere dat in het Charter moet worden gespecificeerd. De ontwikkeling van het Projectcharter is wederom een ​​apart onderwerp.
Het trainen van het projectteam in werkmethoden en hulpmiddelen, het afspreken van werkregels, soorten en samenstelling van documentatie	Ten eerste is het noodzakelijk om aan het projectteam alles uit te leggen wat er in het Charter staat en hoe het in de praktijk zal worden toegepast. Ten tweede moet het projectteam van de klant getraind worden in de werkmethoden die je in alle volgende fases gaat hanteren. Het is zinvol om de documentformaten die zullen worden gebruikt te bespreken en voorbeelden te overwegen. Als er regels worden toegepast voor het beschrijven van modellen of bedrijfsprocessen, moeten deze regels worden besproken zodat ze duidelijk zijn.
Vragenlijst	In de enquêtefase kunt u relatief snel een redelijk betrouwbare dwarsdoorsnede van informatie over het bedrijf verkrijgen. De kwaliteit van dergelijke informatie wordt bepaald door drie factoren: Allereerst de manier waarop je het projectteam van de klant hebt getraind. Ze moeten duidelijk begrijpen hoe het enquêteproces werkt en informatie aan alle deelnemers kunnen overbrengen De vragenlijst vormt zichzelf. Vragenlijsten moeten begrijpelijk zijn. Het is raadzaam om instructies te hebben voor het invullen van de vragenlijsten. Het zou nog beter zijn als er een voorbeeld was van hoe je het invult. Lijst van deelnemers. Het is noodzakelijk om de juiste samenstelling van deelnemers te kiezen. Als u zich alleen beperkt tot managers, kunt u geen betrouwbare informatie verzamelen. Ik raad aan om iedereen die in de toekomst gebruiker zal zijn van de eindresultaten, in de enquête te betrekken. Als we het bijvoorbeeld hebben over de implementatie van een geautomatiseerd systeem, dan is het de moeite waard om iedereen die de gebruiker zal zijn erbij te betrekken. Er zijn momenten waarop van de tien medewerkers van één functie er één is die een speciale functie vervult waar geen van de overige negen meer vanaf weet (bijvoorbeeld het opstellen van een speciaal rapport voor het management). Als we het hebben over een verdere herverdeling van verantwoordelijkheden of de ontwikkeling van functiebeschrijvingen, moet u hetzelfde doen. Houd er rekening mee dat de onderzoeksmethodologie voor de daaropvolgende implementatie van een geautomatiseerd systeem of de beschrijving van bedrijfsprocessen in het juiste geval verschilt. Natuurlijk kan de structuur van de vragenlijsten hetzelfde zijn, maar dit is niet het meest de beste optie. Wanneer we bedrijfsprocessen beschrijven, zijn de vragenlijsten doorgaans algemener van aard Het is niet precies bekend waar u mee te maken krijgt. Als we het hebben over de implementatie van een specifiek geautomatiseerd systeem, is het beter om vragenlijsten te hebben die rekening houden met de kenmerken van dit systeem. Met deze aanpak kunt u direct alle knelpunten van het systeem identificeren die niet geschikt zijn van deze onderneming. In de regel voorzien methoden voor het implementeren van kant-en-klare systemen in de aanwezigheid van dergelijke vragenlijsten. Dergelijke vragenlijsten kunnen worden ontwikkeld voor specifieke gebieden van de boekhouding (bijvoorbeeld orderadministratie, verkoop, prijsstelling) of voor specifieke functies (bijvoorbeeld financieel directeur). De samenstelling van de vragen is ongeveer hetzelfde.
Opiniepeilingen	Een enquête is een mondeling interview met specialisten om de kenmerken van individuele processen te achterhalen. Het is noodzakelijk om de enquête zo te organiseren dat deze niet alleen maar op een ‘meet and talk’ lijkt, maar op een meer georganiseerde manier. Om dit te doen, moet u een zogenaamd onderzoeksplan opstellen. U kunt daarin die delen van de vragenlijst opnemen die vragen bij u oproepen, informatie uit andere vragenlijsten tegenspreken of de informatie oppervlakkig wordt gepresenteerd. Het is raadzaam om vragen toe te voegen die louter uit persoonlijke ervaring komen en de antwoorden moeten absoluut worden genoteerd. Het is ideaal als u het eens bent over de audio-opname. In dezelfde fase moet u zorgen voor de volledigheid van de verstrekte informatie over de documentstroom (zowel vormen van primaire documenten als verschillende rapporten)
Identificatie van belangrijke bedrijfsprocessen of automatiseringsgebieden	Na de vragenlijst en het onderzoek kan redelijkerwijs worden aangenomen dat er voldoende informatie is om conclusies te trekken over de identificatie van de belangrijkste bedrijfsprocessen. In feite is het al mogelijk om niet alleen de belangrijkste bedrijfsprocessen te identificeren, maar bijna alles (als de deelnemers correct zijn gekozen). De kwestie van het identificeren van bedrijfsprocessen is een volledig apart en niet eenvoudig onderwerp. Leren is hier moeilijk en wordt vooral ontwikkeld door ervaring. Er moet een lijst (classifier) ​​worden samengesteld op basis van de geïdentificeerde bedrijfsprocessen. U kunt dan beslissingen nemen over welke onderwerpen diepgaander moeten worden onderzocht, welke niet, en welke prioriteiten er moeten zijn.
Formulering van de belangrijkste vereisten voor het systeem, doelen, criteria voor projectsucces, processen voor gedetailleerd onderzoek	In deze fase moet alle primaire informatie over de activiteiten van het bedrijf zijn verzameld en moet er een lijst met bedrijfsprocessen worden opgesteld. Dit is het moment om terug te keren naar de doelstellingen, deze te specificeren en, indien nodig, te bespreken met de topfunctionarissen van het bedrijf. Bij het formuleren van doelen moeten we rekening houden met specifieke indicatoren, bij het behalen daarvan zullen we het project als succesvol beschouwen. Als we het hebben over de implementatie van een geautomatiseerd systeem, kan een aparte lijst de vereisten voor het systeem van de belangrijkste gebruikers benadrukken. Dit doe ik in de vorm van een aparte tabel, waarbij alle eisen zijn gegroepeerd per subsysteem, waarbij voor iedere eis de auteur van de eis, de bewoording en de prioriteit wordt aangegeven. Deze informatie kan worden gebruikt voor het opstellen van een systeemimplementatieplan (volgorde van implementatie van individuele subsystemen), maar ook voor voorstellen voor de verdere ontwikkeling van het systeem (als het niet de bedoeling is dat individuele subsystemen in het huidige project worden geïmplementeerd). Als het nodig is om bedrijfsprocessen te beschrijven, worden er beslissingen genomen over die processen die nader moeten worden bestudeerd.

Dus komen we bij de vraag: “Wat is het volgende?” Vervolgens zullen we de taken van het beschrijven van bedrijfsprocessen en het afzonderlijk ontwikkelen van technische specificaties bekijken. Het is geen toeval dat ik deze taken parallel beschouw. Er zijn echt veel overeenkomsten tussen hen, en dat is wat ik wil aantonen. Laten we eerst eens kijken naar de volgorde van het werk bij het beschrijven van bedrijfsprocessen.

	Wat en hoe te doen
Wij brengen het bedrijfsproces onder de aandacht	Uit de algemene lijst met bedrijfsprocessen die we in de voorgaande fasen hebben verkregen, selecteren we er één (op prioriteit) voor gedetailleerde ontwikkeling. Daarna doen we hetzelfde met de rest.
Gedetailleerde studie bedrijfsproces	We onderwerpen het geselecteerde bedrijfsproces aan een gedetailleerd onderzoek: we analyseren de ontvangen primaire documenten, rapporten en hun structuur die in het programmaproces wordt gebruikt, diverse bestanden(bijvoorbeeld Excel), praten we met de uiteindelijke artiesten. We verzamelen verschillende ideeën over hoe het proces verbeterd kan worden. Het is erg handig als het je lukt om het proces precies te observeren onder de omstandigheden waarin het wordt uitgevoerd (niet veel mensen houden ervan om in de gaten te worden gehouden, maar wat kun je doen)
Grafische en/of tekstuele beschrijving van het bedrijfsproces (primair)	Ontvangen gedetailleerde informatie We beginnen te beschrijven. Voordat we het proces beschrijven, moeten we beslissen of dit nodig is grafische beschrijving. Als het proces eenvoudig en duidelijk is, er weinig functies in zitten, en een grafische weergave het begrip of de perceptie ervan niet zal verbeteren, dan is het niet nodig om er tijd aan te verspillen. In dit geval is het voldoende om het in tekstvorm in tabelvorm te beschrijven. Als het proces complex is, met verschillende logische voorwaarden, is het beter om er een grafisch diagram van te maken. Diagrammen zijn altijd gemakkelijker te begrijpen. Als u besluit een proces grafisch te beschrijven, betekent dit niet dat u geen tekstuele beschrijving hoeft te geven. Die. Er moet in ieder geval een tekstbeschrijving van het proces zijn, en dit moet volgens hetzelfde schema gebeuren. Handig is om dit te doen in de vorm van een tabel waarin je aangeeft: de uitvoerders van elke stap, welke informatie zij als input ontvangen, een beschrijving van elke stap, welke informatie er bij de output wordt gegenereerd. Hieronder bekijken we een voorbeeld van hoe dit eruit zou kunnen zien.
Afstemming met artiesten en bedrijfsproceseigenaar	De beste manier Om te begrijpen hoe goed u de stijl van het presenteren van informatie hebt gekozen, moet u het resultaat aan de gebruikers (uitvoerders) van het proces laten zien. Het belangrijkste bij zo'n demonstratie is begrijpen hoe goed u heeft begrepen hoe het proces wordt uitgevoerd. de training van het projectteam succesvol was, dan mag je van de performers ruim voldoende verwachten feedback. En als ze geïnteresseerd raken, gaat alles veel sneller vooruit. Geïdentificeerde verduidelijkingen en inconsistenties moeten worden weerspiegeld in de beschrijving (bijgewerkt) en indien nodig moet de operatie worden herhaald.
Isolatie van bedrijfsprocesindicatoren	Zodra u een correct inzicht heeft ontwikkeld in de manier waarop een bedrijfsproces wordt uitgevoerd, moet u nadenken over indicatoren die de kwaliteit of snelheid van het proces kunnen meten. Dit is niet gemakkelijk, maar wel noodzakelijk. De indicator moet meetbaar zijn, d.w.z. uitgedrukt in numerieke termen en er moet een eenvoudige manier zijn om deze waarde te verkrijgen. Als de gemeten indicator niet kan worden geïdentificeerd, bestaat het risico dat het bedrijfsproces niet succesvol is geïdentificeerd. Bovendien zal er geen manier zijn om te begrijpen (het kan immers niet worden gemeten) of veranderingen in het proces tot verbetering zullen leiden of niet.
Finale documentatie van het bedrijfsproces	Nadat we ervoor hebben gezorgd dat we goed inzicht hebben in hoe een proces wordt (of zou moeten) worden uitgevoerd, kunnen we dit opnemen in de documentatie.
	Er zijn nog meer opties mogelijk: de onderzochte processen zullen worden geanalyseerd en geoptimaliseerd, er zullen functiebeschrijvingen worden ontwikkeld, er zullen beslissingen worden genomen over de noodzaak om individuele processen te automatiseren, enz. Dit zou een apart project kunnen zijn: een beschrijving van bedrijfsprocessen.

Laten we nu eens kijken hoe de aanpak voor het bestuderen van de vereisten voor een informatiesysteem eruit zal zien met hun verdere reflectie in de Terms of Reference

	Wat en hoe te doen
We benadrukken de zakelijke behoefte/het gebied van automatisering	Het isoleren van een heel gebied van automatisering als vereisten (bijvoorbeeld: “ Aandelen") wordt in de praktijk gebruikt, maar dit is niet het meest effectieve methode detaillering van eisen. Het automatiseringsgebied is een groep vereisten en het is het beste om ze afzonderlijk te bekijken. Bijvoorbeeld: 'Boekhouding voor de ontvangst van goederen in het magazijn'
Gedetailleerde studie van zakelijke vereisten	Een gedetailleerde studie van een bedrijfsvereiste heeft betrekking op hoe de eindgebruiker deze wil zien en zal gebruiken (uiteraard in overeenstemming met de doelstellingen van het project). In software-engineeringtechnologie wordt dit vaak een "use case" genoemd. Een gedetailleerde studie van een bedrijfsvereiste komt dus neer op het ontwikkelen van gebruiksscenario's. Een voorbeeld van deze optie wordt gegeven in bijlage 2 bij het artikel. In de eenvoudigste gevallen hoeven use cases niet noodzakelijkerwijs in het formulier te worden getekend grafische schema's, kun je je beperken tot tekstuele formulering. De eis “Bij het invoeren van een artikel moet de prijs worden berekend als de inkoopprijs + 20%” heeft bijvoorbeeld geen zin. Het is zinvol om in de vorm van een diagram de eisen gecombineerd met het automatiseringsgebied weer te geven, zoals weergegeven in het voorbeeld in bijlage 2.
Het modelleren van eisen in een informatiesysteem	Hier is het! Zoals u zich waarschijnlijk herinnert, heb ik hier al de aandacht op gevestigd essentieel onderdeel in de methodologie voor het ontwikkelen van technische specificaties. “Bouw een model – je krijgt het resultaat!” Wat moet er gemodelleerd worden? Het is noodzakelijk om de in de vorige fase verkregen use cases te modelleren. Wat zou de output van de simulatie moeten zijn? Het resultaat zou een demonstratieprogramma moeten zijn waarin gebruikersgegevens worden ingevoerd, bij voorkeur een programma dat bekend is voor zijn gehoor (de gebruiker), rekening houdend met branchespecifieke kenmerken en actuele problemen. En ze zijn niet voor niets ingevoerd, maar het moet duidelijk zijn waar deze gegevens vandaan komen en hoe ze zijn berekend. Op dit punt zou de lezer vragen moeten hebben: Maar wat als u van plan bent een nieuw systeem te ontwikkelen en er simpelweg niets te modelleren is? Wat als de demo functionaliteit mist en het systeem verbeterd moet worden? Natuurlijk moet je met een dergelijke situatie worden geconfronteerd, en dat is normaal. Wat moeten we doen? Als het systeem helemaal nieuw is (zoals ze zeggen, "vanaf nul"), dan zul je het meeste op papier moeten modelleren, hier zullen use case-diagrammen je veel helpen. Gedeeltelijk is het zinvol om enkele van de schermvormen te schetsen die ontwikkeld zouden moeten worden (precies in de omgeving waarin de ontwikkeling zal worden uitgevoerd), omdat het tekenen ervan in een bepaalde editor zal langer duren en dit werk is saai. Als er een kant-en-klaar systeem wordt geïmplementeerd en het mist functionaliteit, dan is er niets aan de hand, de gegevens worden handmatig ingevoerd en de gebruiker krijgt te horen dat het na de nodige aanpassingen op die en die manier moet worden berekend (en hij ziet het). Het is raadzaam om een ​​dergelijk model te voorzien van een tekstbeschrijving, al is het maar een korte, zodat de gebruiker zelfstandig kan proberen met het model te werken. vrije tijd. In dezelfde beschrijving kunt u eisen voor verbeteringen formuleren.
Demonstratie informatie model werkgroep	We laten het resulterende model aan de klant zien en vertellen hoe alles zou moeten werken. Het is beter om het model te demonstreren per subsysteem, d.w.z. door groepen van eisen. Als blijkt dat het voorgestelde schema niet werkt voor de klant, moet je nadenken over andere gebruiksscenario's, wijzigingen aanbrengen in het model en het opnieuw laten zien. Alleen als er vertrouwen bestaat dat het geplande model voor een bepaalde klant zal ‘leven’, kan het model als succesvol worden beschouwd.
Ontwikkeling testen	Waarom zijn tests nodig? Hoe we de eisen hebben kunnen implementeren, zal moeten worden getest. Daarom is het raadzaam om tests uit te voeren voor alle belangrijke gebieden, complexe algoritmen, enz. Deze toetsen kunnen ook gebruikt worden bij het inleveren van werkstukken. Het is helemaal niet nodig om voor elke functie van het systeem tests uit te voeren; het gezond verstand moet overal worden gebruikt. Als we het hebben over een kant-en-klaar systeem, dan zal het doen van een test voor "het invoeren van een nieuw element in het klantenbestand" er dom uitzien en een verspilling van tijd en moeite. Maar als dit volledig is nieuw systeem, dit is heel goed mogelijk. Waarom testen als er nog geen systeem is? Ten eerste zal het voor de ontwikkelaar duidelijker zijn wat ze met hem willen bereiken. Ten tweede maken we het leven van de tester gemakkelijker (iemand test het ontwikkelresultaat). Over het algemeen is testen een aparte discipline, niet zo eenvoudig met veel technieken. In de praktijk worden in de regel nog steeds de eenvoudigste testmethoden gebruikt.
Het documenteren van eisen in de vorm van Technische Specificaties	De informatie die in de voorgaande fasen is verzameld, zal precies zijn wat moet worden opgenomen in de basis van het document “Technische specificaties” in het gedeelte met vereisten. Het enige dat overblijft is om alles correct te formatteren.
Volgende stappen (of het gebrek daaraan), afhankelijk van de doelstellingen van het project	Het kan langer duren voordat het ontwikkelingsproces begint, de zoektocht naar partners voor het project, een aanbesteding, etc., het hangt allemaal af van de situatie.

Ja, de ontwikkeling van Terms of Reference is een arbeidsintensief proces en daarom kostbaar. Maar als het correct wordt gedaan, verlost het de klant van onvervulde verwachtingen. De opdrachtnemer moet doen wat de klant verlangt en niet honderd keer hetzelfde doen. En over het algemeen geeft het het hele project transparantie.

Het concept van technische specificaties

Technische specificaties - het originele ontwerpdocument technisch voorwerp. De technische specificatie legt het hoofddoel vast van het object dat wordt ontwikkeld, de technische kenmerken, kwaliteitsindicatoren en technische en economische vereisten, instructies voor het voltooien van de noodzakelijke fasen van het maken van documentatie (ontwerp, technologie, software, enz.) en de samenstelling ervan, evenals als speciale vereisten.
Een taak als startdocument voor het creëren van iets nieuws bestaat op alle activiteitsgebieden, verschillend in naam, inhoud, volgorde van uitvoering, enz. (bijvoorbeeld een ontwerptaak ​​in de bouw, een gevechtstaak, huiswerk, een contract voor een literair werk, enz.). d.).

In overeenstemming met het Burgerlijk Wetboek is ontwerp een van de soorten contractwerk, waarvan het resultaat producten zijn ( project), dat wil zeggen een set ontwerpdocumentatie voor een ander product ( ontwerpobject). Het project is bedoeld om een ​​object, de werking, reparatie en verwijdering ervan te creëren, en om de tussen- en eindoplossingen op basis waarvan dit object is ontwikkeld te verifiëren of te reproduceren.
Woord "project" op het gebied van activiteit "project management " En "design Management" gebruikt in de betekenis van “programma”, “actieplan”, “werkpakket”.

Deelnemers aan ontwerpwerk zijn onderverdeeld in consumenten ( klanten deze werken) en leveranciers ( artiesten deze werken, aannemers). De gespecialiseerde uitvoerder wordt een ontwerper of ontwikkelaar genoemd. Zowel de leverancier als de consument van het product kan een organisatie zijn ( entiteit) of een specifieke persoon (individu).

Het ontwerpobject kan een materieel apparaat zijn, of de uitvoering van werk, of de levering van een dienst, bijvoorbeeld een gebouw of een industrieel complex, een technisch apparaat (apparaat, machine, apparaat), besturingssysteem, informatiesysteem, regelgeving documentatie (bijvoorbeeld een standaard), enz.

Een technische specificatie is een juridisch document - een toepassing is opgenomen in het contract tussen de klant en de aannemer voor ontwerpwerkzaamheden en vormt de basis ervan: het bepaalt de procedure en arbeidsvoorwaarden, inclusief het doel, de doelstellingen, principes, verwachte resultaten en deadlines .

Alle wijzigingen, aanvullingen en verduidelijkingen van de bewoordingen van de technische specificaties moeten met de klant worden overeengekomen en door hem worden goedgekeurd. Dit is ook nodig omdat als er onnauwkeurigheden of fouten in de initiële gegevens worden ontdekt tijdens het oplossen van een ontwerpprobleem, het noodzakelijk wordt om de mate van schuld vast te stellen van elk van de partijen die betrokken zijn bij de ontwikkeling en de verdeling van de verliezen die zijn geleden in verband hiermee.

Plaats van technische specificaties in de ontwerpstructuur

Ontwerpen is een proces (projectontwikkeling) dat een zekerheid heeft structuur, dat wil zeggen de volgorde en samenstelling van fasen en fasen, de reeks procedures en technische middelen die erbij betrokken zijn, de interactie van procesdeelnemers.

De ontwerpfasen worden geregeld door normen. Dit is de volgende volgorde:

• Technische specificaties (volgens GOST 2.103-68 zijn niet van toepassing op ontwikkelingsfasen),
• Voorlopig ontwerp,
• Fasen van een werkproject.

De oplossing voor elk probleem begint met het begrijpen en verduidelijken van de initiële gegevens. Die (technische) eisen die door de klant worden gesteld, zijn geformuleerd in de taal van een niet-gespecialiseerde consument en zijn technisch niet altijd helder en volledig. Het vertalen van de vereisten in de taal van het vakgebied, het zo volledig en competent mogelijk formuleren van het probleem, het rechtvaardigen van de noodzaak om het op te lossen, dit is het hoofddoel van de technische specificatie, een verplichte werkfase. De opdrachtnemer voert dit uit in nauw contact met de klant. In feite betekent dit dat de werkzaamheden van de aannemer aan het project al zijn begonnen.
In de machinebouw wordt deze fase soms genoemd extern ontwerp.

In de regel worden technische specificaties samengesteld op basis van een analyse van de resultaten van voorstudies, berekeningen en modellering.

Particuliere technische opdrachten

Tijdens het ontwerpproces van een complex object (systeem), waarbij de deelname van verschillende ontwikkelaars vereist is, worden privé-technische specificaties voor subsystemen gecreëerd.

In overeenstemming met de ontvangen technische vereisten genereert de systeemontwikkelaar technische specificaties en voert hij, in de fase van het technische voorstel, een decompositie van het object uit en stelt hij specifieke technische specificaties voor subsystemen op. Nadat alle fasen van het technische voorstel zijn voltooid, coördineert en keurt de ontwikkelaar het goed met de systeemklant, en verduidelijken zij gezamenlijk de initiële technische specificaties.

Na goedkeuring van het technisch voorstel verdeelt de systeemontwikkelaar private technische specificaties onder mede-uitvoerders, op basis waarvan private technische specificaties voor subsystemen kunnen worden ontwikkeld. lage niveaus. Als subsystemen op het tweede niveau ontbreken, wordt het technische voorstel voor de subsystemen vaak niet geïmplementeerd omdat het praktisch op systeemniveau is voltooid.

Na voltooiing van de fase van distributie van technische specificaties beginnen de ontwikkelaars van het systeem en zijn subsystemen met het uitvoeren van de voorlopige ontwerpfase. De ontwikkeling van de structuur in deze fase wordt uitgevoerd in nauwe interactie tussen alle ontwikkelaars. Tijdens dergelijk werk worden afzonderlijke onderdelen met elkaar verbonden en worden de belangrijkste parameters van het ontworpen object overeengekomen. De kwaliteit van het ontwerp hangt af van de breedte van de visie van de ontwikkelaar op het probleem, dat wil zeggen van zijn horizon en zijn vermogen om rekening te houden met alle verbindingen van het object in kwestie, en de aanwezigheid van kennis die vastlegt gerelateerde gebieden. Tijdens het voorlopig ontwerp en de coördinatie van specifieke oplossingen met de algemene is het mogelijk om de technische specificaties aan te passen.

Na voltooiing van het voorlopig ontwerp, de afstemming en goedkeuring van de daaruit voortvloeiende technische oplossingen met de klant, gaan zij over naar de fase van het technisch ontwerp. Hier worden alle belangrijke structurele werkzaamheden aan het object en zijn onderdelen uitgevoerd. Het is mogelijk om technische oplossingen te verduidelijken door terug te keren naar eerdere fasen. Het technisch ontwerp wordt uitgevoerd in nauwe samenwerking tussen alle ontwikkelaars.

De behoefte aan technische specificaties

De initiële taak wordt door de klant uitgegeven. De belangrijkste redenen die hem dwingen zich tot een ontwikkelaar te wenden zijn het gebrek aan relevante speciale kennis of de beperkte middelen (gebrek aan tijd om het probleem op te lossen, het benodigde aantal mensen, apparatuur) bij de klant.

De taak kan duidelijk worden gedefinieerd, bijvoorbeeld wanneer al het werk door één persoon wordt uitgevoerd, of wordt uitgegeven door een gerenommeerde specialist, of niet in twijfel kan worden getrokken (overheidsbevel). Maar vaker wordt het geformuleerd in algemeen overzicht in de taal van een niet-gespecialiseerde consument, ver verwijderd van de taal- en domeintermen van de ontwikkelaar. Onzekere eisen veroorzaken onzekerheid bij alle deelnemers aan het werk, omdat ze verschillende interpretaties van de eisen mogelijk maken en geen objectieve beoordeling van de kwaliteit van het ontwikkelde product mogelijk maken. Ook moet de ontwikkelaar begrijpen dat de klant de speciale vereisten mogelijk niet (of gedeeltelijk kent), wat de ontwikkelaar niet ontslaat van de verantwoordelijkheid en verplichting om te voldoen aan de vereisten van toezichthoudende autoriteiten, ongeacht hun aanwezigheid bij de taak. Niet alleen de klant, maar ook de ontwikkelaar (uitvoerder) is dus verantwoordelijk voor het stellen van ontwikkelingsdoelen en het nut van het resultaat ervan.

Het opstellen van technische specificaties is een complexe en verantwoordelijke taak: veel gegevens zijn nog niet bekend, maar hoe de taak wordt gesteld, kan het daaropvolgende ontwerp gemakkelijker of moeilijker maken (figuurlijk gesproken: “hoe je het schip ook noemt, zo zal het varen”) .

Deskundigen zijn van mening dat een competente technische specificatie meer dan 50% van het succes bij het oplossen van een probleem bepaalt, en dat de tijd die wordt besteed aan het opstellen van technische specificaties een van de beste investeringen is die een bedrijf tijdens de ontwerpperiode kan doen. Niet voor niets wordt het opstellen van technische specificaties toevertrouwd aan toonaangevende specialisten - hoofdontwerpers, project- en werkmanagers, enz.

Academicus A. N. Krylov vertelde het. In één fabriek werd een nieuwe machine geïnstalleerd, maar die kregen ze niet werkend. Vervolgens wendden ze zich tot een universiteitsprofessor voor hulp. Aangekomen in de fabriek liep hij lange tijd rond de auto, zorgvuldig op zoek naar iets en ergens naar luisterend. Vervolgens pakte hij een hamer en sloeg op haar lichaam. En de auto begon te werken. Voor zijn hulp vroeg de professor het fabrieksbestuur om 100 roebel (dit was aan het begin van de 20e eeuw). Maar het fabrieksbestuur vond dit te veel om voor één klap met een hamer te betalen. Waarop de professor antwoordde dat de slag zelf één roebel kost, maar waar hij moet worden 99 roebel. Het is opgevallen dat als de kosten voor het corrigeren van een ontwerpfout die in de fase van het technisch ontwerp is gemaakt op 1 worden genomen, de kosten voor het corrigeren ervan ongeveer 10, 100 en 1000 keer stijgen als de fout respectievelijk in de fase van het voorbereidende ontwerp is gemaakt. ontwerp, technisch voorstel en technische specificaties!

Als communicatiemiddel in de communicatieverbinding tussen klant en uitvoerder kunt u met technische specificaties:

• Aan beide partijen:
  • stel je het eindproduct voor,
  • het uitvoeren van een puntsgewijze controle van het eindproduct (acceptatietesten – uitvoeren testen),
  • het aantal fouten verminderen dat gepaard gaat met veranderende vereisten als gevolg van hun onvolledigheid of fouten (in alle fasen en stadia van de creatie, met uitzondering van testen).
• Aan de klant:
  • beseffen wat hij precies nodig heeft,
    • inclusief, vertrouwend op de momenteel bestaande technische mogelijkheden en onze middelen,
  • van de contractant eisen dat hij voldoet aan alle voorwaarden vermeld in de technische specificaties.
• Uitvoerder:
  • de essentie van de taak begrijpen, de klant het ‘technische uiterlijk’ van het toekomstige product, softwareproduct of geautomatiseerde systeem laten zien,
  • de uitvoering van het project plannen en volgens plan werken,
  • weigeren werkzaamheden uit te voeren die niet in de technische specificaties zijn gespecificeerd.

Gereglementeerde technische specificaties

Ondanks het belang ervan wordt de inhoud van technische specificaties weinig gereguleerd door regelgevingsdocumenten (GOST, OST).

Wat het uitvoeren van onderzoekswerkzaamheden betreft, wordt de technische specificatie geregeld door de volgende documenten:

Secties met technische specificaties volgens GOST 34.602-89 (voorbeeld)

Om doelen en eisen te specificeren die vaag of kwalitatief gespecificeerd zijn, wordt de decompositiemethode gebruikt.

Het is vermeldenswaard dat de gegevens in de voorwaarde nominale parameters zijn, maar het zou juister zijn om de genormaliseerde waarden van deze parameters te geven, gespecificeerd door hun maximaal toegestane waarden (de massa van het product is bijvoorbeeld 9,8...10,1kg). Dat wil zeggen: wat als voorwaarden worden beschouwd, zijn in de praktijk beperkingen in de vorm van bilaterale ongelijkheden. De breedte van het bereik is een gevolg van de tolerantie op deze parameter.

Bij het vormen van een systeem van eisen is analyse van de volgende bronnen vereist:

• Beschikbaarheid van middelen ter beschikking van de klant en ontwikkelaar: financieel, productie, menselijk, tijd. Alle middelen zijn met elkaar verbonden; door bijvoorbeeld de projectfinanciering te vergroten, kan de ontwikkelingsperiode worden verkort. Een gevolg van de mate van toegankelijkheid is de introductie van beperkingen op de methoden en nauwkeurigheid van het oplossen van het ontwerpprobleem, wat op zijn beurt het gekozen type model beïnvloedt. Wanneer de tijd beperkt is, voeren ze dus evaluatieberekeningen uit met behulp van vereenvoudigde methoden of gebruiken ze kant-en-klare software, standaardmethoden, standaardapparatuur, standaard- en aangekochte onderdelen en samenstellingen, enz. Tegelijkertijd moeten het model, de methode en de nauwkeurigheid van de oplossing moet ervoor zorgen dat aan de eisen van de technische specificaties wordt voldaan, ook al zijn deze hoog.
• Rekening houden met de eisen van toezichthouders en vergunningverlenende instanties bij het ontwerpen van bijvoorbeeld technologische complexen (producties). In overeenstemming met de wetten van de Russische Federatie vereist elke productie het verkrijgen van een regionale exploitatievergunning. Bovendien beschikken veel productiefaciliteiten over een vergunning van toezichthoudende autoriteiten en zijn zij onderworpen aan hun controle. De meest controlerende instanties zijn de regionale instanties Rostekhnadzor, Rosstandart, Ministerie van Regionale Ontwikkeling van Rusland (voorheen Gosstroy), Rospotrebnadzor, Rosprirodnadzor, Staatsbrandweer, Ministerie van Binnenlandse Zaken van Rusland, Rostrud.
• Leefomgeving van het ontworpen systeem. Het specificeert de eisen die de wederzijdse invloed van het ontworpen systeem en de omringende levende en niet-levende objecten en de externe omgeving kenmerken. Basisinstructies hierover worden gegeven in de technische vereisten onder de consumptievoorwaarden van toekomstige producten. Deze omstandigheden kunnen vrij algemeen worden gekarakteriseerd en vereisen specificatie.

Opstellen van een lijst met technische specificaties eisen

Hoofd artikel: Ontwerpmethoden

Het werk aan technische specificaties omvat een aantal fasen. En de onzekerheid die inherent is aan dit werk zorgt ervoor dat ze er verschillende keren, iteratief, doorheen gaan, van een meer algemene formulering van het probleem naar de gedetailleerde uitwerking ervan (het ontwerp is iteratief van aard en waar in het begin geen rekening mee is gehouden, kan in het ontwerp worden opgenomen). rekening in volgende fasen).

Laten we eerst een verhaal vertellen over hoe Edison zichzelf een technische taak stelde.

Voordat Edison elektrische verlichting voor in huis begon te ontwikkelen, deed hij onderzoek onder welke omstandigheden deze qua prijs, helderheid en gemak zou concurreren met gasverlichting (claxon). Hij bestudeerde de gasindustrie gedetailleerd, ontwikkelde een plan voor een centrale elektriciteitscentrale en een diagram van elektriciteitsleidingen naar huizen en fabrieken. Vervolgens berekende hij de kosten van koper en andere materialen die nodig zouden zijn om lampen te maken en elektriciteit op te wekken met behulp van een door stoom aangedreven dynamo. Data-analyse bepaalde niet alleen de afmetingen van de lamp, maar ook de concurrerende prijs, gelijk aan 40 cent. En pas toen Edison ervan overtuigd was dat hij het probleem van de elektrische verlichting kon oplossen, begon hij te werken aan een gloeilamp met een koolstofdraad in een glazen bol waaruit de lucht werd weggepompt. Op zoek naar draadmateriaal testte hij ongeveer 6.000 soorten plantaardige vezels.

Analyse van de opdracht van de klant

De initiële taak wordt door de klant uitgegeven en in het formulier opgesteld technische benodigdheden . Het vertalen van deze vereisten in de taal van het vakgebied, het zo volledig en competent mogelijk formuleren van het probleem, het rechtvaardigen van de noodzaak voor de oplossing ervan, het begrijpen en verduidelijken van de initiële gegevens is de eerste fase van het werk. De opdrachtnemer voert dit uit in nauw contact met de klant.

U moet de volgende problemen identificeren en proberen te vermijden:

• taken die niet aan de sociale behoeften voldoen - crimineel, immoreel, inhumaan. Hun beslissing is een gewetenskwestie van de ontwikkelaar;
• technische pseudo-taken met ten onrechte gestelde doelen. Dit zijn taken waarvoor al een oplossing bestaat, of waarvoor geen objectieve voorwaarden bestaan ​​voor hun oplossing (voortijdige taken, maar dit moet gerechtvaardigd worden zodat de weigering om op te lossen niet het gevolg is van psychologische traagheid of andere subjectieve redenen);
• chimere problemen. Dit zijn taken met een verkeerd gesteld doel, waarvan de verwezenlijking in tegenspraak is met de wetten van de natuurkunde (bijvoorbeeld het creëren van een apparaat met een efficiëntie van meer dan 100%, een onmiddellijk apparaat, enz.), of abstract naar voren gebrachte taken die fundamenteel zijn geen oplossing (zoals de steen der wijzen).

Bij het opstellen van technische specificaties is het belangrijk om de initiële eisen kritisch en onbevooroordeeld te benaderen. Om dit te doen heb je nodig:

• zorg ervoor dat de aangegeven behoeften echt waardevol zijn voor de klant, of de initiële gegevens waar zijn en welke nadelige of schadelijke gevolgen kunnen optreden tijdens het realiseren van deze behoefte;
• ontdek de essentie van de behoefte, vind de bron van het voorkomen ervan;
• ontdek wat het gebruik van het vorige product verhindert om aan nieuwe behoeften te voldoen.

De belangrijkste reden voor de behoefte nieuwe ontwikkeling, geldt als beschikbaarheid tegenstrijdigheden tussen verlangen en mogelijkheid tot bevrediging behoeften. Als er geen tegenstrijdigheid is, kan aan de behoefte worden voldaan zonder nieuwe producten te creëren. Als er geen tegenstrijdigheid lijkt te zijn, maar de bestaande oplossing niet past, betekent dit dat er daadwerkelijk een tegenstrijdigheid bestaat, en dat je daar zorgvuldig naar moet zoeken.

De tegenstrijdigheid kan worden ontleed, dat wil zeggen gepresenteerd in de vorm van elementaire problemen.

In de meeste gevallen is er sprake van een prototype: een prototype of origineel product dat de klant niet meer tevreden stelt. De aanwezigheid van een prototype vereenvoudigt de beslissing, maar de afwezigheid ervan creëert geen psychologische traagheid in de vorm van vooraf bepaalde oplossingstrajecten, die niet altijd tot het beste resultaat leiden.

• of vergeet het bestaan ​​ervan en bied, uitgaande van de initiële behoefte, aan mogelijke opties gevolgd door het kiezen van de beste;
• of het prototype verbeteren met behulp van IFR;
• of lokaliseer de behoefte. Meestal worden onbevredigende prestaties geassocieerd met imperfectie van slechts enkele subsystemen. Voor dit doel wordt het prototype ontleed op basis van zijn functionele kenmerken, en wordt de tegenstrijdigheid gepresenteerd in de vorm van elementaire problemen. Door elementaire problemen te correleren met bepaalde subsystemen van het prototype, worden ‘imperfecte’ subsystemen geïdentificeerd. Van het oplossen van een algemeen en complex probleem gaan ze dus over op een eenvoudiger specifiek probleem. Maar de mate van verbetering van de eigenschappen kan laag zijn en er kunnen problemen ontstaan ​​bij het verbinden van de verbeterde subsystemen met de voorgaande.

Specificatie van ontwerpdoelen

Na het verduidelijken en verantwoorden van de ontwikkelingsdoelen worden de bijbehorende functies toegewezen. Om ervoor te zorgen dat vooroordelen en psychologische traagheid het zoekgebied niet verkleinen en de klant door zijn probleemformulering niet vooraf de richting van het zoeken naar een oplossing bepaalt, is het raadzaam om de functie in het algemeen en in neutrale termen te formuleren. Het is dus beter om de functie "omverwerpen" (bijvoorbeeld planken) te vervangen door de term "verbinden", waarmee je kunt ontsnappen aan de natuurlijke associatie - neerhalen met spijkers, en een breder scala aan mogelijke oplossingen biedt.

Tijdens het zoeken naar de meest complete en nauwkeurige formulering wordt een keten van functies (een boom van doelen) opgebouwd - van het aanvankelijk voorgestelde tot het uiteindelijk aanvaarde. Dit wordt geholpen door het beantwoorden van de vraag “Waarom is dit nodig?” (en andere vragen over de methode test vragen). In de meeste gevallen is het doel dat in de eisen wordt vermeld de noodzaak om meerdere functies (opeenvolgend of gelijktijdig) uit te voeren. Voor elk van hen wordt een keten van functies gebouwd.

Naast de noodzaak tot enige actie kan er ook een noodzaak bestaan ​​om een ​​actie niet uit te voeren of een actie uit te voeren met een negatief effect.

Verwerking van verzamelde informatie

1. Generalisatie en abstractie.
Individuele fragmenten worden met elkaar verbonden en samengevat zodat, indien mogelijk, een volledig, duidelijk en beknopt beeld wordt verkregen van het object dat wordt ontwikkeld, rekening houdend met mogelijke veranderingen. Dubbele informatie wordt verwijderd, inclusief informatie die elkaar in andere formuleringen herhaalt of een speciaal geval is.

Abstractie is bedoeld om de vereisten zo te formuleren dat het vooraf bepalen van manieren om het probleem op te lossen wordt vermeden (niet om psychologische barrières te creëren). Om ‘sterke’ oplossingen te verkrijgen wordt aanbevolen om het systeem van eisen te versterken en tegenstellingen te verergeren door het formuleren van een IFR.

2. Controleer op inconsistenties.
Als er meerdere functies zijn, kunnen sommige tegenstrijdig zijn in hun effect (het water moet bijvoorbeeld heet zijn (voor het zetten), maar je handen niet verbranden). Om tegenstrijdigheden op te lossen is het gebruik van heuristische methoden effectief. Tegelijkertijd is het elimineren van tegenstrijdigheden mogelijk, zowel in de fase van het opstellen van technische specificaties (het veranderen van de formulering van functies, het verspreiden van hun acties in tijd of ruimte, enz.), Als in de daaropvolgende ontwerpfasen.

Voorwaarden en beperkingen moeten ook worden gecontroleerd op inconsistentie. Beperkingen kunnen dus een lege set specificeren. Dergelijke tegenstrijdigheden zijn niet altijd voor de hand liggend: informatie van bovenaf en lagere limieten mag binnenkomen andere keer of op verschillende plaatsen in de technische specificatie worden geplaatst, in een impliciete vorm worden gepresenteerd.

3. Eisen opsplitsen in voorwaarden, beperkingen en kwaliteitsindicatoren.
Door eisen te presenteren in de vorm van indicatoren kunt u oplossingen met hoge prestaties verkrijgen, maar dit probleem is moeilijker op te lossen. De indicatoren zijn de indicatoren die de belangrijkste eigenschappen karakteriseren (om de beste waarden te kunnen verkrijgen). Voor de ingevoerde voorwaarden is het noodzakelijk om de omvang van de spreiding te evalueren en de noodzaak om grenswaarden aan te geven, dat wil zeggen om ze in de vorm van beperkingen te presenteren.

4. Parametrering.
De nauwkeurigheid van het oordeel en de juistheid van de keuze zijn afhankelijk van de mate van specificiteit initiële eisen ongeacht of ze in een geformaliseerde of informele vorm worden gepresenteerd. Om de conclusies ondubbelzinnig te maken, moeten alle vereisten worden vertaald in een geformaliseerde vorm, dat wil zeggen dat de parameters die ze karakteriseren moeten worden aangegeven, en de parameters die kunnen worden gemeten, gecontroleerd en berekend. Dit maakt het ook mogelijk om dubbele vereisten (die worden gekenmerkt door dezelfde parameters) te identificeren en deze te generaliseren (introductie van gegeneraliseerde parameters om hun totale aantal en specifieke kenmerken te verminderen).

Bij het oplossen van een optimaal ontwerpprobleem wordt aanbevolen om kwaliteitsindicatoren terug te brengen tot een op criteria gebaseerde, geformaliseerde vorm, dat wil zeggen om ze een numerieke maatstaf toe te kennen. De belangrijkste methode voor het specificeren van formuleringen is het construeren van een boom van doelen (EN- of OF-bomen): de initiële indicator wordt ontleed om elementaire concepten te identificeren die op unieke wijze worden gekenmerkt door sets van parameters.

De wetenschap van “Qualimetry” houdt zich bezig met de problemen van het beoordelen van kwaliteit aan de hand van kwantitatieve indicatoren.

5. Inkorting van de lijst met eisen.
Een grote hoeveelheid informatie, hoewel het het maximale kan geven volledig zicht over het probleem dat wordt opgelost, maar het is moeilijker om in gedachten te houden en bemoeilijkt de oplossing van het probleem. Om de informatie tot een redelijk volume terug te brengen (afhankelijk van de mogelijkheden van elke specifieke ontwikkelaar, naleving van zijn financiële, organisatorische, technische en tijdbronnen), kunt u hun rangschikking of indeling in groepen van verplicht, wenselijk en niet-essentieel gebruiken. Tot de verplichte opties behoren degenen wier ontevredenheid de keuze van beslissingsopties aanzienlijk beïnvloedt. Dit zijn functionele parameters, voorwaarden voor de relatie tussen systemen en hun onderdelen, en andere. Met wenselijke eisen kunt u onderscheid maken tussen opties op basis van kwaliteit.

Het is de moeite waard om rekening te houden met de woorden van Lee Iacocca: “... het probleem is dat je aan Harvard hebt gestudeerd, waar het in je hoofd werd gehamerd dat je geen actie kunt ondernemen voordat je alle feiten hebt verzameld. Je beschikt over 95% van de informatie, en om de ontbrekende 5% te verzamelen heb je nog eens zes maanden nodig. Gedurende deze tijd zullen alle feiten achterhaald raken, omdat de markt zich veel sneller ontwikkelt. Het belangrijkste in het leven is om alles op tijd te doen. ...de hoofdtaak is het verzamelen van alle belangrijke feiten en standpunten die voor u beschikbaar zijn. Maar op een gegeven moment moet je daadkrachtig gaan optreden. In de eerste plaats omdat zelfs de meest correcte beslissing verkeerd blijkt te zijn als deze te laat wordt genomen. Ten tweede omdat er in de meeste gevallen niet zoiets bestaat als volledige zekerheid. Je zult nooit 100% van de informatie kunnen verzamelen. Helaas wacht het leven niet tot je alle mogelijke misrekeningen en verliezen hebt geëvalueerd. Soms moet je gewoon willekeurig vooruit gaan en gaandeweg fouten corrigeren.” - - Telecommunicatieonderwerpen, basisconcepten NL uitdrukking van eisen ... Handleiding voor technische vertalers

TECHNISCHE TAAK- (TK) het originele technische document voor het uitvoeren van verschillende onderzoeken en het ontwerpen van nieuwe (zie) en constructies. In de regel geven de technische specificaties de werkfasen aan, de technische documentatie die wordt ontwikkeld, kwaliteitsindicatoren en technische... ... Grote Polytechnische Encyclopedie

technische taak- 3.29 werkoverzicht: Een document dat door de klant wordt gebruikt als middel om de tijdens de uitvoering van de overeenkomst uitgevoerde taken te beschrijven en te definiëren.

Van de auteur: Hoe te schrijven referentiekader voor websiteontwikkeling? Het onderwerp is vrij uitgebreid en het is moeilijk om het 100% te analyseren binnen het kader van één artikel (als dat al mogelijk is). Maar ik zal in dit artikel proberen de algemene bepalingen te schetsen, waar rekening mee moet worden gehouden, waar op moet worden gelet bij het opstellen van technische specificaties.

Dus, TK

Het reglement is opgesteld voor de site-ontwikkelaar. Bij het opmaken van een overeenkomst tussen opdrachtgever en opdrachtnemer moet naar de technische specificaties worden verwezen. De verantwoordelijkheid voor het niet of onjuist voldoen aan de punten en voorwaarden van de technische specificaties aan beide kanten moet worden vastgelegd. Maar het allerbelangrijkste (naar mijn mening) waarvoor technische specificaties worden gemaakt, is daarvoor het versnellen van het website-ontwikkelingsproces.

Laten we dit voorbeeld analyseren:

Laten we aannemen dat u ergens aan de zijkant van uw website een kalender nodig heeft. Het leek een kleinigheid. Maar hoe gedetailleerder u de functionaliteit van deze kalender beschrijft, hoe sneller u het resultaat krijgt.

Laat me het hier een beetje uitleggen. Kalender is iets anders dan kalender. Er is een kalender die eenvoudigweg de cijfers weergeeft per dag van de week van de huidige maand. Er is een kalender met de mogelijkheid om door de maanden te bladeren. Er is een kalender met de mogelijkheid om door maanden en jaren te bladeren.

Stel dat u de nieuwste kalenderoptie wilt (met de mogelijkheid om door maanden en jaren te bladeren) met achtergrondverlichting huidige datum. Je gaf in de specificatie aan: “er is een kalender nodig in de zijbalk.” De klant maakt voor u de eerste versie van de kalender (deze toont eenvoudigweg de cijfers per dag van de week van de huidige maand).

Wat we hebben. De aannemer voldeed aan de technische eisen, maar jij wilde een heel andere kalender. Het lijkt erop dat alles in overeenstemming is met de technische specificaties, niemand heeft de schuld, er is geen conflict, maar het belangrijkste is verloren tijd en geld.

Dit is een voorbeeld van slechts een banale kalender.

Wat als u iets ernstigers moet overdoen, waarvan de verwerking meer dan een halve dag in beslag neemt, zoals in het geval van een kalender? En je hebt geen website, en de klant is met je aan het rommelen, ook al zou hij je project kunnen afmaken en een nieuw project kunnen starten.

Daarom dan meer details U beschrijft de functionaliteit van elke sitemodule, hoe sneller u het resultaat krijgt. Beide partijen zouden hierin geïnteresseerd moeten zijn.

Uit welke punten bestaat een technische specificatie doorgaans?

Laten we ons voorstellen dat u de eigenaar bent van een bedrijf of firma. Uw bedrijf houdt zich bezig met de productie van elk product en de verkoop ervan. Je hebt kopers. Je werkt samen met verkopers (winkels en webshops), servicecentra en productconsumenten. Of je maakt voor zo’n bedrijf een website en moet technische specificaties schrijven.

Ongeacht welke rol u speelt, het eerste dat u hoeft te doen, is de structuur van de organisatie bestuderen, wat deze doet, de nomenclatuur, kenmerken en in het algemeen alles wat verband houdt met het product en het bedrijf. Wat er op de site zal gebeuren, hangt af van hoe diep de klant de essentie begrijpt van wat er in de onderneming gebeurt. Daarom is de taak hier wederzijds: de klant moet zo gedetailleerd mogelijk over de onderneming vertellen en de aannemer moet de essentie van wat er gebeurt grondig begrijpen.

Zelfs als u zelf technische specificaties schrijft voor een bedrijf dat een website gaat maken, is het een goed idee om dit allemaal op een vel papier uit te zoeken.

Laten we punt voor punt gaan.

Beschrijving van de site

Hier kunt u in een paar zinnen schrijven over het bedrijf en wat het doet. Doe zoiets als een introductie.

voor wie - de doelgroep van de site:

• potentiële kopers
• productverkopers (winkels, online winkels)
• servicecentra
• partners (bedrijven)
• consumenten van producten (degenen die al iets hebben gekocht)

Waarom heb je een website nodig?:

• Om het imago van het bedrijf te verbeteren
• Om de omzet te verhogen
• Voor het gemak van de klant

Sitetype:

• Zakelijk
• Website – visitekaartje
• Online winkel

Taalversies:

• Engels
• Russisch

De site moet een aantal problemen oplossen. Dienovereenkomstig gaan we verder met de doelen en doelstellingen van de site.

Doelen en doelstellingen van de site

In dit deel van de technische specificaties lopen we het geheel door doelgroep en beschrijf het scala aan taken dat de site voor hen moet oplossen.

Potentiële productkopers.

Doel: meer kopers aantrekken en overtuigen om de eerste aankoop te doen, helpen bij het maken van een keuze.

Problemen moeten worden opgelost:

Bied hoogwaardige en uitgebreide informatie over producten, aanvullende diensten, garanties, service en selectiemethoden.

• Geef informatie over showrooms
• Geef informatie over de detailhandel handelsnetwerk

Bied de mogelijkheid om een ​​vraag te stellen via online consultatie potentiële kopers specialisten van de onderneming op het gebied van selectie en aankoop van producten.

Zo doorlopen we de gehele doelgroep. Als u onze website volgt, beschrijven we de doelen en doelstellingen voor productverkopers (winkels, online winkels), servicecentra, partners (bedrijven) en productconsumenten. Dat wil zeggen, wat de site specifiek voor elk van hen zou moeten doen.

Nu vermelden we de sitemodules.

Sitefunctionaliteit

Om de functionaliteit van de site op te sommen, moet u beslissen wat deze nodig heeft:

• Heeft u nieuws nodig op de site?
• Heb ik een advertentieblok nodig?
• Is registratie vereist?
• Is er behoefte aan een gesloten gedeelte van de site (alleen voor geregistreerde gebruikers)
• Is een feedbackformulier nodig?
• Heb ik een mailingscript nodig?
• Enz. enzovoort.

Nadat we dit allemaal hebben beschreven, komen we bij het belangrijkste en meest interessante. Natuurlijk is al het bovenstaande werk erg belangrijk, maar nu wordt het nog heter.

Beschrijving van de sitefunctionaliteit

Op dit moment weten we voor wie de site bedoeld is, aan welke doelen deze moet voldoen en wat de aanvullende functionaliteit is.

De tijd is gekomen dat u alle verzamelde informatie in het systeem moet brengen en deze mooi op de website moet zetten. Om de taak eenvoudiger te maken en het wiel niet opnieuw uit te vinden, kunt u sites over vergelijkbare onderwerpen bekijken. Leer er iets van, bekijk en probeer hun functionaliteit uit en probeer te verbeteren wat lastig leek op uw website. In principe kunt u aan het begin van het opstellen van de technische specificaties naar sites over soortgelijke onderwerpen kijken (en als u geen ervaring heeft, dan is dat zelfs nodig).

Ik stel voor om te beginnen met menu-items. Het moet de hoofdpagina's van de site weergeven en ervoor zorgen dat elke bezoeker snel informatie voor zichzelf kan vinden. En bezoekers zijn onze doelgroep. Het menu zal veel items bevatten, dus het zal de vorm hebben van een vervolgkeuzelijst.

Eerst moet u ons over het bedrijf vertellen. Er kunnen pagina's zijn over het bedrijf, bedrijfsgeschiedenis, contacten, recensies.

Uiteraard moet er een menu-item “producten” zijn, met subitems “productcatalogus”, “releases”, “productrecensies”.

Over het algemeen hoop ik dat het duidelijk is hoe ik het moet beschrijven. Laat me de definitieve versie van een mogelijk menu voor onze website presenteren:

Over bedrijf

• geschiedenis van het bedrijf
• contacten
• beoordelingen

Nieuws

• evenementen
• voorraad
• nieuw op de site

Producten

• Product catalogus
• releases
• productrecensies

Dienst

• service afdeling
• garantie
• service na de garantie

Aan de consument

• aankoop en levering
• gebruik
• over de dienst

Winkels en online winkels

• productfoto's
• FAQ

Servicecentra

• Hoe u een servicecentrum kunt worden
• FAQ

Voor partners

• uitnodiging tot samenwerking
• FAQ

Het lijkt erop dat we het menu hebben uitgezocht. Nu moet je beschrijven wat er op elke pagina staat en hoe het allemaal werkt. Geef bovendien een geschatte site-indeling op. Het kan met een potlood op een stuk papier worden getekend, gescand en aan het werkoverzicht worden gehecht. Het enige dat ik wil zeggen is dat je de verbeeldingskracht van de ontwerper niet beperkt, maar in de meest algemene vorm schetst.

Dit onderdeel verandert afhankelijk van hoe u wilt dat uw pagina eruitziet. Misschien heb je niet zoveel banners bovenaan nodig, misschien moet je bovenaan de contacten (adres, telefoon, fax) aangeven, misschien in de vorm van pictogrammen voor "sitemap", "home", "contacten". Misschien heb je geen nieuws aan de linkerkant nodig, maar laat je aan de linkerkant ‘promoties en releases’ zien.

Het belangrijkste is nu om de logica van het werk te beschrijven.

Bedieningslogica

Ik zal het beschrijven aan de hand van de afbeelding hierboven.

De bovenkant van de site blijft op elke pagina van de site hetzelfde. De nieuwsfeed is alleen zichtbaar op de hoofdpagina. Op de secundaire pagina's aan de linkerkant tonen we de menu-subitems van het item waarin we ons momenteel bevinden (als we bijvoorbeeld op de pagina 'klantenservice' zijn, tonen we links naar 'garantieservice', 'post-garantieservice' ”). Als u op deze links klikt, wordt u dus naar de betreffende pagina's geleid. Hier, onder de subitems aan de linkerkant, tonen we gegevens voor het contacteren van online consultants (Skype, ICQ). Het promotie- en releaseblok blijft op elke pagina staan. De voettekst van de site wordt op elke pagina hetzelfde weergegeven.

Dit is ongeveer hoe de algemene logica van het werk wordt beschreven.

Nu beschrijven we elk blok in detail. Bijvoorbeeld " Nieuwsfeed».

"Nieuwsfeed" van de 10 laatste nieuws. Elk nieuws moet de nieuwstitel, publicatiedatum, kort begin nieuws (4-5 regels) en “volledig lezen” links. Wanneer u op de link ‘volledig lezen’ klikt, wordt u naar de nieuwspagina geleid. Het nieuws dat u bent tegengekomen, wordt weergegeven in plaats van de hoofdinhoud. Het bevat ook de titel van het nieuws en de publicatiedatum. De nieuwsfeed wordt ook aan de linkerkant weergegeven. Nieuws van de afgelopen maanden en jaren wordt gearchiveerd. Dat wil zeggen dat we onder het nieuws voor de huidige maand "archief voor (die en die maand of jaar)" weergeven. Wanneer u op de link “archief voor (die en die maand of jaar)” klikt, verschijnt er een lijst met nieuws voor de overeenkomstige maand/jaar.

Zo beschrijven we de werking van elk blok. Laten we het kalenderincident niet vergeten. En het allerbelangrijkste: u moet het werk van de productcatalogus beschrijven. Hier geef ik je een taak: Probeer na te denken en te beschrijven hoe de directory zal werken. Stuur uw opties per e-mail. De beste publiceren wij.

Wat zou er nog meer moeten zijn? Het zou leuk zijn om de compatibiliteit aan te geven.

Compatibiliteit

In deze paragraaf geven wij aan welke besturingssystemen en in welke browsers de site er even goed uit moet zien. In welke versie, in welke taal moet het geschreven worden. Welk CMS wordt gebruikt. Het is de moeite waard om dit te benadrukken als je echt weet waar je het over hebt.

Als u deze vragen niet kent, geeft u eenvoudig aan in welke browsers de site correct moet worden weergegeven. Vertrouw voor de rest op het geweten van de artiest.

Conclusie

In dit artikel heb ik niet geprobeerd aan te tonen dat dit de manier is waarop technische specificaties worden samengesteld en niet op een andere manier. Doe dit en er zullen geen problemen zijn. Het samenstellen van een hoogwaardige technische specificatie is meer een kwestie van ervaring. Niet iedereen zal de eerste jaren in staat zijn een goede technische specificatie op te stellen.

In dit artikel wilde ik de principes laten zien waarmee het referentiekader is opgebouwd, de belangrijkste punten die de moeite waard zijn om op te letten. In hoeverre ik hierin ben geslaagd, hoop ik uit uw opmerkingen te vernemen.

En vergeet de taak niet!

Technische taak (TK, referentievoorwaarden) - brondocument voor het ontwikkelen en testen van een online winkel.

Het concept van technische specificaties

Technische specificaties - het originele ontwerpdocument technisch voorwerp (product). De technische specificatie legt het hoofddoel vast van het object dat wordt ontwikkeld, de technische kenmerken, kwaliteitsindicatoren en technische en economische vereisten, instructies voor het voltooien van de noodzakelijke fasen van het maken van documentatie (ontwerp, technologie, software, enz.) en de samenstelling ervan, evenals als speciale vereisten.

De referentievoorwaarden worden ook gebruikt bij het maken van een creatief object (videoclip, artikel, grafische afbeelding).

We kunnen zeggen dat de technische specificatie een document is dat beschrijft WAT de klant nodig heeft, in tegenstelling tot daaropvolgende projectdocumentatie, waarbij de nadruk wordt verlegd naar het beantwoorden van de vraag HOE dit te bereiken.

Een technische specificatie is een juridisch document - een toepassing is opgenomen in het contract tussen de klant en de aannemer voor ontwerpwerkzaamheden en vormt de basis ervan: het bepaalt de procedure en arbeidsvoorwaarden, inclusief het doel, de doelstellingen, principes, verwachte resultaten en deadlines .

Alle wijzigingen, aanvullingen en verduidelijkingen van de bewoordingen van de technische specificaties moeten met de klant worden overeengekomen en door hem worden goedgekeurd. Dit is ook nodig omdat als er onnauwkeurigheden of fouten in de initiële gegevens worden ontdekt tijdens het oplossen van een ontwerpprobleem, het noodzakelijk wordt om de mate van schuld vast te stellen van elk van de partijen die betrokken zijn bij de ontwikkeling en de verdeling van de verliezen die zijn geleden in verband hiermee.

Plaats van technische specificaties in de ontwerpstructuur

Ontwerpen is een proces (projectontwikkeling) dat een zekerheid heeft structuur, dat wil zeggen de volgorde en samenstelling van fasen en fasen, de reeks procedures en technische middelen die erbij betrokken zijn, de interactie van procesdeelnemers.

In overeenstemming met het Burgerlijk Wetboek is ontwerp een van de soorten contractwerk, waarvan het resultaat producten zijn ( project), dat wil zeggen een set ontwerpdocumentatie voor een ander product ( ontwerpobject). Het project is bedoeld om een ​​object, de werking, reparatie en verwijdering ervan te creëren, en om de tussen- en eindoplossingen op basis waarvan dit object is ontwikkeld te verifiëren of te reproduceren.
Woord "project" op het gebied van activiteit "project management" gebruikt in de betekenis van “programma”, “actieplan”, “werkpakket”.

Deelnemers aan ontwerpwerk zijn onderverdeeld in consumenten ( klanten deze werken) en leveranciers ( artiesten deze werken, aannemers). De gespecialiseerde uitvoerder wordt een ontwerper of ontwikkelaar genoemd. De leverancier kan, net als de consument van het product, een organisatie (rechtspersoon) of een specifiek persoon (individu) zijn.

Het ontwerpobject kan een materieel apparaat zijn, of de uitvoering van werk, of het verlenen van een dienst, bijvoorbeeld een gebouw of een industrieel complex, een technisch apparaat (apparaat, machine, apparaat), een besturingssysteem, een informatiesysteem , regelgevingsdocumentatie (bijvoorbeeld een standaard), enz.

De ontwerpfasen worden geregeld door normen. Dit is de volgende volgorde:

• Technische specificaties (volgens GOST 2.103-68 zijn niet van toepassing op ontwikkelingsfasen),
• Technisch voorstel,
• Voorlopig ontwerp,
• Technisch project,
• Fasen van een werkproject.

De oplossing voor elk probleem begint met het begrijpen en verduidelijken van de initiële gegevens. Die (technische) eisen die door de klant worden gesteld, zijn geformuleerd in de taal van een niet-gespecialiseerde consument en zijn technisch niet altijd helder en volledig. Het vertalen van de vereisten in de taal van het vakgebied, het zo volledig en competent mogelijk formuleren van het probleem, het rechtvaardigen van de noodzaak om het op te lossen, dit is het hoofddoel van de technische specificatie, een verplichte werkfase. De opdrachtnemer voert dit uit in nauw contact met de klant. In feite betekent dit dat de werkzaamheden van de aannemer aan het project al zijn begonnen.
In de machinebouw wordt deze fase soms genoemd extern ontwerp.

In de regel worden technische specificaties samengesteld op basis van een analyse van de resultaten van voorstudies, berekeningen en modellering.

Particuliere technische opdrachten

Tijdens het ontwerpproces van een complex object (systeem), waarbij de deelname van verschillende ontwikkelaars vereist is, worden privé-technische specificaties voor subsystemen gecreëerd.

In overeenstemming met de ontvangen technische vereisten genereert de systeemontwikkelaar technische specificaties en voert hij, in de fase van het technische voorstel, een decompositie van het object uit en stelt hij specifieke technische specificaties voor subsystemen op. Nadat alle fasen van het technische voorstel zijn voltooid, coördineert en keurt de ontwikkelaar het goed met de systeemklant, en verduidelijken zij gezamenlijk de initiële technische specificaties.

Na goedkeuring van het technisch voorstel verdeelt de systeemontwikkelaar private technische specificaties onder mede-uitvoerders, op basis waarvan private technische specificaties kunnen worden ontwikkeld voor subsystemen van lagere niveaus. Als subsystemen op het tweede niveau ontbreken, wordt het technische voorstel voor de subsystemen vaak niet geïmplementeerd omdat het praktisch op systeemniveau is voltooid.

Na voltooiing van de fase van distributie van technische specificaties beginnen de ontwikkelaars van het systeem en zijn subsystemen met het uitvoeren van de voorlopige ontwerpfase. De ontwikkeling van de structuur in deze fase wordt uitgevoerd in nauwe interactie tussen alle ontwikkelaars. Tijdens dergelijk werk worden afzonderlijke onderdelen met elkaar verbonden en worden de belangrijkste parameters van het ontworpen object overeengekomen. De kwaliteit van het ontwerp hangt af van de breedte van de visie van de ontwikkelaar op het probleem, dat wil zeggen van zijn horizon en zijn vermogen om rekening te houden met alle verbindingen van het object in kwestie, en de aanwezigheid van kennis die verwante gebieden bestrijkt. Tijdens het voorlopig ontwerp en de coördinatie van specifieke oplossingen met de algemene is het mogelijk om de technische specificaties aan te passen.

Na voltooiing van het voorlopig ontwerp, de afstemming en goedkeuring van de daaruit voortvloeiende technische oplossingen met de klant, gaan zij over naar de fase van het technisch ontwerp. Hier worden alle belangrijke structurele werkzaamheden aan het object en zijn onderdelen uitgevoerd. Het is mogelijk om technische oplossingen te verduidelijken door terug te keren naar eerdere fasen. Het technisch ontwerp wordt uitgevoerd in nauwe samenwerking tussen alle ontwikkelaars.

De behoefte aan technische specificaties

De initiële taak wordt door de klant uitgegeven. De belangrijkste redenen die hem dwingen zich tot een ontwikkelaar te wenden zijn het gebrek aan relevante speciale kennis of de beperkte middelen (gebrek aan tijd om het probleem op te lossen, het benodigde aantal mensen, apparatuur) bij de klant.

De taak kan duidelijk worden gedefinieerd, bijvoorbeeld wanneer al het werk door één persoon wordt uitgevoerd, of wordt uitgegeven door een gerenommeerde specialist, of niet in twijfel kan worden getrokken (overheidsbevel). Maar vaker wordt het in algemene termen geformuleerd in de taal van een niet-gespecialiseerde consument, ver verwijderd van de taal van de ontwikkelaar en de voorwaarden van het vakgebied. Onzekere eisen veroorzaken onzekerheid bij alle deelnemers aan het werk, omdat ze verschillende interpretaties van de eisen mogelijk maken en geen objectieve beoordeling van de kwaliteit van het ontwikkelde product mogelijk maken. Ook moet de ontwikkelaar begrijpen dat de klant de speciale vereisten mogelijk niet (of gedeeltelijk kent), wat de ontwikkelaar niet ontslaat van de verantwoordelijkheid en verplichting om te voldoen aan de vereisten van toezichthoudende autoriteiten, ongeacht hun aanwezigheid bij de taak. Niet alleen de klant, maar ook de ontwikkelaar (uitvoerder) is dus verantwoordelijk voor het stellen van ontwikkelingsdoelen en het nut van het resultaat ervan.

Het opstellen van technische specificaties is een complexe en verantwoordelijke taak: veel gegevens zijn nog niet bekend, maar hoe de taak wordt gesteld, kan het daaropvolgende ontwerp gemakkelijker of moeilijker maken (figuurlijk gesproken: “hoe je het schip ook noemt, zo zal het varen”) .

Deskundigen zijn van mening dat een competente technische specificatie meer dan 50% van het succes bij het oplossen van een probleem bepaalt, en dat de tijd die wordt besteed aan het opstellen van technische specificaties een van de beste investeringen is die een bedrijf tijdens de ontwerpperiode kan doen. Niet voor niets wordt het opstellen van technische specificaties toevertrouwd aan toonaangevende specialisten - hoofdontwerpers, project- en werkmanagers, enz.

Academicus A. N. Krylov vertelde het. In één fabriek werd een nieuwe machine geïnstalleerd, maar die kregen ze niet werkend. Vervolgens wendden ze zich tot een universiteitsprofessor voor hulp. Aangekomen in de fabriek liep hij lange tijd rond de auto, zorgvuldig op zoek naar iets en ergens naar luisterend. Vervolgens pakte hij een hamer en sloeg op haar lichaam. En de auto begon te werken. Voor zijn hulp vroeg de professor het fabrieksbestuur om 100 roebel (dit was aan het begin van de 20e eeuw). Maar het fabrieksbestuur vond dit te veel om voor één klap met een hamer te betalen. Waarop de professor antwoordde dat de slag zelf één roebel kost, maar waar hij moet worden 99 roebel. Het is opgevallen dat als de kosten voor het corrigeren van een ontwerpfout die in de fase van het technisch ontwerp is gemaakt op 1 worden genomen, de kosten voor het corrigeren ervan ongeveer 10, 100 en 1000 keer stijgen als de fout respectievelijk in de fase van het voorbereidende ontwerp is gemaakt. ontwerp, technisch voorstel en technische specificaties!

Als communicatiemiddel in de communicatieverbinding tussen klant en uitvoerder kunt u met technische specificaties:

• Aan beide partijen:
  • stel je het eindproduct voor,
  • het uitvoeren van een puntsgewijze controle van het eindproduct (acceptatietesten – uitvoeren testen),
  • het aantal fouten verminderen dat gepaard gaat met veranderende vereisten als gevolg van hun onvolledigheid of fouten (in alle fasen en stadia van de creatie, met uitzondering van testen).
• Aan de klant:
  • beseffen wat hij precies nodig heeft,
    • inclusief, vertrouwend op de momenteel bestaande technische mogelijkheden en onze middelen,
  • van de contractant eisen dat hij voldoet aan alle voorwaarden vermeld in de technische specificaties.
• Uitvoerder:
  • de essentie van de taak begrijpen, de klant het ‘technische uiterlijk’ van het toekomstige product, softwareproduct of geautomatiseerde systeem laten zien,
  • de uitvoering van het project plannen en volgens plan werken,
  • weigeren werkzaamheden uit te voeren die niet in de technische specificaties zijn gespecificeerd.

Gereglementeerde technische specificaties

Ondanks het belang ervan wordt de inhoud van technische specificaties weinig gereguleerd door regelgevingsdocumenten (GOST, OST).

• GOST 19.201-78. Uniform systeem van programmadocumentatie. Technische taak. Eisen aan inhoud en vormgeving (de inhoud van de technische specificaties wordt kort geschetst);
• GOST 34.602-89. Informatie Technologie. Set normen voor geautomatiseerde systemen. Technische specificaties voor het opzetten van een geautomatiseerd systeem (de samenstelling en inhoud van de technische specificaties zijn voldoende gedetailleerd beschreven);
• GOST 25123-82. Computermachines en gegevensverwerkingssystemen. Technische taak. De volgorde van constructie, presentatie en ontwerp (de volgorde van constructie van de technische specificaties wordt gegeven).

Wat het uitvoeren van onderzoekswerkzaamheden betreft, wordt de technische specificatie geregeld door de volgende documenten:

• OST 95 18-2001. De procedure voor het uitvoeren van onderzoeks- en ontwikkelingswerkzaamheden. Basisvoorzieningen.
• Bijlage nr. 3 bij de Regels voor aanvaarding van R&D, goedgekeurd bij besluit van Rosprom op 16 september 2004 nr. 95. Taakomschrijving voor onderzoekswerk (bijgevoegd vindt u een voorbeeld van een taakomschrijving voor ontwikkeling in het kader van het Staatsverdedigingsbesluit)

Secties met technische specificaties volgens GOST 34.602-89 (voorbeeld)

Volgens GOST 34.602-89 moet de technische specificatie de volgende secties bevatten (weergegeven in verkorte vorm):

1. Algemene informatie
   1. volledige naam van het systeem en zijn symbool;
      Voorbeeld:
      Volledige naam van het systeem: Geautomatiseerd systeem"Controle"
      Symbool: ACS
   2. onderwerpcode of code (nummer) van het contract;
      Voorbeeld:
      Overeenkomst nr. XXX gedateerd DD.MM.JJJJ
   3. de naam van de ondernemingen (verenigingen) van de ontwikkelaar en klant (gebruiker) van het systeem en hun gegevens;
      Voorbeeld:
      KLANT Klantnaam: MIR LLC Legaal adres klant: 142345, Moskou, st. Tverskaja, gebouw 15 Postadres klant: 142345, Moskou, st. Tverskaya, huis 15 Werkelijk adres van de klant: 142345, Moskou, st. Tverskaya, gebouw 15 Telefoon: +7 903 456 67 67 Fax: +7 903 453 34 54 E-mailadres: [e-mailadres beveiligd] OGRN: 4554545445454 INN: 4343434345 KPP: 453345443 BANK: ZAO BankStroy, Moskou BIC: 444454554 RS: 564456456456454453445 KS: 43223423400000000 234
      AANNEMER Naam van de aannemer: LLC "WOODPECKER" Juridisch adres van de klant: 142345, Moskou, st. Lenina, huis 34 Postadres van de klant: 142345, Moskou, st. Lenina, huis 34 Werkelijk adres van de klant: 142345, Moskou, st. Lenina, gebouw 34 Telefoon: +7 495 345 63 63 Fax: +7 495 433 34 54 E-mailadres: [e-mailadres beveiligd] OGRN: 4554545445454 INN: 4343434345 KPP: 453345443 BANK: ZAO BankStroy, Moskou BIC: 444454554 RS: 564456456456454453445 KS: 43223423400000000 234
   4. een lijst met documenten op basis waarvan het systeem tot stand is gekomen, door wie en wanneer deze documenten zijn goedgekeurd;
   5. geplande start- en einddata voor de werkzaamheden aan het creëren van het systeem;
   6. informatie over de bronnen en procedure voor financiering van de werkzaamheden;
   7. de procedure voor registratie en presentatie aan de klant van de resultaten van het werk aan het creëren van het systeem (de onderdelen ervan), aan de productie en aanpassing van individuele middelen (hardware, software, informatie) en software en hardware (software en methodologische) complexen van de systeem.
2. Doel en doelstellingen van het creëren van het systeem
3. Kenmerken van het automatiseringsobject
   1. korte informatie over het automatiseringsobject of links naar documenten die dergelijke informatie bevatten;
   2. informatie over de bedrijfsomstandigheden van de automatiseringsfaciliteit en omgevingskenmerken.
4. Systeem vereisten
   1. Eisen aan het systeem als geheel;
   2. Vereisten voor functies (taken) die door het systeem worden uitgevoerd;
   3. Vereisten voor soorten onderpand.
5. Samenstelling en inhoud van het werk om het systeem te creëren
   1. lijst met documenten in overeenstemming met GOST 34.201, gepresenteerd aan het einde van de relevante fasen en fasen van het werk;
   2. type en procedure voor het onderzoek van technische documentatie (fase, fase, volume van de documentatie die wordt gecontroleerd, deskundige organisatie);
   3. een werkprogramma gericht op het waarborgen van het vereiste betrouwbaarheidsniveau van het systeem dat wordt ontwikkeld (indien nodig);
   4. een lijst met werken over metrologische ondersteuning in alle stadia van de systeemcreatie, met vermelding van hun deadlines en presterende organisaties (indien nodig).
6. Procedure voor controle en acceptatie van het systeem
   1. typen, samenstelling, reikwijdte en testmethoden van het systeem en zijn systemen componenten(soorten tests in overeenstemming met de huidige normen die van toepassing zijn op het systeem dat wordt ontwikkeld);
   2. algemene vereisten voor de aanvaarding van werk in fasen (lijst van deelnemende bedrijven en organisaties, locatie en tijdstip), procedure voor coördinatie en goedkeuring van aanvaardingsdocumentatie;
   3. status van de acceptatiecommissie (statelijk, interdepartementaal, departementaal).
7. Vereisten voor de samenstelling en inhoud van de werkzaamheden om het automatiseringsobject voor te bereiden voor de inbedrijfstelling van het systeem
   1. het in het systeem binnenbrengen van de informatie (in overeenstemming met de vereisten voor informatie- en taalkundige ondersteuning) in een vorm die geschikt is voor verwerking met behulp van een computer;
   2. wijzigingen die in het automatiseringsobject moeten worden aangebracht;
   3. het creëren van voorwaarden voor het functioneren van het automatiseringsobject, waaronder de overeenstemming van het gecreëerde systeem met de eisen opgenomen in de technische specificaties is gegarandeerd;
   4. oprichting van afdelingen en diensten die nodig zijn voor het functioneren van het systeem;
   5. timing en procedure voor personeelsbezetting en training.
8. Documentatie-eisen
   1. een lijst met sets en soorten te ontwikkelen documenten die voldoen aan de eisen van GOST 34.201 en wetenschappelijke en technische documentatie van de branche van de klant, overeengekomen door de ontwikkelaar en de klant van het systeem; lijst met documenten uitgegeven op computermedia; vereisten voor documentatie op microfilm;
   2. vereisten voor het documenteren van componenten voor sectoroverschrijdend gebruik in overeenstemming met de vereisten van de ESKD en ESPD;
   3. Zonder staatsnormen, die de vereisten voor het documenteren van systeemelementen definiëren, omvatten bovendien vereisten voor de samenstelling en inhoud van dergelijke documenten.
9. Ontwikkelingsbronnen: documenten en informatiemateriaal (haalbaarheidsstudies, rapporten over voltooide onderzoekswerkzaamheden, informatiemateriaal over binnenlandse en buitenlandse analoge systemen, enz.), op basis waarvan de technische specificaties zijn ontwikkeld en die moeten worden gebruikt bij het creëren van het systeem .

Type en samenstelling van de technische specificaties

Meestal stelt de klant een doel (zoals hij dat begrijpt) en beperkingen van de middelen (tijd, geld). De taak van de uitvoerder is in de eerste plaats om de vereisten in de taal van het vakgebied te vertalen, het probleem zo volledig en competent mogelijk te formuleren en de noodzaak van een oplossing ervan te rechtvaardigen. Als gevolg hiervan zal de technische specificatie de volgende informatie bevatten:

• Doelpunten binnen functionele vorm. Het product is slechts een materiële drager functies, waarvan de implementatie u in staat stelt de gespecificeerde doelen te bereiken (voldoen aan behoeften). Maar verschillende apparaten kunnen dezelfde functie vervullen. Daarom vergroot een functionele in plaats van een inhoudelijke indicatie van een doel het scala aan mogelijke oplossingen dat nodig is voor het zoeken optimale oplossing. Functie is ook een duidelijkere term om de essentie van het doel van het apparaat te beschrijven. Het verduidelijken van de doelstellingen en het toewijzen van de bijbehorende functies is het belangrijkste onderdeel van het werk bij het opstellen van de technische specificaties;
• De uitvoering van functies die bepaalde behoeften implementeren, is altijd gekoppeld aan het voldoen aan bepaalde vereisten (zie de lijst met standaardvereisten voor technische apparaten), die producten aantrekkelijker maken, rekening houden met en specificeren van de kenmerken van productie en bediening, enz. gemak zijn de vereisten onderverdeeld in drie soorten groepen:
  • omstandigheden worden gekenmerkt door specifieke gegevenswaarden (formeel kunnen ze worden weergegeven in de vorm van gelijkheden). De massa van het product moet bijvoorbeeld 10 kg zijn, er moet 40X staal worden gebruikt en de plaats van gebruik moet de toendra zijn. Een belangrijk deel van de voorwaarden wordt gevormd door de beoordeling van de beschikbare middelen;
  • beperkingen specificeren het toegestane gegevensgebied (formeel kunnen ze worden weergegeven in de vorm van eenzijdige of tweezijdige ongelijkheden). Het gewicht van het product mag bijvoorbeeld niet groter zijn dan 10 kg, er moet koolstofstaal worden gebruikt;
  • kwaliteitsindicatoren (die worden omgezet in optimalisatiecriteria) specificeren alleen een lijst met kenmerken en de richting van het zoeken naar de voorkeurswaarde (maximale of minimale waarde, het gewicht van het product moet bijvoorbeeld minimaal zijn en het onderhoudsgemak moet maximaal zijn ). De specifieke waarde van de indicator wordt pas bekend aan het einde van de fase of de gehele cyclus van ontwerpwerkzaamheden en dient als maatstaf voor de voorkeur bij het zoeken naar de optimale optie (de basis voor het kiezen van de uiteindelijke optie).

Net als bij het ontwerpproces wordt ook het eisenwerk beheerd. Deze procedures zijn goed ingeburgerd, bijvoorbeeld in Beheer van softwarevereisten.

Om doelen en eisen te specificeren die vaag of kwalitatief gespecificeerd zijn, wordt de decompositiemethode gebruikt.

Bij het vormen van een systeem van eisen is analyse van de volgende bronnen vereist:

• Beschikbaarheid van middelen ter beschikking van de klant en ontwikkelaar: financieel, productie, menselijk, tijd. Alle middelen zijn met elkaar verbonden; door bijvoorbeeld de projectfinanciering te vergroten, kan de ontwikkelingsperiode worden verkort. Een gevolg van de mate van toegankelijkheid is de introductie van beperkingen op de methoden en nauwkeurigheid van het oplossen van het ontwerpprobleem, wat op zijn beurt het gekozen type model beïnvloedt. Wanneer de tijd beperkt is, voeren ze dus evaluatieberekeningen uit met behulp van vereenvoudigde methoden of gebruiken ze kant-en-klare software, standaardmethoden, standaardapparatuur, standaard- en aangekochte onderdelen en samenstellingen, enz. Tegelijkertijd moeten het model, de methode en de nauwkeurigheid van de oplossing moet ervoor zorgen dat aan de eisen van de technische specificaties wordt voldaan, ook al zijn deze hoog.
• Rekening houden met de eisen van toezichthouders en vergunningverlenende instanties bij het ontwerpen van bijvoorbeeld technologische complexen (producties). In overeenstemming met de wetten van de Russische Federatie vereist elke productie het verkrijgen van een regionale exploitatievergunning. Bovendien beschikken veel productiefaciliteiten over een vergunning van toezichthoudende autoriteiten en zijn zij onderworpen aan hun controle. De meest controlerende instanties zijn de regionale instanties Rostechnadzor, Rosstandart, het Ministerie van Regionale Ontwikkeling van Rusland (voorheen Gosstroy), Rospotrebnadzor, Rosprirodnadzor, Staatsbrandweer, Ministerie van Binnenlandse Zaken van Rusland, Rostrud.
• Leefomgeving van het ontworpen systeem. Het specificeert de eisen die de wederzijdse invloed van het ontworpen systeem en de omringende levende en niet-levende objecten en de externe omgeving kenmerken. Basisinstructies hierover worden gegeven in de technische vereisten onder de consumptievoorwaarden van toekomstige producten. Deze omstandigheden kunnen vrij algemeen worden gekarakteriseerd en vereisen specificatie.

Opstellen van een lijst met technische specificaties eisen

Het werk aan technische specificaties omvat een aantal fasen. En de onzekerheid die inherent is aan dit werk zorgt ervoor dat ze er verschillende keren, iteratief, doorheen gaan, van een meer algemene formulering van het probleem naar de gedetailleerde uitwerking ervan (het ontwerp is iteratief van aard en waar in het begin geen rekening mee is gehouden, kan in het ontwerp worden opgenomen). rekening in volgende fasen).

Laten we eerst een verhaal vertellen over hoe Edison zichzelf een technische taak stelde.

Voordat Edison elektrische verlichting voor in huis begon te ontwikkelen, deed hij onderzoek onder welke omstandigheden deze qua prijs, helderheid en gemak zou concurreren met gasverlichting (claxon). Hij bestudeerde de gasindustrie gedetailleerd, ontwikkelde een plan voor een centrale elektriciteitscentrale en een diagram van elektriciteitsleidingen naar huizen en fabrieken. Vervolgens berekende hij de kosten van koper en andere materialen die nodig zouden zijn om lampen te maken en elektriciteit op te wekken met behulp van een door stoom aangedreven dynamo. Data-analyse bepaalde niet alleen de afmetingen van de lamp, maar ook de concurrerende prijs, gelijk aan 40 cent. En pas toen Edison ervan overtuigd was dat hij het probleem van de elektrische verlichting kon oplossen, begon hij te werken aan een gloeilamp met een koolstofdraad in een glazen bol waaruit de lucht werd weggepompt. Op zoek naar draadmateriaal testte hij ongeveer 6.000 soorten plantaardige vezels.

Analyse van de opdracht van de klant

De initiële taak wordt door de klant uitgegeven en in het formulier opgesteld technische benodigdheden. Het vertalen van deze vereisten in de taal van het vakgebied, het zo volledig en competent mogelijk formuleren van het probleem, het rechtvaardigen van de noodzaak voor de oplossing ervan, het begrijpen en verduidelijken van de initiële gegevens is de eerste fase van het werk. De opdrachtnemer voert dit uit in nauw contact met de klant.

U moet de volgende problemen identificeren en proberen te vermijden:

• taken die niet aan de sociale behoeften voldoen - crimineel, immoreel, inhumaan. Hun beslissing is een gewetenskwestie van de ontwikkelaar;
• technische pseudo-taken met ten onrechte gestelde doelen. Dit zijn taken waarvoor al een oplossing bestaat, of waarvoor geen objectieve voorwaarden bestaan ​​voor hun oplossing (voortijdige taken, maar dit moet gerechtvaardigd worden zodat de weigering om op te lossen niet het gevolg is van psychologische traagheid of andere subjectieve redenen);
• chimere problemen. Dit zijn taken met een verkeerd gesteld doel, waarvan de verwezenlijking in tegenspraak is met de wetten van de natuurkunde (bijvoorbeeld het creëren van een apparaat met een efficiëntie van meer dan 100%, een onmiddellijk apparaat, enz.), of abstract naar voren gebrachte taken die fundamenteel zijn geen oplossing (zoals de steen der wijzen).

Bij het opstellen van technische specificaties is het belangrijk om de initiële eisen kritisch en onbevooroordeeld te benaderen. Om dit te doen heb je nodig:

• zorg ervoor dat de aangegeven behoeften echt waardevol zijn voor de klant, of de initiële gegevens waar zijn en welke nadelige of schadelijke gevolgen kunnen optreden tijdens het realiseren van deze behoefte;
• ontdek de essentie van de behoefte, vind de bron van het voorkomen ervan;
• ontdek wat het gebruik van het vorige product verhindert om aan nieuwe behoeften te voldoen.

De belangrijkste reden voor de behoefte aan nieuwbouw is de beschikbaarheid tegenstrijdigheden tussen verlangen en mogelijkheid tot bevrediging behoeften. Als er geen tegenstrijdigheid is, kan aan de behoefte worden voldaan zonder nieuwe producten te creëren. Als er geen tegenstrijdigheid lijkt te zijn, maar de bestaande oplossing niet past, betekent dit dat er daadwerkelijk een tegenstrijdigheid bestaat, en dat je daar zorgvuldig naar moet zoeken.

De tegenstrijdigheid kan worden ontleed, dat wil zeggen gepresenteerd in de vorm van elementaire problemen.

In de meeste gevallen is er sprake van een prototype: een prototype of origineel product dat de klant niet meer tevreden stelt. De aanwezigheid van een prototype vereenvoudigt de beslissing, maar de afwezigheid ervan creëert geen psychologische traagheid in de vorm van vooraf bepaalde oplossingstrajecten, die niet altijd tot het beste resultaat leiden.

• of vergeet het bestaan ​​ervan en bied, uitgaande van de initiële behoefte, mogelijke opties aan, gevolgd door het kiezen van de beste;
• of het prototype verbeteren met behulp van IFR;
• of lokaliseer de behoefte. Meestal worden onbevredigende prestaties geassocieerd met imperfectie van slechts enkele subsystemen. Voor dit doel wordt het prototype ontleed op basis van zijn functionele kenmerken, en wordt de tegenstrijdigheid gepresenteerd in de vorm van elementaire problemen. Door elementaire problemen te correleren met bepaalde subsystemen van het prototype, worden ‘imperfecte’ subsystemen geïdentificeerd. Van het oplossen van een algemeen en complex probleem gaan ze dus over op een eenvoudiger specifiek probleem. Maar de mate van verbetering van de eigenschappen kan laag zijn en er kunnen problemen ontstaan ​​bij het verbinden van de verbeterde subsystemen met de voorgaande.

Specificatie van ontwerpdoelen

Na het verduidelijken en verantwoorden van de ontwikkelingsdoelen worden de bijbehorende functies toegewezen. Om ervoor te zorgen dat vooroordelen en psychologische traagheid het zoekgebied niet verkleinen en de klant door zijn probleemformulering niet vooraf de richting van het zoeken naar een oplossing bepaalt, is het raadzaam om de functie in het algemeen en in neutrale termen te formuleren. Het is dus beter om de functie "omverwerpen" (bijvoorbeeld planken) te vervangen door de term "verbinden", waarmee je kunt ontsnappen aan de natuurlijke associatie - neerhalen met spijkers, en een breder scala aan mogelijke oplossingen biedt.

Tijdens het zoeken naar de meest complete en nauwkeurige formulering wordt een keten van functies (een boom van doelen) opgebouwd - van het aanvankelijk voorgestelde tot het uiteindelijk aanvaarde. Dit wordt geholpen door het beantwoorden van de vraag “Waarom is dit nodig?” (en andere vragen van de testvraagmethode). In de meeste gevallen is het doel dat in de eisen wordt vermeld de noodzaak om meerdere functies (opeenvolgend of gelijktijdig) uit te voeren. Voor elk van hen wordt een keten van functies gebouwd.

Naast de noodzaak tot enige actie kan er ook een noodzaak bestaan ​​om een ​​actie niet uit te voeren of een actie uit te voeren met een negatief effect.

Verwerking van verzamelde informatie

1. Generalisatie en abstractie.
Individuele fragmenten worden met elkaar verbonden en samengevat zodat, indien mogelijk, een volledig, duidelijk en beknopt beeld wordt verkregen van het object in ontwikkeling, rekening houdend met mogelijke wijzigingen. Dubbele informatie wordt verwijderd, inclusief informatie die elkaar in andere formuleringen herhaalt of een speciaal geval is.

Abstractie is bedoeld om de vereisten zo te formuleren dat het vooraf bepalen van manieren om het probleem op te lossen wordt vermeden (niet om psychologische barrières te creëren). Om ‘sterke’ oplossingen te verkrijgen wordt aanbevolen om het systeem van eisen te versterken en tegenstellingen te verergeren door het formuleren van een IFR.

2. Controleer op inconsistenties.
Als er meerdere functies zijn, kunnen sommige tegenstrijdig zijn in hun effect (het water moet bijvoorbeeld heet zijn (voor het zetten), maar je handen niet verbranden). Om tegenstrijdigheden op te lossen is het gebruik van heuristische methoden effectief. Tegelijkertijd is het elimineren van tegenstrijdigheden mogelijk, zowel in de fase van het opstellen van technische specificaties (het veranderen van de formulering van functies, het verspreiden van hun acties in tijd of ruimte, enz.), Als in de daaropvolgende ontwerpfasen.

Voorwaarden en beperkingen moeten ook worden gecontroleerd op inconsistentie. Beperkingen kunnen dus een lege set specificeren. Dergelijke tegenstrijdigheden zijn niet altijd voor de hand liggend: informatie over de boven- en ondergrenzen kan op verschillende tijdstippen worden ontvangen of op verschillende plaatsen in het werkoverzicht worden geplaatst, en kan in een impliciete vorm worden gepresenteerd.

3. Eisen opsplitsen in voorwaarden, beperkingen en kwaliteitsindicatoren.
Door eisen te presenteren in de vorm van indicatoren kunt u oplossingen met hoge prestaties verkrijgen, maar dit probleem is moeilijker op te lossen. De indicatoren zijn de indicatoren die de belangrijkste eigenschappen karakteriseren (om de beste waarden te kunnen verkrijgen). Voor de ingevoerde voorwaarden is het noodzakelijk om de omvang van de spreiding te evalueren en de noodzaak om grenswaarden aan te geven, dat wil zeggen om ze in de vorm van beperkingen te presenteren.

4. Parametrering.
De nauwkeurigheid van het oordeel en de juistheid van de keuze hangen af ​​van de mate van specificiteit van de initiële vereisten, ongeacht of deze in geformaliseerde of informele vorm worden gepresenteerd. Om de conclusies ondubbelzinnig te maken, moeten alle vereisten worden vertaald in een geformaliseerde vorm, dat wil zeggen dat de parameters die ze karakteriseren moeten worden aangegeven, en de parameters die kunnen worden gemeten, gecontroleerd en berekend. Dit maakt het ook mogelijk om dubbele vereisten (die worden gekenmerkt door dezelfde parameters) te identificeren en deze te generaliseren (introductie van gegeneraliseerde parameters om hun totale aantal en specifieke kenmerken te verminderen).

Bij het oplossen van een optimaal ontwerpprobleem wordt aanbevolen om kwaliteitsindicatoren terug te brengen tot een op criteria gebaseerde, geformaliseerde vorm, dat wil zeggen om ze een numerieke maatstaf toe te kennen. De belangrijkste methode voor het specificeren van formuleringen is het construeren van een boom van doelen (EN- of OF-bomen): de initiële indicator wordt ontleed om elementaire concepten te identificeren die op unieke wijze worden gekenmerkt door sets van parameters.

De wetenschap van “Qualimetry” houdt zich bezig met de problemen van het beoordelen van kwaliteit aan de hand van kwantitatieve indicatoren.

5. Inkorting van de lijst met eisen.
Een grote hoeveelheid informatie, die weliswaar het meest complete beeld kan geven van het probleem dat wordt opgelost, is moeilijker in het hoofd vast te houden en bemoeilijkt de oplossing van het probleem. Om de informatie tot een redelijk volume terug te brengen (afhankelijk van de mogelijkheden van elke specifieke ontwikkelaar, naleving van zijn financiële, organisatorische, technische en tijdbronnen), kunt u hun rangschikking of indeling in groepen van verplicht, wenselijk en niet-essentieel gebruiken. Tot de verplichte opties behoren degenen wier ontevredenheid de keuze van beslissingsopties aanzienlijk beïnvloedt. Dit zijn functionele parameters, voorwaarden voor de relatie tussen systemen en hun onderdelen, en andere. Met wenselijke eisen kunt u onderscheid maken tussen opties op basis van kwaliteit.

Het is de moeite waard om rekening te houden met de woorden van Lee Iacocca: “... het probleem is dat je aan Harvard hebt gestudeerd, waar het in je hoofd is geboord dat je geen actie kunt ondernemen voordat je alle feiten hebt verzameld. Je beschikt over 95% van de informatie, en om de ontbrekende 5% te verzamelen heb je nog eens zes maanden nodig. Gedurende deze tijd zullen alle feiten achterhaald raken, omdat de markt zich veel sneller ontwikkelt. Het belangrijkste in het leven is om alles op tijd te doen. ...de hoofdtaak is het verzamelen van alle belangrijke feiten en standpunten die voor u beschikbaar zijn. Maar op een gegeven moment moet je daadkrachtig gaan optreden. In de eerste plaats omdat zelfs de meest correcte beslissing verkeerd blijkt te zijn als deze te laat wordt genomen. Ten tweede omdat er in de meeste gevallen niet zoiets bestaat als volledige zekerheid. Je zult nooit 100% van de informatie kunnen verzamelen. Helaas wacht het leven niet tot je alle mogelijke misrekeningen en verliezen hebt geëvalueerd. Soms moet je gewoon willekeurig vooruit gaan en gaandeweg fouten corrigeren.”

6. Verzameling van eisen in één document en goedkeuring daarvan door de klant.

Literatuur

• Chorosjev A.N. Inleiding tot ontwerpbeheer van mechanische systemen: een studiegids. - Belgorod, 1999. - 372 p. - ISBN 5-217-00016-3 Elektronische versie 2011