/1.%20Visuals/Website/Icons/RegulatoryCompliance_Visuals_Navigation%20(1).png?width=40&height=40&name=RegulatoryCompliance_Visuals_Navigation%20(1).png){kind=icon}
/1.%20Visuals/Website/Icons/Testing_Visuals_IconNavigation%20(1).png?width=40&height=40&name=Testing_Visuals_IconNavigation%20(1).png){kind=icon}
/1.%20Visuals/Website/Icons/CTG%20Academy.png?height=56&name=CTG%20Academy.png){kind=icon}
‘Know thy customer’ is not only the key commandment in all things marketing and sales; it is just as important for software development. In spite of the iterative, agile approach taken in today’s software projects, it is crucial to lay the foundations of a software app before kicking off the project. Hence Cegeka’s foundation phase: a series of workshops – and visualization, lots of visualization – enabling us to deeply understand your organization and needs.
From request to proposal in 4 steps:
Step 1: Identifying the business drivers: goals, actors, impacts and deliverables
To get a helicopter view of the project at hand, we first identify the high-level business drivers – the ultimate goals of the project – and then prioritize them. Questions we discuss include:
- Why do you need new software: what is the problem the software app needs to solve?
- Who will use the application? What are their needs, expectations and touchpoints?
- What systems will the software interact with (legacy business applications, data stores, data warehouse, external systems, cloud services, etc.)?
- What does the solution have to include – and what not?
By identifying the business drivers, we get to truly understand your organization and your needs. That allows us to think with you, our customer, throughout the development project.
Mapping the customer journey
During step 1 of the foundation phase, we map out the customer journey: the paths your different users follow when interacting with the software. In this way, we can ensure the best user experience at every step.
Understanding the business drivers allows us think with the customer throughout the software development lifecycle.
Step 2: Defining the project scope: functional, non-functional, context and technical requirements
Once we understand your business drivers, we translate those insights into a description of the software’s required features: the functional requirements. In addition, we list non-functional requirements (quality attributes such as the desired performance). Based on these insights and the context of the software, we then determine the technical scope, i.e. the architecture and technology stack needed.
Questions include:
- What does the system have to enable – what are the features needed (functional)?
- What criteria have to be met?
- What is the Minimal Viable Product, the minimal set of features that is absolutely must-have to create a first impact?
- What are the critical non-functional requirements, i.e. how should the system work in terms of performance, scalability, availability, security, reliability, interoperability, maintainability, etc. (non-functional)?
- What is the project context: the application landscape, the use cases, etc.?
All the features we identify in this step are enlisted in a ‘feature map’ that we use to schedule them based on the priorities set. Once we have defined non-functional requirements and context, we draw up context, component and container diagrams. All these documents will serve as guidelines and reference points for the software developers from day 1 until the completion of your software project.
Non-functional requirements: strike the right balance
Writing down the non-functional requirements is essential, but it is often forgotten when preparing a software project. Customers may take characteristics like performance and security for granted, assuming they are inherent to every application. They are right, of course, but only to a certain degree. Factors like project needs, budget restrictions, company politics, regulations and much more all impact your choice to invest (or not) in any one non-functional requirement. That’s no easy task. Over-specify them and the solution may be too costly to be viable. Under-specify them and your software quality will drop dramatically. Tradeoffs will therefore be needed. We have the experience needed to help our customers make the right choices.
Step 3: Setting the price
Only when all the above requirements have been listed will we create the project budget. Together with software developers, we divide the software into subtasks and associate a number of man days with each of them. Our final cost estimate combines that budget with a contingency budget to cover unexpected events that could come up during development.
Step 4: Drawing up the roadmap
At the end of the foundation phase, we draft a concrete project roadmap that specifies the timeline, releases, the number of software developers needed, the need for other personnel like security or UI experts, etc.
In close cooperation
The foundation phase requires teamwork and, ideally, marks the beginning of a successful, long-term partnership with you. To fully understand your needs and wants, a cross-functional Cegeka team – made up of a project manager, domain experts, developers, etc. – listens and talks to your business as well as IT people. Of course, we keep up this dialogue throughout the software development project to ensure the resulting software exceeds your expectations.
The foundation phase requires teamwork and, ideally, marks the beginning of a successful, long-term partnership with you.
/1.%20Visuals/Website/Icons/x-twitter.svg){kind=icon}
