Functional Specification / Requirement Document (FSD / FRD)

Functional Specification / Requirement Document (FSD / FRD) The Functional Specification Document (FSD) in software development is a formal document that describes the functions of the software/system or its component(s). A function can be described as a set of inputs, the behaviour, and intended / exceptional outputs. Functional requirements may be calculations like business logic or revenue model or formulae, technical details, data manipulation & processing and other specific functionality that define what a system is supposed to accomplish. It is an intermediate document between the Business Requirement Document (BRD) and the Technical / Design Document. Functional requirements may also cover Behavioural requirements. Functional requirements are supported by non-functional requirements (a.k.a quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, accessibility, scalability, reliability, etc.). Generally, functional requirements are expressed as “system must do <<requirement>>“, while non-functional requirements are “system shall be <<requirement>>“. The implementation plan for functional requirements is detailed in the system design. The implementation plan for non-functional requirements is detailed in the system architecture. It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect. Note: It is better to get the FSD signed-off with the stakeholders (Client, Architect, Technical Team & QA) in order to keep everyone synced up and to avoid rework in the later stages. What is a System? The black box terminology “System” features “Interfaces” and “States”. Interfaces are through which external entities (human & other sub-systems, generally called users) can interact with the system through inputs and outputs. States are result of interactions with the users based on the functions chosen and the data furnished. Consider the eCommerce site as a system and its login feature as an example of a feature/component of the system. The following are few Use Case Scenarios that needs to be considered while describing the functional flow and behaviour/UI for each scenario in the FSD: 1. User registers during checkout and thus logged in. 2. User registers first and logs-in, and then shops. 3. Already registered user logs-in first before shopping. 4. Already registered user logs-in while checkout. 5. Already registered user cannot login due to incorrect login credentials. 6. Already registered user, reset password through forgot password link and logs-in. 7. Already registered user experiencing account locked during log-in attempt. 8. Account locked user, getting account reset and logs-in. 9. A logged-out user re-logging-in to shop. 10. An affiliate user logs-in and shops. Note: The above being example, various functions like validation for Username and Password are not highlighted here. Though from the above scenarios “Checkout” is a separate component tied up with another component called “Shopping Cart”, the integration scenarios are not explained in this post. Why write FSD? 1. FSD streamlines the development process by incorporating all of the functions and data used respectively. 2. Every engineer working from the FSD has all their questions answered about the system to start building it. 3. Using the stakeholder signed-off FSD ensures the development of system nothing less than what the client is expecting. Producing a comprehensive (Clear, Unambiguous and Understandable) FSD is an arduous task. This may contain multiple sections detailing each of the requirements necessary to deliver the project. Hence writing this needs some domain expertise and is generally written by BAs or SMEs. To achieve the comprehensiveness: Be consistent in style and layout – Use headings and formatting Numbering items and bullet points appropriately – Use abbreviations and define in glossary Use diagrams for visual-oriented readers in addition to the text descriptions. Break up text with screen shots, tables, and other graphical material Develop detailed light-hearted scenarios – use unambiguous terms and keep sentences simple. Define the System – What is the system supposed to be, supposed to do, users, metrics and any precedent for this system. Develop models – User’s conceptual model (UseCases) and Designer’s model (Visio Diagrams). Define Information Flow – Navigational Elements, Organization of Information, Prototype, Wireframes and Mockups Write the Functionality – Cover everything, use screenshots, write concisely, correctly and consistently. Coverage of functionality – For every screen, cover all elements and its functions and data from Top left corner to bottom right corner. Review the document – Check Table of Contents, proof-read the document, and finally review from the hardcopy of the same. What is in the FSD? The conventional format of FSD contains information of Identification Control, Relevant Business Requirement, Functional Behaviour & User Interface Navigation Control, Data & Business Logic and Quality Criteria. Software Requirements Specification (SRS) “Ours is a world where people don’t know what they want and are willing to go through hell to get it.” – Don Marquis A software requirements specification (SRS) is a comprehensive description of the intended purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform. An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost. A good SRS defines how an application will interact with system hardware, other programs and human users in a wide variety of real-world situations. Parameters such as operating speed, response time, availability, portability, maintainability, footprint, security and speed of recovery from adverse events are evaluated. Methods of defining an SRS are described by the IEEE (Institute of Electrical and Electronics Engineers) specification 830-1998. A SRS describes the essential behavior of a software product from a user’s perspective. The purpose of the SRS is to: 1. Establish the basis for agreement between the customers and the suppliers on what the software product is to do. The complete description of the functions to be performed by the software specified in the SRS will assist the potential user to determine if the software specified meets their needs or how the software must be modified to meet their needs 2. Provide a basis for developing the software design. The SRS is the most important document of reference in developing a design 3. Reduce the development effort. The preparation of the SRS forces the various concerned groups in the customer’s organization to thoroughly consider all of the requirements before design work begins. A complete and correct SRS reduces effort wasted on redesign, recoding and retesting. Careful review of the requirements in the SRS can reveal omissions, misunderstandings and inconsistencies early in the development cycle when these problems are easier to correct 4. Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates 5. Provide a baseline for validation and verification. Organizations can develop their test documentation much more productively from a good SRS. As a part of the development contract, the SRS provides a baseline against which compliance can be measured 6. Facilitate transfer. The SRS makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization and suppliers find it easier to transfer it to new customers 7. Serve as a basis for enhancement. Because the SRS discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued product evaluation. Conclusion Business Analyst Vs System Analyst The terms Business Analyst (BA) and System Analyst (SA) are often used interchangeably to describe the same job. Actually the two are completely different roles with distinct descriptions and duties. Let me try to explain the differences between BAs and SAs, and also list a few commonalities shared by these positions. Roles of a Systems Analyst? SAs utilize an organization’s IT systems to help achieve strategic business goals. They may design and develop new systems by configuring new hardware and software, or use existing systems in new ways to accomplish additional or different outcomes. Typical tasks performed by SAs include: Consulting with management and users to determine the needs of the system. Designing a system to meet the business goals. Specifying inputs and formatting outputs to meet users’ needs. Using techniques such as sampling, model building and structured analysis, along with accounting principles, to ensure the solution is efficient, cost-effective and financially feasible. Developing specifications, diagrams and flowcharts for programmers to follow. Overseeing implementation, coordinating tests and observing initiation of the system to validate performance. Skill Sets for a Systems Analyst Generally a bachelor’s degree when hiring SAs, typically in a technical field such as computer

Load more