1

LEARNING MODULE INFORMATION

i. Course Code ADET201
II. Course Title Application Development and Emerging Technologies
III. Module Number 2
IV. Module Title Understanding the Requirements Gathering in Software
Development
V. Overview of the Module This module will allow the reader to understand the importance
of requirements gathering in software development. With this
module, students would be able to determine kinds of
requirements specifications in software development and
demonstrate data gathering techniques and its guidelines. In the
end, readers would be able to present requirements gathering
framework as baseline for software development.
VI. Module Outcomes
As for the outcome of the module, you are about to
• Learn on how to interpret a data
• Learn different ways on how to manage a data.
• Describe the requirements analysis process and
techniques
• Use the correct usability testing method for a software
development
• Distinguish a proper deployment plan based on real-life
scenarios.
 1
2

LESSON1. REQUIREMENTS GATHERING

Lesson Objectives:
1. Understand the principle of requirements gathering and specifications
2. How and what requirements to gather.
3. Define the techniques in requirements gathering
4. Identify the importance of requirements gathering

ADET 201
What are requirements and its specifications?

Application
• A requirementDevelopment and
is a statement about an intended product that specifies what it should do or
how it should perform.
Emerging Technologies
• Goal: To make as specific, unambiguous, and clear as possible.
• Functional Specifications: What the system should do
• Non-Functional Specifications: what constraints there are on the system its development -
(For example that a work processor runs on different platforms)
What requirements should be gathered?
• Functional: What the product should do.
• Data requirements: Capture the type, volatility, size/amount, persistence, accuracy and
the amounts of the required data.
• Environmental requirements:
• a) context of use
• b) Social environment (eg. Collaboration and coordination)
• c) how good is user support likely to be d) what technologies will it run on
• User Requirements: Capture the characteristics of the intended user group.
• Usability Requirement: Usability goals associated measures for a particular product.

Data Gathering Techniques

• Questionnaires: Series of questions designed to elicit specific information
from us.
 3

• The questions may require different kinds of answers: some require a

simple Yes/No, others ask us to choose from a set of pre-supplied
answers.

• Interviews: Interviews involve asking someone a set of questions.

• Often interviews are face-to-face
• Interviews:
• Forum for talking to people
• Structured, unstructured or semi-structured
• Props, e.g. sample scenarios of use, prototypes, can be used in
interviews
• Good for exploring issues
• But are time consuming and may be infeasible to visit everyone
• Focus groups and workshops

• Interviews tend to be one on one, and elicit only one person’s perspective.
It can be very revealing to get a group of stakeholders together to discuss
issues and requirements.
• Naturalistic Observation
• It can be very difficult for humans to explain what they do or to even
describe accurately how they achieve a task.
• Spend time with stakeholders in their day-to-day tasks, observing work as
it happens

• Gain insights into stakeholders’ tasks

• Good for understanding the nature and context of the tasks
• But, it requires time and commitment from a member of the design
team, and it can result in a huge amount of data
• Ethnography is one form : entire class devoted to this.
• Studying documentation:
 4

• Procedures and rules are often written down in a manual and these are a
good source of data about the steps involved in an activity and any
regulations governing a task.

Requirements Gathering

Requirements
Gathering is a
fundamental part of
any software
development
project. It is the
process of
generating a list of
requirements
(functional, system,
technical, etc.) from
all the stakeholders
(customers, users, vendors, IT staff) that will be used as the basis for the
formal definition of what the project is.

The importance of Requirements Gathering

• The problem with the business customers is that the latter tends to expect software teams
to deliver a solution based on unspoken, incomplete or unknown requirements
• The problem with software teams is that they tend to assume that business customers will
communicate exactly what they want as succinctly as possible.
• Therefore, the requirements need to be formally captured in one document that can be
used as a reference during software development.
• Good gathering, processing and management of requirements is important as it sets clear
targets for everyone to aim for. It can be a lot of hard work, but it need not be a daunting
task if you can keep some key points in mind.

