BriteIdeas - Completing an SRS

From BriteWiki
Jump to: navigation, search

IWS now requires complete SRS documentation for every significant change request prior to development. This has generated high acceptance and lowered error rates for new features. The purpose of the SRS is to make sure we're all on the same page prior to development. When you're ready to outline the Software Requirement Specifications for your change request with IWS, your personal Account Executive will help walk you through the process.

Why is the completion of an SRS required?

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.

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.

What exactly is an SRS?

A Software Requirement Specification is a document that describes change requests in detail and promotes understanding and accountability for all parties. It’s completed by originators of change requests and composed of several sections as detailed below:

  • Business Requirements – Breaks down each requirement individually. Considers what desirable outcome you’re trying to enable or what undesirable outcome you’re trying to prevent.
  • IWS Success Conditions – Describes how IWS measures success.
  • Client Success Conditions – Explains specifically how the end-user tests the proposed changes. When possible, includes the scale, sample, and range to be measured.
  • Scope – Explains how the software described herein addresses the business requirements.
  • Definitions, Acronyms, and Abbreviations – Provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS.
  • Perspective – Describes the context and origin of the feature specified in this SRS.
  • Functionality by User Class – Describes the primary functions the feature must perform or must let the user perform. Optionally includes any Data Flow Diagrams. When possible, user classes are identical to BriteCore roles. If a new user class must be created for this SRS, it's indicated here.
  • Assumptions and Dependencies – Describes 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 – Describes 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 - Lists all entities that will need to be created, read, edited, or deleted, along with any explicit error-handling to be created. Also includes any data conversion instructions.
  • Behavior Requirements – Describes specific behavior in a sequence through Use Case documents.
  • Testing Scenarios – Lists any quality characteristics and testing instructions that are important to either customers or developers.
  • Performance Testing / Benchmarking – Describes any explicit or implicit performance requirements from a systems or usability standpoint.
  • Third Parties – Optionally describes the necessary, secondary, or third party application (vendors) or communication interfaces. Otherwise, links to reference(s) where this information is stored.

When do I complete an SRS?

Careful thought and consideration is required to generate an SRS document. The entire process provides many opportunities for reflection and modification. IWS asks change request originators to complete an SRS document once an item is fully funded or supported by the community. That way all questions are answered and all requirements are clearly defined prior to development. IWS will not begin work on a major change request until an SRS document is completed. The process for completing an SRS for funded development is outlined below.

How do I initiate Funded development?

  • Step 1: Make a forum post with your idea to get input from other clients and build consensus.
  • Step 2a: If it looks like at least one other client might support your idea, put it in the Community list of BriteIdeas.
  • Step 2b: If it looks like your request is unique to your company at this time, put it in the Funded list of BriteIdeas.
  • Step 3: A Product Analyst will review the Funded list regularly, and will contact the CEO at your company to discuss your change request within 1 week of your posting it.

IWS staff will be reviewing the top items of the Community list on a recurring basis and will engage with interested parties via the forum and emails for SRS development to make sure all needs are met during the implementation of the change request.

If you have any questions about the SRS process or BriteCore please contact the Account Executives, at

Go to Working with BriteIdeas