Customer Requirement Document(CRD), High Level

Design(HLD), Low Level Design(LLD), Network

Implementation Plan(NIP) and Network Ready For
Use(NRFU) documentation
Project Management for IT-Related Projects
Deliverable examples:
?Request for Work,
?Statement of Work,
?Architecture Requirements,
?Architecture Definition,
?RAID Catalogue,
?Migration Plan
Enterprise Architecture Good Practices Guide
==The Enterprise Architect & the Architectural Engineer
Enterprise architects direct and constrain solution architects
?Solution architects direct and constrain software architects and other technica
l specialists
?Software architects direct and constrain software developers
HLD gives an Overview Understanding of a System,
irrespective of the Languages & technologies used for it.
It represents the Modules and sub modules that make up the
system and the interaction with each other.
1) Eg. Functional Architecture(Which gives details about
the Modules)-a)Use Case Diagram
2)Interaction Diagram
3) Database Design-- which gives the structure and the
Contents Design of the Database .
LLD represents the Low Level representation i.e the Code
Level design which could be used directly by the Programmer
to construct the code.
Eg.
1)Algorithims & Pseudocodes
2)Unit Test Case
High Level Design (HLD) is the overall system design - covering the system archi
tecture and database design. It describes the relation between various modules a
nd functions of the system. data flow, flow charts and data structures are cover
ed under HLD.
High-level_design
Low Level Design (LLD) is like detailing the HLD. It defines the actual logic fo
r each and every component of the system. Class diagrams with all the methods an
d relation between classes comes under LLD. Programs specs are covered under LLD
.
Types of Requirements Documents & What They Mean
Requirements Document
April 11, 2012 By Michael Shrivathsan

Email, RSS Follow

in
Share
.
15
Email Email
In my previous post I discussed different types of software requirements and how
they are used. I covered five different types of requirements.
In this post, I will walk you through the different types of requirements docume
nt and what they mean.
Before I jump into it, I gotta tell you
there are numerous types of requirements
document out there, we re just going to cover the most popular ones in this post! O
kay, let us get going
Types of Requirements Document
The most common types of software requirements documents are the following. I ve l
isted them in the order in which they re usually created during a project:
1.Business requirements Document (BRD) ?BRD outlines Business Requirements
i.e. hi
gh-level business goals of the organization building the product, or the custome
r who commissioned the project.
?BRD is usually provided as a single page document containing high-level bullets
.
2.Market Requirements Document (MRD) ?MRD outlines Market Requirements
i.e. one-le
vel deeper than BRs, but still at high-level. The focus is on market needs.
?It is often also referred to as Marketing Requirements Document (notice the ext
ra ing ). But this is frowned upon by the experts and they will send Guido after
you!
Trust me, he is scary. :)
?MRDs are usually provided as a prioritized bulleted list or table, and are usua
lly less than 5 pages long.
3.Functional Requirements Document (FRD) ?FRD outlines Functional Requirements , i.
e. functionality of the software in detail.
?Depending on the product being built, FRDs can be anywhere from ~10 pages to se
veral hundred pages.
?Even several thousand pages are not unheard of
for very complex, very long proj
ects. Like the ones by the government and such.
4.Product Requirements Document (PRD)
?PRD contains all the requirements for a product being built.
?PRDs usually include the same content as FRDs but also contain Non-Functional Re
quirements I discussed in my previous post on types of software requirements.
5.User Interface Requirements Document (UIRD), Interface Requirements Document ?
These documents outline the UI requirements for the software.
?These usually contain mockups, wireframes, and even production-quality UI proto
types.
6.Technical Requirements Document (TRD), Design Requirements Document, Engineeri
ng Requirements Document, Development Requirements Document ?The documents are w
ritten by engineering teams and contain technical requirements such as design, a
rchitecture, etc to achieve the requirements outlined in the documents outlined
above.
The following are other popular types of requirements documents. These are not r
eally new types of documents. Rather, they usually refer to one or more of the d
ocuments defined above
but in a specific context.
1.Software Requirements Document, Software Requirements Specification (SRS), Sys
tem Requirements Document, Application Requirements Document ?These terms usuall
y refer to FRD or PRD for a specific software, system or IT project.
2.Project Requirements Document, IT Requirements Document
?These terms usually refer to PRD

