HBSS follows the industry standard Agile development methodology for all of its projects that require customization, integration and configuration to meet the specific requirements of the project. Agile Methodology refers to procedures that have been tested time and again and proven to help overcome problems. It is a very well organized and well researched plan to solve a problem. It is scientific in nature and can be executed in a series of small steps with the ability to be customized according to the requirements of a particular situation. Agile methodology provides detailed steps that are required to overcome a problem to accomplish a goal. For example: Software System Development, Testing and Deployment task consists of the following sub-tasks and are followed for all modules implemented: a) Develop software & system requirements; b) Gathering Requirements; c) Systems Engineering & Planning; d) Software development; e) Presentation and Acceptance of Design; f) Software system refinement based on partner and public interface beta testing and feedback.

Agile methods are based on iterative and incremental development where all the requirements are not a pre-cursor to software design and development.

HBSS offers the QRyde Cloud platform that has been developed using our own methodologies and will configure, customize, and develop additional components to meet and exceed the requirements. HBSS also has a REST API of its own that it can use to integrate with 3rd Party systems.

HBSS Agile Development Methodology

HBSS follows a very strict Agile Software Development Methodology following an iterative and incremental development process where all the requirements are not a pre-cursor to software design and development. As expressed earlier, user requirements and experiences evolve in an iterative manner and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile development promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. HBSS’ Scrum approach will be followed for the entire software (web portal, mobile app, integration and UI/UX) development and the subsequent maintenance efforts. Each iterative step is called a SCRUM.

Figure: Agile Software Development


SCRUM, the Agile method deconstructs tasks into small increments so that with minimal planning, software can be designed and developed. The time periods typically last from one to four weeks. For each iteration a cross functional team works in all functions: a) planning, b) requirements analysis, c) design, d) coding, e) unit testing, and f) acceptance testing. HBSS will demonstrate a working product at the end of the iteration to the client and its partners. This approach will a) minimize overall risk, b) keep the client and its partner aware of the progress, c) modify and adapt the project to user feedback, and d) steer the project in a user requirements driven manner. Even though a single iteration may not result in a release, they can be accumulated to meet the release milestones.


   Product Owner

The Product Owner will be the Project Manager that will represent the client and its partners – who are the voice of the customer. He is accountable for ensuring that the team delivers value to the business.

   Development Team

The HBSS Development Team will be responsible for delivering stated sub-goals in the development life cycle of the main website, the web portal, and the mobile app at the end of each Sprint (the Sprint Goal). The HBSS team will usually be made up of 7 +/- 2 individuals with cross-functional skills who will do the actual work (analyze, design, develop, test, technical communication, document, etc.).

   Scrum Master

The HBSS Scrum Master will be responsible for removing any impediments in the ability of the team to deliver the sprint goal/deliverables. The HBSS Scrum Master role is strictly to supervise the Scrum process and will exclude people management which will be managed by the project manager.

Scrum process


Each development unit in the Agile process is defined as SCRUM. For example design of the Fixed Route Bus Itineraries can be defined as a Sprint. The time allocated for this sprint may be 1 week. The concept is called “timebox”; that is, it is restricted to a specific duration (min. is 3 days, max is 2 weeks).


Each sprint will be preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified.

Product Development

If you select HBSS as your project developers, we will work with your stakeholders to develop a best of breed solution for you that delivers value which will exceed your expectation. When our team starts a project.

Partner Involvement

Past Performance in Partner Involvement

During a project review process, the HBSS team will engage the target users, user group representatives, government and corporate representatives and create an active advisory committee. During the MOVET project, groups included the Disabled American Veterans (DAV), Veteran Service Organizations (VSOs), Massachusetts Human Service Transportation, and the Department of Transportation.

Methodology Followed for Partner Involvement