• Remember it’s all about the user. Consider always the user inputs. Find out how actual
users complete their tasks and exactly how they get things done – and how they want to
 5

get things done. What do they need to do? How efficiently can we make that happen?
And what sorts of flexibility might be required?

The User comes first

• The requirements should detail
how a user would
accomplish what they want
using the software being
developed. Awareness of
any technological
preferences and existing
system integration is also
fundamental, as it can have
a huge impact on the
development path and
subsequently impact on
performance and user task
efficiency.
 6

LESSON2. DATA GATHERING GUIDELINES

Lesson Objectives:
1. Understand the principle of data gathering guidelines
2. Understand the requirements gathering framework
3. Define the techniques in requirements gathering
4. Identify the requirements analysis techniques

Data Gathering Guidelines

 Focus on identifying the stakeholders
 Involve all the stakeholder groups
 Need more than in person from stakeholder group(s)
 Use a combination of data gathering techniques
For example: use observation to understand the context, interviews to target specific user
groups, questionnaires to reach a wider population, and focus groups to build a consensus view
 Support the data-gathering sessions with suitable props, such as task descriptions and
prototypes if available.
 Run a pilot session if possible, to ensure that your data-gathering session is likely to go
as planned
In an ideal world, you would understand what you are looking for and what kinds of analysis you
want to do, and design the data-capture exercise to collect the data you want. However, data
gathering is expensive and often a tightly constrained resource
 7

Figure 1 Requirements Gathering Framework How

to interpret the data?
• The next question would be – how to interpret the data?
• What structure and record description of requirement will be used?
• When to start the interpretation?
• We can use analysis models in object-oriented systems by using a
• Use cases diagrams:
consists of actors and user cases, discussed later
• Class diagrams What is the Requirements Analysis?
• Requirements Analysis is the process of defining the expectations of the users for an
application that is to be built or modified. Requirements analysis 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. High-quality requirements are documented, actionable, measurable,
testable, traceable, helps to identify business opportunities, and are defined to a facilitate
system design
 8

Requirements Analysis Techniques

• 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.
• 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.

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
 9

represent the flow of information through a process or a system. It also includes

the data inputs and outputs, data stores, and the various subprocess 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.

• Role Activity Diagrams (RAD)

• Role-activity
diagram (RAD) is
a role-
oriented process
model that
represents
roleactivity
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.

• Gantt Charts
• Gant charts used in
project planning as
they provide a visual
representation of
tasks that are
scheduled along
with the timelines.
 10

The Gant 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.

• 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.

M2:L1-L2 - Enrichment Activity Name: ________________________________

Score: _______________ Year and Section: ______________________ Professor:
____________

1. Following the chosen company from previous activity, choose your own requirements
analysis techniques and present it to the class.
 11

Module #2: Assessment Name: ________________________________ Score:

_______________ Year and Section: ______________________ Professor:
____________

1. Why do we need to identify and establish the requirements in software development?

2. What are kinds of specifications are needed on these requirement gathering? Give
example.
3. What kind of requirements should be gathered?
4. Differentiate each data gathering techniques.
5. How are we going to interpret the gathered data?

LEARNING MODULE INFORMATION

ii. Course Code ADET201

II. Course Title Application Development and Emerging Technologies
III. Module Number 3
IV. Module Title Research design and testing
 12

V. Overview of the Module This module will allow the reader to understand the importance
of research design and testing along with its components and
guidelines
VI. Module Outcomes
As for the outcome of the module, you are about to
• Learn on how to interpret a data
• Learn different ways on how to manage a data.
• Describe the requirements analysis process and
techniques
• Use the correct usability testing method for a software
development
• Distinguish a proper deployment plan based on real-life
scenarios.

LESSON 1. SOFTWARE DESIGN BASICS

Lesson Objectives:
1. Understand the principle of software design
2. Components of software design
3. Importance of software design
 13

Getting Started:

• Software design is a process to transform

user requirements into some suitable form,
which helps the programmer in software
coding and implementation.

