LESSON 4 SOFTWARE REQUIREMENT (3).docx.

Software Requirements
LESSON 4
The software requirements are description of features and
functionalities of the target system. Requirements convey the
expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown,
expected or unexpected from client’s point of view.
Requirement Engineering
The process to gather the software requirements from client,
analyze and document them is known as requirement
engineering.
The goal of requirement engineering is to develop and maintain
sophisticated and descriptive ‘System Requirements Specification’
document.
Requirement Engineering Process
It is a four step process, which includes –
 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation
Let us see the process briefly -
Feasibility study
When the client approaches the organization for getting the
desired product developed, it comes up with rough idea about
what all functions the software must perform and which all
features are expected from the software.
Referencing to this information, the analysts does a detailed
study about whether the desired system and its functionality are
feasible to develop.

This feasibility study is focused towards goal of the organization.
This study analyzes whether the software product can be
practically materialized in terms of implementation, contribution
of project to organization, cost constraints and as per values and
objectives of the organization. It explores technical aspects of the
project and product such as usability, maintainability, productivity
and integration ability.
The output of this phase should be a feasibility study report that
should contain adequate comments and recommendations for
management about whether or not the project should be
undertaken.
Requirement Gathering
If the feasibility report is positive towards undertaking the
project, next phase starts with gathering requirements from the
user. Analysts and engineers communicate with the client and
end-users to know their ideas on what the software should
provide and which features they want the software to include.
Software Requirement Specification
SRS is a document created by system analyst after the
requirements are collected from various stakeholders.
SRS defines how the intended software will interact with
hardware, external interfaces, speed of operation, response time
of system, portability of software across various platforms,
maintainability, speed of recovery after crashing, Security,
Quality, Limitations etc.
The requirements received from client are written in natural
language. It is the responsibility of system analyst to document
the requirements in technical language so that they can be
comprehended and useful by the software development team.
SRS should come up with following features:
 User Requirements are expressed in natural language.
 Technical requirements are expressed in structured
language, which is used inside the organization.
 Design description should be written in Pseudo code.

 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.
Software Requirement Validation
After requirement specifications are developed, the requirements
mentioned in this document are validated. User might ask for
illegal, impractical solution or experts may interpret the
requirements incorrectly. This results in huge increase in cost if
not nipped in the bud. Requirements can be checked against
following conditions -
 If they can be practically implemented
 If they are valid and as per functionality and domain of
software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
Requirement Elicitation Process
Requirement elicitation process can be depicted using the
folloiwng diagram:
 Requirements gathering - The developers discuss with the client
and end users and know their expectations from the
software.
 Organizing Requirements - The developers prioritize and
arrange the requirements in order of importance, urgency
and convenience.
 Negotiation & discussion - If requirements are ambiguous or
there are some conflicts in requirements of various
stakeholders, if they are, it is then negotiated and discussed
with stakeholders. Requirements may then be prioritized
and reasonably compromised.
The requirements come from various stakeholders. To
remove the ambiguity and conflicts, they are discussed for
clarity and correctness. Unrealistic requirements are
compromised reasonably.

 Documentation - All formal & informal, functional and non-
functional requirements are documented and made available
for next phase processing.
Requirement Elicitation Techniques
Requirements Elicitation is the process to find out the
requirements for an intended software system by communicating
with client, end users, system users and others who have a stake
in the software system development.
There are various ways to discover requirements
Interviews
Interviews are strong medium to collect requirements.
Organization may conduct several types of interviews such as:
 Structured (closed) interviews, where every single
information to gather is decided in advance, they follow
pattern and matter of discussion firmly.
 Non-structured (open) interviews, where information to
gather is not decided in advance, more flexible and less
biased.
 Oral interviews
 Written interviews
 One-to-one interviews which are held between two persons
across the table.
 Group interviews which are held between groups of
participants. They help to uncover any missing requirement
as numerous people are involved.
Surveys
Organization may conduct surveys among various stakeholders
by querying about their expectation and requirements from the
upcoming system.
Questionnaires
A document with pre-defined set of objective questions and
respective options is handed over to all stakeholders to answer,
which are collected and compiled.

