The BriteCore community is deeply committed to the march of progress. We’ve all worked together to deliver steady improvements to our product and our process year after year. As part of this tradition, we’ve recently deployed Software Requirement Specifications (SRS) to enhance our process and our product in a powerful, new way.
At any one point in time, there are hundreds of change requests for BriteCore across all clients. However, a quick glance at the forum illustrates that most change requests are controversial. A required feature for one company frequently spells disaster for another. Priorities vary greatly based on operational procedures and require deep thought and reflection.
We want to provide the best software possible to small insurance carriers. To do so, we must carefully consider the following for every proposed modification to the system: operational impact, regulation, employee acceptance and training, agent acceptance and training, audit compliance, workflow migration, organizational politics, development processes, testing frameworks, hosting and deployment environment, technical feasibility, available capacity, funding, opportunity cost, and contractual obligations. Disciplined reflection and investigation are key to delivering a quality user experience, so we’ve deployed a new process and subsequent document to promote thorough investigation prior to change deployment.
The implementation of SRS has been a pleasant surprise for us. After working through a couple projects, the process really works and fine tunes the feature prior to it ever being released. – Scott Krum, CEO, McMillan-Warner Mutual, Marshfield, WI.
A Software Requirement Specification is a document that describes change requests in detail and promotes understanding and accountability for all parties. It’s composed of several sections as detailed below:
- Business Requirements – Break down each requirement individually. Consider what desirable outcome you’re trying to enable or what undesirable outcome you’re trying to prevent.
- IWS Success Conditions – Describe how IWS measures success.
- Client Success Conditions – Explain specifically how the end-user tests the proposed changes. When possible, include the scale, sample, and range to be measured.
- Scope – Explain how the software described herein addresses the business requirements.
- Definitions, Acronyms, and Abbreviations – Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS.
- Perspective – Describe the context and origin of the feature specified in this SRS.
- Functionality by User Class – Describe the primary functions the feature must perform or must let the user perform. Optionally include any Data Flow Diagrams. When possible, user classes are identical to BriteCore roles. If a new user class must be created for this SRS, indicate that here.
- Assumptions and Dependencies – Describe the assumptions and dependencies that can affect the requirements specified in this SRS. This includes environmental variables within BriteCore and its operating environment.
- Risks and Limitations – Describe the constraints that can affect the requirements specified in this SRS. This includes any safety and security considerations or potential negative side-effects of particular design decisions.
- CRUD(E) and Data Analysis - List all entities that will need to be created, read, edited, or deleted, along with any explicit error-handling to be created. Also include any data conversion instructions.
- Behavior Requirements – Describes specific behavior in a sequence through Use Case documents.
- Testing Scenarios – List any quality characteristics and testing instructions that are important to either customers or developers.
- Performance Testing / Benchmarking – Describe any explicit or implicit performance requirements from a systems or usability standpoint.
- Third Parties – Optionally describe the necessary, secondary, or third party application (vendors) or communication interfaces. Otherwise, link to reference(s) where this information is stored.
Careful thought and consideration is required to generate this document. The entire process provides many opportunities for reflection and modification. We’ve begun to require complete SRS documentation for every significant change request prior to development. This has generated high acceptance and lowered error rates for new features. We’re excited for all of you to experience this process firsthand and trust you’ll continue to experience an upward trend in quality as a result.