Determining Requirements Complexity - White Paper

White Paper on Determining Requirement Complexity by Saurabh Goel| ABSTRACT 1
Requirement’s Complexity
WhitePaper
Saurabh Goel
Business Analyst

White Paper on Determining Requirement Complexity by Saurabh Goel| ABSTRACT 2
ABSTRACT
With a rapidly changing and an ever growing IT landscape, there is always a need and room
for improvement for organizations who have adopted IT. Enterprises look for a more
efficient and better way to manage their IT infrastructure. An existing setup needs to go
through a huge transformation to achieve par excellence reputation. These transformation
projects may sometimes take more than a couple of years to reach the desired state. While
working on several of such projects, I came up with a list of parameters that can help you
determine a Requirement’s Complexity and help Business Analysts think in the right
direction. This will also help the Project Manager, Technical Architect, Design Leads and
Lead Business Analyst (or BA Manager) clearly, that they are able to estimate the right
amount of time required during different phases of the project. Unless the right estimation
of complexity & time required is not made, an effective Strategy cannot be chalked out,
which is vital to the very existence of a project. Unforeseen complexities, issues, deadlocks,
conflicts due to time/budget constraints and limitations to absorb the ever changing
requirements, add fuel to the idea of scrapping a project altogether. This shall help the
entire team to make the right estimates & keep the reins of project in hand.

White Paper on Determining Requirement Complexity by Saurabh Goel| About the AUTHOR 3
About the AUTHOR
Saurabh Goel has been working in IT industry for over 9 years now and has a vast experience
in Banking & Finance domain and Life Sciences & Healthcare domain. When published, this
will be his second white paper, the earlier one being on Infrastructure Transformation
Projects. He is working as a Business Analyst on numerous projects for over 5 years now,
including Greenfield & Brownfield projects in Waterfall, Agile & Reverse Engineering
methodologies in the UK, US and India. He also has a unique experience in collecting and
analysing Business Requirements & Use Cases, Functional Specifications, Business Rules,
Transformation Requirements and Application Portfolio Management.

White Paper on Determining Requirement Complexity by Saurabh Goel| About the DOMAIN 4
About the DOMAIN
Any project which is aimed at developing an application, either from scratch or by upgrading
a legacy one, needs an approved set of requirements to begin with. Such projects range
from relatively simple upgrades to complex ones, upgrading the entire underlying
infrastructure like Data Centre movement, Services, Network, User Interface and Database
movements. This may involve outsourcing to a 3rd
party vendor as well. In any case, even
before the new strategy is laid out, the existing one should be understood thoroughly;
whether it’s currently implemented electronically or not. A thorough analysis of Business
and System requirements demand for an approved set of requirements which, then become
the ultimate source for Estimation. Time & Budget calculations determine the organization
readiness, feasibility of the project, resource requirements and finally, the decommissioning
of old system. Unless the correct complexities are determined, the project is either doomed
to fail or to stretch over such a long duration that the Sponsor may lose his faith in the
investments made.

White Paper on Determining Requirement Complexity by Saurabh Goel| About the DOMAIN 5
Contents
White Paper ............................................................................................................................................1
ABSTRACT................................................................................................................................................2
About the AUTHOR .................................................................................................................................3
About the DOMAIN.................................................................................................................................4
INTRODUCTION.......................................................................................................................................6
CLASSIFICATION ......................................................................................................................................7
SEGGREGATION CRITERIA...................................................................................................................7
Very Simple/Elementary.................................................................................................................7
SIMPLE.............................................................................................................................................7
MEDIUM..........................................................................................................................................9
HIGH..............................................................................................................................................11
CONCLUSION.........................................................................................................................................13

White Paper on Determining Requirement Complexity by Saurabh Goel| INTRODUCTION 6
INTRODUCTION
Project estimations are based on several parameters and one of the very essential pillars is
the Complexity of the Requirements. This factor is so important in determining the strategy
that it is capable of steering it in a direction from not allowing to proceed at all to
determining the release strategy. The highly complex projects, if not adopted on Agile
methodology, are often based on release-based roll out. A right mix of varying complexity
requirements and functionalities are rolled-up in a release, enhancing the product with each
release. In order to determine this, Business Analysts must work hard to determine the right
complexity of the requirements. This list comprehensively defines numerous parameters
that can be used to do this job. Primarily written keeping a legacy application in mind, this
paper is yet flexible enough to be used for moving from an existing offline (paper based
channels etc.) project to a digital one.