A shortcoming of this technique is, if an option for some issue is
not mentioned in the questionnaire, the issue might be left
unattended.
Task analysis
Team of engineers and developers may analyze the operation for
which the new system is required. If the client already has some
software to perform certain operation, it is studied and
requirements of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert
people in the domain can be a great help to analyze general and
specific requirements.
Brainstorming
An informal debate is held among various stakeholders and all
their inputs are recorded for further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail
functionality for user to interpret the features of intended
software product. It helps giving better idea of requirements. If
there is no software installed at client’s end for developer’s
reference and the client is not aware of its own requirements, the
developer creates a prototype based on initially mentioned
requirements. The prototype is shown to the client and the
feedback is noted. The client feedback serves as an input for
requirement gathering.
Observation
Team of experts visit the client’s organization or workplace. They
observe the actual working of the existing installed systems. They
observe the workflow at client’s end and how execution problems
are dealt. The team itself draws some conclusions which aid to
form requirements expected from the software.
Software Requirements Characteristics

Gathering software requirements is the foundation of the entire
software development project. Hence they must be clear, correct
and well-defined.
A complete Software Requirement Specifications must be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source
Software Requirements
We should try to understand what sort of requirements may arise
in the requirement elicitation phase and what kinds of
requirements are expected from the software system.
Broadly software requirements should be categorized in two
categories:
Functional Requirements
Requirements, which are related to functional aspect of software
fall into this category.
They define functions and functionality within and from the
software system.
Examples -
 Search option given to user to search from various invoices.
 User should be able to mail any report to management.
 Users can be divided into groups and groups can be given
separate rights.
 Should comply business rules and administrative functions.

 Software is developed keeping downward compatibility
intact.
Non-Functional Requirements
Requirements, which are not related to functional aspect of
software, fall into this category. They are implicit or expected
characteristics of software, which users make assumption of.
Non-functional requirements include -
 Security
 Logging
 Storage
 Configuration
 Performance
 Cost
 Interoperability
 Flexibility
 Disaster recovery
 Accessibility
Requirements are categorized logically as
 Must Have : Software cannot be said operational without
them.
 Should have : Enhancing the functionality of software.
 Could have : Software can still properly function with these
requirements.
 Wish list : These requirements do not map to any objectives
of software.
While developing software, ‘Must have’ must be implemented,
‘Should have’ is a matter of debate with stakeholders and
negation, whereas ‘could have’ and ‘wish list’ can be kept for
software updates.
User Interface requirements
UI is an important part of any software or hardware or hybrid
system. A software is widely accepted if it is -
 easy to operate

 quick in response
 effectively handling operational errors
 providing simple yet consistent user interface
User acceptance majorly depends upon how user can use the
software. UI is the only way for users to perceive the system. A
well performing software system must also be equipped with
attractive, clear, consistent and responsive user interface.
Otherwise the functionalities of software system can not be used
in convenient way. A system is said be good if it provides means
to use it efficiently. User interface requirements are briefly
mentioned below -
 Content presentation
 Easy Navigation
 Simple interface
 Responsive
 Consistent UI elements
 Feedback mechanism
 Default settings
 Purposeful layout
 Strategical use of color and texture.
 Provide help information
 User centric approach
 Group based view settings.
Software System Analyst
System analyst in an IT organization is a person, who analyzes
the requirement of proposed system and ensures that
requirements are conceived and documented properly & correctly.
Role of an analyst starts during Software Analysis Phase of SDLC.
It is the responsibility of analyst to make sure that the developed
software meets the requirements of the client.
System Analysts have the following responsibilities:
 Analyzing and understanding requirements of intended
software
 Understanding how the project will contribute in the
organization objectives
 Identify sources of requirement
 Validation of requirement

 Develop and implement requirement management plan
 Documentation of business, technical, process and product
requirements
 Coordination with clients to prioritize requirements and
remove and ambiguity
 Finalizing acceptance criteria with client and other
