IT 118 - SIA - Module 3

Bicol University College of Science
CS/IT Department IT 118 - System Integration and Architecture

Legazpi City Module 3: Requirements
Module 3
Requirements
Requirement Analysis
Requirements Analysis, also called Requirement Engineering, is the process of determining the
expectations of the users for an application that is to be built or modified. It involves all the tasks that
are conducted to identify the needs of different stakeholders. Therefore requirements analysis means
to analyze, document, validate and manage software or system requirements. These requirements,
often also called as features, must be quantifiable, relevant and detailed. In software engineering, such
requirements are often called functional specifications.
Requirements analysis involves frequent communication with system users to determine specific
feature expectations, resolution of conflict or ambiguity in requirements as demanded by the various
users or groups of users, avoidance of feature creep and documentation of all aspects of the project
development process from start to finish. Energy should be directed towards ensuring that the final
system or product conforms to client needs rather than attempting to mold user expectations to fit the
requirements.
Requirements analysis is a team effort that demands a combination of hardware, software and human
factors engineering expertise as well as skills in dealing with people. High-quality requirements are
documented, actionable, measurable, testable, traceable, helps to identify business opportunities, and
are defined to a facilitate system design. Requirement Analysis is always done in the early phase of
any project to ensure that the final product conforms to all the requirements.
Requirement Analysis Process

A requirements analysis process involves the following steps:
Step 1: Identify Key Stakeholders and End-Users
The first step of the requirements analysis process is to identify key stakeholders who are the main
sponsors of the project. They will have the final say on what should be included in the scope of the
project.
Next, identify the end-users of the product. Since the product is intended to satisfy their needs, their
inputs are equally important.
Step 2: Capture Requirements
Ask each of the stakeholders and end-users their requirements for the new product. Here are some
requirements analysis techniques that you can use to capture requirements:
Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Page 1 of 18
1. Hold One-on-One Interviews
Interview each stakeholder and end-user individually. This technique will help you gather specific
requirements.
2. Use Focus Groups
Conduct group interviews or group workshops to understand the flow of information between different
stakeholders and end-users. This technique will ensure that there will be no conflict of interest later on
during the project.
3. Utilize Use Cases
Use cases provide a walkthrough of the entire product through the eyes of the end-user. This technique
will help visualize how the product will actually work.
4. Build Prototypes
A prototype provides users a sample look and feel of the final product. This technique will help address
feasibility issues and identify problems ahead of time.
Step 3: Categorize Requirements
Since requirements can be of various types, they should be grouped to avoid confusion. Requirements
are usually divided into four categories:
 Functional Requirements - Functions the product is required to perform.

 Technical Requirements - Technical issues to be considered for the successful implementation
of the product.
 Transitional Requirements - Steps required to implement a new product smoothly.
 Operational Requirements - Operations to be carried out in the backend for proper functioning
of the product.
Step 4: Interpret and Record Requirements
Once the requirements are categorized, determine which requirements are actually achievable and
document each one of them. Here are some techniques to analyze and interpret requirements:
 Define Requirements Precisely - Ensure that the requirements are clearly worded, sufficiently
detailed, and related to business needs.
 Prioritize Requirements - Prioritize requirements and list them out based on which ones are
the “most critical” and which ones are just “nice-to-have”.

Page 2 of 18
 Carry Out an Impact Analysis - Carry out an impact analysis to make sure that you fully
understand the consequences of the requirements.
 Resolve Conflicts - Arrange a meeting with key stakeholders and resolve conflicting
requirements. You can also perform a scenario analysis to explore how the requirements would
work for different possible scenarios.
 Analyze Feasibility - Perform a detailed analysis of the product based on the requirements
gathered to determine its reliability and to identify any major problems.
Once all the requirements are analyzed, create a detailed written document and circulate it among the
key stakeholders, end-users and development teams.
Step 5: Sign off
Once a final decision is made on the requirements, ensure that you get a signed agreement from the
key stakeholders. This is done to ensure that there are no changes or uncontrolled growth in the scope
of the project.
Requirement Analysis Techniques