HBSS team will adopt the Agile Development methodology to interact with the partners with assistance from the client. The already identified partners, if needed, will be explained the Agile process and encouraged to become part of the process. 

   Existing Connections: HBSS team will leverage its existing partnership with existing users (if possible) and develop peer-to-peer partnerships between different groups as needed.

   THE CLIENT Advisory Group:  HBSS team will engage users, user group representatives, and state and other government agency representatives by developing an active advisory committee.

   Expansion of Current Commitments: HBSS assumes that a client’s project partners have agreed to provide the data to seed the transportation database and to be actively involved in the system design and analysis and evaluation of the proposed user interface and deployment.

   Maintenance Cost Beyond the Project: HBSS team, with the help of THE CLIENT will describe the Return on Investment as well as continued value proposition and help the partners cover the future supports.

Software System Development, Testing and Deployment

Develop software & system requirements

Past Performance

HBSS, will leverage its 20 years of experience in software development in transportation applications, to help build a state of the art website and the associated software application that will be world class. HBSS has recently completed several large size projects (MOVET, DART ) and has learned a lot about specific user demographic issues as well as support systems and the institutional challenges that are present when developing these community based projects. Over the years HBSS has evolved a very unique requirements gathering technique.

Requirements Gathering Methodology

HBSS, while working closely with its existing clients, has developed a very unique method of generating realistic requirements and because of this approach 99% of HBSS software features are utilized by the users. It is based on a simple observation that:

“Software is a tool that allows users to do their job faster, more accurately and with reduced stress. If the tool is not understood they will not use it.”

HBSS has long ago discarded the thesis of gathering all the requirements up front as a) they are gathered in a conference room not on the desk of the user when they are working, b) they are at a high level and usually gathered by ‘nudging/coaxing’ the user as opposed to in a free-flowing environment where users can think deep, and c) developers do not relate and need to go to the users anyway.

HBSS conducts a) Scope Identification – a preliminary discussion with stakeholders on identifying operational/functional challenges, development of initial requirements by white boarding, screen sketching and power point animation; b) by Iterative Modeling and Model Storming, firming up on user interface screens and business rules by drilling down into functional details, finally developing a work plan and sharing of an high level architectural vision – so stakeholders can conceptualize the solution strategy; c) using a Test First Approach by rapid prototyping and allowing stakeholders and beta testers to click through and type in and develop a final set of requirements which are tested again with stakeholders and beta testers.

Figure: HBSS Agile Requirements Gathering Methodology a) Scope Identification, b) Iterative Modeling, c) Test First approach.


Systems Engineering & Planning

Past Performance

HBSS brings significant experience in managing large projects (from Panama Canal to Trading systems, to brokerage call center management systems, and more recently to statewide VTCLI scheduling and dispatching systems) – and consequently brings a very strong discipline in software development life cycle management.

Continuous planning and design keeps the team and the system honed in on maximum business value by the deadline.

Agile Functional Design process and Technology Stack Creation

The next stage after completing the Iterative Agile process of requirements gathering is the firming up of the Functional Design and the System Design. The former leads to application development framework, the latter to system architecture development.

The functional design process can be described in five (5) basic steps:

  1. Assembly of all Requirements Artifacts: During requirements gathering, several artifacts are gathered in an opportunistic manner. The requirements process attempts to refine and complete the missing holes as much as possible.
  2. Top-Down Validation and Refinement of Logical Model/DFD: Each user interaction is then traced from the top through all functional tasks and data stores, up until a final archival. This allows the HBSS team to evaluate any missing steps, missing requirements, missing users, missing 3rd Party components etc.
  3. Finalization of Functional Flow (DFD): Each DFD bubble is classified as a functional component to be fully defined either by further decomposing the DFD or if it cannot be further decomposed, handed over to the software development team as a ‘functional specification’ of a ‘component’.
  4. Creation of Data Dictionary and System Objects: The data elements gathered allow creation of formal data objects which map fairly closely the paper documents that record various pieces of information required to run the operation (e.g. a trip request is a data object and a driver record is a data object).
  5. Creation of Functional Design Document: The functional descriptions and data elements combined with user requirements upgrading and high level data model development leads to development of a functional design document. This document defines the overall structure of the product from a functional viewpoint.

The following elements from the previous phases are firmed up in this phase, and are the necessary steps needed to create a formal System Design Document.

