Een nieuw project starten of een vastlopend project uit het dal halen?
InnoBridge helpt in het proces van het identificeren en het definiëren van projecteisen, en daarnaast ook met het formuleren en formaliseren van deze projecteisen.
Door het verzamelen van alle belangen, behoeften en wensen door interactief met de opdrachtgever en stakeholders het gesprek aan te gaan.
Door InnoBridge zal dat uitgewerkt worden in een overzicht van requirements, constraints, interests en needs.
InnoBridge helpt met het formuleren (en het formaliseren) van klantwensen en project-(on)mogelijkheden om hiermee het gewenste projectresultaat te realiseren.
Met jarenlange ervaring is het doorgronden en inzichtelijk maken van behoeften en belangen gesneden koek voor InnoBridge. Dat kan bij de initiatie van een project, tijdens de realisatie van het project of bij de evaluatie van een project.
Onfhankelijk Betrouwbaar No-nonsens Snel To the point geen politiek.
Een opdracht wordt per voorkeur met een duidelijke omschreven resultaatverplichting fixed price vervuld, maar een inspanningsverplichting op basis van uren kan natuurlijk ook.
Leveringsvoorwaarden volgens DNR2011 ingenieurs en architecten.
DUURZAAMHEID MVO
Bridge the Gap
Projecten lopen uit en overschrijden het budget. De verwachtingen zijn hoger dan het resultaat. Het is bijna standaard. Natuurlijk zijn er legitieme redenen aan te wijzen of te bedenken, maar er is veel te winnen door er bewust van te zijn welke GAP's er kunnen optreden bij een project en weten hoe deze zoveel als mogelijk te beperken en te beheersen. InnoBridge kan daarbij helpen.
| Eliciteren |
Het woord eliciteren komt niet voor in de meeste Nederlandse woordenboeken, maar mag binnen requirements engineering met recht een werkwoord worden genoemd.
Het is een proces van (iteratief) kwalificeren en geïntegreerd interpreteren van eisen en wensen in samenwerking met de business.
Doorvragen in het zogenaamde elicitatieproces is essentieel om duidelijk te krijgen wat er gerealiseerd moet worden. |
| Analyseren |
Bepalen in welke mate de opgestelde klanteisen onduidelijk, incompleet, onbepaald of tegenstrijdig zijn, en deze onvolkomenheden corrigeren. |
| Specificeren |
SMART documenteren van de klanteisen in een ontwerpsysteem. |
| Valideren |
Samen met de klanten en gebruikers evalueren of de set van klanteisen juist en volledig is in relatie tot hun behoeften en vereisten. |
| Realiseren |
Het tot resultaat brengen van het project. Inclusief Contracten - V&V - V&G. |
How to gather functional and non-functional requirements?
Guided brainstorming session is one of the best ways to gather requirements by getting all stakeholders together. You should include user representatives who are the best sources of non-functional requirements.
Basically functional requirements can be divided into 4 groups which are:
Business requirements. They contain the ultimate goal, such as an order system, an online catalogue, or a physical product. It can also include things like approval workflows and authorization levels.
Administrative functions. They are the routine things the system will do, such as reporting.
User requirements. They are what the user of the system can do, such as place an order or browse the online catalogue.
System requirements. These are things like software and hardware specifications, system responses, or system actions.
Once the functional requirements are defined then its time to think about the non-functional requirements, such as:
Usability. This focuses on the appearance of the user interface and how people interact with it. What colour are the screens? How big are the buttons?
Reliability / Availability. What are the uptime requirements? Does it need to function 24/7/365?
Scalability. As needs grow, can the system handle it? For physical installations, this includes spare hardware or space to install it in the future.
Performance. How fast does it need to operate?
Supportability. Is support provided in-house or is remote accessibility for external resources required?
Security. What are the security requirements, both for the physical installation and from a cyber perspective?
How to write functional and non-functional requirements?
There are different ways to write functional and non-functional requirements.
The most common way to write functional and non-functional requirements is through a Requirements Specification Document. It is a written description of the required functionality.
It states the project objective and includes an overview of the project to provide context, along with any constraints and assumptions. The requirements specification document is should
include visual representations of the requirements to help non-technical stakeholders understand the scope.
Closely related to a requirements specification document is a Work Breakdown Structure or WBS. This breaks down the entire process into its components by “decomposing” the requirements into their elements until they cannot be broken down any further.
Another approach is User Stories. They describe the functionality from the perspective of the end-user and states exactly what they want the system to do.
It effectively states “As a
, I want so that ”. One benefit of user stories is that they do not require much technical knowledge to write. User stories can also be used as a precursor to a requirements specification document by helping define user needs.
Use Cases are similar to user stories in that no technical knowledge is necessary. Use cases simply describe in detail what a user is doing as they execute a task. A use case might be “purchase product”, and describes from the standpoint of the user each step in the process of making the purchase.
Haalbaarheidsstudies bepalen de haalbaarheid van een toepassingsproject voordat het wordt goedgekeurd en gefinancierd, zodat het project is afgestemd op de doelen en doelstellingen van de organisatie. Zodra de vereistenbeoordeling is goedgekeurd, begint een gedetailleerde studie van de zakelijke behoeften van de organisatie. Dit proces omvat het interviewen en faciliteren van kleine groepssessies met belangrijke belanghebbenden.
InnoBridge biedt diensten om de applicatievereisten te verzamelen, kenmerken en functionaliteiten te identificeren, functionele en technische vereisten te ontwikkelen en de Request for Proposal (RFP) op te stellen met key performance indicators (KPI's), metrische gegevens of vereisten op serviceniveau indien nodig .
- Enterprise Analysis – Project initiation activities for assessing requirements and functional design work, conducted within the context of the entire organization.
- Requirements Planning and Management – Resources and tasks associated with the planning and management of requirements gathering.
- Requirements Elicitation – Standard techniques used to gather requirements for an application or integrated system. These activities focus on:
- High-level design – how applications will interact
- Low-level design – how individual applications will function
- Interface design – the technical mapping and graphical representation of the interfaces
- Data design – the actual data requirements
- Requirements Analysis and Documentation – Methods and tools used to structure data collected during Requirements Elicitation.
- Requirements Communication – Activities for expressing the output of Requirements Analysis and Documentation to a broad, diverse audience.
- Solution Assessment and Validation – These activities are conducted to ensure the solution meets stakeholder objectives, is thoroughly tested, and is successfully implemented
- Bedrijfsanalyse – Projectinitiatieactiviteiten voor het beoordelen van eisen en functioneel ontwerpwerk, uitgevoerd in de context van de gehele organisatie.
- Vereisten planning en beheer – Middelen en taken die verband houden met de planning en het beheer van het verzamelen van vereisten.
- Vereisten uitlokken – Standaardtechnieken die worden gebruikt om vereisten voor een applicatie of geïntegreerd systeem te verzamelen. Deze activiteiten richten zich op:
- Ontwerp op hoog niveau – hoe applicaties samenwerken
- Low-level design – hoe individuele applicaties zullen functioneren
- Interface-ontwerp – de technische toewijzing en grafische weergave van de interfaces
- Gegevensontwerp – de feitelijke gegevensvereisten
- Analyse en documentatie van vereisten – Methoden en hulpmiddelen die worden gebruikt om gegevens te structureren die zijn verzameld tijdens het opsporen van vereisten.
- Vereisten Communicatie – Activiteiten om de output van Requirements Analyse en Documentatie uit te drukken aan een breed, divers publiek.
- Beoordeling en validatie van oplossingen – Deze activiteiten worden uitgevoerd om ervoor te zorgen dat de oplossing voldoet aan de doelstellingen van belanghebbenden, grondig wordt getest en met succes wordt geïmplementeerd
Utiliteitssector
De technologie in de utiliteitssector verandert snel. Aangezien cloud-, mobiele en andere digitale technologieën aanzienlijke operationele voordelen bieden, willen nutsbedrijven bestaande legacy-technologieën bijwerken en ondersteunende bedrijfsprocessen transformeren. Van complexe factureringssystemen voor nutsbedrijven tot hybride IT-infrastructuur
Transport
In het afgelopen decennium werd de wereldwijde transportsector gekenmerkt door toegenomen toezicht door de regelgeving en de concurrerende eisen van veiligheid en efficiëntie. Meer dan ooit moeten transportentiteiten in staat zijn om gebruik te maken van kosteneffectieve IT als drijvende kracht achter verbeterde veiligheid en operationele stroomlijning, waardoor de vlotte levering van grote hoeveelheden passagiers en vracht over de hele wereld wordt gegarandeerd.
Onderwijs
In de onderwijssector moeten technologische oplossingen worden ontworpen, geïmplementeerd en onderhouden rond de behoeften van eindgebruikers: de studenten, docenten, personeel en ouders die afhankelijk zijn van technologie om belangrijke institutionele resultaten te bereiken, evenals nationale en federale vereisten
Gezondheidszorg
Ziekenhuizen zijn omgevingen met hoge druk zonder uitvaltijd. De faciliteiten zijn 24/7/365 open en moeten worden beveiligd en optimaal presteren. Vol met processen, vereisten en voorschriften - het is noodzakelijk om de privacy van patiënten te beschermen, gemoedsrust te creëren voor werknemers en diefstal te voorkomen. In de gezondheidszorg is een alomvattende oplossing nodig om iedereen te bewaken en te beschermen, van patiënten, bezoekers, personeel en artsen.
Wie is Marc
Marc is iemand die werkt op basis van vertrouwen om de beste prestaties binnen een organisatie te bereiken. Hij gaat samen met de mensen en de data binnen organisaties aan de slag om prestaties inzichtelijk te maken en resultaat te bereiken. Marc kan zich uitstekend inleven in complexe vraagstukken en de behoeftestelling optimaal vertalen naar een concrete oplossing.
Hij bezit een breed spectrum aan vakkennis en een hoog abstractievermogen.
Met een bedrijfskundige en een technische achtergrond, beweegt Marc zich zowel op een bestuurlijk als een technisch werkterrein.
Marc heeft ruim 30 jaar (internationale) werkervaring en is vanaf 2003 zelfstandig ondernemer.
Een uitgebreide profielbeschrijving is te vinden op Linkedin. 