There are different techniques used for business Requirements Analysis. Here are some requirement
analysis techniques:
1- Business process modeling notation (BPMN)
This technique is similar to creating process flowcharts, although BPMN has its own symbols and
elements. Business process modeling and notation is used to create graphs for the business process.
These graphs simplify understanding the business process. BPMN is widely popular as a process
improvement methodology.
2- UML (Unified Modeling Language)
UML consists of an integrated set of diagrams that are created to specify, visualize, construct and
document the artifacts of a software system. UML is a useful technique while creating object-oriented
software and working with the software development process. In UML, graphical notations are used to
represent the design of a software project. UML also help in validating the architectural design of the
software.
3- Flowchart technique
A flowchart depicts the sequential flow and control logic of a set of activities that are related. Flowcharts
are in different formats such as linear, cross-functional, and top-down. The flowchart can represent
system interactions, data flows, etc. Flow charts are easy to understand and can be used by both the
technical and non-technical team members. Flowchart technique helps in showcasing the critical
attributes of a process.

Page 3 of 18
4- Data flow diagram
This technique is used to visually represent systems and processes that are complex and difficult to
describe in text. Data flow diagrams represent the flow of information through a process or a system. It
also includes the data inputs and outputs, data stores, and the various sub-process through which the
data moves. DFD describes various entities and their relationships with the help of standardized
notations and symbols. By visualizing all the elements of the system it is easier to identify any
shortcomings. These shortcomings are then eliminated in a bid to create a robust solution.
5- Role Activity Diagrams (RAD)
Role-activity diagram (RAD) is a role-oriented process model that represents role-activity diagrams.
Role activity diagrams are a high-level view that captures the dynamics and role structure of an
organization. Roles are used to grouping together activities into units of responsibilities. Activities are
the basic parts of a role. An activity may be either carried out in isolation or it may require coordination
with other activities within the role.
6- Gantt Charts
Gantt charts used in project planning as they provide a visual representation of tasks that are scheduled
along with the timelines. The Gantt charts help to know what is scheduled to be completed by which
date. The start and end dates of all the tasks in the project can be seen in a single view.
7- IDEF (Integrated Definition for Function Modeling)
Integrated definition for function modeling (IDEFM) technique represents the functions of a process and
their relationships to child and parent systems with the help of a box. It provides a blueprint to gain an
understanding of an organization’s system.
8- Gap Analysis
Gap analysis is a technique which helps to analyze the gaps in performance of a software application
to determine whether the business requirements are met or not. It also involves the steps that are to
be taken to ensure that all the business requirements are met successfully. Gap denotes the difference
between the present state and the target state. Gap analysis is also known as need analysis, need
assessment or need-gap analysis.
Types of Requirements
Clearly defined requirements are essential signs on the road that leads to a successful project. They
establish a formal agreement between a client and a provider that they are both working to reach the
same goal. High-quality, detailed requirements also help mitigate financial risks and keep the project
on a schedule. According to the Business Analysis Body of Knowledge (BABOK) definition,
requirements are a usable representation of a need.

Page 4 of 18
Creating requirements is a complex task as it includes a set of processes such as elicitation, analysis,
specification, validation, and management. BABOK, which is a recognized set of business analysis
industry standards, offers the following classification of requirements.
1. Business requirements
These include high-level statements of goals, objectives, and needs. Business requirements do not
include any details or specific features. They just state the problem and the business objective to be
achieved such as
 increased revenue/throughput/customer reach,

 reduced expenses/errors,
 improved customer service, etc.
2. User (stakeholder) requirements
The needs of discrete stakeholder groups (top-level managers, non-management staff, customers, etc.)
are specified to define what they expect from a particular solution. This group serves as a bridge
between the generalized business requirements and specific solution requirements. They are outlined
in a User Requirements Specification and can include, for example, ability to create various reports,
view order history and status, manage customer databases, etc.
3. Solution requirements
Solution requirements describe specific characteristics that a product must have to meet the needs of
the stakeholders and the business itself. They fall into two large groups.
 Functional requirements define what a product must do, what its features and functions are.
