INTRODUCTION TO SOFTWARE ENGINEERING

EC2: Requirement Engineering

INF1512

Course Lecturer:
Dr. KIMBI Xaveria
Recall
●
What is Software Engineering?
●
What are the phases involve in Software Development Life cycle
(SDLC)
●
List and Explain two SDLC methodologies
 Our Society Highly Depends on Software
●
Software development has been the fastest-
growing technology in human history. Despite
the advancement, there is not single software
that can be used in all sectors.
●
Beside Operating Systems and Social
Networking Software:
●
We have Smart/Intelligent Homes
●
Disaster predicting Software
●
Monitoring Software
●
Diagnostics Software
●

Real World Focus All Sectors

(Digitalized World) have gone digitalized
Causes of software failure
●
A study that was conducted found out that success is
“improbable” in 78% of technology projects. I.e full
success is not easily achieved
●
Many of the systems that aren’t totally abandoned but are
delivered to the users significantly late, cost far more than
expected, and have fewer features (few functional
requirements) than originally planned.
How can a System Analyst avoid requirement errors
 Requirements errors are very difficult to manage:
Question: How can you develop a software deliver value to the business

Problem Domain Solution Domain

System Analyst
(Domain Analysis) (Solution Analysis)
 Who is a System Analyst?
●
The key person in the SDLC is the systems analyst, who analyzes the business situation,
identifies opportunities for improvements, and designs an information system to implement
the improvements.
●
A System Analyst is a person who studies an existing solution in order to provide solution to the
identified problems
●
It is important to remember that the primary objective of the systems analyst is not to create a
wonderful system. The primary goal is to create value for the organization, which for most
companies means increasing profits. (Government agencies and not-for-profit organizations measure
value differently.)
●
Many failed systems were abandoned because the analysts tried to build a wonderful system without
clearly understanding how the system would support the organization’s goals, improve business
processes, and integrate with other information systems to provide value.
●
The systems analyst will have significant training and experience in system analysis and
System design and in programming
 Why is requirement negotiation
necessary for system development ?
●
To bridge the gap between the solution domain and
solution domain
●
To avoid ambiguities in requirements
●

●
Course Objective and Development Attitude
Course Description:
To provide a sound technical exposure to the concepts, principles, techniques, and
best practices in software Engineering.

Course Objectives:
Upon successful completion of this course, the students will be able to:

Understand concepts, principles and techniques that will help them development
a requirement specification document in a professional way

Choose the appropriate Requirement Elicitation techniques in Agile Development
methodologies for a specific scenario.

Translate functional requirements into an actual Working Software in Java
●
Build a Software Communication platform using Twilio as a cloud-based API
Development attitude: A collaborative development approach in groups of 5
 Evaluation Method
A three-phased evaluation method will be adopted:

CC evaluation: EC1 +EC2 = CC

TP evaluation of one real live project:

General Examination:

CC = 20% TP = 30% EE = 50%
 Course Content
●
Introduction to Requirement Engineering and Planing
- Software Requirement Specification
●
Requirement Elicitation Techniques
●
An efficient method for Software Requirement Specification (SRS) Document
●
Translating Software Requirement Specification into Actual Program – AN
Introduction to Java Programming using NetBeans IDE
Today’s Lecture Goals
●
To appreciate software development advancement: In the beginning of Software Development Versus Today’s Software
Development

●
Be able explain and categorized Software Requirement Specification
●
Understand the three steps involve in System

●
For a given scenario, been able to extra the functional and nonfunctional requirements for the system to be developed

●
Describe technical, economic, and organizational feasibility assessment.

●
Be able to perform a feasibility analysis for a given project.

●
Feasibility Analysis:
Technical Feasibility
Economic Feasibility
Organizational Feasibility
●
Why will project owners wish to incorporate
Requirement Specification in their projects?
●
What critical role does a System Analyst play in
interpreting and translating business and user
requirements into essential functional requirements
for the new system?
Introduction to Requirement Engineering
and Planing
●
Requirements analysis and planning is the first stage in the Software
Engineering process and it forms the building blocks of a software system.
●
Software requirements describe the outlook of a software application by specifying
the software’s main objectives and goals.
●
Requirements define the framework for a software development process, by
specifying what the system must do, how it must behave, the properties it must
exhibit, the qualities it must possess, and the constraints that the system must satisfy.
●
Requirement Engineering is considered as one of the most critical phases of a
software development life cycle as unclear, ambiguous, and low quality
requirements specification can lead to the failure of a product or deployment of
a completely undesired product and even raise development costs
 Software Requirement Specification