stakeholders
Software Metrics and Measures
Software Measures can be understood as a process of quantifying
and symbolizing various attributes and aspects of software.
Software Metrics provide measures for various aspects of
software process and software product.
Software measures are fundamental requirement of software
engineering. They not only help to control the software
development process but also aid to keep quality of ultimate
product excellent.
According to Tom DeMarco, a (Software Engineer), “You cannot
control what you cannot measure.” By his saying, it is very clear
how important software measures are.
Let us see some software metrics:
 Size Metrics - LOC (Lines of Code), mostly calculated in
thousands of delivered source code lines, denoted as KLOC.
Function Point Count is measure of the functionality
provided by the software. Function Point count defines the
size of functional aspect of software.
 Complexity Metrics - McCabe’s Cyclomatic complexity
quantifies the upper bound of the number of independent
paths in a program, which is perceived as complexity of the
program or its modules. It is represented in terms of graph
theory concepts by using control flow graph.
 Quality Metrics - Defects, their types and causes,
consequence, intensity of severity and their implications
define the quality of product.
The number of defects found in development process and
number of defects reported by the client after the product is
installed or delivered at client-end, define quality of product.

 Process Metrics - In various phases of SDLC, the methods and
tools used, the company standards and the performance of
development are software process metrics.
 Resource Metrics - Effort, time and various resources used,
represents metrics for resource measurement.
Software Design Basics
Software design is a process to transform user requirements into
some suitable form, which helps the programmer in software
coding and implementation.
For assessing user requirements, an SRS (Software Requirement
Specification) document is created whereas for coding and
implementation, there is a need of more specific and detailed
requirements in software terms. The output of this process can
directly be used into implementation in programming languages.
Software design is the first step in SDLC (Software Design Life
Cycle), which moves the concentration from problem domain to
solution domain. It tries to specify how to fulfill the requirements
mentioned in SRS.
Software Design Levels
Software design yields three levels of results:
 Architectural Design - The architectural design is the highest
abstract version of the system. It identifies the software as
a system with many components interacting with each
other. At this level, the designers get the idea of proposed
solution domain.
 High-level Design- The high-level design breaks the ‘single
entity-multiple component’ concept of architectural design
into less-abstracted view of sub-systems and modules and
depicts their interaction with each other. High-level design
focuses on how the system along with all of its components
can be implemented in forms of modules. It recognizes

modular structure of each sub-system and their relation and
interaction among each other.
 Detailed Design- Detailed design deals with the implementation
part of what is seen as a system and its sub-systems in the
previous two designs. It is more detailed towards modules
and their implementations. It defines logical structure of
each module and their interfaces to communicate with other
modules.
Modularization
Modularization is a technique to divide a software system into
multiple discrete and independent modules, which are expected
to be capable of carrying out task(s) independently. These
modules may work as basic constructs for the entire software.
Designers tend to design modules such that they can be executed
and/or compiled separately and independently.
Modular design unintentionally follows the rules of ‘divide and
conquer’ problem-solving strategy this is because there are many
other benefits attached with the modular design of a software.
Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
Concurrency
Back in time, all software are meant to be executed sequentially.
By sequential execution we mean that the coded instruction will
be executed one after another implying only one portion of
program being activated at any given time. Say, a software has
multiple modules, then only one of all the modules can be found
active at any time of execution.
In software design, concurrency is implemented by splitting the
software into multiple independent units of execution, like
modules and executing them in parallel. In other words,

concurrency provides capability to the software to execute more
than one part of code in parallel to each other.
It is necessary for the programmers and designers to recognize
those modules, which can be made parallel execution.
Example
The spell check feature in word processor is a module of
software, which runs along side the word processor itself.
Coupling and Cohesion
When a software program is modularized, its tasks are divided
into several modules based on some characteristics. As we know,
modules are set of instructions put together in order to achieve
some tasks. They are though, considered as single entity but may
refer to each other to work together. There are measures by
which the quality of a design of modules and their interaction
among them can be measured. These measures are called
coupling and cohesion.
Cohesion
Cohesion is a measure that defines the degree of intra-
dependability within elements of a module. The greater the
cohesion, the better is the program design.
There are seven types of cohesion, namely –
 Co-incidental cohesion - It is unplanned and random cohesion,