Also, functional requirements are product features or functions that developers must implement
to enable users to accomplish their tasks. It is important to make them clear both for the
development team and the stakeholders. Generally, functional requirements describe system
behavior under specific conditions. For example:
- The system sends an approval request after the user enters personal information.
- A search feature allows a user to hunt among various invoices if they want to credit an issued
invoice.
- The system sends a confirmation email when a new user account is created.
 Nonfunctional requirements describe the general properties of a system. They are also known
as quality attributes. Nonfunctional requirements are not related to the system functionality,
rather define how the system should perform. For example:
- The website pages should load in 3 seconds with the total number of simultaneous users <5
thousand.
- The system should be able to handle 20 million users without performance deterioration.

Page 5 of 18
4. Transition requirements
An additional group of requirements defines what is needed from an organization to successfully move
from its current state to its desired state with the new product. They are only necessary for the short
period of time while the transition takes place. Examples can be “users must be trained to operate the
system” or “previous data must be migrated to the cloud storage.”
To learn more about software documentation and planning, consider checking our video explainer.
Requirements Life Cycle Management

Requirements life cycle management is the knowledge area that describes the tasks that a business
analyst performs to manage and maintain requirements from initiation right through to final
implementation. The process includes monitoring, planning, analyzing, managing, and communicating
organizational requirements. The life cycle of requirements can have a deciding impact on the outcome
of the project. Managing requirements life cycle requires a business analyst to manage and maintain
requirements while identifying relationships with designs, assessing changes, and helping reach
consensus on those changes.
The objective of requirements life cycle management is to provide an environment where all of the
analysis crucial elements – the business itself, stakeholders, requirements, and design are aligned with
each other and ensure that the solution properly implements those requirements and designs. When
conducted in the right way, requirements management doesn’t end with the implementation of the
solution, but it continues to provide value as long as that solution is in use.
During requirements life cycle management, the business analysts employ all six of the key concepts
listed in BABOK. They are responsible for evaluating changes to requirements and designs and
managing requirements so that the stakeholders’ needs are satisfied.
The BAs trace requirements to the solution components and align the solution with the need. During
this process, they cooperate with interested stakeholders on the understanding and approval of
requirements. The goal is to maintain requirements in a way that will provide future value and that is
only possible through understanding the organizational context in which these activities take place.
The knowledge area of requirements life cycle management involves five tasks that a business analyst
needs to perform:
1. Trace Requirements
Tracing requirements involves analysis and maintaining relationships between requirements, designs,
and solutions which should provide the basis for impact analysis, allocation, and coverage. The life
cycle of every requirement needs to be identified and recorded in a way that ensures backward and
forwards traceability. Through traceability, the business analyst can ensure that the solution is aligned
to the requirement and manage the scope, timeline, risks, and potential costs.

Page 6 of 18
It’s also helpful for discovering requirement inconsistencies and flaws and provides a better
understanding of the change. Tracing enables the analyst to assess at any given moment if certain
requirements have been addressed or not.
Requirements tracing is based on two key inputs – requirements that can be traced to other
requirements, solutions, and other process components, and designs which can also be similarly
traced. The completely traced requirements and designs are the expected outputs of this process. The
elements of requirements tracing are:
 Level of Formality
 Relationships
 Traceability Repository
The main guidelines and tools used for tracing the requirements are domain knowledge, information
management approach, legal/regulatory information, and requirements management tools/repository.
The techniques that the business analyst will most likely use are:
 Business Rules Analysis

 Functional Decomposition
 Process Modelling
 Scope Modeling
Tracing requirement requires the involvement of the following stakeholders: customers, domain subject
matter expert, end-user, implementation subject matter expert, operational support, project manager,
sponsor, suppliers, and tester.
2. Maintain Requirements
Maintaining requirements is necessary for keeping the requirements and designs accurate and current
throughout the cycle. It also enables their reuse if needed. Maintenance of requirements is crucial for
preserving their validity through the process, especially since it represents a certain organizational
need. To maximize the benefits of maintaining requirements, the business analysis must make sure
that the requirements are consistently represented, approved, and reviewed using standardized
procedures, and easy to access and understand.
Two inputs are key for requirement maintenance – requirements (goals, business requirements,
stakeholder requirements, and transition, and solution requirements) and designs that are maintained
throughout the whole process. The main elements of requirements maintenance task are:
 Maintaining Requirements
 Maintaining Attributes
 Reusing Requirements

