A requirements analysis as the basis for a future project

We gather, organize, unify, and document product requirements, identify and analyze contradictions, investigate and eliminate points of incompleteness. A requirements analysis allows you to find the optimal technical solution, harmonize understanding of the goals and system features, formulate user behavior scenarios, and create a roadmap for development.

The project documentation that is subsequently created is a set of analytic artifacts that will become a solid foundation in the implementation and subsequent operation of your IT system.

“The first 90% of the project takes 10% of the time, and the last 10% of the project takes 90%.”
Murphy’s Law
The benefits of a project requirements analysis
Find the optimal IT solution
Expert analytics helps to determine the optimal technical implementation of the planned IT system and to consider possible solution options that would meet business needs.
A requirements analysis as the basis for a future project
Correctly define the project boundaries and scope of work

By neglecting to carry out a thorough requirements analysis, both you and the contractor can be mistaken in the project cost by an order of magnitude: the initial drafts of terms of reference often conceal the underwater part of the iceberg. At first blush, the project may appear to be relatively straightforward; however further down the line it turns out that in order for the software to really solve the problem for which it was intended, you will have to do much more than planned.

There is also an inverse risk: overestimating the project, putting in unnecessary requirements that will be scrapped after priority analysis. Elaboration of requirements can significantly improve the overall accuracy of the estimation.

Uncertainty in software cost and size estimation
relative size range accuracy vs. phase
A requirements analysis as the basis for a future project A requirements analysis as the basis for a future project
  • Feasibility
  • Concept of operation
  • Requirements specification
  • Product design specification
  • Detailed design
  • Accepted software
Reduce total project cost

In a situation of great uncertainty the contractor typically includes all possible risks and unfavorable scenarios in the cost estimation of the project. With the help of detailed project analytics the questionable elements can be worked out at an early stage, thus reducing both the risks and the overall cost estimation.

The cost of the risks is usually significantly higher than the additional costs for analytics at the initial stage.

For example, in a project consisting of 10 modules, a certain percentage of risk is included for every module, which summarily significantly increases the total cost.

Cost savings due to requirements analysis
A requirements analysis as the basis for a future project
Cost per module
  • Initial estimation
  • Corrected estimation after requirements analysis
Total project cost
  • Initial estimation
  • Corrected estimation after requirements analysis
Retain accumulated knowledge

The product requirements are captured according to a fixed methodology throughout a project which allows you to preserve knowledge in the most complete and structured form. All evolutions will be available for subsequent use by new participants in any time span.

This task is especially important for corporate systems in which further development and transition to internal support are planned.

A requirements analysis as the basis for a future project A requirements analysis as the basis for a future project
Provide for future product development

In order for a solution to support the scalability and performance requirements in the long-term, a technical implementation must be carefully thought out ahead of time.

If you start development without analyzing the requirements, you can find yourself in a situation where further product development will be unfeasible, and the cost of correcting decisions will be much higher than at the planning stage.

Cost of Change
Boehm’s Curve
A requirements analysis as the basis for a future project A requirements analysis as the basis for a future project
  • Requirements specification and analysis
  • Development
  • Testing
Monitor work progress and control the final result

Analytics allows you to bring all participants to a common understanding of the requirements and scope of the project, set the final goal, agree on a suitable roadmap and monitor progress along it.

Our experience shows that once a project is underway requests for changes more often than not arise; it thus follows that work on requirements happens continuously throughout the entire development process, allowing you to maintain manageability at all stages of the project life cycle.

A requirements analysis as the basis for a future project A requirements analysis as the basis for a future project
  • What the customer needs
  • What the developer builds
  • Customer contact points
  • Expectation gap with customer engagement
  • Expectation gap without customer engagement
What documentation does your project require?

The more accurate the required estimation, the more detailed all parts of the requirements analysis should be. A set of required project documentation is determined based on the needs of your business and the specifics of the project.

Basis of requirements

These documents are a must-have for any project. Without these, the chances of the project succeeding to its full potential are sharply reduced.

Basis of requirements
Project concept

A high-level description of the project (goals, objectives, boundaries, stakeholders, user roles, key processes, etc.)

Context diagram

A visualization of the system and the environment in which it will operate along with a data flow structure.

Functional flow block diagram

A visual representation of the main functions of the system without reference to roles or components.