which might be the result of breaking the program into
smaller modules for the sake of modularization. Because it is
unplanned, it may serve confusion to the programmers and
is generally not-accepted.
 Logical cohesion - When logically categorized elements are put
together into a module, it is called logical cohesion.
 Temporal Cohesion - When elements of module are organized
such that they are processed at a similar point in time, it is
called temporal cohesion.
 Procedural cohesion - When elements of module are grouped
together, which are executed sequentially in order to
perform a task, it is called procedural cohesion.

 Communicational cohesion - When elements of module are
grouped together, which are executed sequentially and work
on same data (information), it is called communicational
cohesion.
 Sequential cohesion - When elements of module are grouped
because the output of one element serves as input to
another and so on, it is called sequential cohesion.
 Functional cohesion - It is considered to be the highest degree
of cohesion, and it is highly expected. Elements of module in
functional cohesion are grouped because they all contribute
to a single well-defined function. It can also be reused.
Coupling
Coupling is a measure that defines the level of inter-dependability
among modules of a program. It tells at what level the modules
interfere and interact with each other. The lower the coupling, the
better the program.
There are five levels of coupling, namely -
 Content coupling - When a module can directly access or
modify or refer to the content of another module, it is called
content level coupling.
 Common coupling- When multiple modules have read and write
access to some global data, it is called common or global
coupling.
 Control coupling- Two modules are called control-coupled if
one of them decides the function of the other module or
changes its flow of execution.
 Stamp coupling- When multiple modules share common data
structure and work on different part of it, it is called stamp
coupling.
 Data coupling- Data coupling is when two modules interact
with each other by means of passing data (as parameter). If
a module passes data structure as parameter, then the
receiving module should use all its components.
Ideally, no coupling is considered to be the best.
Design Verification

The output of software design process is design documentation,
pseudo codes, detailed logic diagrams, process diagrams, and
detailed description of all functional or non-functional
requirements.
The next phase, which is the implementation of software,
depends on all outputs mentioned above.
It is then becomes necessary to verify the output before
proceeding to the next phase. The early any mistake is detected,
the better it is or it might not be detected until testing of the
product. If the outputs of design phase are in formal notation
form, then their associated tools for verification should be used
otherwise a thorough design review can be used for verification
and validation.
By structured verification approach, reviewers can detect defects
that might be caused by overlooking some conditions. A good
design review is important for good software design, accuracy
and quality.
Software Analysis & Design Tools
Software analysis and design includes all activities, which help
the transformation of requirement specification into
implementation. Requirement specifications specify all functional
and non-functional expectations from the software. These
requirement specifications come in the shape of human readable
and understandable documents, to which a computer has nothing
to do.
Software analysis and design is the intermediate stage, which
helps human-readable requirements to be transformed into actual
code.
Let us see few analysis and design tools used by software
designers:
Data Flow Diagram

Data flow diagram is graphical representation of flow of data in an
information system. It is capable of depicting incoming data flow,
outgoing data flow and stored data. The DFD does not mention
anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The
flowchart depicts flow of control in program modules. DFDs depict
flow of data in the system at various levels. DFD does not contain
any control or branch elements.
Types of DFD
Data Flow Diagrams are either Logical or Physical.
 Logical DFD - This type of DFD concentrates on the system
process, and flow of data in the system.For example in a
Banking software system, how data is moved between
different entities.
 Physical DFD - This type of DFD shows how the data flow is
actually implemented in the system. It is more specific and
close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data
using the following set of components -
 Entities - Entities are source and destination of information
data. Entities are represented by a rectangles with their
respective names.
 Process - Activities and action taken on the data are
represented by Circle or Round-edged rectangles.
 Data Storage - There are two variants of data storage - it can
either be represented as a rectangle with absence of both
smaller sides or as an open-sided rectangle with only one
side missing.
 Data Flow - Movement of data is shown by pointed arrows.
Data movement is shown from the base of arrow as its
source towards head of the arrow as destination.

Levels of DFD
 Level 0 - Highest abstraction level DFD is known as Level 0
