Software Requirements Specifications Best Practices

Most customers specify a product at a high conceptual level, focusing on the external look and feel, systems behavior: what it will do and how end-users will work with it. While, developers think of the product in terms of its internal characteristics. That’s why a Business Analyst steps in to translate a customer’s needs into requirements, and defines the requirements into tasks for developers.

Poorly specified requirements can lead to some functionality not being included in the application. Every assumption should be clearly communicated rather than just implied. Good requirements should define all of the software requirements.

Think about it, of the projects started in your organization over the past 12 months that were either marked failures or ended, what were the key causes of those failures?

• Change in the organization’s priorities
• Change in project objectives
• Inaccurate requirements gathering
• Inadequate vision of project goal
• Inadequate/poor communication
• Opportunities and risks not defined
• Inaccurate cost and project time estimates
• Poor change management
• Inadequate sponsor support
• Organization silos

Software specifications requirements are also comprised of user stories or use cases. User stories describe the system itself and use cases describe how a user interacts with the system.

A way to enhance your software requirements specifications is through visuals like diagrams, wireframes and models. This contributes to a better understanding of the processes. Visuals are irreplaceable when it comes to highlighting the main functions and their interoperability.

Avoid ambiguity. The SRS should be clear and not cause endless discussions or second thoughts. Remember, it’s not the developer’s task to fill in the blanks. Ambiguous language means fuzzy words like synonyms and subject adverbs (i.e., reasonably, generally, approximately). Terms combined with a slash (i.e, delivery/fulfillment team) can also cause confusion. A formal peer review is a good way to avoid ambiguities.

Be customer-oriented. After you’ve defined your end user, use this information to outline the operations and end-user is going to perform with the software. Take into account every little nuance. Then add it to you SRSs. Remember, developers can’t read your mind. It’s not a developer’s job to take into account every possible scenario that can happen with the software – it’s a Business Analysts (BA) task and it should be documented in the SRS.

Keep SRS flexible. Requirements must be flexible. BAs watch how the system works, get the feedback, access the outcome and if it’s not satisfactory – modify the requirement.