SEN 211

Introduction to Software
Engineering
 INSTRUCTOR
Prof. Dr Rashidah Funke Olanrewaju

Email: [email protected]

TEL NO: +601133097094

FACEBOOK: rashidah lanre
Domain Analysis and
Requirement
 4

▪ The process by which a software

engineer learns about the domain to
better understand the problem:
▪ The domain is the general field of
business or technology in which the
clients will use the software

Domain ▪ A domain expert is a person who has a

deep knowledge of the domain
Analysis
Benefits of performing domain
analysis:
• Faster development
• Better system
• Anticipation of extensions.
Domain Analysis document
A. Introduction
B. Glossary
C. General knowledge about the domain
D. Customers and users
E. The environment
F. Tasks and procedures currently performed
G. Competing software
H. Similarities to other domains
 A problem can be expressed as:
• A difficulty the users or
customers are facing, Or as an
opportunity that will result in
Defining the some benefit such as improved
Problem and productivity or sales.
the Scope • The solution to the problem
normally will entail developing
software
• A good problem statement is
short and succinct
7
 8

Defining the Scope

 ▪ It is a statement describing either
▪ 1) an aspect of what the proposed
system must do, or
▪ 2) a constraint on the system’s
development. l In either case it must
What is a contribute in some way towards
adequately solving the customer’s
Requirement
problem;
▪ the set of requirements as a whole
represents a negotiated agreement
among the stakeholders.
▪ A collection of requirements is a
requirements
9
document.
 What is Requirement…
1 Software Requirement
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

2 Requirement Engineering
The process to gather the software requirements from client, analyze and
document them is known as requirement engineering. l The goal of requirement
engineering is to develop and maintain sophisticated and descriptive ‘System
Requirements Specification’ document.

preencoded.png
 REQUIREMENT ENGINEERING

• Requirement engineering process is a four-step process, which includes

• Feasibility study
• Requirement gathering
• Software requirement specification
• Software requirement validation
 ▪ 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
Feasibility organization. This study analyzes whether the software

study 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

1. Software requirement specification (SRS) SRS is a document created by system analyst after the requirements are
collected from various stakeholders. L 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.

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

3. Software requirement elicitation is a process can be depicted using the following diagram: l requirements gathering
- the developers discuss with the client and end users and know their expectations from the software.
1. organizing requirements - the developers prioritize and arrange the requirements in order of importance, urgency and
convenience.
2. 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.
3. Documentation - all formal & informal, functional and non-functional requirements are documented and made
available for next phase processing
 ▪ Gathering software requirements is the foundation
of the entire software development project. Hence
they must be clear, correct and well-defined. L
▪ A complete Software Requirement Specifications
must be:
▪ Clear
▪ Correct

Software ▪ Consistent
▪ Coherent
Requirements ▪ Comprehensible
Characteristics ▪ Modifiable
▪ Verifiable
▪ Prioritized
▪ Unambiguous
▪ Traceable
▪ Credible source
 Types of Requirements 15

Requirements help to understand the behavior of a system,

which is described by various tasks of the system.
For example, some of the tasks of a system are to provide a
response to input values, determine the state of data objects,
and so on. Note that requirements are considered prior to the
development of the software.
The requirements, which are commonly considered, are
classified into three categories:
 16

Requirement Categories
Requirement
Categories

17
 18

Software Requirement
Specification
 SOFTWARE REQUIREMENTS
SPECIFICATION DOCUMENT
1.Complete: the SRS should include all the requirements for the software system, including both
functional and non-functional requirements.

2.Consistent: the SRS should be consistent in its use of terminology and formatting, and should be
free of contradictions.

3.Unambiguous: the SRSshould be clear and specific, and should avoid using vague or imprecise
language.

4.Traceable: the SRS should be traceable to other documents and artifacts, such as use cases and
user stories, to ensure that all requirements are being met.

5.Verifiable: the SRS should be verifiable, which means that the requirements can be tested and
validated to ensure that they are being met.

6. Modifiable: the SRS should be modifiable, so that it can be updated and changed as the
software development process progresses.

7.Prioritized: the SRS should prioritize requirements, so that the most important requirements are
addressed first.
 SOFTWARE REQUIREMENTS SPECIFICATION
DOCUMENT…
7. Testable: the SRS should be written in a way that allows the requirements to be tested and
validated.

8.High-level and low-level: the SRS should provide both high-level requirements (such as overall
system objectives) and low-level requirements (such as detailed functional requirements).

9.Relevant: the SRS should be relevant to the software system that is being developed, and should
not include unnecessary or irrelevant information.

10.Human-readable: the SRS should be written in a way that is easy for non-technical stakeholders
to understand and review.

11.Aligned with business goals: the SRS should be aligned with the overall business goals and
objectives of the organization, so that the software system meets the needs of the business.

12.Agile methodologies: agile methodologies, such as scrum and kanban, provide an iterative
approach to requirements capturing and validation, where requirements are captured and
validated in small chunks of functionality and feedback is gathered from the customer.
 21

Software Requirement
Validation
 Requirements validation These techniques help identify
techniques are essential and fix issues early in the
processes used to ensure that development process,
software requirements are reducing the risk of costly
complete, consistent, and errors later on. By thoroughly
accurately reflect what the validating requirements,
Requirement customer wants. teams can ensure that the final
product meets user needs and

validation expectations.

We typically use requirements

validation to check errors at the
initial phase of development as
the error may increase
excessive rework when
detected later in the
development process.
 REQUIREMENT VALIDATION
TECHNIQUES

1. Test Case Generation

2. Prototyping
3. Requirements Reviews
There are several techniques that 4. Automated Consistency
are used either individually or in Analysis
conjunction with other techniques 5. Walk-through
to check entire or part of the
system: 6. Simulation
7. Checklists for Validation