Our Process


The image below details the 6 steps that Benchmark incorporates into the software development lifecycle for all projects.



During this phase, our business analysts defines the scope of the project at hand, who the end users are, any noticeable problems and opportunities, business and technical constraints, apparent project goals, and possible solutions. The end result is a feasibility study that produces a preliminary cost-benefit analysis report. This report will enable us to determine whether significant resources should be dedicated to the other phases of this project.


Gathering the overall total project requirements is one of the most important aspects in any software development process. All of these requirements are gathered and inserted into a document called the Software Requirements Specifications (SRS). This document will contain the functional requirements of the project and how the developers will enhance the project to achieve all the objectives. The Software Requirements Specifications in general serves as a guide for both the client and the developers. It is used for ongoing maintenance on the project as well as the base document for generating the validation and acceptance tests. The Software Requirements Specifications mainly addresses the problem domain in which the product will exist. It is the first step in a project that moves it from the problem domain, to the solution domain. The basic Software Requirements Specifications outline contains the following sections:


This section is a stand-alone executive summary. It is divided into the following four sub-sections:

  • Purpose: This part identifies the purpose and target audience of the Software Requirements Specifications.
  • Scope: This section identifies the products to be produced. It also explains what these products will and will not do.
  • Assumption and Dependencies: This section lists and describes the factors that affect the requirements stated in the Software Requirements Specifications. These factors are not design constraints on the software. However, any changes made to them affect the requirements in the Software Requirements Specifications.
  • Overview of the SRS: This section describes the Software Requirements Specifications and how it is organized.


This section describes the general factors that affect the product and its requirements. The following five subsections make the requirements easier to understand:

  • Product Perspective: It relates the product to other projects, or products. A block diagram showing the major components of the larger system or project, interconnections, and external interfaces is used as an effective explanatory tool .
  • Product Functions: It summarizes the functions of the product. The functions are organized in a manner that makes the list of functions understandable to the customer, or to anyone else reading the document for the first time. Block diagrams showing different functions and their relationships, are used as an effective explanatory tool.
  • User Characteristics: List the general characteristics of the users that will affect the specific requirements. Characteristics such as education level, experience, and technical expertise impose constraints on the systems’ operating environment.
  • General Constraints: Provide a general description of the other items that limit the developer’s options for designing the system. These may include regulatory policies, hardware limitations, interface to the other applications etc .


This section contains all the details that a software developer needs to create a design. This is the largest and the most important part of the Software Requirements Specifications. In this section, details are defined as individual specific requirements. Specific requirements are organized in the following subsections:

  • Functional Requirements: This subsection specifies what the input and output should be, and what operations are required.
  • External Interface Requirements: This subsection of Software Requirements Specifications contains all the information products will and will not do. Adequately develop the interfaces to entities outside of the software specified. Specific interfaces to hardware, other software applications, and communication systems are specified in this subsection.
  • Performance Requirements: This subsection should specify the static and dynamic numerical requirements placed on the software, or on human interaction with the software as whole. Static numerical requirements may include a number of terminals to be supported, a number of concurrent users etc. Dynamic numerical requirements may include a number of transactions and tasks, as well as the amount of data to be processed within certain time periods for both normal, and peak workload conditions.


The supporting information adds to the completeness of the Software Requirements Specifications:

  • Definitions Abbreviations and Acronyms: This section provides the definitions of all terms, acronyms, and abbreviations required to interpret the Software Requirements Specifications correctly.
  • References: This section provides the complete list of documents referenced elsewhere in the Software Requirements Specifications.


Once the software requirements specifications is approved, the next stage is Use Case modeling. Use Case modeling is a form of requirements engineering. It is a different way of eliciting and documenting software requirements. It partitions the system functionality into transactions meaningful to actors, who are idealized users of the system. Use Case describes an interaction with the actors as a sequence of messages between the system, and one or more actors. The term actor includes humans, time, other computer systems, or processes.