Technology Stack Creation: Technology stack diagrams will identify all the layers in the stack and the various technology components that will be required as well as any 3rd Party system components. User Interface (UI) Flows Finalization: User interface (UI) navigation or UI-flow diagram, are the follow up from DFDs created in the functional design. Each function identified is represented by one or more mock-up screens (continued and expanded from the requirements phase). Business Domain Model Completion: The business model finalization is an important part of complete system design. This model, that starts evolving from the requirements gathering phase is completed and ratified in this phase. It documents all of the business entities (big and small) and documents the business relationships between them. Change Case Documentation: Each project we undertake is designed with a futuristic viewpoint and will always have several requirements for future development (change) such as Route Optimization already articulated. There are 2 types of changes that need to be documented: Technology changes and Business changes. System Design Document Creation: After completing the design phase, the HBSS team will assemble the individual results of the system design process in a System Design Document (SDD). This document will completely describe the system at the architecture level, including subsystems and their services, hardware mapping, data management, access control, global software control structure, and boundary conditions.

Presentation and Acceptance of Design

HBSS development methods focus rigorously on delivering business value early and continuously, as measured by running, tested software. From week to week and from iteration to iteration, the HBSS team will track how many running, tested features they are delivering.

This approach helps by creating a solution design and product that matches the user requirement very closely and the acceptance of Design becomes more of a ‘knocking of finer points’ rather than a large-scale evaluation of system design.

Following the Agile methodology, HBSS will keep the client’s team, the stakeholders and other partners in complete partnership from day one.

Software system refinement based on partner and public interface beta testing and feedback

The project when developed will be in continuous refinement from requirements stage to design to development and deployment stages. By reflecting on what features we have completed using both hard metrics like running, tested features and more subjective measures, we can then adjust our estimates and plans accordingly.

Edge Due to Continuous Beta Testing

With continuous testing the HBSS SCRUM team deterministically measure progress and prevents defects that may linger through the life of the project and then surprise everyone at the end of the cycle. The HBSS team is continuously cranking out only the running and tested features. This enables us to reduce the risk of failure, lateness in the project.

Emergent Feature Discovery During Beta Testing

As opposed to spending weeks or months detailing requirements as in waterfall systems, and then arguing at the end of delivery why the users did not point out flaws in the design and the requirements early on, the Agile development projects quickly prioritize and estimate features, and then refine details when they emerge during different phases of testing including late beta testing stages.

Website Design and Development

Agile Web Development Approach

As described elaborately, HBSS follows the Agile software development process and will use the same methodology with web development. This methodology will streamline the project and will allow HBSS team to spend quality time on actions that add value to the website and make it better.

Figure: Agile Web Development Methodology (All tasks are broken into Sprints and Agile methodology is followed to speed up the tasks). Software development starts early in the form of Prototyping.

In the process shown above, HBSS team’s web editors are interacting with content and navigation on day one. Navigation is fluid, and the HBSS team is getting in front of users faster.

THE CLIENT Website Specifications

The website developed will meet all the requirements laid out by the CLIENT.

Website Look and Feel

If desired the CLIENT logos and overall look and feel of their home page will be incorporated on the main Web Portal. The software on the other hand will be standard QRyde presentation.

Our general approach is built upon the following: a) Affordance: The UI displays visual clues indicating its next step: users do not “guess” their interaction; b) Expectation: Functionally, the UI delivers predictable results based on experience or standard UI conventions; c) Efficiency: The UI lets users perform an action with minimum effort. If the intention is clear, the UI delivers expected results the first time so users do not need to repeat efforts to achieve the desired action; d) Responsiveness: The UI provides immediate feedback indicating the action is in progress, and was successful/unsuccessful; e) Forgiveness If users make a mistake, it is easy to change or “undo” their action; g) Explorability: Users can navigate throughout the UI without penalty or “getting lost”; h) No frustration Users are emotionally satisfied with the interaction.

Cross Browser Compatibility

The client portal will be compatible with major web browsers including recent versions of Microsoft Internet Explorer, Mozilla Firefox, Google Chrome and Apple Safari. Any scripts used in the portal are categorized as cross-browser. Additionally, website development will have the following:

  • It will not require the users to download plug-ins.
  • Will be developed on technologies that will enable cross platform deployments

ADA Requirements