Page 7 of 18
While maintaining requirements, the business analysts commonly use information management
approach as a useful guideline or tool. Besides this, there are several helpful business analysis
techniques:

 Data Flow Diagrams
 Data Modelling
 Document Analysis
 Functional Decomposition
 Process Modelling
 Use Cases and Scenarios
 User Stories
The significant stakeholders at this stage of the business analysis project are domain subject matter
expert, implementation subject matter expert, operational support, regulator, and tester.
3. Prioritize Requirements
Prioritizing requirements or ranking them in order of importance helps business analysts assess the
value, risk, and urgency related to certain requirements and designs. This ensures that the most
important requirements and designs are always at the top of the queue for analysis. the relevance of
the requirements to their stakeholders plays the most important part of their ranking and according to
this, the requirement can be prioritized to a greater or lesser extent.
The ranking doesn’t just reflect the relevance of a requirement, but often their place in a project timeline.
As the project moves on, and new changes and needs are introduced, the prioritization can also change
reflecting this process. The ultimate objective of requirements prioritization is securing the maximum
value for the stakeholders.
The crucial inputs for requirements prioritization are requirements that are to be prioritized (in the form
of text, diagrams, or matrices) and designs in similar forms ready for prioritization. Prioritizing
requirements is expected to produce two key outputs; prioritized requirements ranked according to the
highest value and prioritized designs that are also ranked similarly and ready for further work.
The task of prioritizing requirements has three key elements:
 Basis for Prioritization

 Challenges of Prioritization
 Continual Prioritization
When prioritizing requirements use several guidelines and tools such as business constraints, change
strategy, domain knowledge, governance approach, requirements architecture, requirements
management tools/repository, and solution scope. There are also some useful BA techniques for this
process:

Page 8 of 18
 Backlog Management
 Business Cases
 Decision Analysis
 Estimation
 Financial Analysis
 Interviews
 Item Tracking
 Prioritization
 Risk Analysis and Management
 Workshops
Stakeholders that have significance at this phase of the project are customer, end-user, implementation
subject matter expert, project manager, regulator, and sponsor.
4. Assess Requirements Changes
When assessing requirements change, the business analysts evaluate every existing and potential new
stakeholder requirement and design so they can make an informed decision whether an action on those
requirements is required. Every change to the requirements and designs has its implications and
analysts assess those changes to estimate the impact of those changes on the project. This task needs
to be performed every time a new need arises or the possible solution is proposed.
Assessment of requirements changes helps understand how those changes increase or decrease the
value of the solution and identify the potential steps to be taken. Also, it reveals possible conflicts or
inconsistencies in relationships with other requirements. Each proposed requirement change needs to
be checked for alignment with the overall strategy, the potential value for stakeholders, the impact on
the delivery timeline, and possible influence on the risks, opportunities, and constraints of the whole
project.
The inputs for requirements change assessments are proposed change, requirements, and designs.
This task should produce outputs of requirements change assessment containing recommendations
on approval, denial or modification, and design change assessment with similar recommendations. The
three main elements of the task of assessing requirements changes are:
 Assessment Formality
 Impact Analysis
 Impact Resolution
Guidelines and tools the business analysts use while assessing requirements changes are change
strategy, domain knowledge, governance approach, legal/regulatory information, requirements
architecture, and solution scope. The key business techniques of use here are:

Page 9 of 18
 Business Cases
 Document Analysis
 Estimation
 Financial Analysis
 Interface Analysis
 Interviews
 Item Tracking
 Risk Analysis and Management
 Workshops