DFD, which depicts the entire information system as one
diagram concealing all the underlying details. Level 0 DFDs
are also known as context level DFDs.
 Level 1 - The Level 0 DFD is broken down into more specific,
Level 1 DFD. Level 1 DFD depicts basic modules in the
system and flow of data among various modules. Level 1
DFD also mentions basic processes and sources of
information.

 Level 2 - At this level, DFD shows how data flows inside the
modules mentioned in Level 1.
Higher level DFDs can be transformed into more specific
lower level DFDs with deeper level of understanding unless
the desired level of specification is achieved.
Structure Charts
Structure chart is a chart derived from Data Flow Diagram. It
represents the system in more detail than DFD. It breaks down
the entire system into lowest functional modules, describes
functions and sub-functions of each module of the system to a
greater detail than DFD.
Structure chart represents hierarchical structure of modules. At
each layer a specific task is performed.
Here are the symbols used in construction of structure charts -
 Module - It represents process or subroutine or task. A
control module branches to more than one sub-module.
Library Modules are re-usable and invokable from any
module.
 Condition - It is represented by small diamond at the base of
module. It depicts that control module can select any of

sub-routine based on some condition.
 Jump - An arrow is shown pointing inside the module to
depict that the control will jump in the middle of the sub-
module.
 Loop - A curved arrow represents loop in the module. All
sub-modules covered by loop repeat execution of module.
 Data flow - A directed arrow with empty circle at the end
represents data flow.

 Control flow - A directed arrow with filled circle at the end
represents control flow.
HIPO Diagram
HIPO (Hierarchical Input Process Output) diagram is a
combination of two organized method to analyze the system and
provide the means of documentation. HIPO model was developed
by IBM in year 1970.
HIPO diagram represents the hierarchy of modules in the
software system. Analyst uses HIPO diagram in order to obtain
high-level view of system functions. It decomposes functions into
sub-functions in a hierarchical manner. It depicts the functions
performed by system.
HIPO diagrams are good for documentation purpose. Their
graphical representation makes it easier for designers and
managers to get the pictorial idea of the system structure.

In contrast to IPO (Input Process Output) diagram, which depicts
the flow of control and data in a module, HIPO does not provide
any information about data flow or control flow.
Example
Both parts of HIPO diagram, Hierarchical presentation and IPO
Chart are used for structure design of software program as well
as documentation of the same.
Structured English
Most programmers are unaware of the large picture of software
so they only rely on what their managers tell them to do. It is the
responsibility of higher software management to provide accurate
information to the programmers to develop accurate yet fast
code.
Other forms of methods, which use graphs or diagrams, may are
sometimes interpreted differently by different people.
Hence, analysts and designers of the software come up with tools
such as Structured English. It is nothing but the description of
what is required to code and how to code it. Structured English
helps the programmer to write error-free code.
Other form of methods, which use graphs or diagrams, may are
sometimes interpreted differently by different people. Here, both
Structured English and Pseudo-Code tries to mitigate that
understanding gap.
Structured English is the It uses plain English words in structured
programming paradigm. It is not the ultimate code but a kind of

description what is required to code and how to code it. The
following are some tokens of structured programming.
IF-THEN-ELSE,
DO-WHILE-UNTIL
Analyst uses the same variable and data name, which are stored
in Data Dictionary, making it much simpler to write and
understand the code.
Example
We take the same example of Customer Authentication in the
online shopping environment. This procedure to authenticate
customer can be written in Structured English as:
Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
PRINT error message
Call procedure NEW_CUSTOMER_REQUEST()
ENDIF
The code written in Structured English is more like day-to-day
spoken English. It can not be implemented directly as a code of
software. Structured English is independent of programming
language.
Pseudo-Code
Pseudo code is written more close to programming language. It
may be considered as augmented programming language, full of
comments and descriptions.
Pseudo code avoids variable declaration but they are written
using some actual programming language’s constructs, like C,
Fortran, Pascal etc.
Pseudo code contains more programming details than Structured
English. It provides a method to perform the task, as if a
computer is executing the code.