●
Before we start to develop our software, it becomes quite essential for
us to understand and document the exact requirement of the customer.
Experienced members of the development team carry out this job. They
are called as system analysts.
●
The analyst starts requirements gathering and analysis activity by
collecting all information from the customer which could be used to
develop the requirements of the system. He then analyzes the collected
information to obtain a clear and thorough understanding of the product
to be developed, with a view to remove all ambiguities and
inconsistencies from the initial customer perception of the problem.
●
During the requirement specification phase, the project team
investigates any current system(s), identifies improvement
opportunities, and develops a concept for the new system.
 How to investigate the current system
●
The following basic questions pertaining to the project should be clearly understood by the
analyst in order to obtain a good grasp of the problem:
●
What is the problem?
●
Why is it important to solve the problem?
●
What are the possible solutions to the problem?
●
What exactly are the data input to the system and what exactly are the data output by the
system?
●
What are the likely complexities that might arise while solving the problem?
●
If there are external software or hardware with which the developed software has to interface,
then what exactly would the data interchange formats with the external system be?
●
Who are the users of the system?
●
After the analyst has understood the exact customer requirements,
he proceeds to identify and resolve the various requirements
problems. The most important requirements problems that the
analyst has to identify and eliminate are the problems of
anomalies, inconsistencies, and incompleteness in a given set
requirements. (Reasons for Software Requirement Gathering )
●
When the analyst detects any inconsistencies, anomalies or
incompleteness in the gathered requirements, he resolves them by
carrying out further discussions with the end users and the
customers.
 Steps in System Analysis
●
This phase has three steps:
(1) An analysis strategy is developed to guide the project team’s
efforts. Such a strategy usually includes a study of the current
system (called the as-is system) and its problems, and envisioning
ways to design a new system (called the to-be system).
(2) The next step is requirements gathering (e.g., through
interviews, group workshops, written documents or questionnaires).
(3)The production of specification document called Software
Requirement Specification (SRS) document.
Functional and Nonfunctional Requirements

●
Using any project of your choice, define the following terms as used in
Software Engineering:
●
Functional Requirements
●
Non-Functional Requirements
Functional Requirements

●
The functional requirements part discusses the functionalities required for the
system.
●
Therefore, functional requirements define what a system is supposed to do .
Nonfunctional requirements

●
A non-functional requirement (NFR) is a requirement that specifies criteria that
can be used to judge the operation of a system, rather than specific behaviors
and the overall system constraint.
●
Nonfunctional requirements deal with the characteristics of the system which
cannot be expressed as functions - such as the maintainability of the system,
portability of the system, usability of the system, interoperability of the system,
scalability of the system, learnability of the system, memorability of the
system, efficiency of the system, effectiveness of the system, System
performance/response time, etc.
●
Therefore, non-functional requirements define how a system is supposed to
be.
 TD1/Exercise 1
(1)With referenced to a named project, explain the following concepts as used in Software
Engineering:
- Functional Requirements
- Non Functional Requirements
(2) Assuming you have been hired by University of Yaounde I, to design and implement a system for
the management of student result.
(a) List two software development methodology and hence write down the code for processing
student results.
(b) List five functional requirements and five non-functional requirements for the above system.

(3) With the aid of a simple diagram, explain the role of System Analyst in the Software development
life cycle
 Identifying functional requirements from a problem description
From Users’ View Point
●
There can be many types of users of a system and their requirements from the system may be very
different. So, it is often useful to identify the different types of users who might use the system and
then try to identify the requirements from each user’s perspective.

●
The high-level functional requirements often need to be identified either from an informal problem
description document or from a conceptual understanding of the problem. Each high-level
requirement characterizes a way of system usage by some user to perform some meaningful piece
of work.

●
The system is considered to perform a set of high-level functions {f}. The functional view of the
system is shown in fig. 1. Each function fi of the system can be considered as a transformation of a
set of input data to the corresponding set of output data ).
●
The user can get some meaningful piece of work done using a high-level function.
Diagrammatic View of a System Performing a set of Functions
Example 1: Library Management System

Consider the case of the library system, where –

●
F1: Search Book function
●
Input: An author’s name
●
Output: Details of the author’s books and the location of these
books in the library

●
So the function Search Book (F1) takes the author's name and
transforms it into book details.
Example 1: Automated Teller Machine (ATM) System

●
F1: Withdraw Cash function
F1.1: select account type
Input: user option - prompt to enter amount
Output: get required amount

●
F2: get required amount
F2.1: Amount to be withdrawn must be between 5,000frs to 250,000frs
Input: user option - prompt to enter amount
Output: The requested cash and printed transaction statement.
TD/Exercise 1
 TD/Exercise 2
A record keeping system may require a user to enter her full name, the name of her university, the name of the name of
her department, her Specialty (Domain), gender and date of birth in a database. Identify the high-level functional
requirement(s) for the system under study and hence convert the functional requirement(s) to a C/Java program:

Welcome to Introduction to Software Engineering: INF1512

I am the Latest System Analyst in Town
I am called: Dr. KIMBI
I am from: University of Yaounde I, Yaounde - Cameroon
The name of my Department is: Computer Science
My Specialty is: Software Engineering
My Gender is: Female
My date of birth is: 04/11/1980
 Feasibility Analysis
The feasibility analysis examines key aspects of the proposed project:

●
Technical Feasibility
●
Economic Feasibility
●
Organizational Feasibility

●
The technical feasibility (Can we build it?)
●
The economic feasibility (Will it provide business value?)
●
The organizational feasibility (If we build it, will it be used?)
●
Feasibility Analysis helps to determine helps the project
team to decide whether it is advisable to proceed with the
system development project.
●
The technical feasibility (Can we build it?): The first
technique in the feasibility analysis is to assess the
technical feasibility of the project, the extent to which
the system can be successfully designed, developed,
and installed by the development team. Technical
feasibility analysis is, in essence, a technical risk
analysis that strives to answer the question: “Can
we build it?”
●
The Economic feasibility: The second element of a
feasibility analysis is to perform an economic feasibility
analysis (also called a cost–benefit analysis). This attempts
to answer the question:
●
“Should we build the system?” Economic feasibility is
determined by identifying costs and benefits associated with
the system, assigning values to them, calculating future cash
flows, and measuring the financial worthiness of the project.
●
The organizational feasibility:The final technique used
for feasibility analysis is to assess the organizational
feasibility of the system: how well the system ultimately
will be accepted by its users and incorporated into the
ongoing operations of the organization.
●
organizational feasibility addresses the question: If we
build it, will it be used?
 Lecture Two: Requirements Elicitation

●
What is requirement elicitation process?
●
Requirements Elicitation Techniques
 What is Requirement Elicitation Process?
●
The software requirements elicitation process involves
identifying, analyzing, documenting, and managing
requirements to ensure they meet stakeholder needs and
align with project goals.
●
By having a clear understanding of software requirements,
businesses can ensure that the software they develop will
meet the needs of their users and deliver the expected
value.
 The requirement elicitation techniques include:
●
Gathering
Today’s Lecture Goals

●
Describe Requirements Elicitation Techniques
●
Be able to selecting the appropriate
Techniques
 Requirements elicitation Techniques

●
Brainstorming
●
Interviews
●
Joint Application Development (JAD)
●
Questionnaires
●
Document Analysis
●
Observation
●
Focus Group
●
Interface Analysis
●
Brainstorming: The requirement elicitation process
begins with brainstorming
 Lecture Three: Software Requirement Specification (SRS)
Document
●
Software Requirement Specification (SRS) Document
●
Components of SRS document
●
Properties of a good SRS document
●
Problems without a SRS document
 Software Requirement Specification (SRS) Document
The important parts of SRS document are:
●
Functional requirements of the system
●
Non-functional requirements of the system, and
●
Goals of implementation
 Properties of a good SRS document
●
The important properties of a good SRS document are the following:
●
Concise: The SRS document should be concise and at the same time
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
reduce readability and also
increase error possibilities.
●
Structured: It should be well-structured. A well-structured document is easy to
understand and modify. In practice, the SRS document undergoes several
revisions to cope up with the customer requirements. Often, the customer
requirements evolve over a period of time. Therefore, in order to make the
modifications to the SRS document easy, it is important to make the document
well-structured.
●
Black-box view: It should only specify what the system should do and refrain
fromstating how to do these. This means that the SRS document should specify the
external behavior of the system and not discuss the implementation issues. The SRS
document should view the system to be developed as black box, and should specify the
externally visible behavior of the system. For this reason, the SRS document is also
called the black-box specification of a system.
●
Response to undesired events: It should characterize acceptable responses to
undesired events. These are called system response to exceptional conditions.
●
Verifiable: All requirements of the system as documented in the SRS document should
be verifiable. This means that it should be possible to determine whether or not
requirements have been met in an implementation.
Problems without a SRS document

●
Without developing the SRS document, the system would not be
implemented according to customer needs. Software developers would not
know whether what they are developing exactly what the customer
requires.
Note: Requirements errors are very difficult to manage
●
Without SRS document, it will be very much difficult for the maintenance
engineers to understand the functionality of the system.
●
Difficulty in writing system documentation: It will be very much difficult
for user document writers to write the users’ manuals properly without
understanding the SRS document.
Problems with an unstructured specification

●
It would be very much difficult to understand that
document.
●
It would be very much difficult to modify that document.
●
The SRS document might be unambiguous and
inconsistent.