Ashwini Kumar Rath 
The art of software development has witnessed a significant evolution over the years. With the introduction of Rapid Application Development (RAD), the focus has shifted towards lean, flexible, and quick development processes. One crucial aspect that is often challenging in such fast-paced environments is specification (Specs) management. In this blog, we will explore an efficient and innovative approach to specs management when working with RAD, complete with examples.
The Dawn of Specs Management in Software Development
During the early days of software development, the Waterfall model was prevalent. Specs management in this era was highly document-oriented and rigid. Every detail about the software application, such as system architecture, user interfaces, data models, and functional requirements, was meticulously documented. These documents were treated as contracts, and any deviation was not acceptable. This approach, while thorough, lacked flexibility and often led to increased development time and cost overrun.
The Advent of Agile and Changing Specs Management
As the software industry evolved, Agile methodologies came into play. Agile brought in a paradigm shift in specs management. Documentation was no longer a primary focus. Instead, Agile principles emphasized working software and customer collaboration. User stories and product backlogs replaced detailed requirement documents. This change provided much-needed flexibility to software development but also brought new challenges in maintaining the alignment between the development team and the stakeholders due to the need for comprehensive documentation.
The Rise of RAD and Its Impact on Specs Management
Rapid Application Development (RAD) emerged in response to the need for faster, more efficient, and customer-centric software development. RAD principles focus on iterative development, reusability, and early feedback. In the RAD model, an application is divided into several microservices, each encapsulating one or more Microservice Objects. The specs are managed through a 'Sprint Board', which includes all the necessary details about the project and the features to be developed.
The Feature Table, a crucial component of the Sprint Board, lists all the features, their details, timelines, team members responsible for them, and their compliance level. The project is considered complete when all features reach Full Compliance. This approach aligns perfectly with the RAD principles of quick development cycles and early customer feedback, as each feature can be developed, tested, and improved independently. With RAD, specs management has become more dynamic and efficient. The focus has shifted from extensive documentation to lean and actionable requirements specification. The Sprint Board and Feature Table have become the central hub for managing the project, providing a perfect blend of structure and flexibility.
This approach ensures that the project remains aligned with the business requirements and allows for quick adjustments as needed. It also provides detailed project documentation at the end, proving invaluable for future reference and improvements.
As we look forward, RAD is set to play an even more significant role in shaping the future of specs management, making it more responsive, efficient, and in tune with the rapid pace of the software industry.
Demystifying RAD: Microservices and Microservice Objects
Before delving into the nitty-gritty of specs management, let's understand the fundamental building blocks of RAD - microservices and microservice objects.
A RAD project divides an application into several microservices, which are independent modules that work together to create a comprehensive application. Each microservice comprises one or more 'Microservice Objects', categorized into:
-
Data Objects: These include a database table with fields and records for data storage and a set of class methods to operate on the data during user interaction.
-
Integration Objects: These contain code to call an external API or webhook, integrating third-party software services with the application.
-
Generic Objects: These are custom-coded for specialized functions.
The Sprint Board: Your Project Management Hub
The 'Sprint Board', equivalent to the specifications document, is the central hub for managing the project. It includes:
-
Project Name & Code - Code is something that people refer to the project within the team
-
Project Summary
-
Team Members List (Batoi RAD Platform will anyway handle when you add users to your project’s team)
-
Start Date & Target Date
-
Sandbox URL - the server location where an application and the microservice get deployed for testing and quality assurance.
-
Application Type (web app or mobile app, or a service portal with both public and private pages)
-
Feature Table - a list of features
-
Access Control List (ACL) - details of user roles and privileges presented in a tabular form
The Feature Table: Heart of Specs Management
A key component of specs management in RAD is the Feature Table. This table includes all the features that will be part of the application. Here is a sample layout:
| Sl No | Feature Category | Sub-Category | Feature Details | Date Added | Timeline | Team Member | Compliance Level | Remarks |
|---|---|---|---|---|---|---|---|---|
| 1 | Application | NA | Navigation Menus | 05/15/2023 | 05/22/2023 | John Doe | F | Completed successfully |
| 2 | Microservice | User Management | Password Reset | 05/16/2023 | 05/18/2023 | Jane Smith | P | Under testing |
| 3 | Object | Data Object | User Database Table Menus | 05/16/2023 | 05/20/2023 | John Doe | N | Yet to start |
To avoid redundant writing, we may restrict the content of ‘Feature Details’ to 140 characters.
The compliance level is divided into three categories: Full (F), Partial (P), and None (N). The project is considered complete when all features reach Full Compliance.
‘Remarks’ pertain to the note by the Product Owner or a team member in charge of reviewing and approving the feature.
The other important thing is that we should be able to mark a feature (a record on the Feature Table) as a Key Performance Indicator (KPI). This will offer greater relevance in specs documentation for coordinating with the project stakeholders for a high-level review and easier sign-off.
What’s Next?
Gradually, a Sprint Board becomes a hub for managing the project where you add a timeline for each feature, and team members responsible for implementing a feature get added to the feature via the feature category. The testing of the application is done on the Sandbox URL. The application is deployed to one or more server locations if user testing is satisfactory with all features marked with Compliance Level, F.
Finally, the Sprint Board will lead to complete documentation of the project with project information, features and compliance, application navigation and routes, ACL, microservices and objects (class, database tables, workflow states, and transitions), theme and UI, API Gateway (single end-point URL) and access methods, and sandbox and product deployment details (without hyper-sensitive data like passwords, etc.).
In Summary
Specs management in RAD can be a breeze with the right tools and methodologies. The Sprint Board and Feature Table serve as the go-to resources for project management. With features organized and tracked effectively, RAD truly shines in delivering quick, efficient, and successful software development projects. The final Sprint Board serves as a detailed document of the project, making it an invaluable resource for future reference and improvements.
