Many times, business partners email their software requirements to the development team, thinking their job is...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
done until testing. Developers take these requirements and begin coding almost immediately, not realizing that they have misread the requirements and are developing code that is totally off track from what business wants. Who is to blame when the final product is not accepted by the business partner? What can business partners and developers do to ensure this doesn’t happen to their release?
Here are five simple ideas to help business partners and developers work together to ensure a release that is not only acceptable, but exceeds everyone’s expectations.
1. Hold a preliminary meeting.
Before any documentation or requirements gathering is started, the developer and business partner need to meet to talk about the project, at a conceptual level. For example, developers can share templates with the business partner and the business partner can share other graphical user interfaces (GUI) and websites so development can get the big picture for what business has in mind for the final product. Roles and responsibilities can be discussed. This preliminary meeting establishes a positive approach to business and development working together as partners throughout all phases of the upcoming release.
2. Negotiate preliminary wish list and create Business Requirements Document (BRD).
After the preliminary meeting, the business partner goes off and creates a wish list (i.e., early business requirements). Each wish is discussed with development to ensure that the business partner and developer are on the same page with what is being requested. The wish list is then negotiated, based on development resources, time, and scope. Not all wishes will make it into an upcoming release and some may never make it to a release at all. From this negotiation, the business partner creates a Business Requirements Document (BRD), which has the final, agreed-upon business requirements for this release. Both the business partner and developer sign the BRD, an important step to ensuring everyone agrees with what will be part of the release.
3. Complete Functional and Technical Specifications documents, along with roadmap.
Development can now use the Business Requirements Document to write both the Functional Specification and the Technical Specification. A Functional Specification looks at the product from a user’s perspective, such as features, screen samples, data input fields, etc. The Technical Specification is the developer’s view and includes data structures, tools, algorithms and relational database models. Both of these documents are critical to ensure that all the agreed-upon business requirements are included in the release. A third document needed is the roadmap, which includes the major deliverables and when they are due. These three documents are best utilized when signed by the business partner and developer to show acceptance by both. However, if the Technical Specification is not understood by the business partner, a high overview of this document by the developer is probably sufficient rather than an approval signature by business.
This step takes time, but once everything is agreed to upfront, developers can move very quickly and can be confident that they are meeting the business partner’s stated requirements.
4. Communicate, communicate, communicate.
Business partners and developers need to meet regularly during the development phase to discuss the status of the release. How often these meetings are held is based on the roadmap, deliverables and unforeseen obstacles or challenges that may arise. These meetings will help ensure development is designing what has been agreed to in the Business Requirements Document, Functional Specifications and Technical Specifications. Should development accidentally include a non-approved feature or should the GUI not work for the business partner, rework will be minimized when caught early in the development phase.
5. Involve everyone in testing.
Both developers and business partners need to jump in with both feet during testing. Since there is solid documentation on what is to be included in this release and there have been regular meetings to review the milestones and deliverables, testing will hold minimal surprises. The GUI will work extremely well as the team has already worked through any ambiguities during the regularly held milestone meetings. The features will meet business needs, as they follow the Functional Specification and were agreed to at the very beginning of the development phase. All requirements from the Business Requirements Document have been accounted for and work as expected. There are no major bugs, as they were caught during the milestone meetings.
Business will now eagerly accept and sign off on the release!
These five steps may sound simple and obvious, but there is nothing simple about keeping the business partner and developers on the same page throughout a long development cycle. Documenting items such as the Business Requirements Document, and the Functional and Technical Specifications can help ensure good communication, along with holding regular meetings to review status and coding. When business and development follow these five simple steps, the final outcome is sure to exceed expectations on both sides, plus build a stronger relationship for future releases: a win-win for everyone.