but for a specific project or IT initiative.

3.Customer Requirements Document, Client Requirements Document ?These terms usua

lly refer to PRD but for a specific customer or client.
Who Writes Requirements Documents?
Now that we ve covered different types of requirements documents
k at who writes these documents.

let us take a loo

Requirements document Who writes them (i.e. Job role)

BRD Product Managers, Product Marketing Managers
MRD Product Managers, Product Marketing Managers
FRD Business Analysts, System Analysts, Product Managers
PRD, SRS Business Analysts, System Analysts, Product Managers
UIRD User Interface Designers
TRD Engineering manager, System Architect
Okay, there you have it
all you ever wanted to know about the different types re
quirements documents. And then some!
FYI: Accompa Requirements Management Software can help you automatically create
different types of requirements documents listed above. This can save you a lot
of time compared to manually creating them. Check out product tour or request fr
ee trial.
This specification is intended to provide the environmental and software functional
requirements for the <project name> system being developed by Organization for
<court
or agency name>. \

This Functional and Technical Requirements Document outlines the functional,

performance, security and other system
requirements identified by the FDP Expanded Clearinghouse System Development
Working Group (EC-SDWG) as the
proposed information system solution for the Expanded Clearinghouse.
The On-line-Expanded Clearinghouse will
� House on-line profiles of FDP member institutions documenting the static/annual
information needed by pass-through
entities for routine subaward issuance and subrecipient monitoring activities, such
as annual audit results, F&A and
fringe benefit rates, and key contacts. The content of on-line profiles is expected
to mirror the content currently found
in the Expanded Clearinghouse pilot profiles found at:
http://sites.nationalacademies.org/PGA/fdp/PGA_171219.
� Allow secure access by FDP member institution representatives to create and
maintain their on-line profiles,
including deployment of real-time data validation mechanisms where practical.
� Provide notifications to profile-holders when time-sensitive data are obsolete
(e.g, expired audit information, outdated
SAM record, etc.)
� Import data from secure government systems needed for the On-Line profiles (e.g.,
SAM, Federal Audit
Clearinghouse) to expedite profile completion and increase timeliness of data
(FUTURE)
� Allow FDP member institutions to manage (add, change, delete) user rights for
profile maintenance within their
institution
� Allow FDP members and non-members to view published profiles, and download copies
of individual profiles
� Allow FDP members (only) to export On-Line Expanded Clearinghouse profile data
via an Application Program
Interface (API) for use in their local subaward or contract and grant management
systems
� Provide data for use in discussions with the federal government about reducing
administrative burden and wise
stewardship of federal funds.
The scope of this work includes the initial development of the web based system,
based on information and feedback
gathered during the Phase 1 Pilot. References to future development considerations
are included in this proposal for
information purposes only.

design, deployment, and operation of a Cisco Meraki cloudmanaged wireless network

attached to the fabric of a Cisco SD-Access network

design, deployment, and operation of a Cisco Meraki cloudmanaged wireless network

attached to the fabric of a Cisco SD-Access network

This design includes Meraki wireless endpoints using ISE as a RADIUS authenticator
for endpoints that associate with
each SSID.

required for good operation as a design recommendation. This is generally a

negative RSSI value like -67 dBm. It�s important to understand that this number
assumes good signal to noise ratio of 25 dB with a noise floor of -92 dBm. If the
noise floor is higher than -92 dBm then -67 dBm may not be enough signal to support
the minimum data rates required for the application to perform it�s function.

� Centralized policy�Enables intelligent inspection through the use of firewalls,

as well as application inspection, network access control, policy enforcement, and
accurate traffic classification

Provide Customer�s building layout, including the floor plan, cabling and power
location for applicable site, ten (10)
Business Days prior to Cisco finalizing the WLAN Network Implementation Plan

Cisco Meraki solution includes the MX450 VPN concentrator to centrally switch Guest
SSID traffic in the GRUE network.