• The design phase of software development

deals with transforming the customer
requirements.

• Software design is the process of

conceptualizing the software requirements
into software implementation.

• The design process establishes a plan that takes the user requirements as challenges and
works to identify optimum solutions. The plan should determine the best possible design
for implementing the intended solution.

Components of Software Design Process

• Software requirements specification. This document describes the expected behavior of
the system in the form of functional and non-functional requirements. These requirements
should be clear, actionable, measurable, and traceable to business requirements.
Requirements should also define how the software should interact with humans,
hardware, and other systems.

• High-level design. The high-level design breaks the system’s architectural design into a
less-abstracted view of sub-systems and modules and depicts their interaction with each
other. This high-level design perspective focuses on how the system, along with all its
components, implements in the form of modules. It recognizes the modular structure of
each sub-system and their interaction among one another.
• Detailed design. Detailed design involves the implementation of what is visible as a
system and its sub-systems in a high-level design. This activity is more detailed towards
modules and their implementations. It defines a logical structure of each module and their
interfaces to communicate with other modules.
 14

Why software design is important?

• Software design can be done with several different ways.
• It can be done utilizing some software using some modeling language, such as UML, it
can be written text and images or it can even be a drawing on a whiteboard.
• Important here is that the design can be saved and revisited during the development of the
software — The design will need some refining so if you don’t want to always draw the
design to the whiteboard from scratch, it might be good idea to stay with digital ways of
doing the design.

• This and how it’s done of course depends on project needs. Small projects can easily be
just drawn or written on a single paper while bigger projects usually tend to change a lot
during their lifetime affecting also the software design.

Modularity
• Split your software into smaller pieces with maybe maximum of 5–10 interfaces. These
interface “groups” are called software components. Main idea of the software component
is to provide a single purpose for the software that is being developed.

• When you have a modular software, it’s easy to move or even remove things if needed
and even share the design work between multiple developers per software component.
Having modularity also increases maintainability by making it easier to find necessary
information to edit from the right component. It can also be basis for your source code
name spacing or structure as well as isolating the test cases per component.

Maintainability

• With good software design it’s easier to maintain the software. You can spot straight away
from the design how much a bug fix or introduction of a new feature will change the
existing code base.
• As good design should also show interactions between software components and their
interfaces, it will also reveal possible effects of changing code in another component that
depends on the one needing the change.
• Working especially with old code bases that do not have any software design can be very
painful and cause many unexpected bugs.
 15

Performance

• Good software design can be used to easily pinpoint performance bottlenecks in your
software — especially if the design is done to the level of that granularity.
• This means the design should tell how your system works internally and how it uses
resources such as threads, database connections and other things that might make a hit to
the performance.

• Sometimes it’s very easy to debug or use some logging functionality to find the
bottlenecks from the source code but sometimes the design can tell it by a single image.

Portability
• By including dependencies to other software modules, such as 3rd party libraries, in to
your design makes the software much easier to port into another environment.
• Having these documented in a single place makes it super easy to discover what needs to
be changed if using another environment or if it can be done at all.
Usability
• Generating a design document for your customers from the software design is a good
idea. It provides them an overview how the software they are about to take into use
works.
• You might need to consider if you want to publish only your public interfaces and leave
your internal design out of the document as good design makes it possible to very easily
write the software from scratch.
Trackability
 16

Usually projects have requirements coming from either a customer or from an internal
source. Good design also tracks the requirements and proves on the design level that all
that is required from a piece of software is actually there and that it’s understood
correctly.
• This brings even more value to the provided design document as the customers can
actually see what of their requirements are done and where.
• To integrate this with source code, some kind of linking between the design, requirements
and the source code is more than advised. Deployment
• Design should also provide information what the software deliverables are and where
should they be placed in the deployment.
• This information is very important for your customers as well as integration as they need
to know where to look for your library/executable/whatever your software is about.
• It makes it easier to spot right away if the latest delivery is missing some crucial parts of
the software by simply taking a look at your design.