The stakeholders that are important for assessing requirements changes are customer, domain subject
matter expert, end-user, operational support, project manager, regulator, sponsor, and tester.
5. Approve Requirements
During the approving of the requirements, the business analysts work closely with the stakeholders
with the role in the governance process to approve and agree on certain requirements and designs.
Reaching the agreement and obtaining approval is crucial for the continuation of the business analysis
process.
Analysts are required to provide the understanding and unambiguous communication of any
information on requirements and designs needed for stakeholders’ approval. The approval itself can be
formal or informal and the time when it occurs depends on the business analysis approach taken –
predictive or adaptive.
The inputs for requirements approval are verified requirements and designs. The task should end with
the output of approved requirements and designs. The elements of the requirements approval task are:
 Understanding Stakeholders Roles

 Conflict and Issue Management
 Gaining Consensus
 Tracking and Communicating Approval
Business analysts can make use of the following guidelines and tools for requirements approval:
change strategy, governance approach, legal/regulatory information, requirement management
tools/repository, and solution scope. Business analysis techniques that will most likely be used are:
 Acceptance and Evaluation Criteria

 Item Tracking
 Reviews

Page 10 of 18
 Workshops
The stakeholders that are important for requirements approval are customer, domain subject matter
expert, end-user, operational support, project manager, regulator, sponsor, and tester.
Requirements Elicitation
Business analysts conduct requirements elicitation to identify the business need, scope, assumptions,
and risks of a project based on data from key stakeholders. It’s an imperative part of requirements
management as the outcome impacts the fundamental understanding of the project’s goal. Failure to
clearly define business needs can lead to catastrophic results such as expensive mistakes or system
failure.
Requirements elicitation is perhaps the most difficult, most error-prone and most communication
intensive system or project development. It can be successful only through an effective customer-
developer partnership. It is needed to know what the users really need.
Requirements elicitation is important for product teams because it is the main way product requirements
are identified. The elicitation process unearths requirements insights from key stakeholders. By expertly
asking the right questions of subject matter experts, enabling deep conversations, and recording
findings, business analysts discover the true business needs to drive the project.
In the absence of properly identified business needs and requirements, development costs will be over
budget due to rework, users/customers will not get what they want, and projects will be unsuccessful.
There are five main steps to the requirements elicitation process:
1. Gathering requirements
You may be thinking, “How is requirements elicitation different from requirements gathering?” especially
when the two terms are often used interchangeably. It is a good question, and it is acceptable to
casually interchange them. However, there is a slight difference between gathering requirements and
requirements elicitation that is worth pointing out when discussing the specifics of the requirements
elicitation process.
By definition, “gathering” is the act of collecting from scattered sources, while “eliciting” is the act of
drawing out information from a source. Both acts are essential to the overall process of requirements
elicitation and take expertise to execute properly.
An effective way to prepare for requirements elicitation is for business analysts to gather all available
requirements and study them for insights. A few techniques for requirements gathering include:
- Document analysis, such as studying process models or researching regulations.

- Analyzing system interfaces and business rules.
- Reading available user feedback.

Page 11 of 18
The findings from requirements gathering can help identify key stakeholders and inform which
requirements elicitation techniques might best suit the project. Business analysts can then begin the
work of drawing out the enlightening experiences that fill in the missing requirements. Therefore,
requirements gathering is the perfect first step in the process of requirements elicitation.
2. Identifying key stakeholders
As noted, requirements gathering can provide insight on relevant stakeholders. It is important to identify
the right people up front so everyone can begin on the same page. Doing so eliminates the need to fill
in missing requirements later that could potentially change the course of the project.
3. Eliciting requirements from key stakeholders
In this part of the process, business analysts need to determine which requirement elicitation
techniques will provide the best results given the project at hand and appropriate stakeholders.
There are a variety of requirement elicitation techniques, here are some of the most popular methods.
Brainstorming
Brainstorming is a group technique intended to generate lots of new ideas hence providing a platform
to share views. A highly trained facilitator is required to handle group bias and group conflicts. Every
idea is documented so that everyone can see it. Finally, a document is prepared which consists of the
list of requirements and their priority if possible.
Focus groups
Focus groups helps stakeholders be more forthcoming and articulate solutions. Business analyst can
get a lot of information at once. To perform focus groups, gather representatives from stakeholder
groups. The facilitator asks questions to get team members to discuss specific areas of interest and
records ideas discussed.
Interviews
Objective of conducting an interview is to understand the customer’s expectations from the system or
project. It is impossible to interview every stakeholder hence representatives from groups are selected
based on their expertise and credibility. Interviews maybe be open-ended or structured.
 In open-ended interviews there is no pre-set agenda. Context free questions may be asked to