Analysis of technical risks and limitations

Description of the key technical risks affecting the feasibility of implementing the system, and proposals for their elimination.

Non-functional requirements

Description of requirements for performance, fault tolerance, security, scalability, and other system parameters.

Large number of system components

The larger the number of different autonomous parts, integrations with external systems, development teams on the project, the more detailed will be the protocols of interaction between parts of the system.

Large number of system components
System architecture

High-level description of system components and schemes of interaction between them.

Communication protocol specification

Description of communication protocols (REST, gRPC, etc.) between system components and between the system and the external environment.

Deployment diagram for enterprise systems

For systems with increased reliability requirements, a careful study of the update delivery process and an action plan in the event of force majeure situations is required.

Complex processes or high regulatory requirements

The higher the requirements for the process regulation, and the more complex the processes to be automated, the more detailed the description of the user interaction with the system will be.

Complex processes or high regulatory requirements
User stories

Description of tasks to be solved and acceptance criteria for all functions of the designed system.

Usage scenarios

Full description of all scenarios of interaction between users and the system, as well as automatic scenarios of the system.

For complex scenarios with several participants or many steps and branches, visualization is additionally accomplished using suitable diagrams (swimlane, sequence, etc.).

Enterprise systems user manuals

For effective operation after deployment, it is necessary to provide users with clear operating instructions and protocols in case of emergency situations.

Wide user audience

The wider the circle of users of the application, the more competing applications, or the more important the user experience, the more detailed the structure of applications will be, especially between-screen navigation and the composition of each screen.

Wide user audience
Blockflow

Visual representation of the main steps of users in the system.

Wireflow / Transition Map

User interface screen layouts and a map of the main transitions between them. Detailed layouts with all the main functional elements and a screen map help to create an understanding of ​​what users can do in the system and how these functions will be distributed across screens without the cost of final visual design of all system states. Also, the presence of wireflow helps to get a more accurate estimate of the cost of implementation.

Interactive prototype

A set of screens in wireflow or in full visual design of the future application (requires a complete interface design), which allows the use of the application to be emulated in the main scenarios.

Several decision makers

The more stakeholders the project has on the client’s side and the more complex the approval process is, the more detailed the visual design of each screen needs to be in order to minimize the expectation gap and make sure everyone is on the same page at the earliest possible stage of development.

Several decision makers
User interface design concept

Style of the main elements (buttons, tables, drop-down menus, etc.) of the user interfaces.

Complete user interface design

With a detailed design study, the client will be able to show the design to potential users to get feedback on the clarity of the interface and the overall impression of the product. You can then make edits and maximize user satisfaction without the cost of rewriting product code.

Cost estimation and implementation plan
Calculation of the cost by phases, the optimal composition of the team, the timing and sequence of actions for system development, possible start date and milestones of development.
A requirements analysis as the basis for a future project
Why project analytics documentation is valuable in its own right
1
Ability to review an estimation and get a second opinion

When there is insufficient technical competence within the company to evaluate the implementation plan received from the developer, the project documentation makes it possible to turn to a third-party expert who can provide an independent assessment. This will reduce the risk of overestimating or underestimating the project and ensure that the requirements are feasible.

2
Keeping original goals in sight

The process of planning a system and developing requirements can go through multiple iterations and face changes in priorities and participants over long periods of time.

Without capturing, structuring and formalizing requirements, it will be impossible to restore the original meanings and goal setting, and crucial elements may lose priority or even be missed altogether.

3
Contractor comparison, selection or change

When comparing preliminary estimates received from several potential contractors, it is important to keep in mind that each of them can interpret your request in a slightly different way and come up with a rate for different functionality. When creating project documentation, the requirements are recorded in a detailed and defined form, which allows you to minimize ambiguity when they are interpreted by different performers and get development estimates that can be compared with each other.

4
Full command of the system after implementation

Project documentation allows you to minimize the need to consult developers or accompanying after the system is put into operation. Detailed user documentation is created on the basis of the analysis of functional requirements, which makes it possible to fully use the system without being tied to specific individuals.

2003
2020
70% of our clients return with new projects
17 years
on custom software 
development market
120+
developers with experience 
across multiple industries
460+
successful projects for 
clients all over the world
Let’s see how we can make your business stronger