Chapter No 3

Software Engineering

Software Engineering
By: Saifullah shakir
For Nisar Ahamad saqib
Department of computer science
UNDERSTANDIN REQUIREMENTS

 Understanding the requirements of a problem is among the most

difficult tasks that face a software engineer. When you first think

about it, developing a clear understanding of requirements doesn’t

seem that hard. After all, doesn’t the customer know what is

required?
UNDERSTANDIN REQUIREMENTS: Continue

 What is it? Before you begin any technical work, it’s a good

idea to apply a set of requirements engineering tasks.

 These tasks lead to an understanding of what the business

impact of the software will be, what the customer wants, and
how end users will interact with the software.

 Who does it? Software engineers (sometimes referred to as

system engineers or “analysts” in the IT world) and other project

stakeholders (managers, customers, end users) all participate in
requirements engineering.
Software Requirements
 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

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.
Feasibility study – Continue
 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.
Feasibility study – Continue
 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.

SRS – Continue
 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 – Continue
 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.

Software Requirement Validation- Cont

 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

Requirement Elicitation Process

 Requirement elicitation process can be depicted using the

folloiwng diagram:
Requirement Elicitation Process- Continue

 Requirements gathering:

 The developers discuss with the client and end users and know

their expectations from the software.

Requirement Elicitation Process- Continue

 Organizing Requirements -

 The developers prioritize and arrange the requirements in

order of importance, urgency and convenience.

Requirement Elicitation Process- Continue

 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.
Continue
 The requirements come from various stakeholders. To remove

the ambiguity and conflicts, they are discussed for clarity and

correctness. Unrealistic requirements are compromised

reasonably.
Requirement Elicitation Process- Continue

 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.
Interviews – Continue

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

Prototyping – Continue
 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 Types
 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.
Functional Requirements - Continue
 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 Performance
 Logging Cost
Interoperability
 Storage
Flexibility
 Configuration Disaster recovery
Accessibility
Requirements
 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.