understand the problem.
 In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.
Observation
Provide a direct view of how a stakeholder performs a particular process. Observation can be
conducted passively—the facilitator watches the stakeholder work without interrupting—or actively—
Page 12 of 18
the facilitator asks questions about the work as it is being performed. In both cases, the facilitator should
take notes and get feedback from the stakeholder on the information collected.
Prototyping
Prototyping collects feedback from non-technical stakeholders by showing them an example with which
they can physically interact. At first prototyping can be executed via storyboard, interactive screen,
virtual mock-up, navigation flow, etc. The exact method depends on the project, but it is usually an
iterative process that is improved based on input. As more requirements come forward, more detailed
prototypes are created to ensure they meet the expectations as recorded.
Requirements workshops
Workshops is designed to get the stakeholders together in a structured, time-based setting to elicit,
refine, and edit requirements. Stakeholders can discuss and provide immediate input on identified
business needs. In workshops, business analyst can set a specific timeframe and agenda for the
workshop. Include brainstorming, focus group, and prototyping (if applicable) opportunities within the
schedule. Use these to guide the discussion and record input.
Surveys
Surveys obtains objective feedback from large groups of customers or end-users. In surveys, business
analyst choose participants wisely based on desired criteria. Create clear questions that do not lead
the respondents. Questions can have a number of finite choices or be open-ended—for best results
consider the goal of the question, as well as the number of respondents, to determine the best structure
for proper analysis.
As is often the case, a variety of requirements elicitation methods can be employed to unearth the
business needs of a project. For example, a business analyst may ask specific requirements questions
in a focus group, in a brainstorming session, or during observation. A business analyst may also
conduct surveys before a requirements workshop, or create a prototype to be used during observation.
Knowing which elicitation techniques to use for a given project comes with experience.
4. Documenting requirements
The next step in the requirement elicitation process is documenting the requirements elicited thus far.
There are a variety of formats for documenting requirements: a home-grown product requirements
document (PRD), a government-mandated system requirements specification, a requirements
management tool like Jama Connect, a spreadsheet, etc. The best tool for documenting requirements
depends on the project.
If the project has many stakeholders, complex development, or compliance or functional safety
standards, it’s a best practice to choose a requirements management tool like Jama Connect. These
are purpose-built to mitigate risks associated with complex systems and regulatory compliance.
Assessing needs and researching functionality will help determine the best option for the project

Page 13 of 18
5. Confirming the findings
Once business analysts document the requirements, it is time to make sure they are recorded correctly.
Requirements are sent to all stakeholders to review so there is a collective understanding of what’s
being developed. Stakeholders are likely to make refinements. It is also possible that this step elicits
further requirements, which will necessitate revisions before approval can take place.
Business analysts conduct the process of requirements elicitation at the beginning of a project, and the
process is ongoing throughout the development process. This is because change is always occurring
and it’s never possible to know all the questions to ask or have all the correct answers upfront.
Requirements Documentation
Requirements documentation describes the business solution for a particular project, including the
user's expectations and needs, the purpose behind that solution, and any high-level constraints that
can affect successful deployment. It typically serves as the guideline for stakeholders to decide on
project priorities, structure, and design to guarantee the project stays aligned with the business's overall
goals. It also serves as a fundamental contract between the vendor and customer, outlining the project's
deliverables and expectations. A requirement document sets the standards for determining when you
have completed a project.
It allows you and the client to:
 Plan predictable project timelines so you can plan accordingly

 Define deliverables and develop only relevant functionality
 Show hidden and assumed requirements
 Get a deeper understanding of the future system or product
Types of Requirement Documents

Requirements documents are used to communicate the aims of a project in a clear, concise way to
ensure all stakeholders are on the same page. When we talk about a requirements document we are
often referring to a Business Requirements Document - or a BRD.
But as well as a BRD, there are 9 other types of requirements documents that a business may want to
use while pushing a project through its stages of completion. The type of format to be used depends
on the result of the project itself, whether it’s a product, service or system, and the particular
requirements it has.
THE KEY PLAYERS
Before we jump into the types of requirements documents, let's talk about the main people involved in
their creation.