The implementation of Section 508 compliance assures accessibility to web content, for example: text descriptions for visuals so users with a visual impairment, or users requiring screen readers and refreshable Braille displays, can access the content.  The screen reader JAWS uses an integrated voice synthesizer with the computer’s sound card to output electronic content.

Automatic Partner Content Augmentation

HBSS will develop a fully customizable website which will have full integration with the YouTube Data API. This API will allow the website to perform many of the operations available on the YouTube website such as search for videos, retrieve standard feeds, and see related content.

User Profile Creation and Trip Management

In our methodology each user will have option to create their own profile whether a rider or a provider. Upon signing up the user will be required to sign a User Agreement/Disclaimer (language to be provided by the client). The system will capture all trip search requests made by consumers, including information such as source, destination, date and time, any special needs and the results provided by the system.

Access Your Web Portal from Commonly Used Devices

The system architecture of ITMS supports multiple user interfaces and devices including voice interface, and supports easy access from commonly used devices including smartphones and tablets based on the Android and iPhone OS (iOS) operating systems, workstations, laptops and kiosk models recommended for this project.

Work Management, Program and Cost Control

In HBSS development methodology, speed is of essence. Each task will be broken down into smaller tasks, and then assigned a specified time to complete. Since human relationship cannot be achieved in a time bound manner, the Agile methodology will allow us to demonstrate early capabilities to accelerate the buy-in, and carry out multiple efforts simultaneously – which should significantly reduce the risk of cost over-runs.

The Agile methodology also allows a very tight work management control using the concept of ‘Sprints’.  The project manager will be managing the relationship and each relationship will be evaluated based on metrics and parameters such as: a) executive commitment level, b) integration level, c) commerce level, d) match capability level and e) resource availability level. The partners and their designees will then be engaged appropriately. This will ensure no expectation mismatch and all partners will be able to participate in the best way they can. The partnership level may change with time and engagement.

Software Development, Testing and Deployment

HBSS’ project manager will be meeting regularly with the various stakeholders as described in the partner involvement task. Client stakeholders will be involved in discussions and sharing of screen shots, architectural design, and final assessment of requirements stack. The methods used will include but not be restricted to: Identifying function Owners – call takers, schedulers, dispatchers, case workers, transportation coordinators etc. The HBSS SCRUM Team will be Assembled, among them the SCRUM Master, UI/UX expert, subject matter expert (SME) and project manager, and developers. Collection of Useful Documents – Existing documents such as agency policy manuals, existing legacy systems, or publicly available resources such as information on the web, books, magazine articles, or the products and services of 3rd Party systems  (other websites) will be collected.

The program and cost control are built in the methodology as the entire process is very closely scrutinized.

The various artifacts that will be generated during the requirements gathering process will include some or all of these:  a) acceptance test; b) business rule definition, c) change case, d) CRC model, e) constraint definition, f) data flow diagram (DFD), g) essential UI prototype, h) essential use case, i) feature, j) technical requirement, k) usage scenario, l) use case diagram, and m) user story.

Methods Used for Eliciting Requirements  

The various methods that may be used during the requirements gathering process will include some or all of these:  a) Active Stakeholder Participation, b) Electronic Interviews, c) Face-to-Face Interviews, d) Focus Groups, e) Joint Application Design (JAD), f) Legacy Code Analysis, g) Observation, h) On-Site Customer, i) Reading.

Quality Control

Through the project review process, HBSS shall consider the following user groups identified by the client, so that the functional focus is based on these focus groups and all folks are not engaged in all functions – potentially losing their interest: riders, prospective riders, caregivers (family and friends), and counselors; transportation providers; partner owners and system administrators; planners and decision-makers; applications developers

The Agile methodology has quality control built into the process itself. The small size of each task (called Sprint), followed by iterative modeling and model storming and prototype testing, keeps the requirement process on track and any loss of control can be quickly adjusted.

Here are some components of our requirements gathering quality control: All meetings will be for fixed amount of time (30 minutes on average, 1 hour max); Members will come prepared for the meeting; Documents needed for the meetings will be sent before-hand; Meetings will result in issue resolution; Any disagreements will be handled by the SCRUM Master.

Ready to Schedule a Demo?

Chat with QRyde

Subscribe to our Monthly Newsletter