Functional requirement

In software engineering, a functional requirement defines a system or its component. It

describes the functions a software must perform. A function is nothing but inputs, its behavior,
and outputs. It can be a calculation, data manipulation, business process, user interaction, or
any other specific functionality which defines what function a system is likely to perform.

Functional requirements in software engineering help you to capture the intended behavior of
the system. This behavior may be expressed as functions, services or tasks or which system is
required to perform.

Example of Functional Requirements

 The software automatically validates customers against the ABC Contact Management
System
 The Sales system should allow users to record customers sales
 The background color for all windows in the application will be blue and have a
hexadecimal RGB color value of 0x0000FF.
 Only Managerial level employees have the right to view revenue data.
 The software system should be integrated with banking API
 The software system should pass Section 508 accessibility requirement.

Advantages of Functional Requirement

Here, are the pros/advantages of creating a typical functional requirement document-

 Helps you to check whether the application is providing all the functionalities that were
mentioned in the functional requirement of that application
 A functional requirement document helps you to define the functionality of a system or
one of its subsystems.
 Functional requirements along with requirement analysis help identify missing
requirements. They help clearly define the expected system service and behavior.
 Errors caught in the Functional requirement gathering stage are the cheapest to fix.
 Support user goals, tasks, or activities for easy project management
 Functional requirement can be expressed in Use Case form or user story as they exhibit
externally visible functional behavior.
 Non-functional requirement

 A non-functional requirement defines the quality attribute of a software system. They

represent a set of standards used to judge the specific operation of a system. Example,
how fast does the website load?
 A non-functional requirement is essential to ensure the usability and effectiveness of
the entire software system. Failing to meet non-functional requirements can result in
systems that fail to satisfy user needs.
 Non-functional Requirements allows you to impose constraints or restrictions on the
design of the system across the various agile backlogs. Example, the site should load in 3
seconds when the number of simultaneous users are > 10000. Description of non-
functional requirements is just as critical as a functional requirement.

Examples of Non-functional requirements

Here, are some examples of non-functional requirement:

1. Users must change the initially assigned login password immediately after the first
successful login. Moreover, the initial should never be reused.
2. Employees never allowed to update their salary information. Such attempt should be
reported to the security administrator.
3. Every unsuccessful attempt by a user to access an item of data shall be recorded on an
audit trail.
4. A website should be capable enough to handle 20 million users with affecting its
performance
5. The software should be portable. So moving from one OS to other OS does not create
any problem.
6. Privacy of information, the export of restricted technologies, intellectual property rights,
etc. should be audited.

Advantages of Non-Functional Requirement

Benefits/pros of Non-functional testing are:

 The nonfunctional requirements ensure the software system follow legal and
compliance rules.
 They ensure the reliability, availability, and performance of the software system
 They ensure good user experience and ease of operating the software.
 They help in formulating security policy of the software system.
 Difference between functional and non functional requirements

Functional Requirements Non Functional Requirements

A functional requirement
defines a system or its A non-functional requirement defines the
component. quality attribute of a software system.

It places constraints on “How should the

It specifies “What should the software system fulfill the functional
software system do?” requirements?”

Non-functional requirement is specified by

Functional requirement is technical peoples e.g. Architect, Technical
specified by User. leaders and software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the Helps you to verify the performance of the
functionality of the software. software.

Functional Testing like System, Non-Functional Testing like Performance,

Integration, End to End, API Stress, Usability, Security testing, etc are
testing, etc are done. done.

Usually easy to define. Usually more difficult to define.

 Gathering and Analysis:-

1) Requirement Gathering
To make sure that all the steps mentioned above are appropriately executed, clear, concise,
and correct requirements must be gathered from the customer. The customer should be able
to define their requirements properly and the business analyst should be able to collect them in
the same way the customer is intending it to convey them.

Many a time it is not possible that requirement gathering is done efficiently by business
analysts from the customer. This might be due to dependency on many people related to the
expected end product, tools, environment, etc. Thus, it is always a good idea to involve all the
stakeholders who could influence or could be influenced by the end product.

The possible stakeholder’s group could be Software Quality engineers (both QC and QA), any
third party vendor who could provide support in the project, end-user for whom the product is
intended, software programmers, and another team within the organization who might provide
a module or software platform, software libraries, etc. for product development.
2) Analyzing Gathered Requirements
Post requirement gathering, analysis of requirement starts. At this stage, various stakeholders
sit and do a brainstorming session. They analyze the requirements gathered and look for the
feasibility to implement them. They discuss it with each other and any ambiguity is sorted out.

This step is important in the requirement analysis process due to the following main reasons:
(i) Customer may provide some requirements which could be impossible to implement due to
various dependencies.
Example: Customers may ask to surround-view the camera system with a rearview camera
feature that will help in parking the car. The customer may also ask for the Trailer hitch feature
which also uses the rear camera to work.
If the customer states a requirement that the rearview camera for parking assistance should
work at all times without an exception, then the Trailer feature would never work and vice
versa.