Page 14 of 18
 The Customer is ultimately responsible for determining the requirements. The customers’ needs
are the origin of the project.
 The Business Analyst is responsible for discovering the problem/requirements and determining
the solution.
 The Project Manager is responsible for delivering the solution to a problem.
 The Systems Analyst uses analysis and design to satisfy business requirements using
information technology.
 The Marketing Manager develops the marketing strategy for the project in line with its
requirements.
 The Product Manager is responsible for defining the why, when, and what of the product that
the development team will build.
Here are the different types of requirements documents:
1. Business Requirements Document (BRD)
Also known as a Business Needs Specification, a BRD is the first stage in a product life cycle. It details
the problems that a product/service/system is trying to solve by logically listing high-level business
requirements in relation to customers’ needs.
As well as non-negotiables, it also details features the project should provide, which can be interpreted
as goals for the development team. It often includes:
 An outline of the requirements of the project

 Objectives of the project
 A needs statement detailing why the project is needed and how it will meet those needs
 Financial statements, demonstrating how the project will be funded and its effect on the
company’s balance sheet
 Functional requirements and features
 A SWOT analysis of the business and how the project fits into it
 Personnel needs. Who do we want to work on the project?
 Schedule, timeline and deadlines
 A cost-benefit analysis
 It’s normally a single page with a bullet-type list.
A BRD is normally prepared by the project manager or business analyst.
2. Functional Requirements Document (FRD)
An FRD defines in logical terms, how a system or project will accomplish the requirements laid out in
the BRD. It outlines the functionality of the system in detail by capturing the intended behavior of the
system, expressed as services, tasks or functions that the developers have agreed to provide. Rather
than define the ‘inner-workings’ and specifications, an FRD focuses on what users might observe when
interacting with the system.
Page 15 of 18
An example functional requirement might be: “When the user clicks the OK button, the dialog is closed
and the user is returned to the main window in the state it was in before the dialog was displayed."
An FRD sometimes includes screen mockups or wireframes to illustrate the system’s design.
Depending on the complexity, FRDs can vary in length from 10 pages to several hundred. An FRD is
normally written by the business analyst or systems analyst.
3. Market Requirements Document (MRD)
Sometimes referred to as a Marketing Requirements Document, an MRD focuses on the target market’s
needs. It typically explains: What the product is, who the target customers are, what products are in
competition with it and why customers are likely to want this product.
An MRD typically includes:
 A definition of the target market, an imagining of the potential buyer or user

 A comprehensive list of market requirements the solution will need to satisfy
 Indicators of success for each requirement
 A prioritized list of requirements from your market’s point of view
 A timeframe for the product’s launch
An MRD is normally prepared by the marketing manager or product manager.
4. Product Requirements Document (PRD)
A PRD is used to communicate everything that must be included in a product release for it to be
considered complete. It is written from a user’s point-of-view to understand what a product should do.
It usually includes the same content as an FRD, but with ‘non-functional requirements’ added. Although
non-functional requirements are not related to the functionality of the product, it’s often important to
identify them - they may include such needs as reliability, security and scalability. A typical PRD might
contain:
 Objectives for the product

 Features
 User experience (UX) flow & design notes
 System and environment requirements
 Assumptions, constraints & dependencies - What’s expected as well as any limitations or
obstacles that may impede the project’s progress
A PRD is normally prepared by the product manager.
5. User Interface Requirements Document (UIRD)
A UIRD describes the look and feel of the User Interface (UI) of the system. It often defines:

Page 16 of 18
 How the content is presented to the user

 User navigation
 Color codes to be used
 Hints, tips and suggestions to be displayed
 ‘Save data’ options
 Shortcut keys
 A UIRD more often than not includes mockup screenshots and wireframes to give readers an