The Use Case model is a prime source for objects and classes. It is the primary input for class modeling. The system architect does the Use Case modeling. Once the Use Case model is completely built, Use Cases are mapped with the actual requirements in the software requirements specifications. A Use Case/Requirement matrix is created. This ensures that a Use Case is modeled for every requirement.


Based on the written Use Cases, the systems analyst designs the user interface layout of the software. The User Interface is designed in such a way that all the use cases are satisfied through that user interface. This may be the final deliverable interface (Windows Forms/Web Pages), or the dummy user interface with placeholders. Creation of the user interface at this stage makes the requirements clearer to the client.


Once the requirements are frozen, and the user interface is finalized, the next stage is to model the entire application. Unified Modeling Language (UMLA) is extensively used for modeling the application. UML helps you specify, visualize, and document models of software systems, including their structure and design.

Any precise model must first define the key concepts of the application, their internal properties, and their relationship to each other. This set of constructs is the static view. The application concepts are modeled as classes. Each of these classes describes a set of discrete objects that hold information, and communicate to implement behavior. The information they have is modeled as attributes, while the behavior they perform is modeled as methods. Object to object relationships are modeled as associations among the classes. The static view is notated using the class diagram. The static view can be used to generate most data structure declarations in a program. (Source: The Unified Modeling Language Reference Manual)

The view of a system of interacting objects is collaboration. It is a context-dependant view of objects and their links to each other, together with the flow of messages between objects across data links. This viewpoint unifies data structure, control flow, and data flow in a single view. Collaborations and interactions are shown in sequence, and collaboration diagrams.


To capture fast paced complex businesses, we must consider methods that go beyond traditional ER diagrams. Maximize Technologies depends on Object Role Modeling (ORM) for its data modeling. ORM is a method for designing and querying database models at the conceptual level. Here the application is described in terms readily understood by users, rather than being recast in terms of implementation data structures.

The architect develops an information model by interacting with others who are familiar with the application. Because these subject matter experts need not have technical modeling skills, reliable communication occurs by discussing the application at a conceptual level, using natural language, analyzing the information in simple units, and working with instances (sample populations). Like any good modeling method, ORM is far more than a mere notation. It includes various design procedures to develop and evolve conceptual models.

Once all the facts are expressed and an ORM model is created, tables can be generated automatically. The design of the database is automatically normalized to the fifth normal form. All relationships, constraints, and default values are maintained when the database is created.


During the course of architecting the software, the architect creates the test plans and quality documents. These documents help the Quality Assurance team to test the product thoroughly, and ensure the quality of the product. The architect also generates a deployment plan for the deployment team. The architect uses the deployment diagrams to explain the deployment of the application.


The conceptual model is handed over to the software developers for coding and developing the application. The developers use cutting edge development tools to convert the conceptual model into a working real life application. Writing an optimized code is the foremost responsibility of a software developer. Best practices and coding standards are followed while developing the application. Every line of code written is properly documented.


Quality assurance is based on the principle that all deliverables from the application shall be independently reviewed, so that defects are identified and corrected as soon as possible.

A strategy for quality assurance may be viewed in the context of a spiral. Unit testing begins at the vortex of the spiral, and concentrates on each unit/component of the software as implemented in the source code. Using the component level design description as a guide, important control paths are tested to uncover errors within the boundary of the module. Testing progresses outwards along the spiral to integration testing, where the focus is on design and the construction of software architecture. Integration testing is a systematic technique for constructing the program structure, while at the same time conducting tests to uncover errors associated with interfacing.

As we move outwards on the spiral, we encounter validation testing where requirements established as part of requirement analysis are validated against the software that has been constructed. Finally, we arrive at system testing, where the software and other system elements are tested as a whole.


After the entire product is completely tested and approved, the deployment team deploys the product in the target environment as specified in the deployment document. The deployment diagram given by the systems architect during the architecture phase is used to deploy various components of the product in their target environments.