White Paper on Determining Requirement Complexity by Saurabh Goel| CLASSIFICATION 7
CLASSIFICATION
SEGGREGATION CRITERIA
The requirements can be categorized as High, Medium and Low complex. The below list
provides the scenarios for each of the categories. The list is more of guidelines and can be
modified based on project needs and technology.
Very Simple/Elementary
These requirements are only Graphical User Interface specific requirements that talk about
the appearance of the screen. While these requirements typically talk about the layout of
the screen, generally depicted in the Wireframes or Prototypes, they may be extended to
include Functional Specifications too i.e. the screen behaviour or user actions. While it is
recommended not to use the Design details and to stick to the generic description of the
user actions (irrespective of the ‘how’ part); practically the organizational practices ask
Business Analysts to detail out everything, making it easier for Testers to follow the suite.
 Displaying Data Elements on the Screen
o Navigation between the data elements on general user actions like ‘mouse
click’, ‘tab-out’ and ‘Enter key’
SIMPLE
This category of requirements is classified as Simple, by the virtue of the fact that they talk
about only the Graphical experience for the User. They are far more elaborative than the
previous category of “Very Simple” requirements, which have a slight overlap here as well.
The addition of other analysis points takes the complexity level to the next stage.
 Navigational Requirements
o This is a slight overlap with the previous category, depending upon the scope
of the project (as to what is the aim) and the organizational practices
 Simple Calculations using Screen Values or Database Values
o This includes UI level (a.k.a. on the fly) calculations based on user entered
values and calculations like Total & Taxes. It may or may not include values
fetched from the Database.

o Include features that require to Show/Hide or Enable/Disable fields on the fly
 Direct Data retrieval and Display on to Screen
o This is the primary function of any retrieve capability. Playback to the user,
previously entered data values.
 Saving of data directly in the Database
o This is for hitting the database, to store the entered values. Number of hits &
mechanism will differ with architecture in place like direct hits in case of
Oracle Apex to clubbed hits in case of SOA architecture.
 Printing of UI screen
o This should ideally fall in to the first category if a Print dialogue box is
initiated on Print call.
o If a soft print to RTF of PDF format is provided, then this qualifies for this
category. Some implementations require to Print the UI in a specific format
including header-footer, Brand Logo or Regulatory notes, in which case, they
may need to be included in Medium category because they need Acro-form
designs apart from UI data filling.
 Sort & Filter capability
o Data sorting in alphabetical or valuation orders etc.
o Filtering on fields that will help reduce the amount of data to be displayed on
the screen, in turn, reducing the Load time.
o Explore the need to implement a default filter (on the relevance of ‘in-
context’ attributes) if the expected load data is huge, for performance
improvement and sanity of display
 Displaying Generated & Stored Reports (from other applications)
o A common practice is to use third party tools to generate reports which will
call for integration requirements & proper analysis of Interface requirements
 System Warnings and Errors
o To enrich UI experience & maintain data sanity (esp. if the architectural layers
include Services before the Database is hit).
o Two fold importance of displaying UI level Warnings and Errors:
 Barring user from passing invalid values that cannot be processed

 Avoiding junk data to be stored in the Database.
o Analysis should factor-in for a better user experience
 Display in a different colour or in box/bold/italics
 To include highlighters like (!)
 Field level OR Screen level warnings
 Whether to bring user/focus back to the error field
 Hard Stops (errors) versus Warnings & whether to include another
click (for warnings) before proceeding further or leave them as a
Disclaimer for the user to read
 Data Formatting
o Rounding of data values
o Truncation of long values that are not required/supported downstream
o Precision logics for data elements like Reducing algorithms to avoid leftover
decimal values
o Other simple formats like for Dates, decimal places, SSN/Aadhar/NI numbers,
phone numbers and email contacts
MEDIUM
This category of requirements is classified as Medium, by the virtue of the fact that they talk
not only bout the user experience but also on the Data operations, Interfaces and some
Technical Features which need to be included in the analysis even before the Non-functional
requirements are analysed. These are far more elaborative than the previous category of
“Simple” requirements, which have a slight overlap here as well. This category is the most
prevalent among all categories.
 Print to Soft copies
o This follows the description as in the previous category.
 Processed and Transformed Data Retrieval on to Screen
o Although the display logic can be simple, the Calculations and Business rules
to process the data can sometimes increase the complexity level.
 Creation of Export Files into various Formats (PDF, Excel, RTF etc.)