idea of what the finished system will look like.
It’s written by the user interface design team.
6. Technical Requirements Document (TRD)
A TRD contains the software, hardware and platform requirements of the product. It includes
requirements like the programming language the system should be developed in and the processor
speed required to run the system. It might also consider the limitations of the system and its
performance. A good TRD will include the following key items:
 An executive summary of the project and its background.

 Assumptions, risks, and factors that may affect the project
 Functional and non-functional requirements
 References or a list of supporting documents
A TRD is written by the engineering team.
7. Quality Requirements Document
The quality requirements document outlines the expectations of the customer for the quality of the final
product. It consists of various criteria, factors and metrics that must be satisfied. Quality requirements
might revolve around reliability, consistency, availability, usability, maintainability and customer
experience.
This document can be written by the project manager or business analyst
8. Software Requirements Document or Software Requirements Specification (SRS)
An SRS outlines the features and the intended behavior of a system. It describes the business’s
understanding of the end user’s needs while laying out functional and nonfunctional requirements.
An SRS is related to the FRD and PRD but written with a specific IT project in mind. Its contents may
include:
 A product overview
 A summary of the current system
 The proposed methods and procedures

Page 17 of 18
 Design considerations
 Security considerations
An SRS is normally compiled by the lead engineer of the project.
9. Customer Requirements Document
This is sometimes referred to as Client Requirement Document and it can refer to a PRD but for a
specific customer or client.
References
https://reqtest.com/requirements-blog/requirements-analysis/
https://www.simplilearn.com/what-is-requirement-analysis-article
https://www.techtarget.com/searchsoftwarequality/definition/requirements-analysis
https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5464/9-Types-Of-Requirements-
Documents-What-They-Mean-And-Who-Writes-Them.aspx
https://www.jamasoftware.com/requirements-management-guide/requirements-gathering-and-
management-processes/a-guide-to-requirements-elicitation-for-product-teams
https://www.geeksforgeeks.org/software-engineering-requirements-elicitation/
https://www.altexsoft.com/blog/business/functional-and-non-functional-requirements-specification-
and-types/
https://ca.indeed.com/career-advice/career-development/requirements-documentation

Page 18 of 18

IT 118 - SIA - Module 3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IT 118 - SIA - Module 3

Uploaded by

Copyright:

Available Formats

Bicol University College of Science

CS/IT Department IT 118 - System Integration and Architecture

Requirement Analysis Process

Step 1: Identify Key Stakeholders and End-Users

Step 2: Capture Requirements

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

1. Hold One-on-One Interviews

2. Use Focus Groups

3. Utilize Use Cases

Step 3: Categorize Requirements

 Functional Requirements - Functions the product is required to perform.

Step 4: Interpret and Record Requirements

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Step 5: Sign off

Requirement Analysis Techniques

1- Business process modeling notation (BPMN)

2- UML (Unified Modeling Language)

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

4- Data flow diagram

5- Role Activity Diagrams (RAD)

7- IDEF (Integrated Definition for Function Modeling)

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

 increased revenue/throughput/customer reach,

2. User (stakeholder) requirements

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Requirements Life Cycle Management

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

 Business Rules Analysis

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

 Business Rules Analysis

The task of prioritizing requirements has three key elements:

 Basis for Prioritization

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

4. Assess Requirements Changes

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

 Understanding Stakeholders Roles

 Acceptance and Evaluation Criteria

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

There are five main steps to the requirements elicitation process:

- Document analysis, such as studying process models or researching regulations.

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

2. Identifying key stakeholders

3. Eliciting requirements from key stakeholders

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

5. Confirming the findings

It allows you and the client to:

 Plan predictable project timelines so you can plan accordingly

Types of Requirement Documents

THE KEY PLAYERS

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Here are the different types of requirements documents:

1. Business Requirements Document (BRD)

 An outline of the requirements of the project

A BRD is normally prepared by the project manager or business analyst.

2. Functional Requirements Document (FRD)

3. Market Requirements Document (MRD)

An MRD typically includes:

 A definition of the target market, an imagining of the potential buyer or user

An MRD is normally prepared by the marketing manager or product manager.

4. Product Requirements Document (PRD)

 Objectives for the product

A PRD is normally prepared by the product manager.

5. User Interface Requirements Document (UIRD)

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024