LESSON2. SOFTWARE DESIGN LEVELS AND TAXONOMY OF ARCHITECTURAL

STYLES

Lesson Objectives:
1. Understand the software design levels
2. Understand the taxonomy of architectural styles
 17

Interface or High-level Design

• Interface design is the specification of the interaction between a system and its
environment.
• This phase proceeds at a high level of abstraction with respect to the inner workings of
the system i.e, during interface design, the internal of the systems are completely ignored
and the system is treated as a black box.
Attention is focused on the dialogue between the target system and the users, devices,
and other systems with which it interacts.
• The design problem statement produced during the problem analysis step should identify
the people, other systems, and devices which are collectively called agents.

• 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.
 18

Interface Design
• Interface design should include the following details:

• Precise description of events in the environment, or messages from agents to which the
system must respond.
• Precise description of the events or messages that the system must produce.

• Specification on the data, and the formats of the data coming into and going out of the
system.
• Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs. Architectural Design
• Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between
them. In architectural design, the overall structure of the system is chosen, but the internal
details of major components are ignored.
• The architectural design adds important details ignored during the interface design.
Design of the internals of the major components is ignored until the last phase of the
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.
• The software needs the architectural design to represents the design of software. IEEE
defines architectural design as “the process of defining a collection of hardware and
software components and their interfaces to establish the framework for the development
of a computer system.” The software that is built for computer-based systems can exhibit
one of these many architectural styles.
• The use of architectural styles is to establish a structure for all the components of the
system.
• Each style will describe a system category that consists of :

• A set of components (eg: a database, computational modules) that will perform a function
required by the system.
 19

• The set of connectors will help in coordination, communication, and cooperation between
the components.
• Conditions that how components can be integrated to form the system.

• Semantic models that help the designer to understand the overall properties of the system.

Taxonomy of Architectural styles • Data centered architectures

• A data store will reside at the
center of this architecture and
is accessed frequently by the
other components that update,
add, delete or modify the data
present within the store.

Data flow architectures

This kind of architecture is used
when input data to be transformed
into output data through a series of
computational manipulative
components.

• The figure represents pipe-and-

filter architecture since it uses both
pipe and filter and it has a set of
components called filters connected
by pipes.
 20

• Pipes are used to transmit data from one component to the next.
• Each filter will work independently and is designed to take data input of a certain form
and produces data output to the next filter of a specified form. The filters don’t require
any knowledge of the working of neighboring filters.
• If the data flow degenerates into a single line of transforms, then it is termed as batch
sequential. This structure accepts the batch of data and then applies a series of sequential
components to transform it.

Layered architecture
• A number of different layers are
defined with each
layer performing a well-defined
set of operations. Each layer
will do some operations that
becomes closer to machine
instruction set progressively.

• At the outer layer, components

will receive the user interface
operations and at the inner
layers, components will perform
the operating system
interfacing(communication and coordination with OS)

• Intermediate layers to utility services and application software functions.

Architectural Design
• Issues in architectural
design includes:
• Gross decomposition of the
systems into
major components.
 21

• Allocation of functional responsibilities to components.

• Component Interfaces

• Component scaling and performance properties, resource consumption properties,

reliability properties, and so forth.
• Communication and interaction between components.

Detailed Design
• Detailed design is closely related to architecture and construction; therefore successful
designers (during detailed design) are required to have or acquire full understanding of
the system’s requirements and architecture.
• They must also be proficient in particular design strategies (e.g., object-oriented),
programming languages, and methods and processes for software quality control.
• Just as architecture provides the bridge between requirements and design, detailed design
provides the bridge between design and code.
 22

The major tasks identified for carrying out the detailed design activity include:
1. Understanding the architecture and requirements
2. Creating detailed designs
3. Evaluating detailed designs
4. Documenting software design
5. Monitoring and controlling implementation

LESSON3. SOFTWARE TESTING

Lesson Objectives:
1. Understand what is software testing
2. Understand the taxonomy of architectural styles
 23

