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 science, information technology,
engineering or information systems. However, preferred are the one that possesses business background combined with computer
skills. Others seek industry-related experience, such as finance, telecommunications or healthcare, along with technical skills.
 In general, the SA job requires more in-depth technical knowledge, while the BA position requires a better understanding of the
complexities of business problems and using technology to solve them.

Roles of a Business Analyst?

BAs generally possess technical knowledge as well. Their main focus is to identify opportunities for improving a business’s
processes and using technology to eliminate problems that affect productivity, output, distribution and ultimately, the bottom line. So,
knowing how technology can solve business problems is vital to a BA’s success. BAs require a high degree of specialized skills in
order to solve business problems through a variety of duties that includes:

 Analyzing the business processes in an organization for inefficiencies.

 Making recommendations for solutions or improvements that can be accomplished through new technology or alternative uses of
existing technology.
 Acting as liaison between business stakeholders, such as management, customers or end users, and the software development
or information technology team.
 Analyzing and communicating stakeholder needs by translating business requirements into software functional requirements.
 Documenting and evaluating required data and information.
 Using modeling, testing and data models to improve the flow of information through an organization to enhance project success.
Skill Sets for a Business Analyst

Becoming a successful BA requires a blend of technical skill and business acumen, along with a high degree of confidence – usually
acquired as a result of proper education, business analysis training and experience. Many professional BAs break into the field by
earning a degree in information technology, business administration, finance or a related area, or by work experience, and then
pursuing specialized training. Industry certifications are becoming more valuable, as employers increasingly demand these
respected credentials.

Attributes of Both Business Analysts and Systems Analysts

Strong problem-solving and analytical skills, communication and interpersonal skills, and the ability to focus with close attention to
detail are required for both the BA and SA. A BA needs a broad knowledgebase of business and sharply honed essential skills,
while the SA’s skill set is more technical.

Systems Analyst ≠ Business Analyst

While there are some common skills and knowledge requirements between SAs and BAs, the BA profession requires an entirely
different set of core specialty skills involving eliciting, analyzing, communicating, testing and verifying requirements, plus the ability
to identify opportunities to solve business problems and improve processes. BAs are functional experts who work for change and
improvement, helping organizations reach their strategic goals through continual, successful technological improvements.