BI project life cycle

Every BI project has its own life cycle. Let us look at a common life cycle:
The first step is Analyze Business requirements, which means that we should gather the
business requirements and transform them into functional and non-functional specifications,
create a template for reports, and so on.

The next step is Design the logical data model, where we build a logical data model based on
business requirements, which shows the business entities and the relationships between them.

The third step is Design the physical data model, where we transform the logical data model
into a physical data model which defines the structure of the data warehouse.

The fourth step is Build the data warehouse. In this step, we create the data warehouse, build
data marts, and load data.

On the fifth step, Create the Project, we start to work directly in MicroStrategy, where we
define schema, attributes, facts, hierarchies and so on. All this information is stored in
metadata, the core of MicroStrategy, in a relation database.

The sixth step is Develop Reports/Documents and of course dashboards. In addition, we share
our insights across the organization using various channels such as email, FTP, and so on.

Business intelligence project deployment process

Utilizing the DW/BI system is the final step before business users gain access to the
information. The first impression the business community gets is when introduced to
the BI frontend drives.
Because acceptance from users is important, the deployment must be thoughtfully planned to
ensure that the DW/BI system can perform and deliver the results it is designed to deliver. To
ensure that the implementation can perform and deliver it has to be exposed to extensive end-
to-end testing.
The process of testing is an ongoing activity along the development process, because defects
that should be correct later in the lifecycle are difficult to find and are associated with
exponentially increasing costs.
A way of securing that the testing is done through the development lifecycle is to follow a
methodology. Kimball prescribe that before adding the DW/BI system, it should have passed a
mock test that will cover the following procedures;

 Testing procedures
 Data quality
 Operations process testing
  Performance testing
 Deployment testing
 User desktop readiness.
 Documentation and Training
 Maintenance and Support

What is BI Testing?
Business Intelligence (BI) is the process of gathering, cleansing, analyzing, integrating and
sharing data to derive actional insights that drive business growth. Business Intelligence Testing
or BI testing verifies the staging data, ETL process, BI reports and ensures the implementation is
correct. BI Testing ensures data credibility and accuracy of insights derives from the BI process.
Sample Test Cases for BI
Following are generic test cases that need to be validated for any BI Testing Project

Test Scenarios Test Cases

ETL  Verify data is mapped correctly from source to target system

verification

  Verify all tables and their fields are copied from source to target

 Verify keys configured to be auto-generated are created properly


in target system

  Verify that null fields are not populated

  Verify data is neither garbled nor truncated

  Verify data type and format in target system is as expected

  Verify there is no duplicity of data in the target system

  Verify transformations are applied correctly

  Verify that the precision of data in numeric fields is accurate

   Verify exception handling is robust

 Reconciliation check- record count between the STG (staging)

Staging data tables and target tables are same after applying filter rules

 Insert a record which is not loaded into target table for given key

combination

 Copy records, sending same records that are already loaded into

target tables-should not be loaded

 Update a record for a key when value columns changed on


day_02 loads

  Delete the records logically in the target tables

  Values loaded by process tables

  Values loaded by reference tables

Data Loading  Check if the target and source data base are connected well and
there are no access issues.
in BI

 For a full load, check the truncate option and ensure its working

fine.

  While loading the data, check for the performance of the session

  Check for non-fatal errors.

  Verify you can fail the calling parent task if the child task fails.

  Verify that the logs are updated

  Verify mapping and workflow parameters are configured

accurately

 Verify the number of tables in source and target systems is the


same

 Compare the attributes from stage tables to that of the target


tables. They should be matched.

 Display date and time

BI Reports

  Decimal precision for key figures

  In a given page display the number of rows and columns

  Free characteristics in the report

 How are blank values/data displayed for both characteristics and


key figures in the report

 Whether search for characteristics is based on key or key&text as


applicable

 Does search option on text is case sensitive- Upper, Lower or


both

Post-production support:

First, subject matter experts (SMEs) will need to provide ongoing support, and need to be
prepared to provide service to many people in their departments, as people will no doubt
encounter difficulties. Second, the support process is divided into tiers.

Tier 1: Is considered triage and is usually the Help Desk or Call Center. This group will attempt to
address very straightforward problems or questions, often related to password problems or
resets or general access issues.
Tier 2: The Help Desk will forward the question or problem to tier 2. Tier 2 support is where the
subject matter experts are used.

Tier 3: Tier 3 can be a combination of technical staff along with vendor or implementation
partner support. These are often complex problems that will require the technical support staff
to research and fix.

There are others ways of providing support to users, in addition to in-person support.

The user could access web based frequently asked questions (FAQs), job aids that are printable
that describe how to access and complete a function within the system, short videos on using
the system and complete training documentation that shows and describes step by step how to
use the system.