How do you know the magnitude of a project? How to derive project estimates? How do you know what to build? Or in testing terms, what should be the expected behavior of a software that you are testing? High-level requirements, Software Requirements Specification (SRS), Functional Specification Document (FSD), User Stories or Use cases – whatever you call it in your project – is essentially a requirements documents which forms the basis for software development & testing. It is the first step in every project kick-off. As the name suggests, it falls in the ‘Requirement Gathering & Analysis’ phase of STLC.
In simple English – the requisite (or condition) of Client with respect to expected software. Requirements are the statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what will be or has been implemented. Without ‘understanding’ the requirements the project is deemed to fail.
How do you go about shopping? Yeah! Everyone has a ‘requirement’ – I want some trendy clothes within 10K budget OR want an elegant sofa set – teak wood – brown color – within 50K. Anything you buy, first you need to make up your mind with respect to ‘what do you need’ – it is nothing but ‘Requirements’. Same concept applies to Software engineering as well. Before anything can be built & tested, first we need to understand the ‘requirements’. Requirements convey the expectations of users from the software product!
Software Requirements Specification
A Software requirements specification (SRS) or Functional Specification Document (FSD) is a description of features and functionalities of a software system to be developed. It lays out functional and non-functional requirements – instructions describing what functions the software is supposed to provide, what characteristics the software is supposed to have, and what goals the software is supposed to meet or to enable users to meet.
- User Requirements are expressed in natural language.
- Technical requirements are expressed in structured language, which is used inside the organization.
- Design description should be written in Pseudo code.
- Format of Forms and GUI screen prints.
Software requirements specification defines various functional & non-functional aspects of the software to-be-developed, like user interactions, hardware requirements, performance & security, accessibility, usability, required functionalities, etc. To derive the requirements a Business Analyst need to have clear and thorough understanding of the product to be developed. This is achieved and refined with detailed and continuous communications with the project team and customer till the completion of the software.
- Establishes the basis for an agreement between customers and contractors on what the software product is to do as well as what it is not expected to do.
- Provides a realistic basis for estimating product costs, risks, and schedules.
- Foundation to Software development and subsequent testing
- Platform for ongoing feedback and refinement via open questions & issues
- Tool for evaluating the quality of a project, because a final review should examine whether each requirement has been met.
A complete Software Requirements Specification must be – Clear, Correct, Consistent, Coherent, Comprehensible, Modifiable, Verifiable, Prioritized, Unambiguous, Traceable, Credible source
Requirements are categorized logically as,
- Must-Have: Software cannot be said operational without these (Baseline)
- Should-have: Enhancing the functionality of software (Competitive)
- Could-have: Software can still properly function without these requirements, but these are good-to-have
- Would-have (Wish list): These requirements do not map to any objectives of software
Software requirements specification is different from the Technical specification in that it describes how a product will work entirely from the user’s (or customer’s) perspective instead of how it is to be implemented. Specifications may take several forms. They can be a straightforward listing of functional attributes, they can be diagrams or schematics of functional relationships or flow logic, or they can occupy some middle ground.
Use Case is one of the methodology to define system requirements / behavior. A use case defines a goal-oriented set of interactions (list of actions or event steps) between external actors and the system under consideration, i.e. how a user uses a system to accomplish a particular goal. Actors are parties outside the system that interact with the system. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal.
User Story is a tool used in Agile Software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
- Format: As a <role or user type>, I want <feature or goal> so that <some reason>
- Example – As an administrator, I want to approve comments before they are posted so that I can make sure they are appropriate.
The user stories should be written by the business in the language of the customer so that it is clear to both the business and the product team what the customer wants and why. Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product. Product backlog can be thought of as a replacement for the requirements document of a traditional project. And User stories have emerged as the best and most popular form of product backlog items.
*** IEEE defines software requirements specification as, ‘a document that clearly and precisely describes each of the essential requirements (functions, performance, design constraints and quality attributes) of the software and the external interfaces. Each requirement is defined in such a way that its achievement can be objectively verified by a prescribed method, for example, inspection, demonstration, analysis or test.’