What is Software Testing?

Software testing is a process of executing a program or application with the intent of
finding the software bugs.
It can also be stated as the process of validating and verifying that a software program or
application or product:

◦ Meets the business and technical requirements that guided it’s design and
development
◦ Works as expected
◦ Can be implemented with the same characteristic.

Let’s break down the basic definition of Software testing into the following parts:
1. Process: Testing is a process rather than a single activity.
2. All Life Cycle Activities: Testing is a process that’s take place throughout the Software
Development Life Cycle (SDLC).
◦ The process of designing tests early in the life cycle can help to prevent
defects from being introduced in the code. Sometimes it’s referred as
“verifying the test basis via the test design”.
◦ The test basis includes documents such as the requirements and design
specifications.
3. Static Testing: It can test and find defects without executing code. Static Testing is done
during verification process. This testing includes reviewing of the documents (including
source code) and static analysis. This is useful and cost effective way of testing.
4. Dynamic Testing: In dynamic testing the software code is executed to demonstrate the
result of running tests. It’s done during validation process.

5. Planning: We need to plan as what we want to do. We control the test activities, we
report on testing progress and the status of the software under test.
6. Preparation: We need to choose what testing we will do, by selecting test conditions and
designing test cases.
7. Evaluation: During evaluation we must check the results and evaluate the software under
test and the completion criteria, which helps us to decide whether we have finished
testing and whether the software product has passed the tests.
 24

8. Software products and related work products: Along with the testing of code the testing
of requirement and design specifications and also the related documents like operation,
user and training material is equally important.

Why is Software Testing needed?

❑ At a high level, software testing is needed in order to detect the bugs in the
software and to test if the software meets the customers requirements.
❑ This helps the development team to fix the bugs and deliver a good quality
product.
❑ There are several points in the software development process where
human error can lead to software that does not meet customers
requirements. Some of them are listed below.
❑ Customer / person providing the requirements on behalf of the customer
organization may not know what exactly is required or may forget to
provide some details, which may lead to missing features
❑ The person who is gathering the requirements may misinterpret or
completely miss a requirement when document them
❑ During the design phase, if there are issues in design, it may lead to bugs
in future
❑ Bugs may be introduced during development phase during to human error,
lack of expertise etc
❑ Testers can miss bugs during testing phase due to human error, lack of
time, insufficient experience etc
❑ Customers may not have the bandwidth to test every feature of the product
and may release the product to their end users which can lead to end users
finding errors in the application
❑ An organizations business and reputation depends on the quality of its
products and in some cases even the revenue may be dependent on the
sales of software product.
❑ Users may prefer to buy a competing product over a product that has poor
quality and this can result in loss of revenue for the organization. In
today’s world, quality is one of the top priorities for any organization.
 25

Importance of Software Testing in Software Engineering

Software testing is an important part of software development. If software testing is not

performed properly, applications can have errors which may lead to rework, costly failure
or worse, loss of life.
Software testing is a process, to evaluate the functionality of a software application with
an intent to find whether the developed software met the specified requirements or not
and to identify the defects to ensure that the product is defect free in order to produce the
quality product.
Testing Methods
Static Testing: It is also known as Verification in Software Testing. Verification is a static
method of checking documents and files.
Verification is the process, to ensure that whether we are building the product right i.e., to
verify the requirements which we have and to verify whether we are developing the
product accordingly or not.
Activities involved here are Inspections, Reviews, Walkthroughs

Dynamic Testing: It is also known as Validation in Software Testing.

Validation is a dynamic process of testing the real product. Validation is the process,
whether we are building the right product i.e., to validate the product which we have
developed is right or not.

Activities involved in this is Testing the software application

Testing Approaches
White Box Testing: It is also called as Glass Box, Clear Box, Structural Testing.
White Box Testing is based on applications internal code structure. In white-box testing, an
internal perspective of the system, as well as programming skills, are used to design test
cases.
This testing is usually done at the unit level.
Black Box Testing: It is also called as Behavioral/Specification-Based/Input-Output
Testing.
 26