Example
Program to print Fibonacci up to n numbers.
void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
if a greater than b
{
Increase b by a;
Print b;
}
else if b greater than a
{
increase a by b;
print a;
}
}
Decision Tables
A Decision table represents conditions and the respective actions
to be taken to address them, in a structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group
similar information into a single table and then by combining
tables it delivers easy and convenient decision-making.
Creating Decision Table
To create the decision table, the developer must follow basic four
steps:
 Identify all possible conditions to be addressed
 Determine actions for all identified conditions
 Create Maximum possible rules
 Define action for each rule
Decision Tables should be verified by end-users and can lately be
simplified by eliminating duplicate rules and actions.

Example
Let us take a simple example of day-to-day problem with our
Internet connectivity. We begin by identifying all problems that
can arise while starting the internet and their respective possible
solutions.
We list all possible problems under column conditions and the
prospective actions under column Actions.
Conditions/Actions Rules
Conditions
Shows Connected N N N N Y Y Y Y
Ping is Working N N Y Y N N Y Y
Opens Website Y N Y N Y N Y N
Actions
Check network cable X
Check internet router X X X X
Restart Web Browser X
Contact Service provider X X X X X X
Do no action
Table : Decision Table – In-house Internet Troubleshooting
Entity-Relationship Model
Entity-Relationship model is a type of database model based on
the notion of real world entities and relationship among them. We
can map real world scenario onto ER database model. ER Model
creates a set of entities with their attributes, a set of constraints
and relation among them.
ER Model is best used for the conceptual design of database. ER
Model can be represented as follows :
 Entity - An entity in ER Model is a real world being, which
has some properties called attributes. Every attribute is
defined by its corresponding set of values, called domain.

For example, Consider a school database. Here, a student is
an entity. Student has various attributes like name, id, age
and class etc.
 Relationship - The logical association among entities is
called relationship. Relationships are mapped with entities in
various ways. Mapping cardinalities define the number of
associations between two entities.
Mapping cardinalities:
o one to one
o one to many
o many to one
o many to many
Data Dictionary
Data dictionary is the centralized collection of information about
data. It stores meaning and origin of data, its relationship with
other data, data format for usage etc. Data dictionary has
rigorous definitions of all names in order to facilitate user and
software designers.
Data dictionary is often referenced as meta-data (data about
data) repository. It is created along with DFD (Data Flow
Diagram) model of software program and is expected to be
updated whenever DFD is changed or updated.
Requirement of Data Dictionary
The data is referenced via data dictionary while designing and
implementing software. Data dictionary removes any chances of
ambiguity. It helps keeping work of programmers and designers
synchronized while using same object reference everywhere in
the program.
Data dictionary provides a way of documentation for the complete
database system in one place. Validation of DFD is carried out
using data dictionary.
Contents
Data dictionary should contain information about the following
 Data Flow

 Data Structure
 Data Elements
 Data Stores
 Data Processing
Data Flow is described by means of DFDs as studied earlier and
represented in algebraic form as described.
= Composed of
{} Repetition
() Optional
+ And
[ / ] Or
Example
Address = House No + (Street / Area) + City + State
Course ID = Course Number + Course Name + Course Level +
Course Grades
Data Elements
Data elements consist of Name and descriptions of Data and
Control Items, Internal or External data stores etc. with the
following details:
 Primary Name
 Secondary Name (Alias)
 Use-case (How and where to use)
 Content Description (Notation etc. )
 Supplementary Information (preset values, constraints etc.)
Data Store
It stores the information from where the data enters into the
system and exists out of the system. The Data Store may include
-
 Files
o Internal to software.
o External to software but on the same machine.
o External to software and system, located on different
machine.

 Tables
o Naming convention
o Indexing property
Data Processing
There are two types of Data Processing:
 Logical: As user sees it
 Physical: As software sees it
END
LESSON 4

LESSON 4 SOFTWARE REQUIREMENT (3).docx.

More Related Content

Similar to LESSON 4 SOFTWARE REQUIREMENT (3).docx. (20)

Recently uploaded (20)

LESSON 4 SOFTWARE REQUIREMENT (3).docx.