Business Analysis Session 9.

Understanding Requirements

RAM N SANGWAN

WWW.RNSANGWAN.COM

YOUTUBE CHANNEL : HTTP://YOUTUBE.COM/USER/THESKILLPEDIA

TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM

1

Agenda

• Define the term requirement

• Understand requirement types

• Present the requirements process

• Requirements vs. specifications and business rules

2

Define the term requirement

A requirement is:

1. A condition or capability needed by a stakeholder to solve a problem orachieve an objective.

2. A condition or capability that must be met or possessed by a solution orsolution component to satisfy a contract, standard, specification, or otherformally imposed documents.

3. A documented representation of a condition or capability as in (1) or (2).”

Goals of doing requirements:

1. understand precisely what is required software2. communicate this understanding precisely to all developmentparties

3. control production to ensure that system meets specs (includingchanges)

3

Requirements Documentation

• In the real world requirements may be clearly understood or they may be

implied or derived from other requirements.

• But, ultimately, when eliciting requirements for a project, a requirement is not

truly a requirement until it is documented.

• A requirement may be documented as a requirement statement such as

“The system shall…”, “The process shall…”, “The Financial Analyst shall…”, or

it can be documented through any number of representative techniques

including models and diagrams.

4

Understand requirement types

Requirements are typically

classified into a number of

categories for easier organization

and maintenance:

• Business Requirements

• Stakeholder Requirements

• Solution Requirements

• Functional Requirements

• Non-Functional Requirements

• Transition Requirements

5

Understand requirement types

• Requirements fall into different, layered categories.

• Solution requirements include functional and nonfunctional requirements

created either by hand or with technology (which has its own technical

requirements).

• And when complete, the solutions are put into place by way of transition

requirements.

6

Present the requirements process

A business requirement is a formal document that addresses the need of the

stakeholders for the project or product. There is no standard format to present

the business requirement. A business requirement can be presented in any of

the following ways

• A table or a spreadsheet

• A diagram (workflow)

• A graph

• A model ( entity-relationship diagram)

• A prototype or simulation

• A structured sentence or text template

7

Organize and present a requirements

Step 1) Categorize the requirements

• Place specific requirement to its relevant categories

• For technical stakeholders there should be technical requirement

category, for non-technical stakeholders there should be generic

requirement category

• Each organization should figure out which category suits their

standards

• Categorization can also be done based on their types (functional

versus business). Though this is not applicable to all cases

Step 2) Gather and arrange requirements in a logical order. So when

stakeholders review the requirements, it is easy to navigate and also

identify missing items.

8

Organize and present a requirements

Step 3) Prepare a list of the requirements that is meant to be reviewed

by specific stakeholders.

• For example, if a stakeholder is from technical background then he

would like to know only the technical aspect of the product

Step 4) If tracing requirement to each other is difficult then use unique

identifiers, ease in traceability.

Step 5) In certain scenarios, you might have to present same

requirement in different ways for different stakeholders. For example,

one stakeholder prefers a graphical format while other prefers a

structured sentence format

Step 6) Prepare a table of content for all the requirements, it helps

stakeholder to easily track requirements

9

Organize and present a requirements

Step 7) Use tools that help in presenting and categorizing the

requirements

Step 8) In your requirement document, remove all unnecessary

requirements, and organize requirement documents by process flow

Step 9) Map the requirements you have gathered to a particular step

in a process flow, this will help reviewers to relate requirement to

process flow

Step 10) Use a table for presenting complex requirement. Use bullet

points to highlight the key aspect of requirement

10

Business Rules

• A business rule relates to the way an organization or company

operates.

• In addition to applying to individuals, business rules might apply to

general corporate behavior or business processes.

• They might also apply to specific elements of an organization, such

as data management. The overall objective is to ensure an

organization is meeting its goals.

• The best business rules are clearly defined and written down.

• There should also be accountability to understand who has

ownership of the business rules, whether it is a company's president,

the board of directors or another individual or body.

11

Business Rules

• Business rules are generally a set of statements or conditions that help guide

actions and activities by a business and potentially their stakeholders, such

as staff, managers, suppliers, customers and others.

• Conditions and other criteria help inform decisions. Business rules provide

guidance related to what specific actions or activities that can beundertaken.

• They help inform the development of policies and processes, including

defining requirements for services, projects and other initiatives.

• Since they are typically foundational, business rules are usually long-term

and fairly static. Any changes to a rule will result in new or amended

business requirements.

12

Business Requirements

• A business requirement outlines what needs to be done to meet a business

need or objective.

• They state what the end result or future state.

• Business requirements are typically developed for a specific business activity

or project.

• They are usually developed when looking for solutions to address a business

need or implement a business goal or objective.

• They are often clear and concise, and are defined in a business case, a

statement of work, a cost-benefit analysis or a similar foundational

document for a specific project or activity.

13

Business Requirements

• Since they are informed by business rules, business requirements should be

consistent with the latest set of rules.

• Different sets of business requirements may be needed for different rules.

• Generally relates to what must be done in order to enable or achieve a business

rule.

• Business requirements also relate to achieving business needs or objectives,

which might not relate to a business rule but are influenced by these rules.

• To add detail to business requirements, functional requirements must be

developed to clearly outline how a business requirement will be addressed or

achieved.

• Functional requirements provide specific steps to develop and implement abusiness requirement.

14

Business Rules V/s Business Requirements

• While a business rule can exist without business requirements, business

requirements exist within the context of a company's business rules,

objectives, goals, mandate or vision.

• Do the rules exist even when you can't implement the

requirement? Absolutely.

• Will implementing the requirement mean all the rules will be complied

with? Not for sure.

• Will implementing the requirement enable easier compliance with the

rules? Yes.

• Is this the ONLY feasible requirement to enable compliance with this

set of rules? No.

15

Requirements(BRD) vs. Specifications(FSD)

BRD

• Contains the client requirements at a very

high level. These requirements can be

one-liner, a statement or user stories. It

depends on how the client reverts back to

the Business Analysts (BA).

• In general, BA’s use various Business

Requirement Gathering Techniques (like

Questionnaires, One-One Interviews,

Group Discussions, Requirements

Patterns etc.) to get the information from

the client depending upon the complexity

of the business and availability of the

client.

FSD

• Contains the apt solution and the

workflow to achieve the solution in

terms of the product’s intended

capabilities, look and feel, and UI.

• This document is mainly targeted at

the technical team to understand the

requirements correctly and implement

the solution in the intended way.

Hence the document shall have

details about the workflow laid in to

achieve the solution.

16

Requirements vs. Specifications

BRD Example

The user should be able to capture the

customer data.

FSD Example

• For User to capture the customer data, create amenu option called ‘Customer Data’. When theuser clicks on the menu option, render ascreen/pop-up window/dialog-box containing theFORM with the required fields (Name, Address,City, State, Zip, Phone, SSN, etc.) and ‘Save’ &‘Cancel’ button. When the user clicks the ‘Save’button, and validate the FORM for mandatoryfields are populated and the correctness of thefield values that is entered.

• If ‘yes’, save the details.

• If ‘no’, then alert the user with meaningful errormessage and highlight the fields with error. Alsoretain the values of the fields in the form that arecorrect.

17

ThankyouWWW.RNSANGWAN.COM

18