Black Box Testing is a software testing method in which testers evaluate the functionality
of the software under test without looking at the internal code structure.
Grey Box Testing: Grey box is the combination of both White Box and Black Box
Testing.
The tester who works on this type of testing needs to have access to design documents.
This helps to create better test cases in this process.

Testing Levels
Unit Testing: Unit Testing is done to check whether the individual modules of the source
code are working properly. i.e. testing each and every unit of the application separately
by the developer in the developer’s environment.
Integration Testing: Integration Testing is the process of testing the connectivity or data
transfer between a couple of unit tested modules.
It is subdivided into Top-Down Approach, Bottom-Up Approach and Sandwich Approach
(Combination of Top Down and Bottom Up).
System Testing (end to end testing): It’s a black box testing.
Testing the fully integrated application this is also called as end to end scenario testing.
To ensure that the software works in all intended target systems. Verify thorough testing
of every input in the application to check for desired outputs.
Testing of the users experiences with the application
Acceptance Testing: To obtain customer sign-off so that software can be delivered and
payments received.
Testing Artifacts
Some of the test deliverables are as follows:
• Test plan
• Traceability matrix

• Test case

• Test script
 27

• Test suite

• Test data or Test Fixture

• Test harness Principles

of Software Testing

▪ Testing shows presence of defects

▪ Exhaustive testing is impossible
▪ Early testing
▪ Defect clustering
▪ Pesticide paradox
▪ Testing is context dependent

▪ Absence of error – fallacy

M3:L1-L3 - Enrichment Activity Name: ________________________________

Score: _______________ Year and Section: ______________________ Professor:
____________

1. Make a research that apply the SDLC process. Include all process identified on this
module. User fishbone in defining the gaps, techniques on data gathering should
apply only based on the current circumstances that we have.
i. Proposed topic
ii. Rationale
iii. Research Questions
iv. Significance of the Study

Module #3: Assessment Name: ________________________________ Score:

_______________ Year and Section: ______________________ Professor:
____________
 28

1. Explain in your own words, software design give example on how you can make a
good system design.
2. What is the importance of doing software testing?
3. What are the different testing styles that you can use in your system? Which do you
this is more feasible in your project?

SUGGESTED LINKS

Link 1 https://www.youtube.com/watch?v=SS3k1X6r7s0

Link 2 https://www.youtube.com/watch?v=I1RIhmf0IlI

Link 3 https://www.youtube.com/watch?v=bNDlg1h-za0

REFERENCES/ATTRIBUTIONS:
• Chapter 7 from J. Preece, Y. Rogers, H. Sharp: Interaction Design: Beyond Human-
Computer Interaction.
• “Applying Requirements Management with Use Cases,” Roger Oberg (IBM Rational
Software)
• Constance L. Heitmeyer. “Software cost reduction”. In John J. Marciniak, editor,
Encyclopedia of Software Engineering. John Waley & Sons, 2nd edition, 2002
• Alistai Sutcliffe, "Scenario-based requirements analysis." Requirements Engineering
Journal, London, UK, 1998.
• Satzinger, John W., Jackson, Robert B., Burd, Stephen D., (2004), Systems analysis and
design in a changing world (3rd ed.), Course Technology ß Hoffer, Jeffrey A., George, Joey
F., Joseph S., (2005), Modern systems analysis and design (3rd ed.), Upper Saddle River,
N.J. : Prentice Hall
 29

• http://www-306.ibm.com/software/awdtools/reqpro/
• http://cs.sru.edu/~mullins/cpsc100book/module02_introduction/
module0203_introduction.html

• http://cs.sru.edu/~mullins/cpsc100book/module02_introduction/
module0203_introduction.html

• https://www.techopedia.com/definition/4356/software

• https://www.bbconsult.co.uk/blog/requirements-gathering

• https://www.tutorialspoint.com/software_engineering/software_engineering_overview