• it makes the whole development project well defined and predictable. Therefore it allows us to much more precisely estimate completion time, and  overall cost.
• it significantly reduces the need for changes in the middle of the project. Through insightful, detailed analysis there are very few second thoughts - As a result it is more than likely that the only changes that will arise during the project, will be as a consequence of   unpredictable trends in the business environment This is also very important from a budgeting point of view. Any changes introduced later - meaning during the development, the testing stage or after  implementation - are much more expensive and may lead to substantial delays. Eliminating software defects during the  requirement phase costs next to nothing.
• it facilitates budgeting and internal evaluation - you know well in advance what are you going to pay for. It also helps to build successful reasoning, supporting the project inside your organisation
• because of the precise scope and acceptance criteria, it facilitates the acceptance process and sets a solid basis for  settlement. In other words, we know exactly, what we have to deliver, and you have a precise checklist, to decide whether the product is acceptable.

• high quality documentation allows us to keep our whole team constantly focused on our targets at any stage of planning and coding, and deliver exactly what you have demanded
• it helps diminish the effect of vendor lock. Having the complete project documentation allows you to easily compare our offer to the competition. We actually encourage our clients to do so
• it is beneficial also for your internal processes. The analytical workshops  have something to do with consulting services. They are the great opportunity to stop for a moment and look into some details you usually have no time to think about, and try to optimize them
• it helps us refine the testing routines to precisely recreate the final user’s needs and scenarios. Therefore it enables us to issue a warranty of compliance for the product with your specs
• Importantly for both parties - documentation strengthens our knowledge maintenance, and enables newcomers to quickly join the development team

We find out what are your pain areas

We start with the meeting or a series of meetings targeted to get to know you and your needs at the most rudimentary level.

The starting point for the conversation can be BRS (Business Requirements Specification) document already prepared by your organisation, but we can also prepare it together, during the consultation process.

The most common parts of a business specification are:

• Business objectives and background
• Scope
• Features
• Business environment constraints
• Functional requirements
• Personnel requirements
• Delivery schedule and progress reporting

We come to the workshops equipped with our analytical experience and predefined questions that let us outline the what kind of new value you need to introduce to your organisation what are your functional and non-functional requirements. We also look to identify the most sensitive areas of the project that can greatly influence its scope and cost such as legacy systems migrations, applications to integrate with, legal and fiscal requirements to meet etc.

Similarly important questions are the ones related to project’s scale and time horizon. That means a number of staff users and levels of access, expected network traffic, prospective future development of project’s scope.

That’s the moment we also identify users groups and their characteristics, and write user stories reflecting the activities that the app will perform in the future. We also ask about your analytical needs, to find out what tools you would require and what database traffic it can generate. The company culture can also influence the project greatly, i.e. it can influence the decision to use open source software components, and what level of security we should target.

This phase of the analysis process is extremely engaging and even fascinating for both parties. It is also very fruitful from a business perspective. Going through business processes one step after another and scanning different stakeholders requirements can be a great eye opener and a rare opportunity to rethink and optimize your business logic - at least partially. Analysts are here a kind of translator between you and the team of product managers and developers as they usually use a lot of technical vocabulary, that may cause a lot of confusion and misunderstandings. Skilled translation is also needed in the opposite direction - to ensure the developers accurately understand your business goals.

The requirements gathering phase is the right moment to estimate the projects time to market.   We are able to divide the project into smaller pieces and propose an MVP (that means the version with just enough features to be introduced into market, and provide feedback for future development) that can be delivered significantly sooner than the full product. Of course you have always the final word regarding the scope of the MVP.  As a result of our conversation we generate a concise but possibly detailed specification, with a project’s vision and its valuation.

Coding and testing - still under the analyst’s eye

The beginning of the coding stage does not mean, that we are finished analysing. On the contrary, our analysts remain involved throughout as a part of our agile approach to development.  

• while the preparation of business and technical analyses, as described above, are usually part of the initial few project iterations, they are constantly updated and expanded in every new product iteration and delivery of new features
• after every iteration we check the product accuracy, comparing it with the specification. In this  way we can ensure you, that despite dealing with lots of project details we still focus on your requirements and stick to what has been planned

• analysts also come in every time you request a change. In this case we analyze your newly reported requirements within the context of the whole project, we examine contact points of the new features with the other and try do minimize the change’s influence on the process KPIs.
• analysts are present at the stage of User Acceptance Tests (UAT) and product release to check its accuracy once more. At this stage we can issue a warranty of compliance with the clients requirements.