Our process begins with a face-to-face consultation where we will gather some preliminary information about your business, the challenges faced, and how we can help. Once we have an understanding of your business requirements, we offer up to 8 hours of planning and consultation free of charge to provide you with a "ball-park" estimate of time, cost, and project scope. We then work with you to establish a budget that we will adhere to so there are no surprises. Once a budget has been established, we will undergo the Requirements Analysis phase that will allow us to commit to the specified project scope.

During the Requirements Analysis phase, we take an in-depth look at your current business processes and how we can address problems or bottlenecks with a custom built solution. This phase is absolutely critical to the current and future success of the software; without it we are building a house without a blueprint. The only way to validate the success of a custom software endeavour is to thoroughly understand what needs to be delivered.
The Requirements Analysis phase also allows us to establish and commit to project scope, time, and cost so there are no surprises. This phase is typically comprised of the following sub-phases:

• Requirements Elicitation  

  
  
  Definition: The process through which the clients, buyers, or users of a software system discover, reveal, articulate and understand their requirements.
  
  The requirements elicitation phase involves interviewing the client, or more specifically, the users of the system, in order to establish their needs and/or wants in terms of system functionality. This approach will require a first-hand experience of the business processes currently in place, which will allow us to envision what it is we need to automate. From here, we will be able to develop the best possible solution to increase efficiency of operations.



• Scope Identification  

  
  

  
  

  • System Requirements Analysis  

    
    
    

    Definition: The process of reasoning about the requirements that have been elicited; it involves activities such as examining requirements for conflicts or inconsistencies, combining related requirements, identifying missing requirements, and confirming the requirements with the client.
    
    The functional requirements that have been identified at this stage will be clearly specified using use cases, which is a popular software engineering technique used for capturing the potential requirements of a new system. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert.
    
    Upon completion, the use cases will be reviewed by the end users of the system to ensure that the system’s functional requirements have been accurately captured.
    
    
  • Non-Functional Requirements Identification  

    
    
    

    Definition: Non-functional requirements specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. Whereas functional requirements identify “what“ the system should do, non-functional requirements identify “how“ the system should do those things. Examples of non-functional requirements are reliability, scalability, and usability.


• Requirements Triage  

  
  
  

  By prioritizing components of the system based on several key factors, it can be ensured that the most important functionality is implemented in the shortest period of time, resulting in a working system that is deliverable sooner. Some of the key factors to consider when prioritizing requirements are:
  
  

  • How fundamental the component is to business operations
  
  
  • How reliant other system functionality is on the feature
  
  
  • The client’s level of interest in the feature
  
  
  • Technical difficulty of implementation
  
  

  
  
• Estimations and Project Scheduling  

  
  
  

  Once the product requirements and architecture have been established and are well understood, project estimations and scheduling may take place. The end result is a more intricate understanding of time and cost, allowing us to commit to a specified scope for within your budget.
  
  

With the now solid understanding of the business requirements and project scope, we are able to proceed with the high and low-level designs of the system that serve as the final blueprint for your solution.

• Systems Architecture  

  
  
  

  Definition: The software systems architecture of a program or computing system is the structure or structures of the system, which comprise the software components, the externally visible properties of those components, and the relationships among them.
  
  In plain terms, software systems architecture is the high level design of the system. This initial stage of the elaboration phase is intended to provide a high enough level of abstraction so that the system can be viewed as a whole.
  
  
• Prototyping  

  
  

  
  Definition: A development mock-up of the system used to test various aspects of the design. This stage will involve conducting usability studies with actual end-users. We will have the users perform various tasks using the mock-up in order to determine if the design is appropriate. There may be a need for multiple usability studies throughout the development process.
  


• System Design  

  
  
  

  Definition: Defining the hardware and software components from a technical standpoint, in order to satisfy the project requirements, as per the Use Cases and Usability Studies.
  
  

The System Implementation and Testing components are executed in an iterative fashion, in accordance with the prioritization of the business requirements (Requirements Triage). This entails that we will build the most critical components of your software application first, deploying the system at frequent milestones. Accompanied with weekly feedback, these short iterations allow you to begin realizing a return on investment after only a short period of time. The end results of this agile approach are minimized risk and a more effective system.

• System Implementation and Testing (Iterative Process)  

  
  
  

  Throughout the system implementation and testing stages, the application will be physically constructed, as per the information gathered thus far. This is an iterative process, in that design, implementation, and testing iterations are repeated as the system is built.
  
  

The fourth and final phase involves the deployment of the completed system and integration with your business processes. By this time, you will have already tried and tested the system several times to ensure a seamless transition with no surprises.

• System Testing - All Components in Hand  

  
  
  

  The system will endure rigorous integration testing to ensure that all requirements have been met, and all bugs have been worked out.
  


• Installation  

  
  
  

  Integrating the software into the workplace. This will involve connections with servers, further minor system testing, and information seminars.