o Export functions should include formatting requirements like header-footer,
Logo or Regulatory notes.
o Export may sometimes need Acroform designs.
o This should include an approval from Compliance department as well, if the
exports are meant for sharing them outside the organization like with
customers or regulatory departments
 Multiple UI rules while displaying data for selection (drop downs etc)
o Some of such field very well qualify for Simple complexities like displaying
months in the year while others may pose some challenges if Business Rules
or Data Transformation rules are to be applied
o This may also trigger an analysis exercise on Data Mapping, if the data is
traversing through interfaces or an external system
 Data Transformation before Persistence
o This may call for an analysis exercise on Business Rules for Data
Transformation
o Include any Calculation requirements
o Include Database layer constraints & designs on what can be passed-on,
stored and processed
 Direct Import of Data into the System
o Although it sounds similar to UI display requirement but these requirements
are around Importing the data from External Systems to the System in
Context
o A dump from an external source through a Batch process OR a User Action to
upload an Excel/CSV file on to the system, will require a specific format to be
rolled out, keeping in mind the features (as already discussed above) so that
the Import is accepted in the System
o For automated Batch processes, apart from the format of the file, anaylse the
requirements around source folders (where the files should be kept), batch
frequency & failover mechanism.
 Security Features
o Login: Password requirements or 2FA (Two Factor Authentication)

o Session Termination on Inactivity
o Navigation Restrictions upon Logout
o Browser Features
 Cookies and Session Data
 URL tweaking
 Back Button implementation and overriding default behaviour
o Third party integration for Payment Gateways
o Data Masking (passwords, CVV codes, SSN/NI numbers etc.)
o Data encryption at UI level for Customer’s Sensitive Information
o Remote Login (& VDI requirements, if applicable)
 Sending Automated Notifications
o Email messages
o Type of information and attachments in Outgoing communication
o Legal and Compliance to Approve of the Message Format & Content
 Document or Letter Generation for display within the System
o This is covered as sub-part in Soft Print section above
o Also include features for user to Save the generated document
 Save to a default location or allow to choose
 Naming convention for File Names or allow to change
 Role based Business Rules/Requirements
o Include a Role Matrix to chalk out authorization rules around access
restrictions and limiting operations
o Role based restrictions should honour Segregation of Duties
o Satisfy Audit requirements down the line
HIGH
This category of requirements is classified as High, by the virtue of Complexity they pose
during the Implementation & Analysis phases. These are way more elaborative than all of
the previous categories, which have a full overlap here, but with a greater degree of
complexity. These requirements call for a thorough analysis and utmost care while

determining their Complexity. Bring everyone on board to explain why some of the
requirements of the program are classified as Highly Complex, justify the amount of time
required in analysing and implementing them & reasons for including Risks associated with
them (if any). This category is also most vulnerable to Gaps in analysis and may challenge
the agreed-upon Scope.
 The description is already covered in the above sections, but for Highly Complex
requirements, the Intricacy levels change with Multiplicity
o Complex calculation & Business Rules
o Data flow through Multiple Interfaces
o Screen Data Transformation involving Multiple Rules
o Dynamic Frames/Data Elements on the Screen
o Transformation during Import of Data and its Persistence
o Creation of Reports with Data from Multiple Sources
o Workflow Capability
 Depending upon the nature of the program, this may stand qualified
for a separate analysis exercise altogether

White Paper on Determining Requirement Complexity by Saurabh Goel| CONCLUSION 13
CONCLUSION
It has been a long era since the Requirement Analysis based approach was integrated into
Project Estimation but IT industry is still far from its desired maturity level in making the
right estimates for project implementation. And by diving deep into list of all possible
reasons, we find that the undisputed topper is “Incorrect Estimations”. The root cause
behind? – Incorrect output of Requirement Analysis. It is up to the Business Analyst(s) that
they provide the correct output of Analysis exercise – the complexity of the Requirements.
Everything, from budget to time, cost to resources, methodology to strategy, success to
failure, depend on this. Spend a good amount of time to determine the complexity by
consulting the Technical and Architecture teams, Business stakeholders and Interface
teams, Networking and Security teams and then come up with the right estimates. Time
spent in this phase will save your time in future by many folds.

Determining Requirements Complexity - White Paper

Recommended

Recommended

More Related Content

Similar to Determining Requirements Complexity - White Paper

Similar to Determining Requirements Complexity - White Paper (20)

Determining Requirements Complexity - White Paper