Project success depends on excellent and active requirements management. Requirements-stage errors are the most common type and the most expensive to fix when they go undetected. A ‘requirements defect’ that manages to slip through to production can cost two orders of magnitude more to fix than one which is caught earlier in the lifecycle. For these reasons, Incoda employs a rigorous approach to requirements management.
Incoda takes a systematic approach to eliciting, organizing, and documenting all system requirements. We have a clearly defined process whereby we establish and maintain agreement on requirements, as they are refined throughout the development lifecycle. Our requirements management process is tightly integrated with all aspects of the development lifecycle from business modeling and business case development through testing and system documentation.
Incoda employs multiple techniques to elicit requirements. Depending on the nature of the client and the project, Incoda will perform:
- Structured interviews with key stakeholders
- Facilitated requirements workshops
- Storyboarding
- Use case development
- Role playing
- Prototyping
Incoda’s success in eliciting requirements is our knowledge of which techniques are likely to be most successful in any given situation. We then bring in practitioners, skilled in the chosen techniques, to drive and facilitate client requirements sessions.
To bring value to clients, Incoda looks beyond readily apparent functional requirements. Functional requirements must be viewed and understood in the context of business requirements, quality requirements, and architectural requirements. Incoda’s requirements management process ensures that the broad spectrum of requirements are understood and documented so that our solutions reflect the true needs of our clients.
We also make sure to capture and categorize requirements that reflect future as well as current needs. In this way, we can design our solutions with future growth in mind. We also make sure that good ideas which surface during requirements analysis are not forgotten, even though they may not ‘make the cut’ for the first release of a product.
